[ACCEPTED]-Maven - installing artifacts to a local repository in workspace-repository

Maven can search multiple repositories (local, remote, "fake" remote) to 32 resolve dependencies but there is only ONE local 31 repository where artifacts get installed 30 during install. It would be a real nightmare to 29 install artifacts into specific locations 28 and to maintain this list without breaking 27 anything, that would just not work, you 26 don't want to do this.

But, TBH, I don't 25 get the point. So, why do you want to do 24 this? There might be alternative and much 23 simpler solutions, like installing your 22 artifacts in the local repository and then 21 copying them under your project root. Why 20 wouldn't this work? I'd really like to know 19 the final intention though.

UPDATE: Having read 18 the update of the initial question, the 17 only solution I can think of (given that 16 you don't want to use different versions/tags) would 15 be to use two local repositories and to 14 switch between them (very error prone though).

To 13 do so, either use different user accounts 12 (as the local repository is user specific 11 by default).

Or update your ~/.m2/settings.xml each time you 10 want to switch:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                      http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <localRepository>${user.home}/.m2/repository</localRepository>
  <!--localRepository>${user.home}/.m2/repository2</localRepository-->
  ...
</settings>

Or have another settings.xml and point 9 on it using the --settings option:

mvn install --settings /path/to/alternate/settings.xml

Or specify the alternate 8 location on the command line using the -Dmaven.repo.local option:

mvn -Dmaven.repo.local=/path/to/repo

These 7 solutions are all error prone as I said 6 and none of them is very satisfying. Even 5 if you might have very good reasons to work 4 on several branches in parallel, your use 3 case (not rebuilding everything) is not 2 very common. Here, using distinct user accounts 1 migh be the less worse solution IMO.

This is INDEED possible with the command 32 line, and in fact is quite useful. For 31 example, if you want to create an additional 30 repo under your Eclipse project, you just 29 do:

mvn install:install-file -DlocalRepositoryPath=repo \
   -DcreateChecksum=true -Dpackaging=jar \
   -Dfile=%2 -DgroupId=%3 -DartifactId=%4 -Dversion=%5

It's the "localRepositoryPath" parameter 28 that will direct your install to any local 27 repo you want.

I have this in a batch file 26 that I run from my project root, and it 25 installs the file into a "repo" directory 24 within my project (hence the % parameters). So 23 why would you want to do this? Well, let's 22 you say you are professional services consultant, and 21 you regularly go into customer locations 20 where you are forced to use their security 19 hardened laptops. You copy your self-contained 18 project to their laptop from a USB stick, and 17 presto, you can do your maven build no problem.

Generally, if 16 you are using YOUR laptop, then it makes 15 sense to have a single local repo that has 14 everything in it. But to you who got cocky 13 and said things like "why would you want 12 to do that", I have some news...the world 11 is a bigger place with more options than 10 you might realize. If you are using laptops 9 that are NOT yours, and you need to build 8 your project on that laptop, get the resulting 7 artifact, and then remove your project directory 6 (and the local repo you just used), this 5 is the way to go.

As to why you would want 4 to have 2 local repos, the default .m2/repository 3 is where the companies standard stuff goes, and 2 the local "in project" repo is where YOUR 1 stuff goes.

This is not possible with the command line 9 client but you can create more complex repository 8 layouts with a Maven repository server like 7 Nexus.

The reason why it's not possible is that 6 Maven allows to nest projects and most of 5 them will reference each other, so installing 4 each artifact in a different repository 3 would lead to lots of searches on your local 2 hard disk (or to failed builds when you 1 start a build in a sub-project).

FYI: symlinks work in Windows7 and above 4 so this kind of thing is easy to achieve 3 if all your code goes in the same place 2 in the local repo, i.e /com/myco/.

type mklink 1 for details

I can see that you do not want to use special 20 versions or classifiers but that is one 19 of the best solutions to solve this problem. I 18 work on the same project but different versions 17 and each mvn install takes half an hour to build. The 16 best option is to change the pom version 15 appended with the change name, for example 14 1.0.0-SNAPSHOT-change1 that I'm working on thereby having multiple 13 versions of the same project but with different 12 code base.

It has made my life very easy 11 in the long run. It helps run multiple builds 10 at the same time without issues. Even during 9 SCM push, we can skip the pom file from 8 staging so there can always be 2 versions 7 for you to work on.

In case you have a huge 6 project with multiple sub-modules and want 5 to change all the versions together, you 4 can use the below command to do just that

mvn versions:set -DnewVersion=1.0.0-SNAPSHOT-change1 -DprocessAllModules

And 3 once done, you can revert using

mvn versions:revert

I know this 2 might be not what you are looking for, but 1 it might help someone who wants to do this.