[
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
