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 7.0.0.202403111508 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)?
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
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.
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
-----------------
Errors
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=1.0.0.201502190831, osgi.enroute.base.api version=1.5.0.201502191630, 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…
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.
/**
* This can be used to add component-level meta data such as version, vendor, etc.
*
* @see org.apache.uima.resource.metadata.ResourceMetaData
*/
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
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.
