[
http://jira.codehaus.org/browse/MDEP-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=233666#action_233666
]
Raymond Feng commented on MDEP-275:
-----------------------------------
Coincidentally, I wrote a plugin for the Apache Tuscany project
(tuscany.apache.org) that do the similar job. You can find the code at:
https://svn.apache.org/repos/asf/tuscany/maven-plugins/trunk/maven-dependency-plugin/
It comes with a few additional features over this proposal:
* It can scan jars from a directory
* It groups duplicate classes under the list of artifacts
* It goes one step further to check the size and CRC of the class file and
marks the different cases in the report (potentially we can use BCEL to further
compare the two classes):
* X: the duplicate classes have different size (most likely different versions)
* ?: the duplicate classes have the same size but different CRC (probably the
same version but were built separately)
* : the duplicate classes have the same size and CRC (most likely the same
version).
I think the maven-dependency-plugin should be the place to go. I would like to
work with you guys to get my code merged into this proposal.
> Figuring out duplicate class definitions using the Analyze goal
> ---------------------------------------------------------------
>
> Key: MDEP-275
> URL: http://jira.codehaus.org/browse/MDEP-275
> Project: Maven 2.x Dependency Plugin
> Issue Type: Improvement
> Components: analyze
> Affects Versions: 2.1
> Reporter: Petter Måhlén
> Assignee: Brian Fox
> Attachments: dependency-analyzer.diff, dependency-plugin.diff
>
>
> Hi,
> I've pretty frequently run into issues where changes to the library structure
> of some product (that is, changing the way that classes are grouped into
> libraries) leads to the same classes being defined in more than one place.
> This can lead to system-dependent problems, because different versions of the
> same class are being loaded by different systems.
> I was going to create a new goal for the dependency plugin to check for
> duplicate classes, but when I looked a bit closer at the analyze goal, it
> already had all the information needed to do that check as well, so I came up
> with some changes that add this functionality.
> The intended usage is something like:
> mvn dependency:analyze -DcheckDuplicateClasses
> I get the feeling that I might want to add the ability to exclude certain
> packages (that I might be comfortable are safe to have duplicates of), so I
> added this option too:
> mvn dependency:analyze -DcheckDuplicateClasses -DexcludePrefixes="org.,
> net.sf.cglib, javax.xml, junit."
> The output looks something like:
> [WARNING] Duplicate class definitions found:
> [WARNING] com.shopzilla.common.data.ObjectFactory defined in:
> [WARNING] com.shopzilla.site.url.c14n:model:jar:1.4:compile
> [WARNING] com.shopzilla.common.data:data-model-schema:jar:1.11:compile
> [WARNING] com.shopzilla.site.category.CategoryProvider defined in:
> [WARNING] com.shopzilla.site2.sasClient:sas-client-core:jar:5.47:compile
> [WARNING] com.shopzilla.site2.service:common-web:jar:5.50:compile
> A couple of notes:
> - I was unable to get configuration (setting checkDuplicateClasses, etc.)
> using the pom to work, but I think that might be due to lack of understanding
> on my part.
> - I don't fully understand the effect of calling compileProject() during unit
> tests, but I think it may be sufficient to call it only once for the
> duplicateClasses project, during setUp(). That would speed up the unit tests.
> - I haven't added duplicate class definition checking to the
> AnalyzeReportMojo, because I wanted to get some feedback on whether this
> addition was felt to be valuable before spending any time on that.
> - A lot of the unit test dummy code in the attached diff files needs cleaning
> up, but again I wanted to wait with that until hearing whether this might be
> useful to others.
> - I made an API change in the ProjectDependencyAnalyzer interface, which
> might be an issue if there are other implementations than the default one.
> That change was only needed to support the 'exclude package' feature, which
> might not be super-important.
> Cheers,
> Petter
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
