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

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

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...

@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.

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

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.

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.

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">
          <Item>
            <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>
              <Set name="resourceBase">.</Set>
            </New>
          </Item>
          <Item>
            <New class="org.eclipse.jetty.server.handler.DefaultHandler"/>
          </Item>
        </Array>
      </Set>
    </New>
  </Set>
</Configure>

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:

configurations

dependencies

task runJetty8(type: JavaExec)

EDIT: Sorry about the formatting!

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.

Marcello,

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.

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).

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

 
configurations { jetty9 }

repositories.mavenCentral()

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)
}

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

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...

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)

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)

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

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.

http://bit.ly/gradle-jetty

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.

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

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

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?

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".

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.

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

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!

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

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.