Maven
  1. Maven
  2. MNG-5185

Improve "missing dependency" error message when _maven.repositories/_remote.repositories contains other repository ids than requested

    Details

    • Type: Improvement Improvement
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.2, 3.0.3, 3.0.4
    • Component/s: None
    • Labels:
      None

      Description

      Based on a discussion on the users list [1], Maven 3 has changed how it resolves artifacts from local repositories. Unfortunately, when "conflicts" arise (GAV is cached in local repo, but restricted to some repository ids, and actual POM has no matching repository id declared), Maven just tells the user that the artifact could not be resolved.

      This leads to confusion from users who find the .jar files in their local repository without knowing this restriction feature: they just get frustrated and complain that "maven sucks".

      It would be good if Maven was updated with some improved error messages along the lines of:

      "The (GAV) artifact was found in your local repository, but came from remote repository "xxx": either configure this in your pom with (insert sample XML block in error message), or in your "yyy" mirror."

      The "mirror" section of the error message should be included if the current ~/.m2/settings.xml declares a mirror. By improving the messages here we can help the users move on to building software, rather than pulling out their hair

      [1] http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html

        Issue Links

          Activity

          Hide
          Tim Molter added a comment -

          Improving this error message would be a very quick change and would save people like me literally hours of frustration. I'm sure this issue turns people away from Maven. I blogged about this issue here: http://obscuredclarity.blogspot.com/2012/05/using-maven-offline.html, in hopes other people will find the solution faster. Improving this error message is a no-brainer.

          Show
          Tim Molter added a comment - Improving this error message would be a very quick change and would save people like me literally hours of frustration. I'm sure this issue turns people away from Maven. I blogged about this issue here: http://obscuredclarity.blogspot.com/2012/05/using-maven-offline.html , in hopes other people will find the solution faster. Improving this error message is a no-brainer.
          Hide
          Hervé Boutemy added a comment -

          Improving this error message would be a very quick change

          do you have a patch? I can apply it

          Show
          Hervé Boutemy added a comment - Improving this error message would be a very quick change do you have a patch? I can apply it
          Hide
          Joseph Walton added a comment -

          Aether doesn't make it easy to expose this information back to Maven. I've attached a simple patch to Sonatype Aether to log when this is encountered.

          Show
          Joseph Walton added a comment - Aether doesn't make it easy to expose this information back to Maven. I've attached a simple patch to Sonatype Aether to log when this is encountered.
          Hide
          Devin Reid added a comment -

          Just got bit by this one. I have using '-Dmaven.repo.local' option to create portable builds for working on non-networked (default settings.xml on those boxes) computers and spent about an hour scratching my head as to why this didn't work with Maven3. After deleting all the _maven.repositories it finally worked. This new 'feature' really introduces some headaches for certain uses of maven3.

          So +1 for improving the error message.

          bonus points if this feature could be disabled for offline "mvn -o" builds entirely.

          Show
          Devin Reid added a comment - Just got bit by this one. I have using '-Dmaven.repo.local' option to create portable builds for working on non-networked (default settings.xml on those boxes) computers and spent about an hour scratching my head as to why this didn't work with Maven3. After deleting all the _maven.repositories it finally worked. This new 'feature' really introduces some headaches for certain uses of maven3. So +1 for improving the error message. bonus points if this feature could be disabled for offline "mvn -o" builds entirely.
          Hide
          Olivier Lamy (*$^¨%`£) added a comment -

          option to disable that and disable it when building offline ?

          Show
          Olivier Lamy (*$^¨%`£) added a comment - option to disable that and disable it when building offline ?
          Hide
          Olivier Lamy (*$^¨%`£) added a comment -

          pushed
          can be desactivated using:

          • new cli option: slrm,-simple-local-repository-manager
          • or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
          Show
          Olivier Lamy (*$^¨%`£) added a comment - pushed can be desactivated using: new cli option: slrm, -simple-local-repository-manager or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true
          Hide
          Olivier Lamy (*$^¨%`£) added a comment -
          Show
          Olivier Lamy (*$^¨%`£) added a comment - will be available here: https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x/ build #368
          Hide
          Arnaud HERITIER added a comment -

          Reopen as there is a discussion in progress about the proposed fix : http://maven.40175.n5.nabble.com/Pain-with-MNG-5181-maven-repositories-td5743021.html

          Show
          Arnaud HERITIER added a comment - Reopen as there is a discussion in progress about the proposed fix : http://maven.40175.n5.nabble.com/Pain-with-MNG-5181-maven-repositories-td5743021.html
          Hide
          Jeff MAURY added a comment -

          The main problem with this "feature" is that it is not documented thus I
          can't explain the real reason why Maven download several times released
          artifacts and this causes members of the Maven bashing group to grow

          See http://maven.40175.n5.nabble.com/Pain-with-MNG-5181-maven-repositories-tp5743021p5745327.html

          Show
          Jeff MAURY added a comment - The main problem with this "feature" is that it is not documented thus I can't explain the real reason why Maven download several times released artifacts and this causes members of the Maven bashing group to grow See http://maven.40175.n5.nabble.com/Pain-with-MNG-5181-maven-repositories-tp5743021p5745327.html
          Hide
          Robert Scholte added a comment -

          options have been renamed to --llr, -legacy-local-repository and -Dmaven.legacyLocalRepository

          Show
          Robert Scholte added a comment - options have been renamed to --llr, -legacy-local-repository and -Dmaven.legacyLocalRepository
          Hide
          Stephen Connolly added a comment -

          Thinking about this some more, what users probably want is a way to mark specific repository ids as offline.

          Most of the cases where -Dmaven.legacyLocalRepository is required are, IMHO, where the user is not connected to the corporate VPN and so resolution against the corporate repo should not be attempted because it is "offline"

          The "legacy" behaviour is really a global switch for all repositories, much better IMHO is

          -Dmaven.repositories.offline=central,java.net2,...
          

          or

          -Dmaven.repository.offline.central
          -Dmaven.repository.offline.java.net2
          

          Now it may not be possible to implement this way with the current Aether, but I think this is more the solution we should be heading towards.

          Another way would be to have a repository-status file on disk that contained the list of repository id's and their on-line/off-line status... or even an extension to allow querying... so that users could plug a vpn status detector into their maven installation and have auto-just-works

          Show
          Stephen Connolly added a comment - Thinking about this some more, what users probably want is a way to mark specific repository ids as offline. Most of the cases where -Dmaven.legacyLocalRepository is required are, IMHO, where the user is not connected to the corporate VPN and so resolution against the corporate repo should not be attempted because it is "offline" The "legacy" behaviour is really a global switch for all repositories, much better IMHO is -Dmaven.repositories.offline=central,java.net2,... or -Dmaven.repository.offline.central -Dmaven.repository.offline.java.net2 Now it may not be possible to implement this way with the current Aether, but I think this is more the solution we should be heading towards. Another way would be to have a repository-status file on disk that contained the list of repository id's and their on-line/off-line status... or even an extension to allow querying... so that users could plug a vpn status detector into their maven installation and have auto-just-works
          Hide
          Devin Reid added a comment -

          When I'm using a corporate repository, all maven artifact resolution gets proxied through the corporate repository so the ability to turn off individual repositories by id is of limited utility to users with that workflow because they only have one repository id (configured as a mirror with <mirrorOf>*</mirrorOf> in settings.xml).

          What -Dmaven.legacyLocalRepository restores, for me at least, is the ability to stage an offline build for a project on a connected box and then move the project and the local repository to another box with no network access (and likely no maven settings configuration) and still be able to build the project in offline mode.

          Show
          Devin Reid added a comment - When I'm using a corporate repository, all maven artifact resolution gets proxied through the corporate repository so the ability to turn off individual repositories by id is of limited utility to users with that workflow because they only have one repository id (configured as a mirror with <mirrorOf>*</mirrorOf> in settings.xml). What -Dmaven.legacyLocalRepository restores, for me at least, is the ability to stage an offline build for a project on a connected box and then move the project and the local repository to another box with no network access (and likely no maven settings configuration) and still be able to build the project in offline mode.
          Hide
          Stephen Connolly added a comment -

          Your corporate repository has an ID, so when off-VPN you would just go

          -Dmaven.repository.offline.corp-mirror
          

          And then all your corporate artifacts will not be attempted to re-download... oh that repo is missing... oh fail the build.

          -Dmaven.legacyLocalRepository is just a hack on top of a hack, what I am pointing is a solution to the first hack that removes the need for the second.

          Show
          Stephen Connolly added a comment - Your corporate repository has an ID, so when off-VPN you would just go -Dmaven.repository.offline.corp-mirror And then all your corporate artifacts will not be attempted to re-download... oh that repo is missing... oh fail the build. -Dmaven.legacyLocalRepository is just a hack on top of a hack, what I am pointing is a solution to the first hack that removes the need for the second.
          Hide
          Ondra Žižka added a comment - - edited

          Stephen, you hit the nail on the head - it's about VPN in all our cases. I like the idea to be able to switch on/off the repos individually by id.

          Show
          Ondra Žižka added a comment - - edited Stephen, you hit the nail on the head - it's about VPN in all our cases. I like the idea to be able to switch on/off the repos individually by id.
          Hide
          Jason van Zyl added a comment -

          This patch will have to be adapted and integrated into an Aether 1.0 before we absorb it.

          Show
          Jason van Zyl added a comment - This patch will have to be adapted and integrated into an Aether 1.0 before we absorb it.
          Hide
          Joseph Walton added a comment -

          This patch will have to be adapted and integrated into an Aether 1.0 before we absorb it.

          I've updated the patch to apply against the Eclipse aether-core master branch.

          This gets more complicated now Aether and Maven are separate projects: is this a useful change? What would the next steps be to get this into an Eclipse release that Maven could then consume?

          Show
          Joseph Walton added a comment - This patch will have to be adapted and integrated into an Aether 1.0 before we absorb it. I've updated the patch to apply against the Eclipse aether-core master branch. This gets more complicated now Aether and Maven are separate projects: is this a useful change? What would the next steps be to get this into an Eclipse release that Maven could then consume?
          Hide
          Kamil Demecki added a comment -

          This bug shows standard approach took by maven software - don't care about users because "we know how building should work and all build flexibility is prohibited". Maven has long history of being flawed by design - how tool for build can produce different result when running twice? I've been very unlucky working on projects in maven 1, 2 and 3 since 2005 and maven was supposed to do builds in "proper" way replacing "old" ant. After two years break I'm in the maven project again and still offline mode is horror - after over 10 years. Ant with ivy is so much better in good hands (and gradle is on the market). Only good thing coming from maven is nexus and some standardization of project layout but generally maven is very bad tool.

          Show
          Kamil Demecki added a comment - This bug shows standard approach took by maven software - don't care about users because "we know how building should work and all build flexibility is prohibited". Maven has long history of being flawed by design - how tool for build can produce different result when running twice? I've been very unlucky working on projects in maven 1, 2 and 3 since 2005 and maven was supposed to do builds in "proper" way replacing "old" ant. After two years break I'm in the maven project again and still offline mode is horror - after over 10 years. Ant with ivy is so much better in good hands (and gradle is on the market). Only good thing coming from maven is nexus and some standardization of project layout but generally maven is very bad tool.
          Hide
          David Pilato added a comment -

          I'd like to add here my own experience though it could be caused by some bad maven practices.

          I have a project A which defines in its pom.xml a repository with a given id:

          <repository>
             <id>lucene-snapshots</id>
             <url>https://download.elasticsearch.org/lucenesnapshots/1657571</url>
          </repository>
          

          I have a project B which defines in its pom.xml a repository with another id:

          <repository>
             <id>another-id</id>
             <url>https://download.elasticsearch.org/lucenesnapshots/1657571</url>
          </repository>
          

          Because of the _maven.repositories and _remote.repositories files, mvn compile can not work for the second project and the error raised appears super strange: Access denied to: URL_HERE, ReasonPhrase: Forbidden.. Removing local files in ~/.m2/repository fixes the "remote" issue... o_O

          find ~/.m2/repository -name _remote.repositories -exec rm -v {} \;
          find ~/.m2/repository -name _maven.repositories -exec rm -v {} \;
          

          It means here that even though projects A and B might not be related at all, one can not compile because of a repository id in another project.

          I would like to:

          • fix the message and give more clue to the users (it took me multiple hours to find it)
          • fix the way maven deals with those local files in case of you have multiple ids for the same repository. May be try all of them before failing?

          I hope my feedback could help.
          Best!

          Show
          David Pilato added a comment - I'd like to add here my own experience though it could be caused by some bad maven practices. I have a project A which defines in its pom.xml a repository with a given id: <repository> <id> lucene-snapshots </id> <url> https://download.elasticsearch.org/lucenesnapshots/1657571 </url> </repository> I have a project B which defines in its pom.xml a repository with another id: <repository> <id> another-id </id> <url> https://download.elasticsearch.org/lucenesnapshots/1657571 </url> </repository> Because of the _maven.repositories and _remote.repositories files, mvn compile can not work for the second project and the error raised appears super strange: Access denied to: URL_HERE, ReasonPhrase: Forbidden. . Removing local files in ~/.m2/repository fixes the "remote" issue... o_O find ~/.m2/repository -name _remote.repositories -exec rm -v {} \; find ~/.m2/repository -name _maven.repositories -exec rm -v {} \; It means here that even though projects A and B might not be related at all, one can not compile because of a repository id in another project. I would like to: fix the message and give more clue to the users (it took me multiple hours to find it) fix the way maven deals with those local files in case of you have multiple ids for the same repository. May be try all of them before failing? I hope my feedback could help. Best!

            People

            • Assignee:
              Olivier Lamy (*$^¨%`£)
              Reporter:
              Mark Derricutt
            • Votes:
              27 Vote for this issue
              Watchers:
              31 Start watching this issue

              Dates

              • Created:
                Updated:

                Development