[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342582#comment-342582
]
Jason van Zyl commented on MNG-5435:
------------------------------------
The ids for all repositories just have to be the same, the id does not have to
be "central", that's just what I happen to have. The -llr option forces Maven
to use the SimpleLocalRepositoryManager as opposed to the default
EnhancedLocalRepositoryManager which employs the _remote.repositories tracking
file. In this case I would say that using the enhanced implementation helped
find a configuration error though it would be more helpful to show users where
the misconfiguration is.
> 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)
