ImageJ release cycle
Locked
12
12
 
|
Hi everybody,
Just a quick question: why ImageJ version 1.47 cannot be downloaded directly from the download page and has to be obtained as an update for the 1.46 version? Best, José María Mateos. -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Hi Jose,
it is more work to create a full release then just to build a new ij.jar, which gets loaded by 'update ImageJ'. There are incremental improvements almost daily; it would mean a lot of work to have the full release each time! The full release, for all platforms, with installers etc. is usually created after the last sub-release for a given number is done. So, 1.46r was released on 26 June 2012, and all the installers etc. were created for it. A few days later, the first daily build of 1.47 was out, and 1.47a came out on 17 July 2012. I guess that there will be a final 1.47 version with installers this summer, but then 1.48 will start a few days later. This means, when you download ImageJ, always run 'Update ImageJ' as the first thing (with no internet connection to the target computer, get the ij.jar file, e.g. the daily build from http://rsb.info.nih.gov/ij/ij.jar, and replace it in the installed version). Michael ________________________________________________________________ On May 31, 2013, at 13:08, José María Mateos wrote: > Hi everybody, > > Just a quick question: why ImageJ version 1.47 cannot be downloaded directly from the download page and has to be obtained as an update for the 1.46 version? > > Best, > > José María Mateos. > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by José María Mateos
Hi José María,
On Fri, 31 May 2013, José María Mateos wrote: > Just a quick question: why ImageJ version 1.47 cannot be downloaded > directly from the download page and has to be obtained as an update for > the 1.46 version? As Michael pointed out, release management is a major task. Having said that, the Fiji distribution of ImageJ makes this much easier by having update sites which keep the distribution up-to-date; developers upload new versions, and user installations suggest upgrading automatically. This system allows us to keep ImageJ up-to-date painlessly; it always ships with the current minor version (at the time of writing, ImageJ 1.47q). This system also allows us to offer Fiji as a continuous release, i.e. the packages are updated automatically whenever something new -- including new ImageJ versions -- is uploaded to the Fiji update site; this avoids to require users to know implementation details such as: which command to execute to update to the latest version, what files are required, where they need to be put, etc The whole point of the Fiji distribution of ImageJ is convenience. Wayne, I would be very happy to contribute my experience and knowledge about the continuous release management to install a new job on our continuous integration server to create ImageJ packages for every new minor version and and for all "nightly builds" automatically. Please tell me if you're interested! Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Dear Wayne,
On Fri, 31 May 2013, Rasband, Wayne (NIH/NIMH) [E] wrote: > On May 31, 2013, at 10:48 AM, Johannes Schindelin wrote: > > > Wayne, I would be very happy to contribute my experience and knowledge > > about the continuous release management to install a new job on our > > continuous integration server to create ImageJ packages for every new > > minor version and and for all "nightly builds" automatically. > > I am interested. Would the continuous integration server support the > Inno Setup installer used with the Windows packages? As far as I know, > it only runs on Windows. There are ways to get it to run on Linux, but our setup includes Windows nodes (e.g. for building the ImageJ launcher for Windows). I managed to extract .iss scripts from all three Windows installers, but of course it would be better if you would be willing to provide yours? > By the way, could you remind me where I can get the ImageJ launcher for > Linux? Certainly: http://jenkins.imagej.net/job/ImageJ-launcher/label=master/lastSuccessfulBuild/artifact/launcher/target/nar/ij-launcher-2.0.0-SNAPSHOT-amd64-Linux-gcc-executable/bin/amd64-Linux-gcc/ij-launcher and http://jenkins.imagej.net/job/ImageJ-launcher/label=master/lastSuccessfulBuild/artifact/launcher/target/nar/ij-launcher-2.0.0-SNAPSHOT-i386-Linux-gcc-executable/bin/i386-Linux-gcc/ij-launcher (These URLs look overly complicated, but it's pretty simple: in http://jenkins.imagej.net/job/ImageJ-launcher/label=master/, follow the "Last successful artifacts" link.) Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Dear Wayne,
On Sat, 1 Jun 2013, Rasband, Wayne (NIH/NIMH) [E] wrote: > On May 31, 2013, at 9:43 PM, Johannes Schindelin wrote: > > > On Fri, 31 May 2013, Rasband, Wayne (NIH/NIMH) [E] wrote: > > > >> On May 31, 2013, at 10:48 AM, Johannes Schindelin wrote: > >> > >>> Wayne, I would be very happy to contribute my experience and > >>> knowledge about the continuous release management to install a new > >>> job on our continuous integration server to create ImageJ packages > >>> for every new minor version and and for all "nightly builds" > >>> automatically. > >> > >> I am interested. Would the continuous integration server support the > >> Inno Setup installer used with the Windows packages? As far as I > >> know, it only runs on Windows. > > > > There are ways to get it to run on Linux, but our setup includes > > Windows nodes (e.g. for building the ImageJ launcher for Windows). > > > > I managed to extract .iss scripts from all three Windows installers, > > but of course it would be better if you would be willing to provide > > yours? > > Here is the .iss script I use to generate all three installers. With the > version bundled with 64-bit Java, I uncomment this line: > > ;ArchitecturesInstallIn64BitMode=x64 I got that far by inspecting the extracted .iss files. What I missed (which innounp is apparently not able to detect) is the 'users-modify' permission on the directory. So here is the result of my work so far: http://jenkins.imagej.net/job/ImageJ1-releases/label=Windows/ and http://jenkins.imagej.net/job/ImageJ1-releases/label=master/ Note: MacOSX needs work, I concentrated on Linux and Windows (which should be fine). The job is configured to take http://imagej.net/ij/ij.jar, extract its version, and make all of the installers/archives at 11pm CDT every night. Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Dear Wayne,
On Sun, 2 Jun 2013, Johannes Schindelin wrote: > On Sat, 1 Jun 2013, Rasband, Wayne (NIH/NIMH) [E] wrote: > > > On May 31, 2013, at 9:43 PM, Johannes Schindelin wrote: > > > > > On Fri, 31 May 2013, Rasband, Wayne (NIH/NIMH) [E] wrote: > > > > > >> On May 31, 2013, at 10:48 AM, Johannes Schindelin wrote: > > >> > > >>> Wayne, I would be very happy to contribute my experience and > > >>> knowledge about the continuous release management to install a new > > >>> job on our continuous integration server to create ImageJ packages > > >>> for every new minor version and and for all "nightly builds" > > >>> automatically. > > >> > > >> I am interested. Would the continuous integration server support > > >> the Inno Setup installer used with the Windows packages? As far as > > >> I know, it only runs on Windows. > > > > > > There are ways to get it to run on Linux, but our setup includes > > > Windows nodes (e.g. for building the ImageJ launcher for Windows). > > > > > > I managed to extract .iss scripts from all three Windows installers, > > > but of course it would be better if you would be willing to provide > > > yours? > > > > Here is the .iss script I use to generate all three installers. With > > the version bundled with 64-bit Java, I uncomment this line: > > > > ;ArchitecturesInstallIn64BitMode=x64 > > I got that far by inspecting the extracted .iss files. What I missed > (which innounp is apparently not able to detect) is the 'users-modify' > permission on the directory. > > So here is the result of my work so far: > > http://jenkins.imagej.net/job/ImageJ1-releases/label=Windows/ > and > http://jenkins.imagej.net/job/ImageJ1-releases/label=master/ > > Note: MacOSX needs work, I concentrated on Linux and Windows (which should > be fine). > > The job is configured to take http://imagej.net/ij/ij.jar, extract its > version, and make all of the installers/archives at 11pm CDT every night. In the meantime, I also got MacOSX to work properly (generated in the 'master' configuration). I also changed the configuration so that http://imagej.net/ij.jar is used, and the job inspects every 15 minutes whether that URL's timestamp has changed (and builds when it has). Wayne, could you have a look whether everything works as you expect it? In particular, I would suggest to verify that Jenkins schedules a build within 15 minutes of you uploading a new ij.jar. Ciao, Johannes P.S.: Of course the complete project to make these releases is maintained in a repository with development history, too: https://github.com/imagej/ij1-installer (I will add a README.md later, for now I am done with working this weekend) -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by dscho
Dear Wayne,
sorry, I did not have time yesterday to play more with the continuous releases. On Sun, 2 Jun 2013, Rasband, Wayne (NIH/NIMH) [E] wrote: > On Jun 1, 2013, at 6:17 PM, Johannes Schindelin wrote: > > > I got that far by inspecting the extracted .iss files. What I missed > > (which innounp is apparently not able to detect) is the 'users-modify' > > permission on the directory. > > > > So here is the result of my work so far: > > > > http://jenkins.imagej.net/job/ImageJ1-releases/label=Windows/ > > and > > http://jenkins.imagej.net/job/ImageJ1-releases/label=master/ > > 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? > 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. > > 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? > > The job is configured to take http://imagej.net/ij/ij.jar, extract its > > version, and make all of the installers/archives at 11pm CDT every > > night. > > 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. Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Dear Johannes,
Thank you for your work on the continuous release installers. >... 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/ > I would suggest that the final release get a green badge, and the daily build get a yellow badge. I checked and there's a createShortText(java.lang.String text, java.lang.String color, java.lang.String background, java.lang.String border, java.lang.String borderColor) method that could be used to do that depending on 'version' format instead of action = clazz.createShortText(version) by checking if 'version' ends with a letter or a number. Sincerely, Jerome. -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by dscho
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 |
|
|
Dear Wayne,
On Tue, 4 Jun 2013, Rasband, Wayne (NIH/NIMH) [E] wrote: > On Jun 4, 2013, at 4:53 PM, Johannes Schindelin wrote: > > > 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 could remove this fix if the launcher always passed at least one > argument to ImageJ. The old Pascal Windows launcher must do this because > the "Enable single instance listener" option works as expected on > Windows. Sorry, I should have been more clear. Users calling the ImageJ launcher without arguments expected a second instance to appear. The change you made breaks that expectation from 1.47t3 on. Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Jerome Mutterer-3
Hi Jerome,
On Tue, 4 Jun 2013, Jerome Mutterer wrote: > Thank you for your work on the continuous release installers. You are welcome! > >... 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/ > > I would suggest that the final release get a green badge, and the daily > build get a yellow badge. > > I checked and there's a createShortText(java.lang.String text, > java.lang.String color, java.lang.String background, java.lang.String > border, java.lang.String borderColor) > > method that could be used to do that depending on 'version' format > instead of > > action = clazz.createShortText(version) > > by checking if 'version' ends with a letter or a number. Can you make a patch? That would be awesome. Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Hi Jerome,
On Tue, 4 Jun 2013, Johannes Schindelin wrote: > On Tue, 4 Jun 2013, Jerome Mutterer wrote: > > > >... 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/ > > > > I would suggest that the final release get a green badge, and the > > daily build get a yellow badge. > > > > I checked and there's a createShortText(java.lang.String text, > > java.lang.String color, java.lang.String background, java.lang.String > > border, java.lang.String borderColor) > > > > method that could be used to do that depending on 'version' format > > instead of > > > > action = clazz.createShortText(version) > > > > by checking if 'version' ends with a letter or a number. > > Can you make a patch? That would be awesome. Thank you, I merged your pull request as soon as I saw it! Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Hi Johannes,
Thanks for merging it, but it doesn't seem to work as expected: the badge wasn't created for 1.47t6. Unfortunately, I have no way testing the groovy script directly. The same line runs OK in java, I must have overlooked something. I hope you can fix it. Jerome. On 5 June 2013 05:08, Johannes Schindelin <[hidden email]> wrote: > Hi Jerome, > > On Tue, 4 Jun 2013, Johannes Schindelin wrote: > >> On Tue, 4 Jun 2013, Jerome Mutterer wrote: >> >> > >... 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/ >> > >> > I would suggest that the final release get a green badge, and the >> > daily build get a yellow badge. >> > >> > I checked and there's a createShortText(java.lang.String text, >> > java.lang.String color, java.lang.String background, java.lang.String >> > border, java.lang.String borderColor) >> > >> > method that could be used to do that depending on 'version' format >> > instead of >> > >> > action = clazz.createShortText(version) >> > >> > by checking if 'version' ends with a letter or a number. >> >> Can you make a patch? That would be awesome. > > Thank you, I merged your pull request as soon as I saw it! > > Ciao, > Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Hi Jerome,
On Wed, 5 Jun 2013, Jerome Mutterer wrote: > Thanks for merging it, but it doesn't seem to work as expected: the > badge wasn't created for 1.47t6. Unfortunately, I have no way testing > the groovy script directly. The same line runs OK in java, I must have > overlooked something. I hope you can fix it. I cannot fix it today, unfortunately, because I am stuck in a moving steel box for the day. Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Hi,
On Wed, 5 Jun 2013, Johannes Schindelin wrote: > On Wed, 5 Jun 2013, Jerome Mutterer wrote: > > > Thanks for merging it, but it doesn't seem to work as expected: the > > badge wasn't created for 1.47t6. Unfortunately, I have no way testing > > the groovy script directly. The same line runs OK in java, I must have > > overlooked something. I hope you can fix it. > > I cannot fix it today, unfortunately, because I am stuck in a moving > steel box for the day. So I fixed it, and also added more stuff. The description is now updated after every build to have links to the latest daily and minor releases (and we'll see whether my script catches major releases, too). Additionally, there are stable links at the top of the description to the latest minor and daily builds, too. I wanted to wait until Wayne released another daily version to see whether it worked or not before I announce the changes. It does work: http://jenkins.imagej.net/job/ImageJ1-releases/ Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by dscho
Dear Wayne,
On Mon, 3 Jun 2013, Rasband, Wayne (NIH/NIMH) [E] wrote: > Dear Johannes, > > On Jun 2, 2013, at 10:17 PM, Johannes Schindelin wrote: > > > I also changed the configuration so that http://imagej.net/ij.jar is > > used, and the job inspects every 15 minutes whether that URL's > > timestamp has changed (and builds when it has). > > As I said yesterday, running the job only when there is a new letter > release (e.g. 1.47s but not 1.47s1) would be fine. I hope you do not mind the current solution, as excluding 1.47s1 explicitly would be a lot more work because I cannot skip a build when it already started (and I would have to inspect the *contents* of ij.jar as downloaded from the ImageJ 1.x website to find out what type of version it represents as there is no other mechanism by which I could possibly tell). Also: the description (which is now updated after every build) as well as the color-coded badges contributed by Jerome should make it much easier to navigate the page http://jenkins.imagej.net/job/ImageJ1-releases/ > It might be a good idea, however, to run the unit tests on each daily > build. Unfortunately, this is not as easy as you might think: the unit tests are a full-fledged Maven project, expecting ImageJ 1.x in the same form (as you know, ImageJA is now nothing more than a Mavenized project following the minor versions as published by you on http://imagej.net/notes.html and http://imagej.net/download/src/ (if those two disagree on the latest version, the Jenkins job keeping ImageJA up-to-date refuses to update anything). So to support what you ask for, I would have to - make a new Jenkins job - let that job monitor the daily builds - finagle the ij.jar into a pseudo-Maven repository - let the unit-tests run on that faked Maven artifact I will find those hours later this week to make that happen, but it will be a different job from ImageJ1-unit-tests because those two jobs share only the spirit, not the procedure. Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Dear Wayne,
On Mon, 8 Jul 2013, Rasband, Wayne (NIH/NIMH) [E] wrote: > On Jul 8, 2013, at 12:54 PM, Johannes Schindelin wrote: > > >> It might be a good idea, however, to run the unit tests on each daily > >> build. > > > > Unfortunately, this is not as easy as you might think: the unit tests > > are a full-fledged Maven project, expecting ImageJ 1.x in the same > > form (as you know, ImageJA is now nothing more than a Mavenized > > project following the minor versions as published by you on > > http://imagej.net/notes.html and http://imagej.net/download/src/ (if > > those two disagree on the latest version, the Jenkins job keeping > > ImageJA up-to-date refuses to update anything). > > > > So to support what you ask for, I would have to > > > > - make a new Jenkins job > > - let that job monitor the daily builds > > - finagle the ij.jar into a pseudo-Maven repository > > - let the unit-tests run on that faked Maven artifact > > > > I will find those hours later this week to make that happen, but it > > will be a different job from ImageJ1-unit-tests because those two jobs > > share only the spirit, not the procedure. > > It is fine if you leave things as they are. It is not necessary to run > the unit tests on daily builds. Too late: http://jenkins.imagej.net/job/ImageJ1-daily-unit-tests/ Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by dscho
Dear Wayne,
On Mon, 8 Jul 2013, Johannes Schindelin wrote: > [...] the description (which is now updated after every build) as well as > the color-coded badges contributed by Jerome should make it much easier to > navigate the page http://jenkins.imagej.net/job/ImageJ1-releases/ I noticed two problems with the job: 1) there is no 1.47. That means that there was never a 1.47 uploaded to http://imagej.net/ij.jar. 2) I see that you built your own packaging on http://imagej.nih.gov/ij/download.html which is fine -- of course! -- but I hoped that all my efforts and the time I spent on ImageJ1-releases would not be spent in vain. Sincerely, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Dear Wayne,
I Cc: the list because some people might want to help by sending pull requests. On Wed, 10 Jul 2013, Rasband, Wayne (NIH/NIMH) [E] wrote: > On Jul 9, 2013, at 11:22 PM, Johannes Schindelin wrote: > > > On Mon, 8 Jul 2013, Johannes Schindelin wrote: > > > > 2) I see that you built your own packaging on > > http://imagej.nih.gov/ij/download.html > > I needed to update the contents of the plugins, macros and luts folders. > I am willing to try to synchronize my changes if you tell me exactly > what I need to do. First: clone the repository: git clone [hidden email]:imagej/ij1-installer/ (since you push successfully to your repository, I think that [hidden email] has already a private key on your computer.) Then change all you want changed in the app/ directory. After that, call git add -u app/ git add app/ to mark removed, modified and added files for commit. Then commit: git commit This lets you write an informative commit message, but of course you are free to write a time stamp there (even if that is already recorded by Git automatically). Then push the changes: git push origin HEAD This will be picked up by the Jenkins job and it will rebuild the packages within a quarter of an hour. Ciao, Johannes P.S.: I recently played with the GitHub for Mac application and it looks pretty nice. Maybe you'll like it, too: https://mac.github.com/ -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Dear Wayne,
On Wed, 10 Jul 2013, Rasband, Wayne (NIH/NIMH) [E] wrote: > On Jul 10, 2013, at 8:44 PM, Johannes Schindelin wrote: > > > I Cc: the list because some people might want to help by sending pull > > requests. > > > > On Wed, 10 Jul 2013, Rasband, Wayne (NIH/NIMH) [E] wrote: > > > >> On Jul 9, 2013, at 11:22 PM, Johannes Schindelin wrote: > >> > >>> On Mon, 8 Jul 2013, Johannes Schindelin wrote: > >>> > >>> 2) I see that you built your own packaging on > >>> http://imagej.nih.gov/ij/download.html > >> > >> I needed to update the contents of the plugins, macros and luts folders. > >> I am willing to try to synchronize my changes if you tell me exactly > >> what I need to do. > > > > First: clone the repository: > > > > git clone [hidden email]:imagej/ij1-installer/ > > I got a "Repository not found" error when I tried this. > > wayne% git clone [hidden email]:imagej/ij1-installer/ > Cloning into 'ij1-installer'... > ERROR: Repository not found. > fatal: The remote end hung up unexpectedly This was a simple copy-paste error. Try it without the trailing slash (I had https://github.com/imagej/ij1-installer/ at first, which is not only the URL of the website but also works with modern git-clone, but I did not know what Git version you use). Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
«
Return to ImageJ
|
1 view|%1 views
| Free forum by Nabble | Edit this page |