[
http://jira.codehaus.org/browse/MNG-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl M. Davis updated MNG-4872:
-------------------------------
Attachment: 2010-10-24-1715-fix-to-maven-project-for-MNG4872.patch
This is a patch for the reported issue. This patch is against the root of
{{maven-project}} in the 2.2.1 tag. If you guys end up doing another 2.2.1
release, I'd greatly appreciate it if you could include these fixes.
Please note that once I'd fixed the lines of code mentioned in the description,
I ran into problems with other methods that made similar assumptions. A lot of
the code in {{maven-project}} neglects to account for anything other than the
project's "main" artifact. I fixed those places that I could find (the ones
that caused my build to go boom) but there are likely others still left.
> 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
> Assignee: Benjamin Bentmann
> Priority: Blocker
> Fix For: 3.0-beta-1
>
> Attachments: 2010-10-24-1715-fix-to-maven-project-for-MNG4872.patch,
> 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
