[jira] Commented: (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
http://jira.codehaus.org/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=187470#action_187470
]
David Rousselie commented on MNG-4142:
--
The problem is that when the Maven resolve the artifact version with
maven-metadata-local.xml when it exists and it resolves it to 1.0.0-SNAPSHOT
whereas only module1-1.0.0-SNAPSHOT-clover.jar (in this exemple). Then when it
try to access the file artifact (module1-1.0.0-SNAPSHOT.jar) and fails, it
tries to get the *same version* on remote repositories whereas it should have
try to resolve the artifact version with data found in
maven-metadata-${remotereponame}.xml before trying to get it from each
repository.
I have attached a small patch (base on revision 805295 in branch maven-2.2.x)
which might not be the best way to correct this bug : while resolving artifact
version, it loads local metadata only if artifact's file exists locally.
Maven doesn't try to download a dependency when it already exists a version
with classifier locally
---
Key: MNG-4142
URL: http://jira.codehaus.org/browse/MNG-4142
Project: Maven 2
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: 2.2.x
Attachments: 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 is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-571) Encoding mismatch error
Encoding mismatch error --- Key: MECLIPSE-571 URL: http://jira.codehaus.org/browse/MECLIPSE-571 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.6 Environment: Windows XP, Maven 2.0.10, Maven-Eclipse-plugin 2.6 Reporter: David Rousselie Priority: Minor Using an UTF-8 pom.xml which declare encoding to ISO-8859-1 in the ?xml header, Maven works fine (ie. mvn install works) but mvn eclipse:eclipse fails with the following exception : [WARNING] could not read workspace project:c:\workspace\.metadata\.plugins\org.eclipse.core.resources\.projects\myproject org.codehaus.plexus.util.xml.pull.XmlPullParserException: only whitespace content allowed before start tag and not \uef (position: START_DOCUMENT seen \uef... @1:1) at org.codehaus.plexus.util.xml.pull.MXParser.parseProlog(MXParser.java:1519) at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1395) at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1093) at org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:187) at org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:83) at org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:48) at org.apache.maven.plugin.eclipse.reader.ReadWorkspaceLocations.readArtefact(ReadWorkspaceLocations.java:341) at org.apache.maven.plugin.eclipse.reader.ReadWorkspaceLocations.readWorkspace(ReadWorkspaceLocations.java:533) at org.apache.maven.plugin.eclipse.reader.ReadWorkspaceLocations.init(ReadWorkspaceLocations.java:94) at org.apache.maven.plugin.eclipse.EclipsePlugin.getWorkspaceConfiguration(EclipsePlugin.java:1784) at org.apache.maven.plugin.eclipse.EclipsePlugin.fillDefaultClasspathContainers(EclipsePlugin.java:1350) at org.apache.maven.plugin.eclipse.EclipsePlugin.setup(EclipsePlugin.java:807) at org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:498) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) The Eclipse plugin should have the same behavior as Maven when reading a pom and the WARNING message should be more explicit and point the project's pom.xml file instead of the project's Eclipse metadata directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
-> [jira] Updated: (MNG-4142) Maven doesn't try to download a dependency wh issues -- Thread -- -- Date -- [jira] Updated: (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally David Rousselie (JIRA) Reply via email to [jira] Updated: (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally David Rousselie (JIRA) Reply via email to [jira] Updated: (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally David Rousselie (JIRA) Reply via email to
