NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #1784 (closed enhancement: fixed)

Opened 2013-04-08T13:52:53-05:00

Last modified 2013-05-14T13:27:35-05:00

Add a Jenkins job that can release a new pom-scijava and update our Maven projects accordingly

Reported by: dscho Owned by: dscho
Priority: major Milestone: imagej-2.0.0
Component: Build System Version:
Severity: major Keywords:
Cc: curtis Blocked By:
Blocking: #1783

Description (last modified by dscho)

Just like synchronizes ImageJ 1.x fully automatically, commits, pushes and deploys, we need Jenkins jobs (most likely manually triggered, however) to help bumping up the version in one of our projects (pom-scijava, scijava-common, imglib2, imagej2, scifio, fiji).

The job needs to be parametrized (the Git project to bump).

It would be nice if this job could trigger all projects to be bumped to new pom-scijava versions.

This Jenkins job should avoid pushing updated master branches when builds fail, but simply mark the builds as failed.

For maximal transparency, the job should be implemented as a shell script in scijava-common's bin/ directory.

Change History

comment:1 Changed 2013-04-08T14:09:05-05:00 by dscho

  • Description modified

comment:2 Changed 2013-04-08T14:14:02-05:00 by dscho

  • Description modified

comment:3 Changed 2013-04-09T13:35:30-05:00 by dscho

There is now something in place: and

A little work is left to do:

  • should we use <pluginManagement> instead of properties to manage versions? That would allow us to use the maven-versions-plugin to bump the pom-scijava versions.
  • The Jenkins job currently only updates pom-scijava, but it needs to update scijava-common, imglib2, imagej2, scifio, fiji and any other repository we want to stay on the edge, too. Happily, this is easily accomplised with's --bump-parent option, but it needs thorough testing.

comment:4 Changed 2013-04-09T13:45:43-05:00 by dscho

One thing we have to be careful about: ImageJA. As it is never at a -SNAPSHOT version, we probably need to use --skip-commit --bump-parent in

comment:5 Changed 2013-04-10T12:00:05-05:00 by dscho

Curtis reported that the sed call does not work properly on MacOSX: the pom-scijava version is not incremented properly, most likely due to the great and incredibly powerful BSD sed.

To side-step that issue, and also to update all dependent major projects (IJ2, SCIFIO, etc), let's finalize the job.

However, this requires a substantial change first: should learn to figure out the latest release versions itself and update the pom.xml accordingly, exiting silently if nothing needs to be changed.

comment:6 Changed 2013-04-11T13:52:25-05:00 by dscho

It appears that the <versioning> tag of maven-metadata.xml is not automatically correct when deploying with Maven 2 (which our Jenkins does).

So before could acquire a new, intelligent mode to update pom-scijava to upgrade to our latest release versions, I needed to

  • run Rebuild Metadata on our Nexus, and
  • change a couple of deploy calls used directly or indirectly by Jenkins to include -DupdateReleaseInfo=true

Sadly, it seems that the deploy plugin is not clever enough to skip interpreting the updateReleaseInfo property for -SNAPSHOT versions, so we cannot do it wholesale.

So far, I updated scijava-common's,, ImageJ's doc/release-steps.txt, ImageJA's (on the tools branch) and the ImageJ-release-deploy Jenkins job to use said property.

It seems that the following Jenkins jobs have shell calls to mvn deploy (but want to deploy -SNAPSHOT versions most of the time):

  • Imagej-launcher-deploy
  • Saalfeld-MPICBG-Maven, and
  • TrakEM2-Maven.

The following Jenkins jobs have Maven build steps calling deploy (but also typically deploy -SNAPSHOT versions):

  • Bio-Formats-maven,
  • ImgLib,
  • LOCI,
  • LOCI-daily,
  • native-lib-loader, and
  • SLIM-curve.

So I left all of those jobs untouched. (FWIW I called grep 'mvn.*deploy' jobs/*/config.xml and grep 'targets.*deploy' jobs/*/config.xml in Jenkins' home directory.)

comment:7 Changed 2013-04-11T14:34:11-05:00 by dscho

I tested as well as I can without actually bumping the pom-scijava version. So far, it is only set up to take care of ImageJ2's and Fiji's master branch.

For ImageJA, I enhanced the script (again, tested as well as possible without actually releasing a new ImageJ 1.x version).

I'll leave this ticket open until we get a chance to test it.

comment:8 Changed 2013-04-11T17:18:31-05:00 by dscho

  • Status changed from new to closed
  • Resolution set to fixed

The first test failed: a couple of issues prevented the dependencees to be updated correctly. But the issues have been resolved, the next time we need to bump the pom-scijava project should be just a "Build now" away...

comment:9 Changed 2013-04-11T17:19:21-05:00 by dscho

  • Summary changed from Add a Jenkins job that can release new versions of our Maven projects to Add a Jenkins job that can release a new pom-scijava and update our Maven projects accordingly

comment:10 Changed 2013-04-13T14:38:50-05:00 by dscho

Since IJ2 now depends on release versions of scijava-common, I changed Jenkins to stop triggering ImageJ builds after SciJava-common was built successfully.

comment:11 Changed 2013-05-14T13:27:35-05:00 by dscho

I changed the Jenkins job to be parameterized so you can switch on/off what gets bumped.

For example, in the use case that came up today (and for which we did not have parameters), a new scijava-common version was released that required some changes in imagej.git to go in before bumping the required pom-scijava version. In that case, we would want to uncheck BUILD_IMAGEJ and bump imagej.git's parent version later, when merging the branch with the required changes.