You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Brian Fox (JIRA)" <ji...@codehaus.org> on 2008/02/16 07:28:29 UTC
[jira] Commented: (MNG-3259) Regression: Maven drops dependencies
in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123975 ]
Brian Fox commented on MNG-3259:
--------------------------------
The issue is in the maven-artifact resolver.DefaultArtifactCollector in this vicinity of this line:
{noformat}
// Also, we need to ensure that any exclusions it presents are
// added to the artifact before we retrive the metadata
// for the artifact; otherwise we may end up with unwanted
// dependencies.
Artifact ma = (Artifact) managedVersions.get( childKey );
ArtifactFilter managedExclusionFilter = ma.getDependencyFilter();
if ( null != managedExclusionFilter )
{
System.out.println("Adding Exclusion Filter:"+ma);
if ( null != artifact.getDependencyFilter() )
{
AndArtifactFilter aaf = new AndArtifactFilter();
aaf.add( artifact.getDependencyFilter() );
aaf.add( managedExclusionFilter );
artifact.setDependencyFilter( aaf );
}
else
{
artifact.setDependencyFilter( managedExclusionFilter );
}
}
}
{noformat}
I believe the scope transformation is taking place before the exclusion is processed, thus the artifact is first dumped out of the compile classpath and then erroneously excluded.
> Regression: Maven drops dependencies in multi-module build
> ----------------------------------------------------------
>
> Key: MNG-3259
> URL: http://jira.codehaus.org/browse/MNG-3259
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
> Affects Versions: 2.0.7, 2.0.8
> Reporter: Joerg Schaible
> Assignee: Brian Fox
> Priority: Blocker
> Fix For: 2.0.9
>
> Attachments: MNG-3259-2.zip, MNG-3259.zip
>
> Time Spent: 5 hours
> Remaining Estimate: 0 minutes
>
> Under some circumstances Maven "forgets" about test dependencies in multi-module builds. The affected module can be build only if the build is started from its local project directory. If the build is run from a parent directory, the test fails because of missing classes. This issue applies to M207 and recent M208-RC1, the project can be build without problems with M205 (M206 is completely bogus). The problem was for us already the show stopper for M207 and I thought with some of the now resolved issues it has been gone, but I was wrong. I did not report it earlier, because I was never able to reproduce the problem with a minimal build ... until now and it took me about 3 days to create a demonstrating multi module project.
--
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