[
https://issues.apache.org/jira/browse/KAFKA-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002636#comment-15002636
]
Ewen Cheslack-Postava edited comment on KAFKA-2807 at 11/12/15 7:01 PM:
------------------------------------------------------------------------
Turns out the original patch actually broke things. The way the projects are
named with colons is important in gradle and renaming them actually pointed the
projects at the wrong directories.
Fundamentally, the issue turns out to be a limitation of gradle. It identifies
projects by group (i.e. org.apache.kafka) and the last component of the name
(e.g. :connect:tools is identified by the tuple (org.apache.kafka, tools). This
means that having a top-level tools project and tools within a subproject like
connect:tools makes it impossible to get gradle to express a dependency of
:connect:tools on :tools. See
https://discuss.gradle.org/t/dependency-substitution-wrong-with-more-than-one-sub-project-with-same-name/7253/6
was (Author: ewencp):
Turns out the original patch actually broke things. The way the projects are
named with colons is important in gradle and renaming them actually pointed the
projects at the wrong directories.
Fundamentally, the issue turns out to be a limitation of gradle. It identifies
projects by group (i.e. org.apache.kafka) and the last component of the name
(e.g. :connect:tools is identified by the tuple (org.apache.kafka, tools). This
means that having a top-level tools project and tools within a subproject like
connect:tools makes it impossible to get gradle to express a dependency of
:connect:tools on :tools.
> Movement of throughput throttler to common broke upgrade tests
> --------------------------------------------------------------
>
> Key: KAFKA-2807
> URL: https://issues.apache.org/jira/browse/KAFKA-2807
> Project: Kafka
> Issue Type: Bug
> Reporter: Geoff Anderson
> Assignee: Ewen Cheslack-Postava
> Priority: Blocker
> Fix For: 0.9.1.0
>
>
> In order to run compatibility tests with an 0.8.2 producer, and using
> VerifiableProducer, we use the 0.8.2 kafka-run-tools.sh classpath augmented
> by the 0.9.0 tools and tools dependencies classpaths.
> Recently, some refactoring efforts moved ThroughputThrottler to
> org.apache.kafka.common.utils package, but this breaks the existing
> compatibility tests:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/kafka/common/utils/ThroughputThrottler
> at
> org.apache.kafka.tools.VerifiableProducer.main(VerifiableProducer.java:334)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.kafka.common.utils.ThroughputThrottler
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> ... 1 more
> {code}
> Given the need to be able to run VerifiableProducer against 0.8.X, I'm not
> sure VerifiableProducer can depend on org.apache.kafka.common.utils at this
> point in time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
