[
https://issues.apache.org/jira/browse/KAFKA-3061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15112729#comment-15112729
]
Ewen Cheslack-Postava commented on KAFKA-3061:
----------------------------------------------
[~ijuma] I think they could if they could as of 58def1c because if they specify
the full class name, the reflections library is never invoked since we use it
to scan for subclasses of Connector. However, if we also want to, e.g., expose
a REST endpoint for listing available connectors, that will require using
reflections (and this is useful functionality for validating your connector
plugin installation, for getting metadata when we expose more of that, etc). On
the other hand, I guess you could still get by in that case by never invoking
that REST endpoint if you really needed to avoid Guava.
So strictly speaking you should be fine as long as you allow whatever plugin
has a conflicting version to provide the jar and avoid a small amount of
functionality. The real question is whether we think telling people that is a
reasonable response to incompatibilities... I don't have a strong opinion
because at this point it's hard for us to know how many connectors might pull
in Guava via whatever library they are using to connect to the external system.
This might be a case where it's fine to leave it in with these possible
limitations if you encounter a conflict, and if we see too many problems we can
replace it with another library or write that code ourselves.
> Get rid of Guava dependency
> ---------------------------
>
> Key: KAFKA-3061
> URL: https://issues.apache.org/jira/browse/KAFKA-3061
> Project: Kafka
> Issue Type: Bug
> Reporter: Gwen Shapira
>
> KAFKA-2422 adds Reflections library to KafkaConnect, which depends on Guava.
> Since lots of people want to use Guavas, having it in the framework will lead
> to conflicts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
