curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Proposal : remove references to guava library from public APIs
Date Tue, 31 Mar 2015 12:38:31 GMT

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 "" which contains java packages*

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
* curator-framework: org.apache.curator.framework.api.transaction.CuratorTransactionResult
: method ofTypeAndPath returns
* curator-x-discovery-server: org.apache.curator.x.discovery.server.contexts.GenericDiscoveryContext
: constructor takes param of type
* curator-x-discovery: org.apache.curator.x.discovery.InstanceFilter : inherits from

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 (
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:

Thanks & Regards,

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message