[
http://jira.codehaus.org/browse/MNG-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4961.
----------------------------------
Resolution: Duplicate
bq. 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
3.0-beta-1 fixes MNG-4872, as you would know if you had actually tried the
example project provided by the reporter.
Finally note that the authorative source for the release notes is this issue
tracker, there will never be updates to release notes posted in other places
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=16089
> 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
