Publishing snapshots

Hi,

I’m working on improving the CI/CD for Orekit. One of the most annoying issue is that the develop branch of Orekit regularly depends on a SNAPSHOT version of Hipparchus. Currently, the CI/CD is based on feature/issue of Jenkins, allowing to share a .m2 between multiple jobs from distinct projects… An other side effect (from my external point of view): any new contributor to Orekit has to download and build Hipparchus also, while she is not necessarily interested on.

:unicorn: The ideal solution would be to prohibit such situation and systematically publish a RELEASE of Hipparchus before upgrading Orekit’s dependencies. Of course, ideal is not the most simple to do and can bring more complex situations in the development process.

The other solutions are to publish these SNAPSHOTs somewhere.

As far as I know, the maven central do not let us publish SNAPSHOT. :broken_heart:

I then though about Github Packages feature as Hipparchus’ source code is hosted there, but same rule: no SNAPSHOT hosted. :broken_heart:

So, the only remaining solution seems to be to host these SNAPSHOTs on the (new) Nexus instance for Orekit. One side effect: I fear that I will need to expose this dependency directly inside the pom.xml (not able to hide it somewhere else).

Is it acceptable to have Hipparchus project depends on Orekit’s resources?

With this change, would random external users still be able to download the source distribution and
build the library by themselves as before?

Of course such external builds would not be allowed to trigger anything on the Nexus instance, but I wonder if there would be side effect for these users.

Publishing Hipparchus’ SNAPSHOTs on Orekit’s Nexus will:

  • not affect Hipparchus’ random external users because, as far as I know, the changed settings only concern the deploy phase

  • could affect Orekit’s random external users if they configure their .m2/settings.xml in order to point to Orekit’s Nexus and be able to only download Hipparchus SNAPSHOT (instead of having to rebuild it from sources)

  • not affect users involved in both Orekit’s and Hipparchus development as maven give priority to local packages (installed in .m2/repository): if a SNAPSHOT of Hipparchus is published on Orekit’s Nexus, developer are still able to install their own version of Hipparchus.

Seems fine to me since it’s just hosting snapshots. If you want to make sure it doesn’t affect the normal build process you could put it in a maven profile.

I have a similar situation at work, where two separate maven projects evolve side-by-side, and it is indeed a bit of a pain to work with snapshots. I think the best solution is for the lowest level project (in this case Hipparchus) to host his own snapshots, but if I understand correctly they do not have the resources to do so. In this case, I agree with Evan: relying on Orekit infrastructure should be fine, it’s not a real ‘code’ dependency and will therefore be easy to remove in the future if necessary.

Thanks for your comments.

I made changes in the pipeline in order to deploy Hipparchus’ SNAPSHOTs into the Orekit’s Nexus. I will continue on Orekit to do the same.
Technically:

  • I added a profile ci-deploy to adjust distribution management
  • I moved previous distribution management into a release profile (already supposed to be activated for manual release, reading the docs)

The next step could be to automatically deploy RELEASE on maven central. But I don’t know if it is possible or not (keys to a bot, maven central requiring manual process) or just if it is expected by the maintainers. Let me know.