[MNG-8018] Maven creates local repo at wrong path

**[Jörg Hohwiller](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=hohwille)** opened **[MNG-8018](https://issues.apache.org/jira/browse/MNG-8018?redirect=false)** and commented

I am hunting bugs with maven for years now that is creating a new local repository in an odd location (something like `D:\d\...` but before also `$PWD/${M2_REPO`} - see https://github.com/devonfw/ide/issues/706). Now I was finally able to become able to effectively reproduce it:

I created an empty `d` folder on my `D:` drive but removed all permissions on it even for myself to force errors in case maven will ever try to populate this directory again.
This now happened when maven is executed from `maven-exec-plugin` and the nested maven tries to resolve the local repository in that context it seems to consider the path to the local repository as relative even though it is absolute.
Here are some more detailed circumstances when this error is happening:
* I am on Windows
* I am working in git-bash when I invoke maven (`mvn install`).
* To relocate the local repository, I used this "hack": `export MAVEN_OPTS= -Duser.home=/d/projects/mmm/conf`. This works to take the settings from `/d/projects/mmm/conf/.m2/settings.xml` what in my case configures my repo to be at `/c/Users/hohwille/conf/.m2/repository` (git-bash syntax) or `C:\Users\hohwille\\.m2\\repository` (Windows syntax) at least for the top-level `mvn` process.
* Now when I did run `mvn install` the project was executing `mvn install` in a test folder via `exec-maven-plugin`. See https://github.com/m-m-m/code/blob/238899e2b2525081b39f59932e093d5c331a2864/java/impl/pom.xml#L64
This results in the following error:

```
[INFO] --- exec:3.1.0:exec (Install test project) @ mmm-code-java-impl ---
[ERROR] Could not create local repository at D:\d\projects\mmm\conf\.m2\repository -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/LocalRepositoryNotAccessibleException
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)
at org.apache.commons.exec.DefaultExecutor.executeInternal (DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute (DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:1000)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:947)
at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:471)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
```

I was already hunting down the source-code of maven-exec plugin if it contains any code related to this problem. But it seems not to explicitly handle or tweak any related environment variables or do anything different where `mvn` is executed or any other program.
So my assumption is that maven core itself has some logic to resolve the local maven repo and decide if something is a relative or an absolute path. As this is working for paths in git-bash syntax for the top-level `mvn` process, I would guess that there is some magic detection of git-bash/MSYS that however, stops working if `mvn` is then again executed but not directly from git-bash but from a Java-process (maven itself) within.
BTW: With the path treated wrongly as relative it can not find the `settings.xml` and hence computes the path to the local repository in the "default location" what is inside my tweaked home directory causing the difference between `C` and `D` drive.

I know this is kind of an edge-case but as I was searching for this for a long time, I decided to report this. As I could not see it is a bug of `maven-exec-plugin` itself, I finally filed it here. I would be very pleased, if you have any further ideas on this.
In case I should try anything special please let me know and I will do and provide results.
You could however easily reproduce this by creating a simple project with again a very simple maven project in `src/test/resources/maven.project`
such pom section:

```
...



org.codehaus.mojo
exec-maven-plugin
3.1.0


Install test project
test-compile

exec




mvn
target/test-classes/maven.project

install





...
```

Then in `git-bash` run `export MAVEN_OPTS="-Duser.home=$HOME" && mvn install`. The secondary `mvn` process should then create a repo in something like `C:\c\Users\«yourlogin»\.m2\repository`.

---

**Affects:** 3.9.6

**Attachments:**
- [mng-8018.tgz](https://issues.apache.org/jira/secure/attachment/13066667/mng-8018.tgz) (_1.18 kB_)

Start by reproducing the nested Maven invocation from Git Bash on Windows using the example under src/test/resources/maven.project and the reported MAVEN_OPTS setting. Read Maven core's local-repository and settings.xml path-resolution flow, using the maven-exec-plugin configuration and attached reproduction as context. Done means the secondary mvn process preserves the configured absolute repository path and has coverage for this scenario.

Written by the indexing model from the issue text.