[
http://jira.codehaus.org/browse/MNG-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240640#action_240640
]
Karl M. Davis edited comment on MNG-4872 at 10/22/10 11:38 AM:
---------------------------------------------------------------
Sorry, had planned to but needed sleep last night. Here you are. Just run {{mvn
clean package}} on the root {{myproj}} and then take a look in
{{myproj/myproj-b/target/myproj-b-0.0.1-SNAPSHOT.zip}}. You'll notice that the
supposed-to-be-excluded log4j library is in there. If you comment out the
classifier in {{myproj-b}}'s dependency and re-build, the exclusion works as
expected.
was (Author: karlmdavis):
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
