[
https://issues.apache.org/jira/browse/CURATOR-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15808753#comment-15808753
]
Jordan Zimmerman commented on CURATOR-200:
------------------------------------------
The problem is that those 3 classes are part of Curator's public API - so we
can't move them. The good news is that it's very unlikely that Guava will move
these. Even if they do we can shade them into one of the Curator JARs at the
same FQPN.
> Proposal: Remove references to guava library from public APIs
> -------------------------------------------------------------
>
> Key: CURATOR-200
> URL: https://issues.apache.org/jira/browse/CURATOR-200
> Project: Apache Curator
> Issue Type: Improvement
> Components: Framework
> Reporter: Mike Drob
> Assignee: Jordan Zimmerman
> Fix For: 3.2.2, 2.11.2
>
>
> There was a good discussion on the mailing list:
> http://curator.markmail.org/thread/yjete2ozm32jmz5u
> The critical portion copied here:
> {quote}
> 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
> {quote}
> In the ensuing discussion, it sounded like we'd need to get started on an
> implementation before we had enough information to determine whether the
> changes are too intrusive or not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
