# Excluding automatically injected custom version annotation from baselining **URL:** \ **Category:** GENERAL\ **Created:** [March 11, 2024, 4:49pm UTC](https://bnd.discourse.group/t/excluding-automatically-injected-custom-version-annotation-from-baselining/427 "2024-03-11T16:49:13Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![rec](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/rec/32/155_2.png) [@rec](https://bnd.discourse.group/u/rec)\ **Post date:** [March 11, 2024, 4:49pm UTC](https://bnd.discourse.group/t/excluding-automatically-injected-custom-version-annotation-from-baselining/427/1 "2024-03-11T16:49:13Z")
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. ```auto [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)? ---
**Author:** ![pkriens](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/pkriens/32/3_2.png) [@pkriens](https://bnd.discourse.group/u/pkriens)\ **Post date:** [March 12, 2024, 10:37am UTC](https://bnd.discourse.group/t/excluding-automatically-injected-custom-version-annotation-from-baselining/427/2 "2024-03-12T10:37:58Z")
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? ---
**Author:** ![rec](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/rec/32/155_2.png) [@rec](https://bnd.discourse.group/u/rec)\ **Post date:** [March 13, 2024, 6:02am UTC](https://bnd.discourse.group/t/excluding-automatically-injected-custom-version-annotation-from-baselining/427/3 "2024-03-13T06:02:22Z")
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](https://siom79.github.io/japicmp/MavenPlugin.html) in japicmp). I am using that plugin, but using the level `MINOR` in that setting because that works better in my environment. ---
**Author:** ![pkriens](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/pkriens/32/3_2.png) [@pkriens](https://bnd.discourse.group/u/pkriens)\ **Post date:** [March 13, 2024, 8:21am UTC](https://bnd.discourse.group/t/excluding-automatically-injected-custom-version-annotation-from-baselining/427/4 "2024-03-13T08:21:48Z")
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. ---
**Author:** ![rec](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/rec/32/155_2.png) [@rec](https://bnd.discourse.group/u/rec)\ **Post date:** [March 13, 2024, 8:28am UTC](https://bnd.discourse.group/t/excluding-automatically-injected-custom-version-annotation-from-baselining/427/5 "2024-03-13T08:28:07Z")
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… 😉 ---
**Author:** ![rec](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/rec/32/155_2.png) [@rec](https://bnd.discourse.group/u/rec)\ **Post date:** [March 13, 2024, 8:47am UTC](https://bnd.discourse.group/t/excluding-automatically-injected-custom-version-annotation-from-baselining/427/6 "2024-03-13T08:47:12Z")
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` ```auto 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 <>: 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: but was: 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… ---
**Author:** ![rec](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/rec/32/155_2.png) [@rec](https://bnd.discourse.group/u/rec)\ **Post date:** [March 13, 2024, 4:44pm UTC](https://bnd.discourse.group/t/excluding-automatically-injected-custom-version-annotation-from-baselining/427/7 "2024-03-13T16:44:16Z")
> > > \- Added new parameter to baseline mojo > \- Added additional test to BaselineTest > … > \- Added additional baseline plugin integration test ---
**Author:** ![rec](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/rec/32/155_2.png) [@rec](https://bnd.discourse.group/u/rec)\ **Post date:** [March 14, 2024, 6:22am UTC](https://bnd.discourse.group/t/excluding-automatically-injected-custom-version-annotation-from-baselining/427/8 "2024-03-14T06:22:56Z")
Argh… even just adding the OSGI package version annotations to `package-info.java` triggers the baseline plugin to require a micro bump… ---
**Author:** ![pkriens](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/pkriens/32/3_2.png) [@pkriens](https://bnd.discourse.group/u/pkriens)\ **Post date:** [March 14, 2024, 1:36pm UTC](https://bnd.discourse.group/t/excluding-automatically-injected-custom-version-annotation-from-baselining/427/9 "2024-03-14T13:36:14Z")
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. ---
**Author:** ![rec](https://yyz2.discourse-cdn.com/free1/user_avatar/bnd.discourse.group/rec/32/155_2.png) [@rec](https://bnd.discourse.group/u/rec)\ **Post date:** [March 14, 2024, 1:55pm UTC](https://bnd.discourse.group/t/excluding-automatically-injected-custom-version-annotation-from-baselining/427/10 "2024-03-14T13:55:49Z")
I use the [`enhance` goal of the Apache uimaFIT Maven Plugin](https://uima.apache.org/d/uimafit-current/fit.html#_enhance_goal) which adds the version of the Maven project as a runtime annotation on the any Apache UIMA component classes using the [`@ResourceMetaData`](https://github.com/apache/uima-uimafit/blob/rel/uimafit-3.5.0/uimafit-core/src/main/java/org/apache/uima/fit/descriptor/ResourceMetaData.java) annotation. ```auto /** * 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.