[
http://jira.codehaus.org/browse/MNG-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250634#action_250634
]
Sunil Kumar Dhage commented on MNG-4961:
----------------------------------------
Hi Benjamin,
I have created clone of MNG 4872, since the fix version(3.0-beta-1) provided
for the issue did not have this issue actually fixed. or might not have
included the bug id in the release notes.
If it has been taken care of, please update the release notes of 3.0-beta-1 or
PLEASE avoid closing issues before they actually fixing the same.
> CLONE -Dependency exclusions not always honored for dependencies with
> classifier
> --------------------------------------------------------------------------------
>
> Key: MNG-4961
> URL: http://jira.codehaus.org/browse/MNG-4961
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
> Affects Versions: 2.2.1
> Environment: Windows 7 64bit, Java 1.6 32bit
> Reporter: Sunil Kumar Dhage
> Assignee: Benjamin Bentmann
> Priority: Blocker
>
> Like the summary says, I've encountered and tracked down a bug that prevents
> dependency exclusions from being honored by plugins when the dependency with
> the exclusions has a classifier. This seems to only occur or surface in
> multi-module builds.
> For example, I have a multi-module project structured as follows:
> {noformat}
> myproj-parent
> myproj-a
> myproj-b
> {noformat}
> If {{myproj-a}} produces a classified artifact (say, an obfuscated JAR via
> ProGuard) and {{myproj-b}} has it as a dependency with exclusions, those
> exclusions will not be honored by plugins run in {{myproj-b}} (say, the
> webstart plugin).
> I think I've tracked the problem down to the
> {{replaceWithActiveArtifact(...)}} method of
> {{org.apache.maven.project.MavenProject}}. Specifically, see [lines 1772
> through
> 1784|http://maven.apache.org/ref/2.2.1/xref/org/apache/maven/project/MavenProject.html#1772].
> The following {{if}} clause does not account for artifacts with classifiers:
> {noformat}
> if ( ref.getArtifact() != null
> && ref.getArtifact().getDependencyConflictId().equals(
> pluginArtifact.getDependencyConflictId() ) )
> {noformat}
> Because the classified {{pluginArtifact}} does not match the _main_ artifact
> of {{ref}}, the artifact is not resolved from the currently building
> project's dependencies. As the method continues, it is instead resolved with
> {{myproj-a}}'s "standard" metadata, which of course don't include the
> exclusions in {{myproj-b}}.
> I've marked this bug a blocker because I can't think of a way around it and
> it's badly polluting one of my project's builds. Due to it, a webstart build
> that only needs 30 artifacts has over 100. I have not yet tried to reproduce
> it in Maven 3.x because our company likely won't be moving to it for a couple
> of months.
--
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
