client_java
client_java copied to clipboard
prometheus
Increase Guava version range
Since Guava 21 Guava promised to no longer make breaking changes. I think the simpleclient_guava is compatible with Guava 18.0 onward - so the version import should reflect that. At least an OSGi version range from 18 to 24 would be good. Ideally the version range is extended into the future to accommodate future releases. Not sure what version makes sense but probably at least 26 could be done (or directly 30)
What exact change are you proposing? We have to choose a single version number to run our tests against, and we purposefully use an older version to prevent accidentally depending on new features.
sure, just to add a bundle-plugin <Import-Package> instruction with the increased version-range. I'm creating a patch right now which will show it :)
Attached PR is a first draft. I have not tested it in our env yet. Will do and add a comment here with the outcome, but feel free to check it yourself.
It should only affect the MANIFEST.MF and change com.google.common.cache;version="[18.0,19)" to com.google.common.cache;version="[18.0,30)"
I'm not a fan of adding metadata that only one particular packaging systems can use, that path leads to a lot of maintenance for the numerous packaging systems that are out there.
Without that (nearly) nobody in the OSGi world can use it. It would be a very rare circumstance where you'd end up with exactly the right Guava version for that.
By the way, I've verified and it works (we currently use Guava 21)
Still this is an issue when you have multiple Guavas deployed. One needs to make sure that simpleclient_guava is wired against the same version as the consumer which calls "addCache" - otherwise it'll end up in a class cast exception. That issue is not related to my PR, but can also occur if you have Guava 18.0 and Guava 18.1 deployed with the current version.
Maybe the API needs to be redesigned so that you do not have one metric with the cache being a label but each cache has it's own metric name - with that it might be possible to use the classloader of the caller to resolve the Cache class and then be able to work with multiple versions. But that definitely would be a larger change.
Our expectation is that future versions are backwards compatible, and the user will use whatever version they want rather than the one listed in our pom.
But with OSGi you cannot - OSGi won't resolve that bundle if anything other than Guava 18 is present. Thats the whole point of the OSGi headers. So you either need to tell the maven-bundle-plugin to omit the version (in that case you will use the latest version of Guava which is available, so it might also be a Guava older than 18) or give an explicit version range. Both require that those metadata is placed somewhere. By default the maven-bundle-plugin assumes semantic versioning and that means if you compile / test against version 18(.0.0 as OSGi always uses 3 digit versions) you will work from 18.0.0 to not including 19.0.0 (major version changes indicate breaking API). Unfortunately Guava does NOT follow semantic versioning guidelines hence the defaults of the maven-bundle-plugin are just wrong here.
As I said I'm not willing to start adding and maintaining metadata for various bundling systems, particularly for things that I have no way to test.
In that case I'd recommend to remove the OSGi headers altogether. Broken headers are worse than no headers. I think this could be done by changing the guava submodule to jar instead of bundle. That should make that particular submodule non-OSGi while leaving the others intact.
Not necessarily - as I said, we could change the type to jar only for the simpleclient_guava submodule. It only affects those submodules using dependencies which do not do semantic versioning correctly. If Guava would follow semver the defaults of the maven-bundle-plugin would be fine.
