You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Jason van Zyl (JIRA)" <ji...@codehaus.org> on 2014/01/23 20:04:49 UTC

[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.

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

Jason van Zyl updated MNG-5435:
-------------------------------

    Fix Version/s: Issues to be reviewed for 4.x
    
> Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: MNG-5435
>                 URL: https://jira.codehaus.org/browse/MNG-5435
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Artifacts and Repositories, Dependencies
>    Affects Versions: 3.0.4
>            Reporter: Kirk Rasmussen
>            Priority: Blocker
>             Fix For: Issues to be reviewed for 4.x
>
>         Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml, simple.zip
>
>
> This is a twofer bug report :)
> Issue #1:
> I have included a stripped down version of an example using the maven antrun plugin to spawn the Antlr tool. For technical reasons we cannot use the native maven Antlr plugin.
> If you look at the attached project you will see that Antlr is a dependency of both the antrun plugin:
> {code}
> ...
> <build>
>   <plugins>		
>     <plugin>
>       <groupId>org.apache.maven.plugins</groupId>
>       <artifactId>maven-antrun-plugin</artifactId>
>         <dependencies>				
>           <dependency>
>           <groupId>org.antlr</groupId>
>           <artifactId>antlr</artifactId>
>           <version>${antlr.version}</version>
>         </dependency>					
> ...
> {code}
> And the project itself:
> {code}
> ...
> <dependencies>
>   <dependency>
>     <groupId>org.antlr</groupId>
>     <artifactId>antlr</artifactId>
>    </dependency>
> </dependencies>
> ...
> {code}
> Starting with a blank M2 local repo, and then running
> $ mvn -e -X -U clean install -s settings.xml  > /tmp/maven.log
> Results in failure:
> Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact org.antlr:antlr:jar:3.4
> However this artifact was indeed downloaded (first as a project dependency). I stepped through some of the Maven code and it appears to fail during the second run through org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin dependency.
> I strongly suspect it has to do with how org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is implemented. It sees the file but it is not being tracked correctly I believe so it ignores it.
> If you run the build a second time it will then succeed because the Antlr artifacts will be available as they are in the local repo from the previous run.
> $ mvn -e -X -U clean install -s settings.xml  > /tmp/maven2.log
> I observed the exact same problem when using the Maven enforcer plugin along with TestNG as they both depend on beanshell and with the Maven GWT plugin and GWT project dependencies.
> This was discovered as an issue once we started clearing out our local repo. Once the artifacts are populated locally the issue goes away. It takes a couple of runs to get past the bogus "missing artifact" errors but after that it is ok. It's difficult to predict when it will fail w/o being intimately familiar with all plugin/project dependencies per project.
> I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It also works fine if it's only a project dependency. It's the combination of having it both as a plugin AND a project dependency causes this problem.
> #2
> My first thought to get around issue #1 was to use dependency:resolve as a pre-build step after cleaning the local repo but that doesn't full solve the problem.
> Using the Mavan dependency:resolve and dependency:resolve-plugins goals partially sidesteps issue #1 but it still gets confused about inter-module dependencies.
> For example I have a simple multi-module project that includes: foo-module, bar-module, and baz-module (see simple.zip). 
> Running:
> $ mvn dependency:resolve dependency:resolve-plugins -s settings.xml
> Results in a build failure on the baz-module:
> [INFO] acme-pom .......................................... SUCCESS [6.835s]
> [INFO] foo-module ........................................ SUCCESS [1.327s]
> [INFO] bar-module ........................................ SUCCESS [0.090s]
> [INFO] baz-module ........................................ FAILURE [0.012s]
> This seems to avoid issue #1 as it doesn't complain about missing Antlr artifacts anymore but it gets stuck on the baz-module with the error:
> [ERROR] Failed to execute goal on project baz-module: Could not resolve dependencies for project com.acme:baz-module:jar:4.0.0-SNAPSHOT: The following artifacts could not be resolved: com.acme:foo-module:jar:4.0.0-SNAPSHOT, com.acme:bar-module:jar:4.0.0-SNAPSHOT: Could not find artifact com.acme:foo-module:jar:4.0.0-SNAPSHOT -> [Help 1]
> In our real projects there are many more modules which don't get resolved after this first failure so the local repo becomes only partially populated. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira