Deprecate jetty-runner now, present warnings when using it on Java 9+ Runtimes

[janbartel]

The jetty-runner jar is an uber-jar, containing pretty much all the classes that are necessary to run jetty on a webapp.

Once java-9 multi-release jars proliferate, we can't know which classes to include in the jar. There may be some support eventually from the shade plugin, but they are waiting for the spec to support multi-module executable jars: https://issues.apache.org/jira/browse/MSHADE-234

[joakime]

For now, perhaps a safety check in jetty-runner that detects the JVM version and System.exit(1) with a message indicating that it's incompatible with Java 9.

[janbartel]

For now, I've had to exclude module-info.class from the dependencies in the jetty-runner jar.
For now, none of the dependencies actually use multi-release jars, so this is a future problem, not an immediate one. Anyway, its a build-time problem, not a runtime problem.

[joakime]

Merged. Closed.

[gregw]

Can we revisit this deprecation?

Multi-Release jars should not prevent the creation of an "uber-jar", as we can just add all the versions and the JRE will select the correct version.

I know there may be some features that will never work well with the runner approach, but I still see some value in a single jar that can run a simple jetty setup.

[cor3000]

Is it really necessary to have a single "uber-jar"?
The (awesome) Runner class in combination with normal maven dependencies (even as separate jars) would be enough for efficient development environment setup/sharing. I really like the convenience of adding a single maven/gradle dependency and being able to just run a main class with command line options.

[joakime]

@cor3000 what you just described is what start.jar from jetty-start does.

[joakime]

@cor3000 you also described XmlConfiguration from jetty-xml as well.

[cor3000]

I guess my scenario is much simpler,I don't really need complex configuration for simple example/test/debug projects, e.g. when debugging issues between different versions.
It's invaluable to be able to change a container version by just flipping a dependency-version (without having to download/install a jetty/tomcat version) and have a different container available (as said previously this is independent of uber-jar or separate transitive dependencies).

This also allow IDE-plugin independent debugging using the bleeding edge version without having to wait for plugin providers.

I also liked the simple command line parameters Runner.java class provides (btw mostly compatible to webapp-runner which I use in parallel to compare results/behavior between popular containers)

Those allowed a simple IDE runnable config:

main-class: org.eclipse.jetty.runner.Runner
program arguments: --port 8080 src/main/webapp
working directory: .../projects/mywebapp
use classpath of: mywebapp   (where jetty-runner is a test dependency)

accordingly for webapp-runner (tomcat)

main-class: webapp.runner.launch.Main
program arguments: --port 8080 src/main/webapp
working directory: .../projects/mywebapp
use classpath of: mywebapp   (where webapp-runner is a test dependency)

similarly when sharing a runnable example project with a customer

just ask them to unzip and execute a command (and everything downloads/starts automagically)

./gradlew startJettyRunner

the gradle.build just needs a simple execute task:

//launch Jetty using jetty-runner (e.g.)
task startJettyRunner(type: JavaExec) {
	classpath = sourceSets.jettyRunner.runtimeClasspath
	main 'org.eclipse.jetty.runner.Runner'
	args '--port', '8080', 'src/main/webapp'
}

Should I post a separate Feature Request to preserve the Runner.java class, with required transitive dependencies. Because it's really useful.

Maybe I just missed something in the documentation how to get similar convenient results.

[joakime]

Here's an example with jetty-home artifact ...

https://github.com/jetty-project/jetty-websocket-example

Command line to execute the built project is ...

$ java -jar /path/to/jetty-home/start.jar 

All of the magic is in your start.ini

[cor3000]

I tried the example and for my general usage it doesn't make things simpler:
I still need to download jetty into a jetty-home folder - making it harder to explain this kind of setup to a user/customer without jetty experience.
It requires to package a .war-file making the development round-trip slower, if only single files are changed.

I guess I'll just have to switch to the various specific plugins (maven/gretty/run-jetty-run/eclipse/intellij) once jetty-runner is removed eventually. Or try to fork/preserve the jetty-runner for my specific purposes.

I'd be happy to discuss the advantages (IMO) in a separate channel/chat to avoid distracting from the original topic.

Thanks for the responsiveness! Much appreciated.

[stale]

This issue has been automatically marked as stale because it has been a full year without activit. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been closed due to it having no activity.

[lviggiano]

I am using jetty-runner, with legacy war/webapp folders, and I find it very useful.
If you could revisit the deprecation and remove the warning, would be appreciated for this specific use case.

[joakime]

@lviggiano have you tried jetty-home?

[cor3000]

jetty-home... never noticed that one. What does it do? Or where can I read about it?
I didn't find it mentioned anywhere and searching for "jetty-home" just gives unrelated results

[WalkerWatch]

@cor3000 Jetty-Home is just the Jetty distribution sans any of the example webapps and documentation.

https://www.eclipse.org/jetty/documentation/current/quick-start-getting-started.html#jetty-home-downloading

[cor3000]

thanks for adding a link... still this doesn't restore the simplicity of the jetty-runner Runner class. I still need to tell a customer to download, unzip a package, while this could be happening perfectly via maven dependencies.
I also prefer the Runner class over the maven-jetty-plugin because of it's faster startup time and simpler debugging capabilities (no need to launch/debug a maven stacktrace).

Is there any chance to preserve this class? Even if the jetty-runner.jar is removed?
Or is this a technical obligation holding you back from future innovations.
(I don't really need this uber jar, just the command line options provided by the Runner class are most convenient/simple to explain to the less experienced users.)

My alternatives are webapp-runner (using tomcat), or Spring boot which again offers this kind of development experience, however at the cost of slower startup time (tomcat) or added complexity (spring boot).
Or of course I can implement my own embedded jetty Runner class (forking/duplicating the existing code, which seems a bit pointless).

In any case thanks for a great product/tool and being responsive to comments.

[gregw]

I have reopened #4562 which removed the runner. I think we should be looking at using jlink to create a Runner executable rather that deleting this functionality.
I wont reopen this issue - we can trace progress in the other issue.

[joakime]

I have reopened #4562 which removed the runner. I think we should be looking at using jlink to create a Runner executable rather that deleting this functionality.
I wont reopen this issue - we can trace progress in the other issue.

I like the jlink approach, it would also allow us to prove our JPMS layers in yet another way.
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)

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.

[gregw]

I'll respond in #4562

[csaltos]

What a pity such a powerful web server is unable to "just" start programmatically for local development support and other cases ... governing all that code and have limitations is hard