Jetty @ Eclipse – Jetty7 and Jetty8 (and Jetty6)

I have had a lot of inquiries about what is going on with the latest versions of jetty being talked about and what they mean to our users so I figured I would give clearing it up a shot.
Greg has recently updated the about page on the jetty eclipse site with some very handy historical (and bleeding edge current) information. Throughout the history of java, jetty has been somewhat a fixture as you can see in the table below, paying particular attention to the rather amusing Status column.

What we see is that jetty has done a pretty solid of performing its major version updates with the updating of the servlet specification, also updating the JDK and JSP versions accordingly. Jetty was well on that track with version 7.0 previously being the first pre-releases of jetty with support for the servlet 3.0 specification, but that has been derailed a bit with the move to eclipse coupled with the postponing of the servlet 3.0 spec until at least the September time frame. Jetty7 has been under development for going on a year next month and it is hardly fair to delay the release of jetty7 and all of the work that has gone on with it until the latter part of the year, much less hold off on released eclipse jetty bundles that long. Jetty pre-release artifacts have been available for a long time and we have been unable to start the release process on it at all because we have been chasing the updated servlet spec. Now that the core of jetty is at Eclipse we need to start the jetty release process as soon as possible to get a stable release available for our users that contains all of the latest and greatest improvements to both packaging and code.
We have taken the opportunity to reorganize the packaging of jetty a bit in the migration of jetty to eclipse and the culmination of these changes are available in the first of our jetty milestone releases 7.0.0.M0 which went out last week. Two of the primary changes from previous jetty7 pre-releases are the package changes and the artifact decomposition. The packaging changes consisted of the obvious org.mortbay -> org.eclipse changes but also include the alignment of maven artifact and java package references. Whereas before in jetty6 the org.mortbay.jetty:jetty-util package may have included classes in org.mortbay.component, org.mortbay.thread and org.mortbay.util packages in jetty7 and future versions of jetty will adhere to the convention of all classes in the org.eclipse.jetty:jetty-util artifact being nested under org.eclipse.util package space. This makes using the existing osgi maven tooling ever so much easier to work with and allows us to work in osgi classloaders without a lot of jury-rigging. In fact we were able to pull out the majority of the custom configuration on the org.apache.felix:maven-bundle-plugin and use the default configuration.
We were also able to wire in generic support for version ranges in the Import-Package: and Export-Package: manifest entries such that the bundles are automatically configured for [7.0,8) which should allow us better future support for working in osgi and eclipse (more on this in a future post covering the osgi http service and some jetty eclipse plugins I have been working on).
As to the artifact decomposition I mentioned, this has to do with cleaning up the transitive dependencies for the using jetty. Jetty is not simply a http server with servlet engine, we also have a robust jetty-client implementation that leverages the solid async implementation under the covers of the jetty server (the soup that lets jetty server scale up to 20k connections). The origin of the client was simple, we needed something on the client side that we could scale up to levels needed to test the server, so jetty-client was born. It is now being used in many interesting places, from proxy server setups to backing the artifact downloads within the maven mercury project. Anyway, the interesting annoyance the was in jetty6 regarding the jetty-client was that it has dependencies on the jetty-server and the servlet-api. Which makes sense given its origins, but was still bothersome to take on another few hundred k of dependencies when all you wanted to use was the client. This has been addressed by the creation of the jetty-io and jetty-http artifacts in jetty7 at eclipse which are shared dependencies of both the jetty-client and the jetty-server and the servlet-api is not longer a dependency of the client. Pretty straight forward stuff but still very important.
If you are one of the people that has been tracking the development of the org.mortbay flavor of jetty7, the jetty7 that is located at eclipse should not be fearful as the changes are not overwhelmingly complex at all. Most of the porting work I have done module wise is taken care of in literally minutes and if you have dependencies on the servlet 3.0 api then jetty8 will be addressing those issues in short order. Jetty7 and Jetty8 will be fundamentally the same codebases with jetty8 containing a thin layer of implementation for the servlet 3.0 api changes on top of the already stable jetty7 core codebase. Jetty7 has been stable and ready to being the release process for literally months while we anticipated the move to eclipse and its packaging changes and the release of the servlet 3.0 api. The only thing holding us back on its release has been the eclipse move and the servlet spec release, heck our plans had originally been to release 7.0 on the day of or the day after the 3.0 spec was released anyway. So now we are in the position to get jetty7 released with the servlet 2.5 support that has been supported since its inception last spring and allow our users to start the process of migrating to the latest stable codebase without the rush to support servlet 3.0 spec.
In addition the forthcoming jetty8 milestone or pre-releases will be taking the place of the jetty7 pre-releases that previously allowed intrepid folks the ability to work with the developing servlet 3.0 api.
Lastly, now that jetty7 and jetty8 are announced and the path for their release should be clearer to all we will start shifting the jetty6 codebase towards a slower maintenance release cycle as we focus on getting jetty7 into the stable category on the chart above. Maybe then we can update the about page again and make jetty5 ‘venerable’ or ‘respected’ and jetty6 ‘mature’.