Jetty has moved!
Jetty is a project at the Eclipse Foundation.
Homepage:http://www.eclipse.org/jetty
Downloads: http://download.eclipse.org/jetty/
Documentation:http://www.eclipse.org/jetty/documentation/current/
About:http://www.eclipse.org/jetty/about.php
Jetty Powered:http://www.eclipse.org/jetty/powered/
Contact the core Jetty developers at www.webtide.com
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 3 Next »

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

Phase 1 - jetty-trunk

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.

Cometd Dependencies

Icon

Until cometd is producing maven artifacts that we can bring in as dependencies, there are external svn components getting pulled in for the release. They are in the cometd directory under extra and we need to export this locally to the CHECKED OUT TAG and then add them before the release:perform process is executed.

> svn co https://svn.codehaus.org/jetty/jetty/trunk jetty-trunk
> cd jetty-trunk
> mvn -DautoVersionSubmodules=true release:prepare
> mvn release:perform

Phase 2 - jetty-contrib-trunk

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 https://svn.codehaus.org/jetty-contrib/trunk 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

Phase 3 - jetty-x.x.x:

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.

> svn co https://svn.codehaus.org/jetty/jetty/tags/jetty-x.x.x 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
> vim VERSIONS.TXT <-- alter the version info
> mvn -Pall-modules install
> cd assembly
> vim pom.xml (set to release version)
> mvn -Pcodehaus-release -DupdateReleaseInfo=true deploy

Phase 4 - cleanup

There are still a few steps which require a more manual hand in releasing. Those include generating the installers, moving the assemblies to the traditional download locations, deployed the updated website, announcing the release. Most of those activities are similar or the same as with the jetty6 release and as they are changed will be updated here.

  • No labels
Contact the core Jetty developers at www.webtide.com
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