benchmarks depends on latest available RoaringBitmaps available

When one runs benchmarks via run.sh on the outdated feature branch the codebase is published as let’s say 0.6.45-SNAPSHOT. If in the mean time the newest version was released (e.g…0.6.50) https://github.com/RoaringBitmap/RoaringBitmap/releases then it will be used in the class path for the benchmark. I’ve been hit by that while working on https://github.com/RoaringBitmap/RoaringBitmap/pull/169 and noticing no improvement with the changes (and I knew there were here a months ago when I’ve started). And I suppose it might hit me when I was working on iterators performance merge request - which I decided to close because of benchmarks.

[blacelle]

Hello, if I allow myself interfering, I expect all pom versions to be aligned - in any situation. The usual way to managed this is to have a parent maven project with packaging=pom, referring underlying modules. Each release is done on the parent maven modules, leading to a pom version increment on each sub-modules.

Right now, the top maven module have packaging-jar. Changing this would require moving a lot of code. Not really nice for git histories, but quite trivial to do. An alternative, is to add a maven module with packaging=pom as sub-module as ensure the top module have it as parent, with the proper relativePath. Just the same, the new parent/subFolder module refers to the other modules with relative pathes. mvn versions:set or mvn release ... will need to be done over the parent/subFolder module.

Anyway, a clean solution (i.e. not querying versions in a bash script) will anyway require an additional pom with packaging=pom (@lemire I feel you can not get things clean and simple with maven without this packaging=pom additional pom.xml).

As an additional step, the root module can not have sonatype as parent, as it needs to have the new parent/subFolder as parent. I manage this by rather relying on

<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>

I unsure the understand if current travis behavior is fully satisfying or not.

I sketched this in https://github.com/RoaringBitmap/RoaringBitmap/pull/179

[lemire]

I assume that this is fixed.