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 #1086 (closed enhancement: fixed)

Opened 2012-04-02T12:36:10-05:00

Last modified 2012-10-15T09:17:55-05:00

Deploy snapshot versions of ImageJ2 artifacts only if their corresponding source code changed

Reported by: dscho Owned by: dscho
Priority: minor Milestone: imagej2-b5-scripting
Component: Other Version:
Severity: cosmetic Keywords:
Cc: Blocked By:


To avoid having to download unnecessary snapshot versions, let's only deploy when things actually changed.

Due to .jar files storing files' timestamps, we cannot simply check whether the .jar file changed.

There are basically two options I can think of how to handle things:

1) unpack both the old and the new .jar and md5sum the files, sort by name, compare the md5sums. But that means that we have to keep track somehow what was the previously deployed (old) .jar.

2) upon successful build, store the current commit SHA-1 in a file that is then published. In the build script of we then need to look for ../lastSuccessful/<file> and compare the output of "git rev-parse $SHA1:<path-to-current-project>" between the current HEAD and the one from the last successful build

In any case, to do this, we need to move the deploy target outside of the Maven build step and into the shell build step, and let the shell script traverse all sub-projects with deployable targets.

Hmm. Maybe there is a way to teach Maven's deploy to check the .jar contents' checksums instead and only deploy a new snapshot when they differ? Would be more general and less ugly...

Change History

comment:1 Changed 2012-04-16T10:32:13-05:00 by dscho

  • Milestone changed from imagej-2.0-beta2 to imagej-2.0-final

Just like #1085, this is not really critical for users. So pushing to -final, too.

comment:2 Changed 2012-10-03T17:06:25-05:00 by dscho

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

Since I had to do this for Fiji anyway (a couple of artifacts are *not* -SNAPSHOT versions, so we cannot simply mvn deploy blindly in the Fiji-Maven job), I activated this in the ImageJ job, too.

comment:3 Changed 2012-10-03T17:30:06-05:00 by dscho

To be precise, I replaced the mvn deploy step in the ImageJ job with mvn package and after that added a build step that simply calls Fiji's

While at it, I also replaced the mvn deploy step in ImageJ-daily with mvn package, as there is now no more need for deploying once a day.

comment:4 Changed 2012-10-15T09:17:55-05:00 by bdezonia

  • Milestone changed from imagej-2.0.0 to imagej-2.0.0-beta5