ahgittin commented on pull request #78:
URL: https://github.com/apache/jclouds/pull/78#issuecomment-753944755
@gurkerl83 @gaul @nacx @geomacy This breaks any downstream consumers (such
as Apache Brooklyn) who don't use the _exact_ version of Guava that jclouds
uses. Guava is part of the public API of the project (methods which take
functions etc) so it is important to support a range there. (Also Guava seems
to keep having CVE's against it so it is frequently version-bumped.)
Previously a range of Guava (and okio) packages were allowed, so this is a
regression. I note the `TODO` comments in
7b5c2ae529bee0ed3528df9bc479edde46d9695f about this.
```
<guava.version>22.0</guava.version>
<!-- TODO: this has to be addressed in another feature -->
<guava.osgi.import>com.google.common.*;version="[22.0,30.0.0)"</guava.osgi.import>
<guice.version>4.2.3</guice.version>
<gson.version>2.8.5</gson.version>
<okhttp.version>2.2.0</okhttp.version>
<!-- TODO: this has to be addressed in another feature -->
<okio.osgi.import>okio;version="[1.2.0,1.3)"</okio.osgi.import>
```
This was introduced by the switch from `maven-jar-plugin` to
`bnd-maven-plugin` in 8ac994c2b5d509ca2877efdd77c35881d58ac3e3 as part of this
PR. Obviously the switch to bnd means the import-package range instruction
needs to be configured in a different way.
Is that in the works?
We are blocked from using newer jclouds until this is resolved, as is anyone
trying to use it in an OSGi context unless they can use the exact Guava version.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
