maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Balazs Zsoldos (JIRA)" <>
Subject [jira] [Commented] (MNG-3655) Allow multiple local repositories
Date Fri, 17 Jul 2015 08:25:06 GMT


Balazs Zsoldos commented on MNG-3655:

Another use-case:

We use Gitlab with Gitlab-CI. Gitlab-CI compiles every commit and merges requests within a
docker container. As the docker container is empty, every artifact is downloaded again and
again. I could use the following solution:

 - Configure Maven to have a different local repo for the artifacts downloaded from Maven
 - The separate local repo would be placed on a shared folder coming from the host machine

By having this solution, the artifacts that are coming from Maven Central, should not be downloaded
multiple times. Not downloading the resources again and again is good for the environment

> Allow multiple local repositories
> ---------------------------------
>                 Key: MNG-3655
>                 URL:
>             Project: Maven
>          Issue Type: New Feature
>          Components: Reactor and workspace
>            Reporter: Ittay Dror
>             Fix For: Issues to be reviewed for 4.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
> 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 was sent by Atlassian JIRA

View raw message