You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Ittay Dror (JIRA)" <ji...@codehaus.org> on 2008/07/06 17:19:26 UTC

[jira] Created: (MNG-3655) Allow multiple local repositories

Allow multiple local repositories
---------------------------------

                 Key: MNG-3655
                 URL: http://jira.codehaus.org/browse/MNG-3655
             Project: Maven 2
          Issue Type: New Feature
            Reporter: Ittay Dror


In some environments, branches are rarely used. This means that if a developer wishes to work in parallel on two features, he checks out HEAD into two different locations. The problem is that using 'mvn install' in one checkout will overwrite the result of 'mvn install' in another. Of course one can write poms so that the version contains some classifier and then use 'mvn -Dartifact-classifier=first-checkout install', or, read from a file. Both are tedious.

Instead, it would be good to be able to tell maven to first consider some path under the checkout before trying a global local repository (for external artifacts). 

To make this work when running mvn from a module subdir, maybe allow to write settings.xml in the root directory of the checkout. Then, maven should climb the directory structure until locating settings.xml (or reaching the global root directory) and read there. Using settings.xml in such a way has other benefits that it can be under version control. settings.xml will then be able to specify a list of local repositories, some absolute paths, some relative to it. 

Another approach could be to allow this list of local repositories in the global settings.xml file and have an entry in each module's pom indicating where it is relative to the local repository (like the parent path attribute)

-- 
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] Reopened: (MNG-3655) Allow multiple local repositories

Posted by "Ittay Dror (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MNG-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ittay Dror reopened MNG-3655:
-----------------------------


This is not a duplicate of 2802. I don't need several local repositories to support concurrently running maven, I need it to create a hierarchy of repositories where artifacts are located. 

Imagine a simple project, creating 2 jars named foo-bar-1.0.jar and foo-zoo-1.0.jar. zoo depends on bar. 

I checkout the projects to a directory named named 'foo' (subdirectories 'bar' and 'zoo')

On Monday I come to work, and start developing a new feature. Happily  coding and building. I need to install to local repository since 'zoo' depends on 'bar. All is well.

On Tuesday, my boss comes and tells me there's an urgent bug fix (be it in some client, or simply because QA wants to try out the current iteration of the projects but are blocked).

What do I do? I checkout the projects to a directory 'foo_bugfix' and start correcting the bug.

Now, If I build, the artifacts from 'foo_bugfix' will override those from 'foo'.

Maybe this doesn't sound like much of a problem for this toy example, when I return to work in 'foo', just do a complete build.

But, it becomes a headache for large projects with tens of modules. In such cases, a full rebuild may take a long time. Also, working with branches becomes an issue, since on every checkout from a branch, I need to change version numbers to avoid conflicts.

What I'm suggesting is to allow a user like me to define a local repository that is relative to the current build directory. All problems described above are gone. However, doing just that means that on every checkout I have to wait for all artifacts (plugins, 3rd party, nightly build) to be downloaded. So instead I want the best of both worlds: allow me to define a list of repositories that are examined for artifacts, in order. When installing an artifact, write it to the first repository on the list. Then, I can first setup a shared local repository and afterwards add a reference to a local repository with relative path where further downloaded/installed artifacts are put.

Another approach is to have two definitions: one for 'local repository' and the other for 'project repository'. All items downloaded go to 'local repository' and all installed items go to 'project repository', maybe with a way of configuring maven so that some downloaded items, from a nightly build, go to 'project repository'.

Btw, about nightly builds, it will be good if remote repositories could have a mechanism where if I checkout a branch, maven first tries to download from a repository specifically for that branch (maybe the repository url can have some configuration value, but as long as it's not something that I need to update on every checkout)

> Allow multiple local repositories
> ---------------------------------
>
>                 Key: MNG-3655
>                 URL: http://jira.codehaus.org/browse/MNG-3655
>             Project: Maven 2
>          Issue Type: New Feature
>            Reporter: Ittay Dror
>
> In some environments, branches are rarely used. This means that if a developer wishes to work in parallel on two features, he checks out HEAD into two different locations. The problem is that using 'mvn install' in one checkout will overwrite the result of 'mvn install' in another. Of course one can write poms so that the version contains some classifier and then use 'mvn -Dartifact-classifier=first-checkout install', or, read from a file. Both are tedious.
> Instead, it would be good to be able to tell maven to first consider some path under the checkout before trying a global local repository (for external artifacts). 
> To make this work when running mvn from a module subdir, maybe allow to write settings.xml in the root directory of the checkout. Then, maven should climb the directory structure until locating settings.xml (or reaching the global root directory) and read there. Using settings.xml in such a way has other benefits that it can be under version control. settings.xml will then be able to specify a list of local repositories, some absolute paths, some relative to it. 
> Another approach could be to allow this list of local repositories in the global settings.xml file and have an entry in each module's pom indicating where it is relative to the local repository (like the parent path attribute)

-- 
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] Commented: (MNG-3655) Allow multiple local repositories

Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/MNG-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144246#action_144246 ] 

Brett Porter commented on MNG-3655:
-----------------------------------

apologies, I linked the wrong issue. What I thought I was linking to was this:
http://docs.codehaus.org/display/MAVEN/Local+repository+separation

Would that address your needs?

> Allow multiple local repositories
> ---------------------------------
>
>                 Key: MNG-3655
>                 URL: http://jira.codehaus.org/browse/MNG-3655
>             Project: Maven 2
>          Issue Type: New Feature
>            Reporter: Ittay Dror
>             Fix For: 2.1
>
>
> In some environments, branches are rarely used. This means that if a developer wishes to work in parallel on two features, he checks out HEAD into two different locations. The problem is that using 'mvn install' in one checkout will overwrite the result of 'mvn install' in another. Of course one can write poms so that the version contains some classifier and then use 'mvn -Dartifact-classifier=first-checkout install', or, read from a file. Both are tedious.
> Instead, it would be good to be able to tell maven to first consider some path under the checkout before trying a global local repository (for external artifacts). 
> To make this work when running mvn from a module subdir, maybe allow to write settings.xml in the root directory of the checkout. Then, maven should climb the directory structure until locating settings.xml (or reaching the global root directory) and read there. Using settings.xml in such a way has other benefits that it can be under version control. settings.xml will then be able to specify a list of local repositories, some absolute paths, some relative to it. 
> Another approach could be to allow this list of local repositories in the global settings.xml file and have an entry in each module's pom indicating where it is relative to the local repository (like the parent path attribute)

-- 
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] Closed: (MNG-3655) Allow multiple local repositories

Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MNG-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brett Porter closed MNG-3655.
-----------------------------

    Resolution: Duplicate

> Allow multiple local repositories
> ---------------------------------
>
>                 Key: MNG-3655
>                 URL: http://jira.codehaus.org/browse/MNG-3655
>             Project: Maven 2
>          Issue Type: New Feature
>            Reporter: Ittay Dror
>
> In some environments, branches are rarely used. This means that if a developer wishes to work in parallel on two features, he checks out HEAD into two different locations. The problem is that using 'mvn install' in one checkout will overwrite the result of 'mvn install' in another. Of course one can write poms so that the version contains some classifier and then use 'mvn -Dartifact-classifier=first-checkout install', or, read from a file. Both are tedious.
> Instead, it would be good to be able to tell maven to first consider some path under the checkout before trying a global local repository (for external artifacts). 
> To make this work when running mvn from a module subdir, maybe allow to write settings.xml in the root directory of the checkout. Then, maven should climb the directory structure until locating settings.xml (or reaching the global root directory) and read there. Using settings.xml in such a way has other benefits that it can be under version control. settings.xml will then be able to specify a list of local repositories, some absolute paths, some relative to it. 
> Another approach could be to allow this list of local repositories in the global settings.xml file and have an entry in each module's pom indicating where it is relative to the local repository (like the parent path attribute)

-- 
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] Commented: (MNG-3655) Allow multiple local repositories

Posted by "Wendy Smoak (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/MNG-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=140825#action_140825 ] 

Wendy Smoak commented on MNG-3655:
----------------------------------

As a workaround, you can use -Dmaven.repo.local=/path/to/repo on the command line to point at an alternate local repo.


> Allow multiple local repositories
> ---------------------------------
>
>                 Key: MNG-3655
>                 URL: http://jira.codehaus.org/browse/MNG-3655
>             Project: Maven 2
>          Issue Type: New Feature
>            Reporter: Ittay Dror
>
> In some environments, branches are rarely used. This means that if a developer wishes to work in parallel on two features, he checks out HEAD into two different locations. The problem is that using 'mvn install' in one checkout will overwrite the result of 'mvn install' in another. Of course one can write poms so that the version contains some classifier and then use 'mvn -Dartifact-classifier=first-checkout install', or, read from a file. Both are tedious.
> Instead, it would be good to be able to tell maven to first consider some path under the checkout before trying a global local repository (for external artifacts). 
> To make this work when running mvn from a module subdir, maybe allow to write settings.xml in the root directory of the checkout. Then, maven should climb the directory structure until locating settings.xml (or reaching the global root directory) and read there. Using settings.xml in such a way has other benefits that it can be under version control. settings.xml will then be able to specify a list of local repositories, some absolute paths, some relative to it. 
> Another approach could be to allow this list of local repositories in the global settings.xml file and have an entry in each module's pom indicating where it is relative to the local repository (like the parent path attribute)

-- 
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] Commented: (MNG-3655) Allow multiple local repositories

Posted by "Ittay Dror (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/MNG-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=140826#action_140826 ] 

Ittay Dror commented on MNG-3655:
---------------------------------

I know. The problem with such solutions is that it creates a usability issue (always need to pass the variable) and also all maven plugins and external artifacts will be downloaded again, taking up space and time (think of checking out to do a simple bug fix)

> Allow multiple local repositories
> ---------------------------------
>
>                 Key: MNG-3655
>                 URL: http://jira.codehaus.org/browse/MNG-3655
>             Project: Maven 2
>          Issue Type: New Feature
>            Reporter: Ittay Dror
>
> In some environments, branches are rarely used. This means that if a developer wishes to work in parallel on two features, he checks out HEAD into two different locations. The problem is that using 'mvn install' in one checkout will overwrite the result of 'mvn install' in another. Of course one can write poms so that the version contains some classifier and then use 'mvn -Dartifact-classifier=first-checkout install', or, read from a file. Both are tedious.
> Instead, it would be good to be able to tell maven to first consider some path under the checkout before trying a global local repository (for external artifacts). 
> To make this work when running mvn from a module subdir, maybe allow to write settings.xml in the root directory of the checkout. Then, maven should climb the directory structure until locating settings.xml (or reaching the global root directory) and read there. Using settings.xml in such a way has other benefits that it can be under version control. settings.xml will then be able to specify a list of local repositories, some absolute paths, some relative to it. 
> Another approach could be to allow this list of local repositories in the global settings.xml file and have an entry in each module's pom indicating where it is relative to the local repository (like the parent path attribute)

-- 
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] (MNG-3655) Allow multiple local repositories

Posted by "Mark (JIRA)" <ji...@codehaus.org>.
    [ https://jira.codehaus.org/browse/MNG-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299052#comment-299052 ] 

Mark commented on MNG-3655:
---------------------------

Yes, that would be great. Would improve repeatability of builds and eliminate re-downloading of artifacts where repeatability is an issue and there is no artifact cache/proxy/daemon.
                
> Allow multiple local repositories
> ---------------------------------
>
>                 Key: MNG-3655
>                 URL: https://jira.codehaus.org/browse/MNG-3655
>             Project: Maven 2 & 3
>          Issue Type: New Feature
>            Reporter: Ittay Dror
>             Fix For: Issues to be reviewed for 3.x
>
>
> In some environments, branches are rarely used. This means that if a developer wishes to work in parallel on two features, he checks out HEAD into two different locations. The problem is that using 'mvn install' in one checkout will overwrite the result of 'mvn install' in another. Of course one can write poms so that the version contains some classifier and then use 'mvn -Dartifact-classifier=first-checkout install', or, read from a file. Both are tedious.
> Instead, it would be good to be able to tell maven to first consider some path under the checkout before trying a global local repository (for external artifacts). 
> To make this work when running mvn from a module subdir, maybe allow to write settings.xml in the root directory of the checkout. Then, maven should climb the directory structure until locating settings.xml (or reaching the global root directory) and read there. Using settings.xml in such a way has other benefits that it can be under version control. settings.xml will then be able to specify a list of local repositories, some absolute paths, some relative to it. 
> Another approach could be to allow this list of local repositories in the global settings.xml file and have an entry in each module's pom indicating where it is relative to the local repository (like the parent path attribute)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Commented: (MNG-3655) Allow multiple local repositories

Posted by "Ittay Dror (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/MNG-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144248#action_144248 ] 

Ittay Dror commented on MNG-3655:
---------------------------------

sounds good

> Allow multiple local repositories
> ---------------------------------
>
>                 Key: MNG-3655
>                 URL: http://jira.codehaus.org/browse/MNG-3655
>             Project: Maven 2
>          Issue Type: New Feature
>            Reporter: Ittay Dror
>             Fix For: 2.1
>
>
> In some environments, branches are rarely used. This means that if a developer wishes to work in parallel on two features, he checks out HEAD into two different locations. The problem is that using 'mvn install' in one checkout will overwrite the result of 'mvn install' in another. Of course one can write poms so that the version contains some classifier and then use 'mvn -Dartifact-classifier=first-checkout install', or, read from a file. Both are tedious.
> Instead, it would be good to be able to tell maven to first consider some path under the checkout before trying a global local repository (for external artifacts). 
> To make this work when running mvn from a module subdir, maybe allow to write settings.xml in the root directory of the checkout. Then, maven should climb the directory structure until locating settings.xml (or reaching the global root directory) and read there. Using settings.xml in such a way has other benefits that it can be under version control. settings.xml will then be able to specify a list of local repositories, some absolute paths, some relative to it. 
> Another approach could be to allow this list of local repositories in the global settings.xml file and have an entry in each module's pom indicating where it is relative to the local repository (like the parent path attribute)

-- 
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-3655) Allow multiple local repositories

Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MNG-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brett Porter updated MNG-3655:
------------------------------

    Fix Version/s: 2.1

> Allow multiple local repositories
> ---------------------------------
>
>                 Key: MNG-3655
>                 URL: http://jira.codehaus.org/browse/MNG-3655
>             Project: Maven 2
>          Issue Type: New Feature
>            Reporter: Ittay Dror
>             Fix For: 2.1
>
>
> In some environments, branches are rarely used. This means that if a developer wishes to work in parallel on two features, he checks out HEAD into two different locations. The problem is that using 'mvn install' in one checkout will overwrite the result of 'mvn install' in another. Of course one can write poms so that the version contains some classifier and then use 'mvn -Dartifact-classifier=first-checkout install', or, read from a file. Both are tedious.
> Instead, it would be good to be able to tell maven to first consider some path under the checkout before trying a global local repository (for external artifacts). 
> To make this work when running mvn from a module subdir, maybe allow to write settings.xml in the root directory of the checkout. Then, maven should climb the directory structure until locating settings.xml (or reaching the global root directory) and read there. Using settings.xml in such a way has other benefits that it can be under version control. settings.xml will then be able to specify a list of local repositories, some absolute paths, some relative to it. 
> Another approach could be to allow this list of local repositories in the global settings.xml file and have an entry in each module's pom indicating where it is relative to the local repository (like the parent path attribute)

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