Remove deprecated jetty-runner

[olamy]

No description provided.

[joakime]

See #1905

[gregw]

Why was this deprecated and removed?

[olamy]

this big jar is a very big mess in the java 11 / jpms world.
I don't mind get it back but we must make it very clear it may not work well in such environment....

[gregw]

I expect we will get complaints that it is gone. I think having a single jar that can test run servlets/webapps is a good idea and we should think about how to do that in a JPMS world? In fact isn't one of the main reasons for JPMS is to make executable jars with jlink?

So instead of deleting this module, how about we update it to jlink Runner as a JPMS executable?

[olamy]

@gregw sounds a good idea to try! let me try that
but we now have to change the issue title :)

[olamy]

@joakime while investigating this I discover we're still packaging jetty-all as part of eclipse-release is intended or some leftover from 9.4 branch

[gregw]

I think that is a separate... but similar issue. The aggregate jars have been used by many, but again we need to determine how they work in a JPMS world. Let's see how jlink works for the runner and then see if we still need jetty-all

[gregw]

In #1905 @joakime asked:

Are you thinking that this is something we ship/deploy? or something we document how to do? (Make your own jetty-runner with exactly what you need)
I think it has to be something we ship/deploy as the Runner class has a contract/usage and user base that would be hard to replicate in a document only approach. However, I'm not sure that jlink executables can be shipped/deployed via maven central? So perhaps it is a combination of shipping enough that can be used to generate the executable?

Another approach is to enhance jetty-start to support a single jetty-home jar that could satisfy jetty-runner and jetty-all use cases as well.

So something like:

java -jar $JETTY_HOME/start.jar --war mywebap.war

Not a bad idea as that will allow a war to be run anywhere, without creating a base, so long as there is a distro available. The only issue I see is that Runner has at least 12 command line options available to configure the server and we would not really want to pollute start.jar with all of those.... but perhaps a runner module could do that? Something like:

java -jar $JETTY_HOME/start.jar --module=runner [ server opts] [[ context opts] context ...]

Hmmm maybe we make --war a short cut for --module=runner, but will still be difficult to separate out the start args from those passed to the runner module.

I think it is worth considering this in parallel.

[joakime]

I was actually thinking of bundling up ALL of what's in jetty-home-<ver>.tar.gz into a single jar file.
There would be no need to unpack jetty-home-10.0.0.jar, and only those classes associated with the selected jetty module are actually loaded by the jetty-start classloader. (note: this is NOT a uber jar, that's not what i'm proposing)

So for jetty-runner replacement ...

$ java jar $JETTY_HOME/jetty-home-10.0.0.jar --war mywebapp.war

or for jetty-all replacement for documentation reasons ...

$ java -jar $JETTY_HOME/jetty-home-10.0.0.jar --compile MyExample.java
$ java -jar $JETTY_HOME/jetty-home-10.0.0.jar --run MyExample.class

I would like to NOT have a traditional uber jar, nor have 3 separate projects (jetty-home, jetty-all, jetty-runner) for essentially the same thing (starting jetty).

[gregw]

@joakime that kind of thing used to be very difficult to achieve because jars inside jars just didn't work very well and you needed to unpack to make it work. Perhaps jar handling is better now?

The idea of the distro itself (jetty-home.jar) being both an archive and an executable is kind of cool - specially if it gave access to the Runner class? Worth investigating in parallel.

[olamy]

jetty-runner restored

[olamy]

we do not remove it

[csaltos]

Making a start jar file cannot be more difficult than making the actual web server, can it? ... well, it looks like YES 😢

[gregw]

@csaltos JPMS has made it very difficult to build a single jar that works for many different configurations. Building a single jar for a specific configuration is easy, but trying to be all things to all users is hard. Hence we assemble runtimes from start.jar.

I have opened #10854 to see if there is more we can do. What version of jetty are you using?