[
https://issues.apache.org/jira/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578899#comment-15578899
]
Michael Osipov edited comment on MNG-4142 at 10/15/16 11:11 PM:
----------------------------------------------------------------
I need to revert my previous statement partially. I have found probably the
issue why this is caused. Initially I thought that this is MNG-4343, but it
isn't. It is the Clover Maven Plugin. First of all, I have updated to 4.1.2 to
reproduce with the attached usecase. The issue is located as well as in the
plugin but also in the sample project configuration. At runtime [clover
replaces the main artifact with a classified
one|https://docs.atlassian.com/maven-clover2-plugin/latest/xref/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.html#467].
This happens in {{pre-site}} phase. Unfortunately, the author of the sample
project added {{module1}} as a dependency of {{module2}}, but forgot to add the
classifier. If you now run with added classifier, the stuff works. It can never
ever work the way it is configured now because there is no unclassified main
artifact to depend upon due to Clover plugin.
Upshot: this is a misconfiguration in your POMs.
If some one now still thinks that this will fail even if a main and a side
artifact exist, please create a proper sample project.
was (Author: michael-o):
I need to revert my previous statement partially. I have found probably the
issue why this is caused. Initially I thought that this is MNG-4343, but it
isn't. It is the Clover Maven Plugin. First of all, I have updated to 4.1.2 to
reproduce with the attached usecase. The issue is located as well as in the
plugin but also in the sample project configuration. At runtime clover replaces
the main artifact with a classified one. This happens in {{pre-site}} phase.
Unfortunately, the author of the sample project added {{module1}} as a
dependency of {{module2}}, but forgot to add the classifier. If you now run
with added classifier, the stuff works. It can never ever work the way it is
configured now because there is no unclassified main artifact to depend upon
due to Clover plugin.
Upshot: this is a misconfiguration in your POMs.
If some one now still thinks that this will fail even if a main and a side
artifact exist, please create a proper sample project.
> Maven doesn't try to download a dependency when it already exists a version
> with classifier locally
> ---------------------------------------------------------------------------------------------------
>
> Key: MNG-4142
> URL: https://issues.apache.org/jira/browse/MNG-4142
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
> Reporter: Arnaud HERITIER
> Priority: Critical
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier,
> and not the principal artifact, it won't try in a reactor to download the
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
> Missing:
> ----------
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1)
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2)
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> ----------
> 1 required artifact is missing.
> for artifact:
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
> central (http://maven-proxy.groupe.generali.fr/all),
> remote-repo
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I
> thought it was due to a problem with metadata sent by archiva, but after
> migrating to nexus the problem always occurs.
> I don't know if the problem is in metadata or in the reactor itself. I think
> it is the second one. There are many issues opened about the reactor and
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
