Maven
  1. Maven
  2. MNG-4142

Maven doesn't try to download a dependency when it already exists a version with classifier locally

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 2.0.9, 2.0.10, 2.1.0
    • Component/s: Dependencies
    • Labels:
      None
    • Environment:
      Java 5, Windows XP
    • Complexity:
      Intermediate
    • Testcase included:
      yes
    • Number of attachments :
      2

      Description

      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

      mvn site

      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 :

      [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)
      

      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 :

      mvn install -f module2/pom.xml

      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.

      1. MNG-4142.patch
        2 kB
        David Rousselie

        Activity

        Hide
        Martin Todorov added a comment -

        I have replied to numerous posts on Stack Overflow concerning this particular issue. People keep hitting this and are unhappy with the current behavior. In the company I work for, we had to make Jenkins use private repositories for each project which would be removed before every build, just for the sake of sanity and for us not losing our minds when a build fails due to this reason.

        The problem here is also observed under Maven 3. Furthermore, it's not a classifier problem. It happens to whatever dependencies you have to modules which you've installed locally.

        My suggestion would be to make the -U option "unlock" the Maven metadata files so that they are fetched from the remote repository.

        I would also appreciate some response from the you guys. What's the problem here that keeps this issue unscheduled for future releases? We haven't received an official comment for a long while. :-|

        Show
        Martin Todorov added a comment - I have replied to numerous posts on Stack Overflow concerning this particular issue. People keep hitting this and are unhappy with the current behavior. In the company I work for, we had to make Jenkins use private repositories for each project which would be removed before every build, just for the sake of sanity and for us not losing our minds when a build fails due to this reason. The problem here is also observed under Maven 3. Furthermore, it's not a classifier problem. It happens to whatever dependencies you have to modules which you've installed locally. My suggestion would be to make the -U option "unlock" the Maven metadata files so that they are fetched from the remote repository. I would also appreciate some response from the you guys. What's the problem here that keeps this issue unscheduled for future releases? We haven't received an official comment for a long while. :-|
        Hide
        nodje added a comment -

        Removing a private repository before each build would indeed solve my problem
        I'm considering the option, since I'm losing my mind with all the build failing due to SNAPSHOT update problem.

        Developers new to Maven in our team don't even understand "SNAPSHOT update", they just think they have to install manually each SNAPSHOT dependency... which messes up even more the whole thing.

        And I insist, our CI server build agents don't install SNAPSHOT locally, and still they fail to retrieve the latest snapshots in many cases.

        It's not a locally installed artifact update problem ONLY.

        Show
        nodje added a comment - Removing a private repository before each build would indeed solve my problem I'm considering the option, since I'm losing my mind with all the build failing due to SNAPSHOT update problem. Developers new to Maven in our team don't even understand "SNAPSHOT update", they just think they have to install manually each SNAPSHOT dependency... which messes up even more the whole thing. And I insist, our CI server build agents don't install SNAPSHOT locally, and still they fail to retrieve the latest snapshots in many cases. It's not a locally installed artifact update problem ONLY.
        Hide
        Cody Fyler added a comment -

        We are experiencing this issue with Maven 3.0.5 on Jenkins with multiple slaves.

        It's kind of a nightmare.

        Can we please get this at least assigned?

        Here is the workaround that I came up with that in my opinion really sucks, but it works.

        http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html#include

        In this case, I use a filter to clear out the SNAPSHOT artifacts that need to be updated. But it sucks that I have to do it. And we have a LOT of projects where we are going to have to do something similar.

        Show
        Cody Fyler added a comment - We are experiencing this issue with Maven 3.0.5 on Jenkins with multiple slaves. It's kind of a nightmare. Can we please get this at least assigned? Here is the workaround that I came up with that in my opinion really sucks, but it works. http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html#include In this case, I use a filter to clear out the SNAPSHOT artifacts that need to be updated. But it sucks that I have to do it. And we have a LOT of projects where we are going to have to do something similar.
        Hide
        nodje added a comment -

        Good luck, you just have to live with it or spend the time to understand the Maven sources by yourself.
        See Martin Todorov comments for a work around.

        Show
        nodje added a comment - Good luck, you just have to live with it or spend the time to understand the Maven sources by yourself. See Martin Todorov comments for a work around.
        Hide
        John Chatham added a comment -

        Ran into this issue recently on maven 3.0.4; our workaround was to update to maven 3.2.1, where there's a new property one can set: maven.install.skip

        Set that to true, either with -Dmaven.install.skip or (how we did it) by adding a property entry in the maven settings file our jenkins build was using, and that fixed that; we build and deploy our snapshots, but don't install them into the local repositories.

        Show
        John Chatham added a comment - Ran into this issue recently on maven 3.0.4; our workaround was to update to maven 3.2.1, where there's a new property one can set: maven.install.skip Set that to true, either with -Dmaven.install.skip or (how we did it) by adding a property entry in the maven settings file our jenkins build was using, and that fixed that; we build and deploy our snapshots, but don't install them into the local repositories.

          People

          • Assignee:
            Unassigned
            Reporter:
            Arnaud Heritier
          • Votes:
            72 Vote for this issue
            Watchers:
            39 Start watching this issue

            Dates

            • Created:
              Updated: