[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320033#comment-320033
]
Kirk Rasmussen commented on MNG-5435:
-------------------------------------
Ugh it gets even worse. My next idea was to have a simple stand alone project
which contained the problematic artifacts that we needed to be installed before
running the real build.
Running the following project with a blank repo:
{code}
$ mvn -e dependency:resolve
{code}
results in
{code}
Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not
find artifact commons-cli:commons-cli:jar:1.0
at
org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:528)
{code}
It doesn't get much simpler than this:
{code}
<project xmlns="http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
<modelVersion>4.0.0</modelVersion>
<groupId>com.textura.cpms</groupId>
<artifactId>continuous-integration</artifactId>
<version>2.7.0-SNAPSHOT</version>
<packaging>pom</packaging>
<name>Continuous Integration Build Support</name>
<dependencies>
<dependency>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.1.1</version>
</dependency>
</dependencies>
</project>
{code}
> 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
> Attachments: 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:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
