[
https://jira.codehaus.org/browse/MENFORCER-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=333790#comment-333790
]
Alexander Izyurov edited comment on MENFORCER-165 at 10/8/13 11:06 AM:
------------------------------------------------------------------------
I am suggesting it to be a standard rule because it is a very common problem. I
have been suffering from it for many years. It is very typical that unit-tests
pick up one class while production environment uses another version of the
class with the same name - this is a nightmare. You get mysterious
NoSuchMethodError or irreproducible runtime exceptions. Artifact scope is
ignored by this rule to make sure classes will be the same in all environments.
was (Author: aizyurov):
I am suggesting it to be a standard rule because it is a very common
problem. I have been suffering from it for many years. It is very typical that
unit-tests pick up one class while production environment uses another version
of the class with the same name - this is a nightmare. You get mysterious
NoSuchMethodError or irreproducible runtime exceptions.
> 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
