[jira] Closed: (MNG-4961) CLONE -Dependency exclusions not always honored for dependencies with classifier

["Benjamin Bentmann (JIRA)" <ji...@codehaus.org>]

     [ 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