[
https://issues.apache.org/jira/browse/ZOOKEEPER-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16200454#comment-16200454
]
Hudson commented on ZOOKEEPER-2915:
-----------------------------------
FAILURE: Integrated in Jenkins build ZooKeeper-trunk #3574 (See
[https://builds.apache.org/job/ZooKeeper-trunk/3574/])
ZOOKEEPER-2915: Use "strict" conflict management in ivy (phunt: rev
575e850c4d75191e27368e87ad5945cc5aba673d)
* (edit) build.xml
* (edit) ivy.xml
> Use "strict" conflict management in ivy
> ---------------------------------------
>
> Key: ZOOKEEPER-2915
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2915
> Project: ZooKeeper
> Issue Type: Improvement
> Affects Versions: 3.5.4, 3.6.0, 3.4.11
> Reporter: Abraham Fine
> Assignee: Abraham Fine
>
> Currently it is very difficult to tell exactly which dependencies make it
> into the final classpath of zookeeper. We do not perform any conflict
> resolution between the test and default classpaths (this has resulted in
> strange behavior with the slf4j-log4j12 binding) and have no way of telling
> if a change to the dependencies has altered the transitive dependencies
> pulled down by the project.
> Our dependency list is relatively small so we should use "strict" conflict
> management (break the build when we try to pull two versions of the same
> dependency) so we can exercise maximum control over the classpath.
> Note: I also attempted to find a way to see if I could always prefer
> transitive dependencies from the default configuration over those pulled by
> the test configuration (to make sure that the zookeeper we test against has
> the same dependencies as the one we ship) but this appears to be impossible
> (or at least incredibly difficult) with ivy. Any opinions here would be
> greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
