On 04/08/2015 10:57 PM, Benjamin Abernathy wrote:
> Stefan,
>
> I think I have found a reasonable solution. I implemented it and it
> passes the integration tests as well as solves the problem I am
> experiencing in OSGi. Here is what I did.
>
> 1. I updated the parent pom by adding the following properties:
>
> <slf4j.api.version.min>1.7</slf4j.api.version.min>
> <slf4j.api.version.max>1.8</slf4j.api.version.max>
>
> 2. Then in each child pom that had an import declaration for org.slf4j,
> I changed the import statement from:
>
> org.slf4j;version=${slf4j.api.version},
>
> to:
>
> org.slf4j;version="[${slf4j.api.version.min},${slf4j.api.version.max})",
>
>
> This approach has some drawbacks:
>
> 1. You now have three places that may need to be updated when the
> version of slf4j is updated.
> 2. BND (which is called by maven-bundle-plugin) is not the one deciding
> the what version should be used.
>
> Now, supposedly BND can choose a version range, but I could not get
> consistent behavior from the build using that approach.
You mean the following? I tried to use BND range macro which magically
works:
org.slf4j;version="$«range;[==,=+)»",
The result in mainifest is then org.slf4j;version="[1.7,1.8)"
But I didn't find lot of documenation why it works. And the maven build
prints out a warning (but still it works):
[INFO] --- maven-bundle-plugin:2.5.3:bundle (default-bundle) @
api-ldap-model ---
[WARNING] Bundle
org.apache.directory.api:api-ldap-model:bundle:1.0.0-M30-SNAPSHOT : No
translation found for macro: range;[==,=+), in
> The changes are pretty simple, although it does touch the majority of
> the POMs. Let me know if you'd like to me submit a patch.
>
> Thanks,
>
> Ben
>
