Excluding automatically injected custom version annotation from baselining

I am trying to use the bnd-baseline-maven-plugin in my project to monitor my package-level @Version annotations.

However, I am running into a problem now. As part of my build, I have another tool that injects the current project version as a class-level annotation (MyVersionAnnotation ) into my class files.

This seems to clash with the bnd-baseline-maven-plugin which then fails suggesting me that I should bump the micro level.

[ERROR] ===============================================================
[ERROR]   Name                 Type       Delta      New        Old        Suggest    
[ERROR]   mymodule             BUNDLE     MAJOR 6.5.0      -          
[ERROR] ===============================================================
[ERROR]   Name                 Type       Delta      New        Old        Suggest    If Prov.
[ERROR] * mymodule             PACKAGE    MICRO      6.5.0      6.5.0      6.5.1      -
[ERROR]   MICRO                PACKAGE    mymodule
[ERROR]     CHANGED            CLASS      mymodule.MyClass
[ERROR]       CHANGED          ANNOTATED  MyVersionAnnotation
[ERROR]         REMOVED        PROPERTY   version='6.5.0'
[ERROR]         ADDED          PROPERTY   version='7.0.0-SNAPSHOT'
[ERROR]     ADDED              ANNOTATED  org.osgi.annotation.bundle.Export
[ERROR]     ADDED              ANNOTATED  org.osgi.annotation.versioning.Version
[ERROR]       ADDED            PROPERTY   value='6.5.0'

Now I don’t want to bump the micro level just because this annotation changes.

Is there a way I can tell the baseline plugin to ignore MyVersionAnnotation when calculating the diff?

Or alternatively, could I tell the plugin to just ignore all micro-level changes entirely and just barf on more significant changes (in particular on MAJOR changes)?

Hmm. This is usually the road to hell …

What you could try is to use the@BaselineIgnore annotation on the MyVersionAnnotation. I have not tried it but it seems worth a try.

Could you report the result here if it works or not for future reference?

I can try that.

In general though, I would assume not everybody has the option of modifying the code of the tools they are using. They may just be using existing third party libraries and tooling.

I think, in general it would be useful to have a parameter to configure the level of semantic versioning that should be considered breaking (cf. semanticVersionLevel in japicmp). I am using that plugin, but using the level MINOR in that setting because that works better in my environment.

I tend to disagree … but that has never been a popular standpoint :slight_smile:

Configuration is nice to have if you inflict these kind of problems on yourself and want to hide the consequences. However, it increases the complexity of your code and it inflicts complexity on everybody that tries to use baselining and has to understand these options and has to make choices. Trying to keep this highly complex area simple was always a big goal. I am always very sensitive to this price that is paid by the people not part of this discussion.

If someone would make a decent PR I’d accept it, but it is not something I will work on. If the @BaselineIgnore annotation would not work, we can discuss to make that work though.

So I tried the @BaselineIgnore annotation on the annotation - but that didn’t seem to work.

I am already looking into preparing a PR now… :wink:

Ok, so I am trying to prepare a PR, but I cannot even build the master branch unchanged right now.
I can see that the master branch is green on GitHub… any idea why is going wrong here?

This happens when I ./gradlew :build

biz.aQute.resolve.ProjectResolverTest > testAugment() STANDARD_ERROR
    [HttpClient,https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/cnf/distro/index.xml] INFO aQute.bnd.build.LoggingProgressPlugin - Download https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/cnf/distro/index.xml
    000: Resolution failed Unable to resolve <<INITIAL>>: missing requirement foo;filter:='(bar=1)'

biz.aQute.resolve.ProjectResolverTest > testAugment() STANDARD_OUT
    [enroute [.../git/bnd/biz.aQute.resolve/testdata/projectresolver/ws/cnf/cache/7.1.0/enroute r/w=false], bnd-cache [.../git/bnd/biz.aQute.resolve/testdata/projectresolver/ws/cnf/cache/7.1.0/bnd-cache r/w=false]]
    [enroute [.../git/bnd/biz.aQute.resolve/testdata/projectresolver/ws/cnf/cache/7.1.0/enroute r/w=false], [com.example.jerome.application version=, osgi.enroute.base.api version=, foo.bar version=0.0.0]]

ProjectResolverTest > testAugment() FAILED
    org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
        at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
        at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
        at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
        at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
        at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
        at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
        at app//biz.aQute.resolve.ProjectResolverTest.testAugment(ProjectResolverTest.java:116)

102 tests completed, 1 failed

Nevermind, I’ll just comment out this test in order to prepare the PR…

Argh… even just adding the OSGI package version annotations to package-info.java triggers the baseline plugin to require a micro bump…

A change is a change … It is better to err on the safe side.

We explicitly set the level to MICRO when it is not a RUNTIME annotation, indicating there was some thinking behind it. We once tried to ignore default methods but in the end there were use cases.

However, in this case a non-RUNTIME annotation change seems to be ignorable. So if you make a case for it we might go along.

I use the enhance goal of the Apache uimaFIT Maven Plugin which adds the version of the Maven project as a runtime annotation on the any Apache UIMA component classes using the @ResourceMetaData annotation.

 * This can be used to add component-level meta data such as version, vendor, etc.
 * @see org.apache.uima.resource.metadata.ResourceMetaData
public @interface ResourceMetaData {

The idea is that this annotation can then be picked up by tooling that wants to generate a UIMA XML descriptor for the class.

I want to define a package version for the package containing this UIMA component class to avoid a ripple release effect whenever I do a major release of the bundle.

However, I want the version in the UIMA component class to not reflect the package version but the bundle version (i.e. the Maven project version). Currently, this always leads to e MICRO-level change which I would like to ignore. Actually, I do not care about MICRO-level changes at all, even outside of this particular case. I’m primarily interested in using the baselineing to alert me of incompatibilities.