[ImageJ-devel] ImageJ launcher split to its own repository

[Johannes Schindelin]

Hi Curtis,

On Wed, 5 Jun 2013, Curtis Rueden wrote:

> The ImageJ launcher has been split to its own Git repository:
> 
>     https://github.com/imagej/imagej-launcher
> 
> The reasoning is two-fold:
> 
> 1) The launcher is its own project with its own development cycle,
> supporting ImageJ1, Fiji and ImageJ2. So it should be versioned separately.
> 
> 2) The split makes it much simpler to build and release ImageJ2.
> 
> We have also released version 2.0.0 of the launcher [1]. It has been in
> use with Fiji for a long time now, and we are already committed to
> maintaining backwards compatibility, so unlike ImageJ2, there is no
> point to keeping it in beta.

Good point.

BTW I found one problem with the deployment: I forgot to use
-DupdateReleaseInfo=true in ImageJ-launcher-deploy.

While at it, I looked through all the configurations and found that
Bio-Formats-maven, cppwrap-maven-plugin, curve-fitter, deep-zoom-plugin,
flow-cytometry, forward-cron-job, ImgLib, ImgLib-daily, jar2lib, jvmlink,
loci-checkstyle, LOCI, LOCI-daily, loci-utils, misc-plugins, multi-lut,
native-lib-loader, ome-versioning, prairie-ome-tiff,
Saalfeld-MPICBG-Maven, SCIFIO, SLIM-curve, slim-plotter, slim-plugin,
TrakEM2-Maven, visbio, visbio-imagej, wid-3dniche and wiscscan-java share
the same problem.

I fixed them all, even the disabled (and the obsolete) ones, so that the
following command would give me an empty result:

grep -w 'deploy' $HOME/jobs/*/config.xml |
grep -v -e '-DupdateReleaseInfo=true' -e 'incremental-deploy' \
	-e '</\?description>' -e '<projects>' -e '<command>#' |
sed 's/^[^:]*\/\([^\/:]*\)\/config\.xml:.*/http:\/\/jenkins.imagej.net\/job\/\1\/configure/'

> P.S. to Dscho: Updating the Jenkins jobs was mostly very straightforward,
> except for the ImageJ-launcher-deploy job. Your recent hack to discover the
> triggering Image-launcher build number by extracting it from the current
> build log did not work as we hoped: there was no match. At first I thought
> Jenkins was stripping out the backslashes within the sed expression, so I
> tried escaping the backslashes, which fixed the Jenkins console output but
> ultimately had the same result. So then I figured probably the log is not
> actually written to disk at that point.

That is too bad. I actually tested this in the Sandbox and the first part
of the log *was* written to disk at that point.

> I installed the Parameterized Trigger plugin, added a buildNumber
> parameter to ImageJ-launcher-deploy, and passed ImageJ-launcher's
> $BUILD_NUMBER in via that parameter. It worked, and furthermore we now
> have the ability to manually execute ImageJ-launcher-deploy on any
> desired ImageJ-launcher build.

I agree that is much better than my hack! Sorry to cause you so much
trouble, I would have worked harder on this (and on the split) had I
not expected all of that to happen next week ;-)

> P.P.S. to all: ImageJ 2.0.0-beta-7 will probably be out tomorrow, though
> announcements and blog posts may not be finished before Friday.

Sounds good to me!

Ciao,
Dscho