Broken releases due(?) to broken maven setup (RoaringBitmapParent artifact)

I used to issue releases by going to the main RoaringBitmap repository and typing mvn release:clean && mvn release:prepare && mvn release:perform. Since PR https://github.com/RoaringBitmap/RoaringBitmap/pull/181 this no longer works. Sadly, CI does not check that releases are possible, so I did not catch the issue.

As I recall the point of the release was to move to a “classic maven project” described as follow:

Cannot we do a classic maven project by moving RoaringBitmap actual source to a specific submodule, and leaving all other submodules where they are?

Technically, I can issue the commands, but it does not generate an actual release and the result is a broken repository. I left the broken commits on purpose, so you can see the result…

https://github.com/RoaringBitmap/RoaringBitmap/commits/master

Note that to be able to do this in a sane way, I had to make a small change to the pom file so that jmh is excluded as a submodule by default, because otherwise, we run the full jmh unit test which takes 3 hours on my machine, and fails for an unclear reason (it looks like -DBITMAP_TYPES=ROARING_ONLY has no effect when doing mvn perform), with The forked VM terminated without saying properly goodbye.

Anyhow, the broken aspect of the release with mvn release:clean && mvn release:prepare && mvn release:perform has to do with the fact that this attempts to release an artifact RoaringBitmapParent. I am not sure what that is, and I am not sure that it is correct. Yet this seems to have been deliberate, see the pom file: https://github.com/RoaringBitmap/RoaringBitmap/blob/master/pom.xml#L5

To still be able to issue releases, I did a deploy instead from within the roaringbitmap subdirectory, hoping it would save us from RoaringBitmapParent artifact nonesense…

  cd roaringbitmap
  mvn versions:set -DnewVersion=0.6.53
  mvn clean deploy
  git commit -a
  git tag -a v0.6.53 -m "version 0.6.53"
  git push --tags
  # go to https://oss.sonatype.org/#nexus-search;quick~roaringbitmap and initial the release manually

Sadly, this result in something that is broken as well as you can see from a report on the mailing list:

I’m having some problems pulling the latest release from maven central via Leiningen:

[~/repos/streaming-lda] $ lein deps

Retrieving org/roaringbitmap/RoaringBitmap/0.6.53/RoaringBitmap-0.6.53.pom from central

Could not find artifact org.roaringbitmap:RoaringBitmapParent:pom:0.6.53 in central > (https://repo1.maven.org/maven2/)

This could be due to a typo in :dependencies or network issues.

You can see it’s looking for a artifact with “RoaringBitmapParent” in the name. Leiningen doesn’t do this when I try to pull down any other version, it just grabs the pom and jar having the usual names, like this: [~/repos/streaming-lda] $ lein deps Retrieving org/roaringbitmap/RoaringBitmap/0.6.49/RoaringBitmap-0.6.49.pom from central Retrieving org/roaringbitmap/RoaringBitmap/0.6.49/RoaringBitmap-0.6.49.jar from central
I can see from the history your pom file that this is some sort of intentional change. My maven knowledge is fairly low, but I’m suspicious that this is something Leiningen either doesn’t support requires some workaround for. Do you know anything more about this than I do?

Anyhow, it seems clear that either the maven project is broken or else, I am lacking the right release instructions.

I think that this is an urgent problem.

[lemire]

@Kineolyan

I don’t think he was serious. I am not considering Gradle. Someone would have to build a case for it and do the legwork.

I’ll add that tools like Maven is what turn people off to command line tools. You really, really want to go back and hide in an IDE. I’m a command-like guy and I cringe when I have to issue maven commands… because it is going to be slow and fragile… I mean… like us get serious… what is this -Darguments="-DskipTests" shit? And how does it differ from -Darguments="-Dmaven.test.skip"? It is just insane.

Fortunately, we don’t have to program using maven… most of the time.

[Kineolyan]

Hello @lemire,

As pointed in my comment, I think I can easily tune something not to run tests during the deploy phase of the release process. It only add more elements to the poms. Regarding the release of RoaringBitmapParent, I am pretty sure but not certain that it must be released, because our dear RoaringBitmapParent marks it as its parent. If not present, all builds will fail for this pom cannot be downloaded. But again, as I did not deploy on a real Maven repository, I cannot be sure.

About @richardstartin proposal of migrating to Gradle, it is an option I consider for various projects. In our case, I am not sure it would change much. It is just the trendy tool wrt Maven.

Cheers