-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Description
Jörg Hohwiller opened MNG-8018 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 devonfw/ide#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.xmlwhat in my case configures my repo to be at/c/Users/hohwille/conf/.m2/repository(git-bash syntax) orC:\Users\hohwille\\.m2\\repository(Windows syntax) at least for the top-levelmvnprocess. - Now when I did run
mvn installthe project was executingmvn installin a test folder viaexec-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:
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<id>Install test project</id>
<phase>test-compile</phase>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>mvn</executable>
<workingDirectory>target/test-classes/maven.project</workingDirectory>
<arguments>
<argument>install</argument>
</arguments>
</configuration>
</plugin>
</plugins>
</build>
...
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 (1.18 kB)