You have a few alternatives here. * The dependency:tree goal shows the final resolution selection that can help track them. * In an IDE, you have apps such as this which can manage the versions: http://code.google.com/p/q4e/wiki/DependencyAnalysis * You can set the versions to be restrictive, eg [,3.1] will not allow versions > 3.1.
Cheers, Brett 2008/9/24 陈思淼 <[EMAIL PROTECTED]>: > we're in a big company's project, our project combine with other team's jar > dependences. To manage the dependence is a very hard work to do.for example, > our last accident is becourse of ice jar dependence override. > our project denpends on ice 3.1.0, but one of our partner group provide us a > jar which depends on ice 3.2.0.GBK, the ice 3.2.0.GBK is include into the > final ear package. but the 3.2 is redesign the TCP connection method from > long connect to short connect. after it deploy to the website. our web > server fall down for 1 hour becourse of the connection flood. > > My thoughts is to write a plugin to analyze the pom dependence graph ,and > find all the conflicts in the graph. and we manage a list about conflict > resolve rule. for example when ice 3.1 and 3.2 conflicts, in that list, we > force the dependence to be 3.1, if there is conflict not in the list, the > build will fail. > Is this a feasibility way to resolve this problem? or threre is a better way > for me to do so . > -- Brett Porter Blog: http://blogs.exist.com/bporter/
