Ticket #812 (closed task: fixed)
Opened 2011-10-10T12:54:40-05:00
Last modified 2011-10-21T18:51:13-05:00
Use ImageJA as Maven project to build ImageJ
Reported by: | dscho | Owned by: | dscho |
---|---|---|---|
Priority: | major | Milestone: |
|
Component: | Other | Version: | |
Severity: | serious | Keywords: | |
Cc: | Blocked By: | ||
Blocking: |
Description (last modified by dscho)
It is very convenient to use Eclipse's debugger when trying to find issues, but the ImageJ1 project is not yet integrated into ImageJ2's build procedure. Let's do that, by Mavenizing ImageJ and tracking the result in ImageJA.
This task includes
- undoing all changes we have in ImageJA
- making ImageJA's 'master' branch follow ImageJ slavishly, but moving all the files into the appropriate places for Maven and adding/updating a pom.xml
- use Hudson to follow update the 'master' branch automatically
The first step, undoing all changes in ImageJA means that Fiji needs to use Javassist to put back all the functionality it required ImageJA for. On the upside, it will allow Fiji to run with whatever IJ1 version is thrown at it.
Change History
comment:1 Changed 2011-10-10T12:57:07-05:00 by dscho
comment:3 Changed 2011-10-12T22:59:50-05:00 by dscho
Progress so far:
- all the non-applet specific changes have been backed out of ImageJA.
- even the headless stuff was successfully rewritten using Javassist.
- writing out a headless.jar for scenarios where the security manager might disagree with runtime-patching was a breeze.
- we have a script in ImageJA's 'tools' branch which can update the 'pom' branch (and in the future will update the 'master' branch when we merged 'pom' into it).
Tasks still to do:
- add a Hunkins/Jedson job,
- implement all the ImageJA-specific Applet stuff via Javassist.
- use that Javassist-based method in another Hudkins/Jenson job, triggered by the first, to write signed a .jar file and upload it where ImageJA is still expected to be uploaded.
comment:4 Changed 2011-10-14T23:46:56-05:00 by dscho
Problems. After building ImageJ using the new MiniMaven class (see ticket 813), things stopped working. The problem goes away when forcing ImageJ to compiled for Java 1.5, so it is a javassist problem.
comment:5 Changed 2011-10-16T21:27:57-05:00 by dscho
Okay, I squashed the Javassist bug. See http://fiji.sc/cgi-bin/gitweb.cgi?p=javassist/.git;a=commitdiff;h=fb4d16aaad9a89896d1772a43f17988ed5808e82 for the fix, and https://developer.imagej.net/2011/10/17/art-debugging for an unconventional writeup how I fixed it.
So I committed the fix to our fork of Javassist (but I also sent the patch upstream, let's see whether I found the correct way to submit patches), committed a precompiled javassist to fiji.git and updated ImageJA's 'master' branch.
Remaining tasks:
- install that Hunkjeds job to make HEAD requests to http://imagej.nih.gov/ij/notes.html all the time, and if the timestamp changes, trigger
- another Hedjins job that updates the 'master' branch
- port the applet stuff into a Javassist-based Fiji plugin which can export a possibly signed ij.jar with the embedded applet stuff on the fly
- maybe make another Judhens job to build such an ij.jar automatically when a new ImageJ was released and upload stuff to Sourceforge
- get rid of the 'pom' branch when everything works
comment:6 Changed 2011-10-21T18:51:13-05:00 by dscho
- Status changed from new to closed
- Resolution set to fixed
The Jedhunks job is installed: https://jenkins.imagej.net/job/Synchronize-with-ImageJ1
The applet stuff might very well be a case of YAGNI, let's take care of that iff we need it (and iff IJ2 does not offer a better solution to begin with).
Oh, and it also means to redo the headless mode, which gives us the opportunity to avoid having to adjust the code manually everytime IJ1 adds new methods or fields to the GenericDialog or ij.Menus.