Posted by
dscho on
Jun 04, 2013; 8:53pm
URL: http://imagej.273.s1.nabble.com/ImageJ-release-cycle-tp5003165p5003225.html
Hi Wayne,
On Tue, 4 Jun 2013, Rasband, Wayne (NIH/NIMH) [E] wrote:
> On Jun 4, 2013, at 1:49 PM, Johannes Schindelin wrote:
>
> >> The releases for Windows and Linux look good! I tested them and found
> >> only one problem. The "Enable single instance listener" option in
> >> Edit>Options>Misc is ignored on bother Windows and Linux. You get a new
> >> ImageJ instance each time you run the launcher.
> >
> > That's too bad. I did not yet have time to look into this. Probably
> > renaming the launcher to 'debug' will yield some helpful output, right?
>
> This turned out to be a bug in the OtherInstance.sendArguments() method.
> It only checked for other instances when at least one argument was
> passed to ImageJ. The fix is in the ImageJ 1.47t3 daily build.
That's too bad: I inspected the fix and found that it reverts the
functionality I carefully put into the OtherInstance class: when started
without parameters, it is surprising to users when ImageJ just quits. In
fact, it was an explicit request of a user back when I worked in Dresden.
> >> I have one question. How do I update the files in the plugins, macros
> >> and luts directories on your Jenkins server?
> >
> > As I mentioned in my mail yesterday morning, it is all maintained in a
> > Git repository:
> >
> >
https://github.com/imagej/ij1-installer/> >
> > The plugins, macros and LUTs all live in the app/ directory and are
> > copied verbatim to any of the archives/installers (this should also
> > make them more consistent between the different operating systems and
> > architectures).
> >
> > Of course I added you to the team of that repository, so you can make
> > all the changes you want! Jenkins will pick them up the next time it
> > builds a release.
>
> How do I make changes? I need to modify files, add files, delete files,
> add directories and delete directories. It would be easiest if I could
> simply post updated versions of the plugins, macros and luts
> directories.
Oh, but you use Git already for developing ImageJ, so I thought it would
be easiest for you to just
git clone github.com:imagej/ij1-installer
make your changes in that directory, commit and push whenever you are
satisfied with your changes. If you want something easier, I can set up
something web-based, but that will have to wait until next week: I am on
vacation starting tomorrow.
> >>> Note: MacOSX needs work, I concentrated on Linux and Windows (which
> >>> should be fine).
> >
> > Note: MacOSX is the only platform which does not use the ImageJ
> > launcher yet. I would really like to change that: the difference
> > between ImageJ.app and ImageJ64.app is unnecessary, the ImageJ
> > launcher can solve that problem (by having two launchers, always
> > starting with the 32-bit one and handing off to the 64-bit one
> > whenever appropriate).
> >
> > Do you have objections?
>
> It would be ideal if there was an ImageJ.app that ran in 64-bit mode on
> 64-bit systems and in 32-bit mode on 32-bit systems, and the use could
> check "Open in 32-bit mode" if he or she wanted to run in 32-bit mode on
> a 64-bit system. Is that what you are proposing?
Indeed, the ImageJ launcher checks on MacOSX whether "Open in 32-bit mode"
is checked and forces 32-bit mode even if it could switch to 64-bit. This
has been working for a long time already.
To make things explicit, I could also add a command-line option.
> It would also be good to have a ImageJ7.app that bundled Oracle Java
> 1.7. I looks like the only way to use Java 1.7 or later on OS X, other
> than running from the command line, is to bundle the Java runtime.
Right. This will require major changes as we had to change quite a bit
just for MacOSX to use the funny setup Apple imposed on us. We will have
to revert them *iff* a jre/ subdirectory is found in the current ImageJ
root directory.
Again, something for next week.
> >> It would be better if they were only updated for final releases (e.g.
> >> 1.47r) and not for daily builds (e.g. 1.47r21).
> >
> > I hope you do not feel too strongly about it because that would
> > actually be additional work. For the moment, Jenkins monitors the
> > timestamp of the URL
http://imagej.net/ij.jar and builds new releases
> > whenever the timestamp changes. I also worked quite a bit on making
> > the version more visible (see
> >
https://github.com/imagej/ij1-installer/blob/master/add-jenkins-badge.groovy)
> > in the build list. It worked beautifully:
> >
> >
http://jenkins.imagej.net/job/ImageJ1-releases/> >
> > (builds up until #14 can be safely ignored, they are leftovers from
> > some previous experiments).
> >
> > So if you do not mind, I would really like to build also releases for
> > "nightly" versions, just because it is easier for me that way.
>
> It's not ideal, but I can live with it.
Thank you,
Johannes
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html