maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Zav'yalov (JIRA)" <j...@codehaus.org>
Subject [jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
Date Fri, 07 Mar 2014 09:36:59 GMT

    [ https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342529#comment-342529
] 

Michael Zav'yalov commented on MNG-5435:
----------------------------------------

Well.
I've found a minor inconsistacy in my configuration files.
There are the following essential parameters for this issue:
1. Definition of mirroring - <mirrorOf>*</mirrorOf>
2. settings.xml - it contain a profile that defines repository and plugin repository.
3. Parent POM in the project that defines both repository and plugin repository explicitly.
Note - the same URL is used everywhere!

I've tested the following combinations of the options:
1. No mirror, plugin repository is NOT defined in settings.xml,  plugin repository is defined
in parent POM - FAIL
2. Mirror is defined, plugin repository is NOT defined in settings.xml,  plugin repository
is defined in parent POM - OK
3. No mirror, plugin repository is defined in settings.xml,  plugin repository is NOT defined
in parent POM - OK !
4. No mirror, plugin repository is defined both in settings.xml and in parent POM - OK

> 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 was sent by Atlassian JIRA
(v6.1.6#6162)

Mime
View raw message