You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Karl M. Davis (JIRA)" <ji...@codehaus.org> on 2010/10/22 18:35:33 UTC

[jira] Updated: (MNG-4872) Dependency exclusions not always honored for dependencies with classifier

     [ http://jira.codehaus.org/browse/MNG-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karl M. Davis updated MNG-4872:
-------------------------------

    Attachment: myproj.zip

Sorry, had planned to but needed sleep last night. Here you are.

> Dependency exclusions not always honored for dependencies with classifier
> -------------------------------------------------------------------------
>
>                 Key: MNG-4872
>                 URL: http://jira.codehaus.org/browse/MNG-4872
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Dependencies
>    Affects Versions: 2.2.1
>         Environment: Windows 7 64bit, Java 1.6 32bit
>            Reporter: Karl M. Davis
>            Priority: Blocker
>         Attachments: myproj.zip
>
>
> 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