Permanent URLs to artifacts on jenkins.imagej.net

Could it be that permalinks on jenkins.imagej.net are not working as expected?
E.g.:
http://jenkins.imagej.net/view/Fiji-Standard/job/AnalyzeSkeleton/lastStableBuild/
vs
http://jenkins.imagej.net/view/Fiji-Standard/job/AnalyzeSkeleton/lastBuild/
Both URLs point to the same build when I’d expect the first to point to a release (non -SNAPSHOT) version (3.0.0 as of this writing). I was also thinking of using maven.imagej.net, but I am only able to use URLs associated with specific versions., e.g., http://maven.imagej.net/service/local/repositories/releases/content/sc/fiji/AnalyzeSkeleton_/3.0.0/AnalyzeSkeleton_-3.0.0.jar.

Am I missing something?

It would be useful to have a permanent URL pointing to the latest stable release of an artifact. In particular, I am thinking of Strahler, that asks non-Fiji users to install required dependencies, but download URLs have to be edited every time newer versions get released.

I am also thinking that permanent URLs would be quite useful to use in the Infobox template to guarantee documentation pages are always up-to-date.

While I agree that permanent URLs of the latest builds would be useful for the infoboxes on the wiki, I don’t think that users should ever be required to manually install anything into ./plugins. That’s why the updater was migrated from Fiji to plain ImageJ: you can simply tell users to activate the Fiji update site :smile:

1 Like

Unfortunately Jenkins has no concept of releases - it’s just an automation tool. So “Stable” from a Jenkins perspective means “Build passed.” For Jenkins jobs that build .jars, the artifacts produced will always be SNAPSHOTs - as the actual purpose of these jobs is to deploy the latest SNAPSHOT version to Maven. (we use a single dedicated Jenkins job for all releases)

So from the Maven repo itself is the correct place to look for an artifact. It looks like there is a link you can use to download the latest .jar from Maven, you just need to specify a GAV in the URL, e.g. for ImageJ-ops:

http://maven.imagej.net/service/local/artifact/maven/redirect?r=public&g=net.imagej&a=imagej-ops&v=LATEST&e=jar

I agree. @ctrueden has been working on automated documentation so I think auto-generating the appropriate Maven link would be doable.

1 Like

Thanks for the detailed explanation. It does indeed work.

While true that users should not have to deal with core libraries, that may be simply too draconian (to say the least). Historically, the plugins directory has been the place to fiddle with, and almost every IJ installation I come across has a ./plugins directory that has files not distributed through update sites. Even now, if you want to insert a script in the IJ Menu hierarchy the simplest way is to use the ./plugins/Scripts/Menu/Submenu/ path-mirroring mechanism, which requires placing files in, well, the ./plugins/ directory.

It is lots of work to be inclusive. Just checked my mailbox and have ~10 emails from users that insist on all sorts of shenanigans to run Strahler in their outdated (updater-unaware) ImageJ installations. But I do agree that if the effort to be inclusive becomes a burden, it is not worth it. So, in the good ImageJ tradition of inclusiveness, I’ve modified the dependencies-check block to frown at resilient old-timers:

https://github.com/tferr/Scripts/blob/master/Morphometry/Strahler_Analysis.bsh#L49-L69

3 Likes