Jetty has moved!
Jetty is a project at the Eclipse Foundation.
Jetty Powered:
Contact the core Jetty developers at
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Jetty Version Information


This page contains information related to multiple versions of Jetty. Please select the version of jetty you are using.

Jetty 6
Jetty 7

Jetty6 Release Process

Currently the release procedure for Jetty6 is a mostly manual operation:

  1. Verify that there are no blocking issues on the lists or in JIRA.
  2. Update VERSION.txt with the release number and date and commit to trunk.
  3. Create tags in jetty and jetty-contrib repositories with a copy from trunk (or the branch used as a basis for the release):
    svn cp -m 'release x.y.z'
    svn cp -m 'release x.y.z'
  4. Checkout tag:
    svn co
  5. Edit svn:externals to include contrib tag:
    cd jetty-x.y.z
    svn propedit svn:externals .  # change trunk to tags/jetty-x.y.z
    rm -fr contrib
    svn up
  6. Update the poms and other files to change 6.1-SNAPSHOT to x.y.z:
    bin/ x.y.z
    The diff in the script will sometimes need to be updated. Recursive
    greps should be done to make sure that all 6.1-SNAPSHOT references have been updated.
  7. Commit the changes to the tag:
    svn commit -m 'release x.y.z'
    svn commit -m 'release x.y.z' contrib
  8. build the release
    mvn install
    cd project-website
    mvn install
    cd ..
    #build the release bundles:
    bin/ .
    This builds a binary and source zip bundle in the parent directory.
    #build additional bundles and jars:
    NOTE: you will need the rpmbuild utility installed in order to build the rpm module.
    cd contrib/maven-beanshell-plugin
    mvn install
    cd contrib/rpm
    mvn install
    cd ../jetty-ant
    mvn install
    cd ../../extra/jboss
    mvn -Djboss.home=<your jboss install dir> install
    cd ../..
    NOTE: please also use jdk1.4 to build the jboss sar, as this will use jsp-2.0, which some versions of jboss seem to need in order to run it's web console correctly.
  9. Tell somebody else about the tag and ask them to check it out and test it!
  10. Test the tag yourself in situ (if you need to fix anything you will need to completely clean and go back to first build step).
  11. Test the built bundle
  12. Test the RPM
  13. Wait a day for other feedback from other testers
  14. Create directories in distribution directories and copy artifacts to codehaus (webdav to ) and mortbay (scp to The artifacts to upload are:
    • jetty-ant-x.y.z.jar
    • jetty6-*-x.y.z.noarch.rpm
    • jetty-x.y.z-jboss-p.q.y.GA-jsp-2.1.sar
    mvn deploy
  16. Tell everybody: blogs, lists, etc.
  17. Wait for the bug reports to come in

Jetty7 Release Process

The jetty7 release process leverages many elements of maven2 including the maven-release-plugin for a more automated release experience. The jetty7 release process is currently composed of a couple of different phases which are explained below.

Getting Started!

The jetty7 build has a couple of important enhancements that require a bit of configuration on the users part to use. First and foremost among them is the ability to stage the artifacts of a release. In order to do this a profile is automatically inserted into the runtime upon use of the release plugin. A special property is defined called ${deploy.altRepository} which specifies where the deployed artifacts will be sent. This property is governed by the users .m2/settings.xml file in a profile. Just comment in the entry for which corresponds to where the artifacts are to go.

settings.xml fragment

You will also have to add in the relevant server definition in the settings.xml file as well. These definitions don't need to commented in or out, they can exist peacefully together with all the other server entries in the settings.xml file.

settings.xml fragment


The first portion of the release is to release the portion of the build located in the jetty/trunk svn. The -DautoVersionSubmodules=true portion will skip the versioning of every single artifact in the build which is quite tedious as generally you share the same version of all artifacts in a release. This step will convert the pom.xml files to the released version, build the project, commit the release pom.xml files to trunk, tag the release, convert the pom.xml files back to SNAPSHOT development versions and then commit those new development poms, effectively resetting trunk to the next development cycle. The convention we follow is to reset the development versions back to 7.0-SNAPSHOT which is a question asked during the release:prepare step.

> svn co jetty-trunk
> cd jetty-trunk
> mvn -DautoVersionSubmodules=true release:prepare
> mvn release:perform


The next phase of the release is to process the jetty-contrib trunk. The critical difference here is that we edit and commit the jetty-contrib-parent pom.xml file, setting the ${jetty.version} property to the version we released in the earlier phase. This is the property that all contrib artifacts that make use of jetty trunk artifacts should use in their <version/> sections. Here we activate the all-modules profile which picks up the contrib artifacts that are to be released so they can be processed via the release plugin. In the future we expect that contrib modules will be able to have different release cycles but currently anything being released is kept in lockstep with the jetty release version wise.

> svn co jetty-contrib-trunk
> cd jetty-contrib-trunk
> vim pom.xml - set jetty.version
> mvn -Pall-modules -DautoVersionSubmodules=true release:prepare
> mvn -Pall-modules release:perform


Next we need to checkout the jetty tag that we made in the first phase and adjust the svn:externals to reflect the tagged jetty-contrib version. We also set the pom portion of the svn:externals to the released version of the administrative parent pom. You can get this version by looking for the number of the parent of the root pom in the jetty checkout. If it is '2' then the pom should be set to the tag of jetty-parent-2. This file is not used in the build, but is set for posterity mainly. Then we smoke the contrib and pom directories and update the tagged versions of them. Once the checkout is completely from tagged scm source we run a build from the top level to populate the root project structure with necessary files. We generate the assembly which is currently not an automated portion of the release so we adjust the pom.xml accordingly and then deploy.

Contextual Release Warning


Building the jetty assembly, installers, and website currently hinge upon having files moved around into the root project structure. Things like artifacts or javadoc are aggregated into the root structure and that is why we must be careful with building the versioned software correctly before generating assemblies and installers.

> svn co jetty-x.x.x
> cd jetty-x.x.x
> svn propedit svn:externals modules (adjust contrib and pom to released versions)
> svn commit -m "setting to release versions" modules
> rm -Rf modules/contrib modules/pom
> svn up
> mvn -Pall-modules install
> cd assembly
> vim pom.xml (set to release version)
> mvn -Pcodehaus-release -DupdateReleaseInfo=true deploy
  • No labels
Contact the core Jetty developers at
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery