[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199246#comment-16199246
 ] 

ASF GitHub Bot commented on ZOOKEEPER-2915:
-------------------------------------------

Github user afine commented on the issue:

    https://github.com/apache/zookeeper/pull/396
  
    @phunt Egah. This patch is correct and I fixed the other one (the one based 
on master). 
    
    The end result of this patch should be, when running the tests, all 
dependencies from ivy should be available in one directory (build/test/lib) and 
build/lib should NOT be in the classpath. 


> 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)

Reply via email to