maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Wesdorp (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 Tue, 04 Mar 2014 21:31:00 GMT

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

Chris Wesdorp edited comment on MNG-5435 at 3/4/14 3:30 PM:
------------------------------------------------------------

On my environment I encounter the same issue in combination with the maven-checkstyle-plugin.
The work around seems to be to remove all the state files (lastUpdated) from the m2 repo folder
that holds my JAR file. The workaround for now is to use the maven dependency plugin to extract
the checkstyle.xml from the other JAR. 

I use Maven 3.0.3 but it also happens with 3.1.1.

Are the any clues to where the case of this issue can be found?



was (Author: chriswesdorp):
On my environment I encounter the same issue in combination with the maven-checkstyle-plugin.
The work around seems to be to remove all the state files (lastUpdated) from the m2 repo folder
that holds my JAR file. The workaround for now is to use the maven dependency plugin to extract
the checkstyle.xml from the other JAR. 

Are the any clues to where the case of this issue can be found?


> 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