I don’t have an objection in general. The biggest problem for me is that I know very little about OSGI. All of the OSGI work has been contributed so it’s hard to make sure that we keep it working. That said, changing existing APIs is very disruptive to the Curator community. I’d like to see someone (Simon?) commit to maintaining the OSGi compatibility of Curator and make sure releases don’t introduce issues. Also, can the existing APIs remain and new, OSGi compatible parallel APIs be added?
-JZ On March 31, 2015 at 7:39:08 AM, Simon Kitching ([email protected]) wrote: Hi, I've noticed that several curator classes expose the use of classes from google's guava library [1] as part of their *public* api. [1] maven artifact "com.google.guava:guava" which contains java packages com.google.common.* In an OSGi environment, it is possible to load multiple different versions of the same library, as long as that library is a purely internal implementation detail. Unfortunately, as curator exposes its use of guava, this makes it impossible for code that uses curator to also use a different version of Guava for its own purposes. Unfortunately, this has just bitten me : I need to write code that uses both curator (requires guava 16.0 or later) and a third-party library that requires an earlier version of guava. Are there any objections to me raising an enhancement issue in JIRA for this? Note that this change would be a binary incompatibility (though fairly limited). The problem classes that I have found are: * curator-framework: org.apache.curator.framework.listen.ListenerContainer : method forEach takes a parameter of type com.google.common.base.Function * curator-framework: org.apache.curator.framework.api.transaction.CuratorTransactionResult : method ofTypeAndPath returns com.google.common.base.Predicate * curator-x-discovery-server: org.apache.curator.x.discovery.server.contexts.GenericDiscoveryContext : constructor takes param of type com.google.common.reflect.TypeToken * curator-x-discovery: org.apache.curator.x.discovery.InstanceFilter : inherits from com.google.common.base.Predicate And by the way, I noticed that org.codehaus.jackson types are also used in public APIs (at least, GenericDiscoveryContext). It may also be worth looking into whether it is really necessary to expose this dependency. The goal of the change would be to ensure that in the MANIFEST.MF file for each curator bundle (jarfile), the Export-Packages line minimises the "uses:=" entries which refer to non-curator packages. A uses-constraint on a package should only be needed when something in the package being exported uses an external type in its public API. As a separate problem, I have noticed that with the 2.7.1 release (at least), the "bnd" tool (via maven-bundle-plugin) is adding entries to the "uses" entries even when the referenced library is purely used internally. I have found a reference (https://github.com/emlun/bnd-uses-strange) that suggests this is a bug which is fixed in later bnd releases. Unfortunately I can find no release-notes for bnd, nor any source-code repository so cannot confirm this. However updating curator/pom.xml to specify the following fixes the "uses" clauses: <maven-bundle-plugin-version>2.5.3</maven-bundle-plugin-version> Thanks & Regards, Simon ________________________________ The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. SmartStream Technologies GmbH, Vienna Twin Tower, Wienerbergstrasse 11, 1100 Vienna, Austria, FN 194340w, HG Wien
