[GRADLE-1956] update jetty plugin to current jetty Created: 24/Nov/11  Updated: 16/Jan/17  Resolved: 16/Jan/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Improvement
Reporter: Zsolt Kúti Assignee: Unassigned
Resolution: Won't Fix Votes: 34


At present jetty plugin supports jetty 6.1, when current is at 7.x. This would make it possible to use the plugin for developments where websockets are involved.
Thank you!

Comment by Pavol Slany [ 01/Aug/12 ]

Please, this improvement is important. More new technologies not working with Jetty6 (e.g.: JSF2). When will be done?

Comment by gururaj [ 28/Aug/12 ]

A much better option would be to provide a way to switch between different versions of Jetty (6.x - 7.x - 8.x)

Comment by Stig Brautaset [ 22/Nov/12 ]

Current is now 8.x, with 9.0 being imminent. Any chance of an upgrade? Anything I can do to help? I'm assuming naively bumping jetty dependencies is unlikely to work...

Comment by Adam Murdoch [ 22/Nov/12 ]

@Stig, there are 3 options we could take with the jetty plugin:

1. Simply change the version that we bundle from Jetty 6 to Jetty 8 (or 9).
2. Rework the 'jetty' plugin so that you can specify which version of Jetty you'd like, and this Jetty version is downloaded from a repository.
3. Replace the 'jetty' plugin with a new 'web-container' plugin, that uses Arquillian (or perhaps Cargo) to embed and/or manage and/or deploy to any of the supported web containers.

Both #1 and #2 would be breaking changes to some degree. We could probably manage to do #2 in a more-or-less non-breaking way.

However, our preference is to go with #3, to address a bunch of short-comings with the Jetty plugin, such only working with Jetty 6, not being able to deploy multiple web applications, no decent handling for integration testing, and so on.

Would you be interested in helping with this? If so, let us know on the dev mailing list and we can put together a specification for this work. If not, that's fine. We do intend to improve things with the Jetty plugin, it's just a matter of priorities.

Comment by Oscar Norlander [ 23/Nov/12 ]

I say #3 after looking at Arquillian. It is container agnostic and I really need to be able to deploy multiple web applications.

Comment by Stig Brautaset [ 23/Nov/12 ]

I'm assuming this would mean developing a new Arquillian plugin and deprecate the jetty one? It sounds like the best approach overall. I'm afraid I cannot justify spending a lot of time on this, as we've decided to go with Tomcat instead. The third-party tomcat plugin lets us use tomcat7 which supports servlet 3, which is why we were trying to use a recent Jetty in the first place.

Comment by Ryan Shillington [ 04/Jan/13 ]

This is getting in my way too. I vote for #1. Jetty 6 and 8 aren't that different, from what I've seen so far. Just replace it with Jetty 8, doc it in the release notes, and I suspect you're done.

Comment by Marcello Nuccio [ 17/Apr/13 ]

Here is how I am running/stopping Jetty-9 from gradle for E2E tests (sorry if this is not useful information, I am a novice). As an example, I have included an XML configuration for the context handlers. The XML file is NOT needed, but can be easier to use for non trivial settings.

WARNING: you need to use the Gradle daemon for this to work!!!

==== build.gradle ===

ext {
  jettyVersion = '9.0.3.v20130506'
  jettyStop = '9999'
  jettyPort = '8003'

configurations { jettyServer }

dependencies {
  jettyServer group: 'org.eclipse.jetty', name: 'jetty-server', version: jettyVersion
  jettyServer group: 'org.eclipse.jetty', name: 'jetty-ant', version: jettyVersion

task jettyRun << {
  ant.taskdef(resource: 'tasks.properties', classpath: configurations.jettyServer.asPath)
  ant.'jetty.run'(daemon: true, stopPort: jettyStop, stopKey: jettyStop, jettyPort: jettyPort, jettyXml: 'jetty.xml')

task jettyStop << {
  ant.taskdef(resource: 'tasks.properties', classpath: configurations.jettyServer.asPath)
  ant.'jetty.stop'(stopWait: '1', stopPort: jettyStop, stopKey: jettyStop)

==== jetty.xml ====

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure id="JettyServer" class="org.eclipse.jetty.server.Server">
  <Set name="handler">
    <New class="org.eclipse.jetty.server.handler.HandlerCollection">
      <Set name="handlers">
        <Array type="org.eclipse.jetty.server.Handler">
            <New class="org.eclipse.jetty.server.handler.ResourceHandler">
              <Set name="directoriesListed">true</Set>
              <Set name="welcomeFiles">
                <Array type="String"><Item>index.html</Item></Array>
              <Set name="resourceBase">.</Set>
            <New class="org.eclipse.jetty.server.handler.DefaultHandler"/>
Comment by Randeep Dhaliwal [ 18/Apr/13 ]

Hi guys,

I'm just posting my solution to getting Jetty 8 running in gradle 1.5/java 6, hopefully someone else can find it useful:


{ jetty8 }


{ jetty8 "org.mortbay.jetty:jetty-runner:8.1.10.v20130312" }

task runJetty8(type: JavaExec)

{ main = "org.mortbay.jetty.runner.Runner" args = ['--port', '8001', '--classes', "additional/optional/classes/to/add/filepath", '--path', '/context-path', "warlocation.war"] classpath configurations.jetty8 }

EDIT: Sorry about the formatting!

Comment by Marcello Nuccio [ 19/Apr/13 ]

Thanks Randeep. The reasons why I am not using jetty-runner are:

  • I have not found how to run the server in background (daemon mode).
  • when I use your tecnique with Jetty 9.0.1.v20130408, I get the following error:
    Exception in thread "main" java.lang.SecurityException: Invalid signature file digest for Manifest main attributes

Using the Ant tasks provided with Jetty, every thing works fine with every version and I can use daemon mode.

Comment by Randeep Dhaliwal [ 20/Apr/13 ]


I actually really like your implementation as well, but we are restricted to using Java 6, and Jetty 9 only seems to work on Java 7 which is unfortunate.

Comment by Marcello Nuccio [ 21/Apr/13 ]

Randeep, as I have said, I am using the tecnique that I have described because it works with every version of Jetty. You only need to change jettyVersion AND the XML configuration file (it changed with jetty-9).

Comment by taichi [ 08/May/13 ]

Hey, I try to refine yours code.
my solution doesn't use xml configurations

configurations { jetty9 }


dependencies.jetty9 'org.eclipse.jetty:jetty-ant:9.0.2.v20130417'
ant {
	taskdef(name: 'jettyRun', classname: 'org.eclipse.jetty.ant.JettyRunTask', classpath: configurations.jetty9.asPath)
	taskdef(name: 'jettyStop', classname: 'org.eclipse.jetty.ant.JettyStopTask', classpath: configurations.jetty9.asPath)
project.ext {
	contextPath = '/'
	port = 8080
	stopPort = stopKey = 9999
task jettyRun << {
	ant.jettyRun(jettyPort: project.ext.port, scanIntervalSeconds: 3) {
		webApp(war: webAppDir, contextPath: project.ext.contextPath, extraClasspath: configurations.compile.asPath)
task jettyRunWar(dependsOn: war) << {
	ant.jettyRun(jettyPort: project.ext.port) {
		webApp(war: war.archivePath, contextPath: project.ext.contextPath)
task jettyStart(dependsOn: war) << {
	ant.jettyRun(daemon: true, jettyPort: project.ext.port, stopPort: project.ext.stopPort, stopKey: project.ext.stopKey) {
		webApp(war: war.archivePath, contextPath: project.ext.contextPath)
task jettyStop << {
	ant.jettyStop(stopWait: 1, stopPort: project.ext.stopPort, stopKey: project.ext.stopKey)
Comment by Cho, seokgyu [ 22/May/13 ]

Thank you. Marcello and taichi. now I can go to sleep.

Comment by Nikita Salnikov-Tarnovski [ 24/Jul/13 ]

Hi. I really want to upgrade Jetty plugin to Jetty8. But I think I need your approval for upgrading Gradle's plugin and potentially breaking existing builds. If it is NOT OK for you, then I just fork this one plugin for myself IF I understand, how to extract existing Gradle plugin to standalone project...

Comment by Michael Snell [ 25/Jul/13 ]

Hi All - I tried taichi's workaround (thanks for posting this), but found a few problems which mean that only "jettyRunWar" is usable:

1. "jettyRun" doesn't work at all due to a classpath issue (I need to investigate further, might be my fault)
2. Stdout and info logging from the servlet are lost unless you override the Gradle logging levels:

task jettyRunWar(dependsOn: war) {
    logging.level = LogLevel.INFO
} << {
    ant.jettyRun(jettyPort: project.ext.port) {
        webApp(war: war.archivePath, contextPath: project.ext.contextPath)

3. "jettyStart" doesn't work unless in daemon mode (as stated by by Marcello Nuccio), but then logging no longer works - this is another bug GRADLE-2273. Also, having to use daemon mode is a problem when running eg integration tests on a continuous integration agent.

I also had a look at the Cargo and Arquillian plugins, but couldn't find an example of how to set up what I want - just to be able to run a task that will start up an embedded Jetty with my unassembled web app deployed and hot deployment of changes (as the Maven jetty:run command does)

Comment by Shahzada Hatim [ 27/Jul/13 ]

Hey, thanks Marcello, taichi and Michael

I also cannot make jettyRun to work from taichi's solution (jettyWarRun works)

But I suspect the culprit might be the folloing log lins

[ant:jettyRun] 2013-07-28 04:21:57.767: Starting web application file:/Users/hatim/neo4neodb/src/main/webapp/WEB-INF/web.xml

It seems that I am being asked for web.xml even for my servlet 3.0 no-xml based project. I came from this stackoverflow question http://stackoverflow.com/questions/17370176/webapplicationinitializer-is-not-launched-on-jettyselenium

And the first suggestion they give is to use web.xml (which I wanted to avoid)

Comment by Daisuke Miyamoto [ 02/Sep/13 ]

Taichi's solution works only in Windows environment.

FileCollection.asPath returns platform-specific path.
In Windows environment the path separator is semicolon, and is colon in Linux/MacOSX.

WebAppContext#setExtraClasspath argument requests "Comma or semicolon separated path of filenames or URLs."

Following workaround forces the path separator to comma: https://gist.github.com/dai0304/6388289

Comment by Andreas Sahlbach [ 06/Feb/14 ]

Take a look at my plugin for gradle based on jetty 9 and above. It has similar features as the original plugin. However it cannot change the fact, that you need java 1.7 to use a jetty 9.


Comment by gururaj [ 06/Feb/14 ]

Not sure if still looking for jetty plugin - https://github.com/akhikhl/gretty - this provides support for different versions of jetty and also supports inplace deployment.

Comment by Mike Richardson [ 23/May/14 ]

I agree with guraraj and highly recommend the Gretty plugin, available on github and written by Andrey Hihlovskiy. It's regularly updated, very well documented, and written by someone who is well versed with Gradle and Jetty. The documentation will help you get up and going in no time. https://github.com/akhikhl/gretty

Comment by Mike Richardson [ 08/Jul/14 ]

I vote for solution#1. An imperfect solution is a far superior option than having an open ticket for 2 years.

Comment by Jack C. Holt [ 18/Aug/14 ]

I also vote for solution #1. It's high time a solution is found for this. Deprecate the current implementation and move on. Jetty 6.1 is ancient and makes the Jetty plugin mostly useless for what I need to do (like Servlet 3.0 features).

Until this happens I will be using Andreas Sahlbach's JettyEclipse plugin (http://bit.ly/gradle-jetty) or gretty. However, having to look outside of standard plugins defeats the point of configuration by convention. I should be able to just "apply plugin: 'jetty'" and be done with it for most purposes.

And by the way, could someone enlighten me why compatiblity with Java 1.6- is still a major consideration? Java 8 has been around for a while now. Why are people still using Java 6 at this point?

Comment by Andrey Hihlovskiy [ 02/Oct/14 ]

Regarding Java 1.6: yes, it is still a major consideration. There are large organizations that are reluctant to upgrading things, when they "just work".

Comment by Byron Palmer [ 05/Aug/15 ]

I would suggest the following so as not to break organizations that can't seem to upgrade.

Add in the ability to pick the jetty version to use, default it to the old version but give people a chance to pick the right version for them. The plugin would then download the correct version to use. You already have the dependency management to deal with getting the correct version. I don't see this as that much of something to worry about. The only consideration is that the Java runtime version needs to be capable of running the Jetty version selected. Otherwise it will just throw an error that may be difficult to diagnose.

Comment by Misagh Moayyed [ 30/Nov/15 ]

Are there any plans to upgrade this plugin for the next gradle version? The gretty plugin seems somewhat dead as far as dev goes.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Jochen Kemnade [ 16/Nov/16 ]

Since the jetty plugin is deprecated, I guess this is a WONTFIX.

Comment by Benjamin Muschko [ 16/Jan/17 ]

The Jetty plugin has been deprecated and is scheduled to be removed with Gradle 4.0. We are not going to work on this issue anymore.

Generated at Wed Jun 30 12:08:53 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.