Baseline - allow skipping exported package versions check and bundle version checks individually

[rombert]

We are in the process of migrating a large numble of bundles to using the bnd-maven-plugin and the bnd-baseline-maven-plugin instead of the maven-bundle-plugin. One part which is a bit of a bump in the process is that the baselining functionality now fails in case the expected bundle version was not changed.

This is a problem for us since we use a different versioning conventions:

• development releases are always odd
• release versions are always even

We recently had a case where a change was made, and the baseline correctly flagged the bundle version as needing a version bump from 1.2.6 to 1.3.0. However, we do not do this at development time, so we would need to change to 1.3.1-SNAPSHOT and then release at 1.3.2, which is confusing for consumers - where is 1.3.0 ?

Our workflow could be best adapted by allowing to control baselining for exported package versions and bundle versions.

[bjhargrave]

You can use -fixupmessages to ignore any baseline messages regarding bundle versions. This is what we do in Bnd build itself since all bundles are versioned the same for a release.

[kwin]

The -fixupmessages is not very stable. If you decide to change the error text of baselining that would require a change in our -fixupmessage as well. Wouldn't a dedicated instruction make sense for skipping the bundle version messages?

[kwin]

Just for the record: This would be an example: https://github.com/bndtools/bnd/blob/88c1da70f5a96b0a5c2136b6c08012241fbaaca6/biz.aQute.bndlib/bnd.bnd#L86

[bjhargrave]

The -fixupmessages is not very stable. If you decide to change the error text of baselining that would require a change in our -fixupmessage as well.

True. But I don't expect we will change the message text. At the very least the text would change on a new release and your build can update the pattern when upgrading Bnd versions.

You can also use a more relaxed pattern like bundle version * too low if you don't care about bundle version baselining at all.

[rombert]

I added a bnd.bnd file to my project containing

-fixupmessages.bundleversion: "The bundle version change *";is:=ignore

but the build still fails. The code is at https://github.com/apache/sling-org-apache-sling-repoinit-parser/tree/feature/baseline-fixup, do you see anything obviously wrong in the way I configured it?

[bjhargrave]

Sigh.

I always get mixed up with non-Bnd workspace model (e.g. maven) builds vs. Bnd workspace model builds.

The bnd-baseline-maven-plugin (and the gradle Baseline task type) does not care/know about bnd files. And so it cannot be influenced by -fixupmessages. Sorry.

So we would need to add some support for these non-Bnd workspace model baselining operations to allow this sort of error elision.

So we can use this issue for this feature addition.

[raducotescu]

Also, just as a FYI, the message already changed from the example @kwin found in your examples. When using bnd-baseline-maven-plugin:4.2.0 the message looks like:

The bundle version change (2.0.58 to 2.0.59) is too low, the new version must be at least 2.1.0

Hence why I'd argue that configuration flags would be better, for both the bnd-baseline-maven-plugin, but also for the bnd-maven-plugin (see #3444).

[bjhargrave]

Need a way to disable bundle version baselining since it is of dubious value. The Bnd build would use this option if available.

[rotty3000]

Could I get someone to add the actual error output? A possibly better idea would be a small project that reproduces the issue?

[rotty3000]

I cannot seem to convince the bnd-baseline-maven-plugin to care about the bundle version at all. I would need to see a real example of failure to proceed.

[bjhargrave]

I see this issue in the Bnd bulid (although it is a Bnd workspace model build and does not use the bnd maven plugins.) I think you can trigger this issue by changing a package major version. See here where you did exactly this and had to fixupmessage the baseline error about bundle major version needing to be incremented.

https://github.com/bndtools/bnd/commit/3b9ea43b53693d293b13b28905649ec3122bbab3#diff-2ce2efa3685fea36e5fe307de6346503R67

https://github.com/bndtools/bnd/commit/3b9ea43b53693d293b13b28905649ec3122bbab3#diff-780acf881a4b95debc0184f030495c25R86

[rotty3000]

I'm pretty sure I understand how to make baseline fail. What I'm saying is that I cannot seem to make the bnd-baseline-maven-plugin fail for purely the bundle version, nor is the bundle version ever suggested to be changed. e.g. If I make a MAJOR change to a class, and increment the bundle version by ==+ (micro version only), whether I mark the package version correctly as +== or not does not ask me to change the bundle version. If i mark the package to the correct version and NOT the bundle version (remaining in a micro version range) the baseline plugin is happy.

[stefanseifert]

i've prepared a branch in this project to reproduce this issue: https://github.com/apache/sling-org-apache-sling-servlet-helpers/tree/experimental/bundle-version-issue in the last commit i added a new method to a class forcing a package version update. the baseline plugin now fails the build with the request to update the bundle version as well.

[kwin]

@rotty3000 Are you working actively on this issue? Otherwise I could try to come up with a PR...

[rotty3000]

@kwin I am not at the moment. I see that we could assign you. Let me know.

[kwin]

Just for the record: Disabling bundle version baselining is already supported since quite a while via -diffignore: Bundle-Version (https://bnd.bndtools.org/instructions/diffignore.html). In the bnd-baseline-maven-plugin it works via

<configuration>
        <diffignores>
           <diffignore>Bundle-Version</diffignore>
        </diffignores>
    </configuration>

[kwin]

It turned out this does not work as expected and documented in https://github.com/bndtools/bnd/commit/b52e7978029b4eea358aa295a580802042ba5b6b for package deletions, see #5290.