[ https://jira.codehaus.org/browse/MENFORCER-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Izyurov updated MENFORCER-165: ----------------------------------------- Attachment: MENFORCER-165-maven-enforcer-plugin.patch > No duplicate classes rule > ------------------------- > > Key: MENFORCER-165 > URL: https://jira.codehaus.org/browse/MENFORCER-165 > Project: Maven Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules > Affects Versions: 1.4, 2.0 > Reporter: Alexander Izyurov > Attachments: MENFORCER-165-maven-enforcer-plugin.patch > > > A typical problem in dependency management is caused by artifacts with > different groupId and/or artifactId containing classes with the same fully > qualified names. DependencyConvergence and RequireUpperBoound rules cannot > handle this kind of conflict. Examples are: > Group renamed but classes remain the same: org.jdom:jdom:jar:1.1 and > jdom:jdom:jar:1.0 > Classes moved to another project: org.hamcrest:hamcrest-core:jar:1.1 and > junit:junit:jar:4.10 > Different sources of synonimic classes: xerces:xmlParserAPIs:jar:2.6.2 > xml-apis:xml-apis:jar:1.0.b2 > "All" jar and partial jar are both in dependencies (probably via transitive > dependencies): org.codehaus.xfire:xfire-core:jar:1.2.6 and > org.codehaus.xfire:xfire-all:jar:1.2.6 - this conflict seems harmless, the > previous 3 may cause unpredictable results. > The solution is to have NoDuplicateClasses rule, which detects conflicts of > this kind. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira