Maven
  1. Maven
  2. MNG-5181

New resolution from local repository is very confusing

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0, 3.0.1, 3.0.2, 3.0.3
    • Fix Version/s: 3.1.0-alpha-1
    • Component/s: Dependencies
    • Labels:
      None

      Description

      I just discover the change introduced in Maven 3.x to try to improve the resolution mechanism and to avoid to use a local artifact which may not be available in its remote repository :
      https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository
      Even if the feature is interesting it has several problems :

      1. When an artifact isn't accessible from its remote repository it isn't used by maven which replies a classical "dependency not found error". It is really annoying for a user with some Maven 2 skills which will have a look at his local repo, will find the artifact and won't understand why Maven doesn't use it. At least the error reported by Maven should be clear that even if the dependency is available locally, it isn't used because it's remote repository isn't available.
      2. This behavior cannot be configured to be only a warning for example. It is really annoying because it doesn't take care of some context and constraints we may have in a development team. Let's imagine that the remote artifact is really removed. Cool Maven broke the build to warn us. But it brakes the build of all the team whereas perhaps only one of them may try to solve the issue (and it can be a long resolution). Thus having the ability to configure if this control is blocker or warning may allow the team to configure it as blocker on the CI server and as warning on the development environment.
      3. This behavior may introduce some bad practices for example when we are using a staging feature on a repository manager. In our case my teams have a dedicated profile to activate a staging repository when we are validating a release. I recommend to not have this profile always activated but to do it only on-demand to avoid them to DL staging stuffs they don't need. With this new feature they need for all builds they run to activate this staging profile while binaries are stored in it. When you have to do it 20 times per day minimum let's imagine what the developer does : It adds it as an alwaysActive profile and then forget to remove it when the release is ended.

      For all these reason I would like we improve this feature to make it more usable and before all bet understandable for ours users.

        Issue Links

          Activity

          Hide
          Robert Scholte added a comment -

          Shouldn't the repository-manager keep track of the used repositories?
          Suppose an artifact is moved from staging-repo to central.
          A developer already picked it up from staging-repo to test it.
          According to the story above M3 will hold a reference to this location.
          But if it is pushed towards central it should still be the same artifact.
          M3 (Aether?) should be capable in detecting that these artifacts are still the same by storing every used repo in some meta-data file.
          This assumes that nothing is changed while pushing it forward.

          Show
          Robert Scholte added a comment - Shouldn't the repository-manager keep track of the used repositories? Suppose an artifact is moved from staging-repo to central. A developer already picked it up from staging-repo to test it. According to the story above M3 will hold a reference to this location. But if it is pushed towards central it should still be the same artifact. M3 (Aether?) should be capable in detecting that these artifacts are still the same by storing every used repo in some meta-data file. This assumes that nothing is changed while pushing it forward.
          Hide
          Arnaud HERITIER added a comment -

          As far as I understand you can find already all remote repositories where the artifact was found in the .lastUpdated metadata file in each artifac directory. Thus Maven 3 only check when it does a build if the list of repositories declared in the build (pom or settings) match a positive repository entry in the metadata.
          As I said, I think that the control may be useful but it goes further and we shuld better try to solve the origin of these problems :

          • The unability to identify a repository. An URL is wrong. It may change, you may use a mirror ...
          • The unability to classify entries in the local repository (these new metadata are helping but a long time ago we proposed to go further by splitting the local repository by origin. What's happen when we have 2 times an artifact with the same identity on 2 remote repos but with a different content ? And we should be able to have more control about what we accpet from where)
          Show
          Arnaud HERITIER added a comment - As far as I understand you can find already all remote repositories where the artifact was found in the .lastUpdated metadata file in each artifac directory. Thus Maven 3 only check when it does a build if the list of repositories declared in the build (pom or settings) match a positive repository entry in the metadata. As I said, I think that the control may be useful but it goes further and we shuld better try to solve the origin of these problems : The unability to identify a repository. An URL is wrong. It may change, you may use a mirror ... The unability to classify entries in the local repository (these new metadata are helping but a long time ago we proposed to go further by splitting the local repository by origin. What's happen when we have 2 times an artifact with the same identity on 2 remote repos but with a different content ? And we should be able to have more control about what we accpet from where)
          Hide
          Ondra Žižka added a comment -

          It's good that this feature is present; but I don't like having it forcibly enabled. At least for my use case, i.e. creating a repo for offline use which contains artifacts from various sources (EAP repo zip, JBoss repo, central).
          I'd like to have a switch for this.

          Also, when someone uses -offline, then it's probable that he knows what he's doing and has everything in the local repo; so with -offline, this should be off by default.

          And is every URL a different repo? So e.g. Nexus "public" group alias is different from "releases" repo? Despite having the very same artifacts? Or do some metadata tell this to Maven client?

          Show
          Ondra Žižka added a comment - It's good that this feature is present; but I don't like having it forcibly enabled. At least for my use case, i.e. creating a repo for offline use which contains artifacts from various sources (EAP repo zip, JBoss repo, central). I'd like to have a switch for this. Also, when someone uses - offline , then it's probable that he knows what he's doing and has everything in the local repo; so with -offline , this should be off by default. And is every URL a different repo? So e.g. Nexus "public" group alias is different from "releases" repo? Despite having the very same artifacts? Or do some metadata tell this to Maven client?
          Hide
          Eugene N Dzhurinsky added a comment -

          I would say that this feature makes maven3 unusable for most of maven2 users, and it definitely has to be configurable (and disabled or set to WARNING by default). And yes, I spent time of trying to understand why Maven doesn't use artifact available from local repository. It doesn't make any sense to me.

          Show
          Eugene N Dzhurinsky added a comment - I would say that this feature makes maven3 unusable for most of maven2 users, and it definitely has to be configurable (and disabled or set to WARNING by default). And yes, I spent time of trying to understand why Maven doesn't use artifact available from local repository. It doesn't make any sense to me.
          Hide
          Olivier Lamy (*$^¨%`£) added a comment -

          see comment in MNG-5185

          Show
          Olivier Lamy (*$^¨%`£) added a comment - see comment in MNG-5185
          Hide
          Ondra Žižka added a comment -

          How about instead of having G:A:V:R, the identity of the artifact would be verified using a hash. Simply, G:A:V:H. Same G:A:V and hash => same artifact, dependency satisfied, no matter what repo does it come from.

          <groupdId>foo</groupId>
          <artId>bar</artId>
          <version>1.0</version>
          <hash>0c9ab296701a8</hash> <!-- could be * to match any -->
          

          I guess this approach was considered, but I wonder why not chosen.

          Show
          Ondra Žižka added a comment - How about instead of having G:A:V:R, the identity of the artifact would be verified using a hash. Simply, G:A:V:H. Same G:A:V and hash => same artifact, dependency satisfied, no matter what repo does it come from. <groupdId>foo</groupId> <artId>bar</artId> <version>1.0</version> <hash>0c9ab296701a8</hash> <!-- could be * to match any --> I guess this approach was considered, but I wonder why not chosen.
          Hide
          Devin Reid added a comment -

          This feature makes creating portable offline builds require more steps than it did in Maven2. In Maven2 you could do a build using a custom 'maven.repo.local' property and then tar up the whole project, move it to a new box without network access, and have the project build fine offline. Now you either have to strip all the _maven.repository files manually or configure mirrors on a box that has no network access anyway.

          Would it be possible to have this feature disabled for --offline (-o) builds, or perhaps provide another mechanism for disabling this.

          Show
          Devin Reid added a comment - This feature makes creating portable offline builds require more steps than it did in Maven2. In Maven2 you could do a build using a custom 'maven.repo.local' property and then tar up the whole project, move it to a new box without network access, and have the project build fine offline. Now you either have to strip all the _maven.repository files manually or configure mirrors on a box that has no network access anyway. Would it be possible to have this feature disabled for --offline (-o) builds, or perhaps provide another mechanism for disabling this.
          Hide
          Jörg Hohwiller added a comment -

          Yes, please add a property to disable this feautre. The property could be declated on the commandline as well as in my settings.xml. This would preserve tons of trouble and headaches I had supporting other maven users with this issue.

          Show
          Jörg Hohwiller added a comment - Yes, please add a property to disable this feautre. The property could be declated on the commandline as well as in my settings.xml. This would preserve tons of trouble and headaches I had supporting other maven users with this issue.
          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
          Hervé Boutemy added a comment -

          cli option added in 27f8b0f8
          property added in 8ada7e76
          warning message added in 114c98f3

          Show
          Hervé Boutemy added a comment - cli option added in 27f8b0f8 property added in 8ada7e76 warning message added in 114c98f3
          Hide
          Brian E. Fox (imported) added a comment -

          i'm on the fence about if this is good or not, but I think the option if provided should be simple-local-repository without the manager part. People already get confused about what's a local repo vs what's a repository manager and the mixing of these concepts here will make that worse.

          Show
          Brian E. Fox (imported) added a comment - i'm on the fence about if this is good or not, but I think the option if provided should be simple-local-repository without the manager part. People already get confused about what's a local repo vs what's a repository manager and the mixing of these concepts here will make that worse.
          Hide
          Hervé Boutemy added a comment -

          cli option renamed to -llr / --legacy-local-repository
          MAVEN_OPTS: -Dmaven.legacyLocalRepo=true

          in 720bef7d

          Show
          Hervé Boutemy added a comment - cli option renamed to -llr / --legacy-local-repository MAVEN_OPTS: -Dmaven.legacyLocalRepo=true in 720bef7d
          Hide
          Brian Brooks added a comment -

          The location of the maven 3.x compatibility notes referenced in the ticket have moved to https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes.

          Show
          Brian Brooks added a comment - The location of the maven 3.x compatibility notes referenced in the ticket have moved to https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes .

            People

            • Assignee:
              Olivier Lamy (*$^¨%`£)
              Reporter:
              Arnaud HERITIER
            • Votes:
              20 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development