The trunk of jetty has undergone some substantial changes over the last couple of weeks.  In addition to jetty 7 now requiring a minimum version of jdk 1.5 and the default inclusion of the early servlet 3.0 spec, there have been a number of structural changes a bit more near and dear to my heart.  It leverages a bit more maven2!

The Jetty open source project is really broken up into two separate chunks, the jetty project and the jetty contrib project which are sourced out of separate svn repositories at The Codehaus.  A brief list of the build oriented changes that have gone on are:

  • creation of the jetty-parent artifact which serves as the administrative parent for both projects
  • several non-core artifacts were moved to the contrib project
  • all source artifacts have been moved under the modules directory
  • jetty-contrib is still sourced into the main jetty checkout but is not built by default
  • ‘all-modules’ profile added which builds the jetty-contrib modules and the website
  • ‘codehaus-release’ profile added which allows for staging of jetty release artifacts for review
  • -source and -javadoc classifier artifacts are built and released now (for easily pulling up source on the relevant object in your favorite editor)
  • jetty-assembly artifact which bundles the jetty releases into .zip, .tgz and .bz2 formats and places them into the repository
  • jetty releases make use of the maven-release-plugin now!

Now I am sure that a lot of people couldn’t really care less about many of these things, but for anyone that uses maven extensively they will recognize [hopefully] that the more any given project leverages the conventions of maven, the less time it will take someone already familiar with maven to get up to speed with that project.  Its one of the fundamental reasons maven was created to address that problem at apache. 

What it means here is that it is that easier for new contributors to jetty to get going.  Which is a good thing since one of my goals with much of this restructure was to make it easier for people to contribute.  The jetty-contrib project has a lower barrier of entry for commit privileges then the jetty core but still allows for extreme flexibility and serves in many ways as a sandbox environment.  When it comes to release time for jetty, we can pick and choose easily in the contrib parent what modules will be built and released.  In addition, as part of the ongoing physical (and build) decoupling of jetty and jetty-contrib we make it easier to release portions of contrib against any given official jetty release (from this point forward).

Anyway, I wanted to comment a bit on what has been ongoing with the jetty7 trunk as of late and let people know about the jetty-7.0.0pre0 release!

You can get an assembly of jetty-7.0.0pre0 here!

Oh! and in case you are totally behind on things, the jetty user and dev lists have moved from sourceforge to codehaus as well!  See the new administrative pom for the subscription locations!


3 Comments

Jan Bartel · 22/04/2008 at 21:48

Way to go Jesse! The jetty project layout really needed some attention, so thanks!

Jan

Anonymous · 23/04/2008 at 17:57

I’m curious, does Jetty yet have a consistent method to lie to a webapp about what port, hostname and/or scheme is being used? I’ve got a couple apps deployed on Tomcat behind an SSL-accelerator and would prefer to use Jetty but can’t because I can’t override those request values.

Jan Bartel · 24/04/2008 at 03:44

You can extend the SelectChannelConnector and implement the customize(Endpoint,Request) method. The request is writable inside that method, so you can set up the fields on it.

cheers
Jan

Comments are closed.