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

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