ImageJ builds are not deploying to Maven Central

[ctrueden]

Since the transition from Travis CI to GitHub Actions, the infrastructure that builds net.imagej:ij and deploys it to OSS Sonatype is broken. (The latest available on OSS Sonatype as of this writing is 1.53j, published in May 2021. Since then, ImageJ 1.53k and 1.53m have been released, with 1.53o daily builds currently in progress.)

The following problems need to be addressed to fix it:

• ij1-builds needs to run every day, not just on pushes to the main branch. Hopefully fixed with imagej/ij1-builds@49566d3.
• ImageJA needs to switch from Travis CI to GitHub Actions. I looked into doing this, but the ImageJA Travis build script was forked from travis-build.sh so that it can handle releases differently, and ci-build.sh does not accommodate the ImageJA workflow either. But it could, easily. So rather than keep a forked build script, the needed fix is to enhance ci-build.sh (in scijava/scijava-scripts) to handle the "ImageJA way" of deploying releases directly from the main branch.
• Any missing release versions that happened in the interim need to be back-filled to OSS Sonatype.

@rasband This is far from the first time this tooling has broken down. It is convoluted and brittle. I would prefer to simplify this structure to make things easier to maintain and less breakage-prone. As such, I propose merging the existing original-ImageJ-related repositories into a single imagej/ImageJ repository, as follows:

1. Merge imagej/ij1-tests into this repository. Fix the failing tests.
2. Add build logic to this repository to run the unit tests as part of the build, and to deploy builds (both daily builds and releases) to OSS Sonatype via GitHub Actions. Get rid of imagej/ImageJA and imagej/ij1-builds, which would no longer be necessary, merging the ImageJA history into this repository so that all the old release tags are still functional.
3. Rename this repository to imagej/ImageJ, to indicate that it is the ImageJ repository.
4. To make all of imagej/ij1-tests, imagej/ImageJA, and imagej/imagej1 redirect correctly to imagej/ImageJ, I would rename each to imagej/ImageJ in sequence before deleting the former two, so that GitHub has permanent redirects on file for them. That way, anyone who had cloned any of these repositories, or gets the remote URLs out of pom.xml files and such, would still have a trail leading to the new definitive repository.

For steps (1) and (2), while it's probably possible to achieve without moving around any existing source files, it would be much easier if the existing .java files moved into a common src subtree. Would you be willing to do that? (With Maven, src/main/java is standard, with unit tests going in src/test/java, but I can make src and test work if you strongly prefer that.) Or if you would rather nothing move from its current location, I could investigate how to achieve that.

Either way, for step (2) to work, it would be necessary for you to make releases of ImageJ by pushing to the main branch on GitHub and letting the GitHub Actions CI do the work, rather than making the zip yourself and uploading from your local machine. As things stand, the ij1-builds repository needs to poll the notes.html once per day, and then download the zip, unpack it, move files to their mapped locations in the ImageJA repository, and push it, so that the ImageJA CI can build and deploy a JAR. This will of course not be the same JAR that you built locally, meaning the releases available from the ImageJ downloads page are not binary identical to the ones from Maven Central.

What do you think? Would you like to have one ImageJ repository with all these bits? Or would you rather not change your current workflows as discussed above?

A different idea would be retire/archive ij1-tests and ImageJA, and rework ij1-builds to deploy JAR files using mvn deploy:deploy-file so the release builds are binary identical to what you produce on your local machine. But then users would have no corresponding commit hash or tag for each release, so would not be able to reproduce the release builds themselves from source control. (You do not push the source code at each release build anywhere, do you?) It would probably be possible for me to manually construct -sources and -javadoc JARs as part of that process, but it's extra work that would already be done by Maven-based tooling. (The purpose of a -sources JAR is mostly to let IDEs display the source code to people using ImageJ as a dependency, not to enable rebuilding from source.)

[rasband]

I would prefer that the .java source files not move from their current location.

I have been pushing releases of ImageJ to GitHub for over 10 years. I do not understand why you can't build and deploy a JAR from the files on GitHub.

I would prefer not to change my current workflow.

I do not push the source for every daily build but I do for all released versions of ImageJ.

[jpsacha]

@ctrueden Any update on this? Can I help somehow?

[ctrueden]

I have been pushing releases of ImageJ to GitHub for over 10 years.
I do not push the source for every daily build but I do for all released versions of ImageJ.

@rasband Thank you for reminding me of that. I had forgotten that the source code for releases were mixed into the history with the daily builds.

Here are some of the challenges with the current situation:

1. Many times, the commits here in this repository do not align with what is uploaded to the wsr.imagej.net/src archive. Because of this, the ij1-builds script downloads source zips from wsr.imagej.net/src, unpacks them, and commits them to the ImageJA repository. So we have a situation where the code at wsr.imagej.net/src (and therefore https://github.com/imagej/ImageJA) is not the same as this repository. This is a pitfall of making the JARs and ZIPs yourself—a better workflow would be to push code to GitHub and then allow the CI to build and deploy everything on your behalf.

2. There were no tags in this repository, only commit messages to indicate which version is which. To remedy this, just now I created the tags myself by scraping the commit messages, and pushed the resultant tags to this repository. However, there were some versions for which I could not initially create a tag because multiple commits match the version string:

   • 1.43p - ecf71b0 and 225faf7
   • 1.43u - 5f3cdb6 and 3674405
   • 1.44a - 0ec449f and 943d111
   • 1.45e - 9b0d4c5 and db5dec7
   • 1.45g - 248eb1b and 80afb5f and 3e1a5c5
   • 1.45l - ae5b358 and 6fdc722
   • 1.46k - 70e42d8 and 164d902
   • 1.48a - fe99418 and a165546
   • 1.53a - a775ebc and 9421bc9

   I compared each of the candidate commits to the corresponding ImageJA code, to figure out which commit more closely matches each release. Here is what I found:

   • [1.43p]
     • ecf71b0 = 5
     • 225faf7 = 0
   • [1.43u]
     • 5f3cdb6 = 1
     • 3674405 = 27
   • [1.44a]
     • 0ec449f = 1
     • 943d111 = 521
   • [1.45e]
     • 9b0d4c5 = 12
     • db5dec7 = 19
   • [1.45g]
     • 248eb1b = 11
     • 80afb5f = 10
     • 3e1a5c5 = 45
   • [1.45l]
     • ae5b358 = 13
     • 6fdc722 = 0
   • [1.46k]
     • 70e42d8 = 66
     • 164d902 = 0
   • [1.48a]
     • fe99418 = 1
     • a165546 = 763
   • [1.53a]
     • a775ebc = 0
     • 9421bc9 = 1797

   The number after each commit hash is the number of diff lines between the Java sources of that commit versus the code extracted from the -src.zip archives and recorded in ImageJA. For the ones with 0 or 1 line difference, I went ahead and created those tags as well. That leaves the following ambiguous versions still to resolve: 1.45e and 1.45g. If you have insight into which commit corresponds to either of these two releases, that would be helpful to get them tagged.

3. Versions of ImageJ prior to 1.43i do not have release commits here in this repository. The ImageJA repository has tagged release commits back to 1.38t, and commits in the history back to 1.20 for each numerical version's final lettered release (and correspondingly, the wsr.imagej.net/src archive has those same sources back to 1.20). It would be nice to have everything here in this repository, rather than split across multiple repositories. Here is a breakdown, for each release version of ImageJ for which source is available, showing where the sources can be found:

   source availability by version

   Version	tag here	tag in ImageJA	src zip
   v1.20	no	no	yes
   v1.21	no	no	yes
   v1.22	no	no	yes
   v1.23	no	no	yes
   v1.24	no	no	yes
   v1.25	no	no	yes
   v1.26	no	no	yes
   v1.27	no	no	yes
   v1.28	no	no	yes
   v1.29	no	no	yes
   v1.30	no	no	yes
   v1.31	no	no	yes
   v1.32	no	no	yes
   v1.33u	no	no	yes
   v1.34s	no	no	yes
   v1.35s	no	no	yes
   v1.36b	no	no	yes
   v1.37v	no	no	yes
   v1.38t	no	yes	no
   v1.38u	no	yes	no
   v1.38v	no	yes	no
   v1.38w	no	yes	no
   v1.38x	no	yes	yes
   v1.39a	no	yes	no
   v1.39b	no	yes	no
   v1.39c	no	yes	no
   v1.39d	no	yes	no
   v1.39e	no	yes	no
   v1.39f	no	yes	no
   v1.39g	no	yes	no
   v1.39h	no	yes	no
   v1.39i	no	yes	no
   v1.39j	no	yes	no
   v1.39k	no	yes	no
   v1.39l	no	yes	no
   v1.39m	no	yes	no
   v1.39n	no	yes	no
   v1.39o	no	yes	no
   v1.39p	no	yes	no
   v1.39q	no	yes	no
   v1.39r	no	yes	no
   v1.39s	no	yes	no
   v1.39t	no	yes	no
   v1.39u	no	yes	yes
   v1.40a	no	yes	no
   v1.40b	no	yes	no
   v1.40c	no	yes	no
   v1.40d	no	yes	no
   v1.40f	no	yes	no
   v1.40g	no	no	yes
   v1.41a	no	yes	no
   v1.41b	no	yes	no
   v1.41c	no	yes	no
   v1.41d	no	yes	no
   v1.41e	no	yes	no
   v1.41f	no	yes	no
   v1.41g	no	yes	no
   v1.41h	no	yes	no
   v1.41i	no	yes	no
   v1.41j	no	yes	no
   v1.41k	no	yes	no
   v1.41l	no	yes	no
   v1.41m	no	yes	no
   v1.41n	no	yes	no
   v1.41o	no	yes	yes
   v1.42a	no	yes	no
   v1.42b	no	yes	no
   v1.42c	no	yes	no
   v1.42d	no	yes	no
   v1.42e	no	yes	no
   v1.42f	no	yes	no
   v1.42g	no	yes	no
   v1.42h	no	yes	no
   v1.42i	no	yes	no
   v1.42j	no	yes	no
   v1.42k	no	yes	no
   v1.42l	no	yes	no
   v1.42m	no	yes	no
   v1.42n	no	yes	no
   v1.42o	no	yes	no
   v1.42p	no	yes	no
   v1.42q	no	yes	yes
   v1.43a	no	yes	no
   v1.43b	no	yes	no
   v1.43c	no	yes	no
   v1.43d	no	yes	no
   v1.43e	no	yes	no
   v1.43f	no	yes	no
   v1.43g	no	yes	no
   v1.43h	no	yes	no
   v1.43i	yes	yes	no
   v1.43j	yes	yes	no
   v1.43k	yes	yes	no
   v1.43l	yes	yes	no
   v1.43m	yes	yes	no
   v1.43n	yes	yes	no
   v1.43o	yes	yes	no
   v1.43p	yes	yes	no
   v1.43q	yes	yes	no
   v1.43r	yes	yes	no
   v1.43s	yes	yes	no
   v1.43t	yes	yes	no
   v1.43u	yes	yes	yes
   v1.44a	yes	yes	no
   v1.44b	yes	yes	no
   v1.44c	yes	yes	no
   v1.44d	yes	yes	no
   v1.44e	yes	yes	no
   v1.44f	yes	yes	no
   v1.44g	yes	yes	no
   v1.44h	yes	yes	no
   v1.44i	yes	yes	no
   v1.44j	yes	yes	no
   v1.44k	yes	yes	no
   v1.44l	yes	yes	no
   v1.44m	yes	yes	no
   v1.44n	yes	yes	no
   v1.44o	yes	yes	yes
   v1.45a	yes	yes	no
   v1.45b	yes	yes	no
   v1.45c	yes	yes	no
   v1.45d	yes	yes	no
   v1.45e	no	yes	no
   v1.45f	yes	yes	no
   v1.45g	no	yes	no
   v1.45h	yes	yes	no
   v1.45i	no	yes	no
   v1.45j	yes	yes	no
   v1.45k	yes	yes	no
   v1.45l	yes	yes	no
   v1.45m	yes	yes	no
   v1.45n	yes	yes	no
   v1.45o	yes	yes	no
   v1.45p	yes	yes	no
   v1.45q	yes	yes	no
   v1.45r	yes	yes	no
   v1.45s	yes	yes	yes
   v1.46a	yes	yes	no
   v1.46b	yes	yes	no
   v1.46c	yes	yes	no
   v1.46d	yes	yes	no
   v1.46e	yes	yes	no
   v1.46f	yes	yes	no
   v1.46g	yes	yes	no
   v1.46h	yes	yes	no
   v1.46i	yes	yes	no
   v1.46j	yes	yes	no
   v1.46k	yes	yes	no
   v1.46m	yes	yes	no
   v1.46n	yes	yes	no
   v1.46o	yes	yes	no
   v1.46p	yes	yes	no
   v1.46q	yes	yes	no
   v1.46r	yes	yes	yes
   v1.47a	yes	yes	no
   v1.47b	yes	yes	no
   v1.47c	yes	yes	no
   v1.47d	yes	yes	no
   v1.47e	yes	yes	no
   v1.47f	yes	yes	no
   v1.47g	yes	yes	no
   v1.47h	yes	yes	no
   v1.47i	yes	yes	no
   v1.47j	yes	yes	no
   v1.47k	yes	yes	no
   v1.47m	yes	yes	no
   v1.47n	yes	yes	no
   v1.47o	yes	yes	no
   v1.47p	yes	yes	no
   v1.47q	yes	yes	no
   v1.47r	yes	yes	no
   v1.47s	yes	yes	no
   v1.47t	no	yes	no
   v1.47u	yes	yes	no
   v1.47v	yes	yes	yes
   v1.48a	yes	yes	no
   v1.48b	yes	yes	no
   v1.48c	yes	yes	no
   v1.48d	yes	yes	no
   v1.48e	yes	yes	no
   v1.48f	yes	yes	no
   v1.48g	yes	yes	no
   v1.48h	yes	yes	no
   v1.48i	yes	yes	no
   v1.48j	yes	yes	no
   v1.48k	yes	yes	no
   v1.48m	yes	yes	no
   v1.48n	yes	yes	no
   v1.48o	yes	yes	no
   v1.48p	yes	no	no
   v1.48q	yes	yes	no
   v1.48r	yes	yes	no
   v1.48s	yes	yes	no
   v1.48t	yes	yes	no
   v1.48u	yes	yes	no
   v1.48v	yes	yes	yes
   v1.49a	yes	yes	no
   v1.49b	yes	yes	no
   v1.49c	yes	yes	no
   v1.49d	yes	yes	no
   v1.49e	yes	yes	no
   v1.49f	yes	yes	no
   v1.49g	yes	yes	no
   v1.49h	yes	yes	no
   v1.49i	yes	yes	no
   v1.49j	yes	yes	no
   v1.49k	no	yes	no
   v1.49m	yes	yes	no
   v1.49n	yes	no	no
   v1.49o	yes	no	no
   v1.49p	yes	yes	no
   v1.49q	no	yes	no
   v1.49r	yes	yes	no
   v1.49s	yes	yes	no
   v1.49t	yes	yes	no
   v1.49u	no	yes	no
   v1.49v	yes	yes	yes
   v1.50a	yes	yes	no
   v1.50b	yes	yes	no
   v1.50c	yes	yes	yes
   v1.50d	yes	yes	no
   v1.50e	yes	yes	yes
   v1.50f	yes	no	no
   v1.50g	yes	yes	yes
   v1.50h	yes	yes	yes
   v1.50i	yes	yes	yes
   v1.51a	yes	yes	no
   v1.51b	yes	no	no
   v1.51c	yes	yes	no
   v1.51d	yes	yes	no
   v1.51e	yes	yes	no
   v1.51f	yes	yes	no
   v1.51g	yes	yes	no
   v1.51h	yes	yes	no
   v1.51j	yes	yes	yes
   v1.51k	yes	yes	yes
   v1.51m	yes	yes	yes
   v1.51n	yes	yes	no
   v1.51o	yes	yes	yes
   v1.51p	yes	yes	no
   v1.51q	yes	yes	yes
   v1.51r	yes	yes	yes
   v1.51s	no	yes	yes
   v1.51t	yes	no	yes
   v1.51u	yes	yes	yes
   v1.51v	yes	yes	yes
   v1.51w	yes	yes	yes
   v1.52a	yes	yes	yes
   v1.52b	yes	yes	yes
   v1.52c	yes	yes	yes
   v1.52d	yes	yes	yes
   v1.52e	yes	yes	yes
   v1.52f	yes	yes	yes
   v1.52g	yes	yes	yes
   v1.52h	yes	yes	yes
   v1.52i	yes	yes	yes
   v1.52j	no	yes	yes
   v1.52k	yes	yes	yes
   v1.52m	yes	yes	yes
   v1.52n	yes	yes	yes
   v1.52o	yes	yes	yes
   v1.52p	yes	yes	yes
   v1.52q	yes	yes	yes
   v1.52r	yes	yes	yes
   v1.52s	yes	yes	yes
   v1.52t	yes	yes	yes
   v1.52u	yes	yes	yes
   v1.52v	yes	yes	yes
   v1.53a	yes	yes	yes
   v1.53b	yes	yes	yes
   v1.53c	yes	yes	yes
   v1.53d	yes	yes	yes
   v1.53e	yes	yes	yes
   v1.53f	yes	yes	yes
   v1.53g	yes	yes	yes
   v1.53h	yes	yes	yes
   v1.53i	yes	yes	yes
   v1.53j	yes	yes	yes
   v1.53k	yes	yes	yes
   v1.53m	yes	yes	yes
   v1.53n	yes	no	yes
   v1.53o	yes	no	yes

   What would be more ideal would be:

   • To have only one ImageJ repository at imagej/ImageJ, with all source committed, and all release versions tagged.
   • To publish all binary releases and all -src and -javadoc archives to Maven Central. The wsr.imagej.net/src directory could be deleted, or else kept and maintained by CI only for backward compatibility, since users could obtain the sources from git or download them from their deployed location on Maven Central. There are many advantages to publishing releases in this standard way; for example, versioned javadoc would become available via https://javadoc.io rather than needing to serve it ad hoc from https://imagej.nih.gov/ij/developer/api/ or https://javadoc.scijava.org.

4. We now have many binary releases of net.imagej:ij deployed to Maven Central (and for older versions, maven.scijava.org), which were built from commit hashes in the ImageJA repository, rather than in this one. These binary releases have the ImageJA commit hashes and tags embedded inside, which I think we should take care to preserve. The simplest way of doing that is to archive ImageJA (i.e. make it read-only) rather than deleting it, with a link in the README to this canonical ImageJ repository, once this repository is configured to build and deploy artifacts on its own without using the ij1-builds/ImageJA infrastructure.

I do not understand why you can't build and deploy a JAR from the files on GitHub.
I would prefer not to change my current workflow.

Some questions for you, then:

• Are you OK with me pushing build logic into the .github folder here, which takes care of building and deploying ImageJ releases to Maven Central? I would switch deployment to a new groupId gov.nih.imagej, and build and deploy the binary, source, and javadoc artifacts directly from this repository. Once this is working, I would delete the ij1-builds repository, archive ImageJA, and update the related information on the imagej.net wiki accordingly.

• Are you OK with me deploying all past versions of ImageJ to the new groupId? If so: would you rather I deploy the actual binary builds made at time of release which are served on the website, or should I rebuild from source from each release tag? Edit: A wrinkle is that deploying to Maven Central requires signed JARs. We have the infrastructure to do this, but it means that I cannot deploy the already-released versions of ImageJ to Maven Central in a binary-identical way. We have to sign them first, which will alter their MD5 checksums. So with the current workflow, the binaries served from imagej.nih.gov/ij and/or wsr.imagej.net can never identically match those on Maven Central.

• Similarly: if you would rather I be deploying the exact binary build and source zips you are uploading manually, rather than rebuilding it, I can have the CI do that... but I'd like to know which way you prefer. Having the CI rebuild from source is better in that it will catch regressions in an automated way, but it is worse in that it will result in a non-identical binary build compared to what you are building by hand and uploading. This is a major reason why I would prefer you change your workflow to let CI do the builds+uploads—but since you prefer otherwise, I can make the CI do whatever you want, I just need to know what actions you want it to be taking.

• Which commit hash would you like to use for 1.45e and 1.45g?

• What about the ij1-tests repository? Are you OK with me merging those files into this repository (in a new folder called tests), so that the CI runs them as part of the build+deploy process? After all, the point of those tests is to catch regressions before releases are made.

@jpsacha wrote:

Any update on this?

Thank you for the ping; you spurred me to write the above.

Can I help somehow?

The best way you can help is to describe to us which ImageJ-related resources you use online, how you use them, and what (if any) issues or limitations of the current infrastructure are impacting you. This will help us to prioritize support for the things you need.

[jpsacha]

@ctrueden Is this issue name indicates no new ImageJ build are released on Maven Central. An example: I would like to make use of the new addButton method of the GenericDialog added in v.1.53k in a new plugin planned for ijp-color. That project builds against dependencies published in public repositories, like Maven Central.

[rasband]

a better workflow would be to push code to GitHub and then allow the CI to build and deploy everything on your behalf

I would prefer to build and deploy the daily builds (as I do now) and have the CI build and deploy the release versions.

The wsr.imagej.net/src directory could be deleted, or else kept and maintained by CI only for backward compatibility

The wsr.imagej.net/src directory should be kept and maintained since I use it frequently to restore older versions of ImageJ.

Are you OK with me pushing build logic into the .github folder here, which takes care of building and deploying ImageJ releases to Maven Central?

I am OK with this as long as it preserves the 10+ years of ImageJ commits and it does not cause a major disruption of my current workflow.

Are you OK with me deploying all past versions of ImageJ to the new groupId?

This is OK with me as long as the commit history is preserved.

rebuild from source from each release tag?

Rebuilding from source seems like the way to go.

Which commit hash would you like to use for 1.45e and 1.45g?

Use the latest commit in both cases.

Are you OK with me merging those files into this repository (in a new folder called tests), so that the CI runs them as part of the build+deploy process?

This is okay with me. Does this mean the deploy will fail if any test fails?

[ctrueden]

Thanks @rasband. I have now taken the following actions:

1. Renamed this repository to ImageJ.
2. Archived the ImageJA, ij1-builds, and ij1-installer repositories.
3. Updated pages of the ImageJ wiki accordingly (imagej/imagej.github.io@0084c55).
4. Pushed release tags for 1.45e and 1.45g.
5. Constructed a pom.xml to build and deploy ImageJ with Maven without relocating any files. It works, building an ij.jar that has exactly the same contents as the one from the Ant build, except for the addition of Maven's META-INF/maven directory with the Maven POM embedded (which is useful for introspecting libraries).
6. Wrote a README.md for ImageJ with a brief overview of the project, and instructions on developer-oriented topics including building Imagej from source and using ImageJ as a dependency.
7. Began work on merging ij1-tests into a new tests folder, and updating the Ant build.xml and Maven pom.xml to support building and running the tests.

I have commits on my local machine for (5), (6), and (7), but have not pushed anything to GitHub yet. Tomorrow I will complete work on (7), and then code the GitHub Actions logic for: A) tagging release commits; B) building the code when changes are pushed; C) deploying releases to Maven Central; D) uploading release archives of your choice to locations of your choice (e.g. -src.zip archives to https://wsr.imagej.net/src).

After discussing with @hinerm, I decided not to change the groupId. The net.imagej:ij releases from ImageJA up through 1.53j work just fine as is. I will just deploy 1.53k and later via the new mechanism.

Does this mean the deploy will fail if any test fails?

It is up to you. With a typical development workflow, yes, the CI would fail the build to inform you that a regression has been introduced, with the goal being to fix the regression before cutting the next release. So my advice would be to let the CI build the code and run the tests every time you push changes, notifying you via email of any failures. That way, you catch problems early, in advance of each release. Does that sound OK? Or if you want the system to behave differently, let me know.

[ctrueden]

@rasband @imagingbook Progress update for today:

1. Finished merging ij1-tests into a new tests folder, and added targets to the Ant build file to compile and run the tests.
2. Added a Maven POM to build the project using Maven.
3. Fixed the GitHub Actions continuous integration (CI) job to actually build the code.
4. Created tags for the final versions v1.20 through v1.33, and all lettered versions from v1.34a through v1.43h, by using the commits from the old ImageJA repository. (This was automated infrastructure that Johannes wrote long ago to pull down and committed the source zips from the ImageJ website, with commit messages from the release notes. I am happy that we now preserve this organized history here.)
5. Pushed all of this work, including the new README, to GitHub.

So now:

• ImageJ can be built with either Ant or Maven;
• The CI automatically builds the code whenever it changes, and pushes the resultant ij-1.x-SNAPSHOT.jar and friends to the SciJava Maven repository, so that this deployed snapshot version always reflects the latest and greatest code here;
• ImageJ's unit tests are part of the same repository so that they stay in sync with the main codebase;
• There are tags for all ImageJ releases v1.20 and newer, with letter-release granularity starting at v1.34a, all in one place here.

@rasband There are quite a few failing unit tests, so right now, the Maven build skips them. If we can get to the point where all tests pass, by fixing broken tests and/or disabling obsolete/undesired tests, then we can turn on unit testing by default in the Maven build, and whenever you push to GitHub, the CI will not only build and deploy the JAR files, but also run the tests and send you an email if any of them fail. No rush, but hopefully useful going forward to check for regressions more thoroughly. You can run them using ant run-tests or mvn test if interested.

Next steps:

• Manually build and deploy the v1.53k through v1.53p tags to s01.oss.sonatype.org, which will publish them to Maven Central.
• Improve the CI to automatically tag and deploy new releases, when the code appears to be a release.
• Consider teaching the CI to build source zips and upload them to wsr.imagej.net/src.

I will keep you posted.

[ctrueden]

ImageJ versions 1.53k, 1.53m, 1.53n, 1.53o, and 1.53p are now built and deployed to s01.oss.sonatype.org, Sonatype's new infrastructure mirrored into Maven Central.

• https://s01.oss.sonatype.org/#nexus-search;gav~net.imagej~ij~~~
• https://search.maven.org/artifact/net.imagej/ij

Tomorrow, I will teach the GitHub Actions CI to publish future release versions automatically.

[ctrueden]

I didn't have time to work on the CI release publication today as planned, but I did start a topic branch deploy-releases-to-sonatype with a draft implementation last night. Not yet tested, though.

Edit: I tidied up and merged the branch as b323af0. The case that skips deploying to Sonatype when ImageJ is in daily build status works. We'll find out whether releases get automatically deployed to Sonatype the next time @rasband pushes a release version.

[cleterrier]

Sorry to interrupt - does this mean we might soon see Fiji finally being up-to-date with the latest ImageJ version? That would be excellent news!

[ctrueden]

@cleterrier Yes. Together with imagej/ij1-patcher#50, the problems are solved. I pushed the 1.53p update to Fiji just now. Please update when you have a chance and let me know if anything is broken.