Maven 2 & 3

Separate local repository for each remote repository

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Artifacts and Repositories
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

It would be good if Maven used a separate local repository directory for each remote repository that was used. This would avoid the problem of two repositories using the same GAV for a different artifact. This would also allow the user to easily see where an artifact in the local repository was downloaded from.

In addition the local repository used for "mvn install" could also be separated, so that it would not conflict with artifacts downloaded from remote repositories.

Issue Links

duplicates

New Feature - A new feature of the product, which has yet to be developed. MNG-3655 Allow multiple local repositories

  • Major - Major loss of function.
  • Reopened - This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved.

Activity

Ascending order - Click to sort in descending order
Paul Gier made changes -
Field Original Value New Value
Description It would be good if Maven used a separate local repository directory for each remote repository that was used. This would avoid the problem of two repositories using the same GAV for a different artifact. This would also allow the user to easily see where an artifact in the local repository was downloaded from. It would be good if Maven used a separate local repository directory for each remote repository that was used. This would avoid the problem of two repositories using the same GAV for a different artifact. This would also allow the user to easily see where an artifact in the local repository was downloaded from.

In addition the local repository used for "mvn install" could also be separated, so that it would not conflict with artifacts downloaded from remote repositories.
Brett Porter made changes -
Link This issue duplicates MNG-3655 [ MNG-3655 ]
Hide
Permalink
Brett Porter added a comment -

covered the use case of the subject in http://docs.codehaus.org/display/MAVEN/Local+repository+separation, waiting for after 3.0 and further discussion to consider working on it.

That said, I don't think having the same artifact in multiple different repositories is something that we want to encourage and an implementation would probably want a way to check for that.

Show
Brett Porter added a comment - covered the use case of the subject in http://docs.codehaus.org/display/MAVEN/Local+repository+separation , waiting for after 3.0 and further discussion to consider working on it. That said, I don't think having the same artifact in multiple different repositories is something that we want to encourage and an implementation would probably want a way to check for that.
Brett Porter made changes -
Status Open [ 1 ] Closed [ 6 ]
Assignee Brett Porter [ brettporter ]
Resolution Duplicate [ 3 ]
Hide
Permalink
Dan Allen added a comment -

It's more than just good. It's essential.

Currently, there is one local repository, but let's refer to it a cache. If I build project 1, which depends on repository A and repository B, my cache will be populated with the required dependencies fetch from either of those two repositories. If I then build project 2, which depends on repository C, it will consult my local cache for artifacts and may find artifacts that were pulled from repository A or B, even if they are not in repository C. What we have is an inconsistent truth. There is no way that project 2 should ever see the artifacts from A and B. Absolutely not.

In fact, this whole concept of "nuking your local repository" should have been a huge red flag that something is seriously wrong. A cache should never be a superset of what it is caching. Yet, that's what is happening. In fact, Maven is creating a local repository that is completely unique from any other repository in the world (and not just a subset of a known repository).

If it's true that repository artifacts are never removed remotely (which is a fairly reliable truth), you should definitely never have to nuke your local repository.

What needs to happen is that there needs to be a local repository for each remote repository.

~/.m2/repository/A
~/.m2/repository/B
~/.m2/repository/C

Only if I add repository B to project 2 should it find artifacts that where fetched by building project 1...and then only those from repository B, not A.

To cite a precedence, this is how apt and yum work.

Show
Dan Allen added a comment - It's more than just good. It's essential. Currently, there is one local repository, but let's refer to it a cache. If I build project 1, which depends on repository A and repository B, my cache will be populated with the required dependencies fetch from either of those two repositories. If I then build project 2, which depends on repository C, it will consult my local cache for artifacts and may find artifacts that were pulled from repository A or B, even if they are not in repository C. What we have is an inconsistent truth. There is no way that project 2 should ever see the artifacts from A and B. Absolutely not. In fact, this whole concept of "nuking your local repository" should have been a huge red flag that something is seriously wrong. A cache should never be a superset of what it is caching. Yet, that's what is happening. In fact, Maven is creating a local repository that is completely unique from any other repository in the world (and not just a subset of a known repository). If it's true that repository artifacts are never removed remotely (which is a fairly reliable truth), you should definitely never have to nuke your local repository. What needs to happen is that there needs to be a local repository for each remote repository. ~/.m2/repository/A ~/.m2/repository/B ~/.m2/repository/C Only if I add repository B to project 2 should it find artifacts that where fetched by building project 1...and then only those from repository B, not A. To cite a precedence, this is how apt and yum work.
Hide
Permalink
Dan Allen added a comment -

Gradle is now looking into this as well: http://jira.codehaus.org/browse/GRADLE-981

Show
Dan Allen added a comment - Gradle is now looking into this as well: http://jira.codehaus.org/browse/GRADLE-981

People

  • Assignee:
    Brett Porter
    Reporter:
    Paul Gier
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: