[GRADLE-671] Option to fork the jetty process Created: 01/Oct/09  Updated: 16/Jan/17  Resolved: 16/Jan/17

Status: Resolved
Project: Gradle
Affects Version/s: 0.7, 0.8
Fix Version/s: None

Type: New Feature
Reporter: Jason Porter Assignee: Unassigned
Resolution: Won't Fix Votes: 2


 Description   

There is currently the daemon option which stops the jetty process from blocking, but doesn't actually fork the process. When the build script finishes the server is also terminated. The ability to fork the jetty process would help development time as the developer can start the server forked and continue to make changes. Jetty can then pick up changes to the war or classes and reload those changes effectively creating something similar to a hot deploy. Eliminating (or at least cutting down) the deploy phase of JEE development is always a plus.



 Comments   
Comment by Jason Porter [ 02/Oct/09 ]

According to the jetty folks this would have to be done via gradle calling Jetty. In Jetty7 it's possible, but not in Jetty 6:

11:56:55 < lightguard_jp> When using the embedded jetty (calling the APIs directly) is there a way to spawn the server process into a different thread or JVM?
11:59:38 <@jmcconnell> lightguard_jp: via programmatic usage of jetty-start I think so
11:59:57 <@jmcconnell> but you won't be doing Server server = new Server()
12:00:03 < lightguard_jp> jmcconnell: Hm, which class is that? And I'm in jetty6 btw
12:00:15 <@jmcconnell> you wuld be processing jetty.xml via XMLConfiguration
12:00:18 <@jmcconnell> ah, not in jetty6
12:00:33 <@jmcconnell> that support was added not long ago in jetty7
12:00:44 < lightguard_jp> Drat.
12:00:51 < lightguard_jp> How stable is 7?
12:01:17 <@jmcconnell> i staged the final release of jetty7.0.0.v20091001 yesterday
12:01:28 <@jmcconnell> it is very stable
12:01:53 <@jmcconnell> jetty6 is in maintenance now
12:02:20 < lightguard_jp> Anything major in 7 like new spec support or anything like that?
12:02:41 <@jmcconnell> packaging changes and security refactored to support jaspi
12:03:18 < lightguard_jp> Stuff like Servlet 3.0 is in 8, correct?
12:03:19 <@jmcconnell> jetty8 will be out shortly following jetty7 initial release with support for servlet 3.0
12:03:24 <@jmcconnell> yes
12:03:24 < lightguard_jp> lol
12:03:31 < lightguard_jp> Cool, thanks.
12:03:40 <@jmcconnell> jetty8 is a thin wrapper over 7
12:03:55 <@jmcconnell> jetty7 is really solid imo, going to be a good release
12:04:13 <@jmcconnell> easier to work with, the package changes have been really helpful in clarity
12:04:57 <@jmcconnell> RC6 is published to maven central and is effectivelt the same as the staged final jetty7 release
12:05:07 <@jmcconnell> well 7.0.0
12:05:36 <@jmcconnell> 7.0.1 has some cool stuff in it as well, centralized logging and webapp verification

Comment by Jason Porter [ 22/Apr/10 ]

We may want to wait on this, or we'd have to upgrade to a newer version of Jetty. Hans if you're in IRC we can discuss this and the glassfish plugin I've been toying with.

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 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 11:35:52 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.