[
https://issues.apache.org/jira/browse/MNG-8018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Hohwiller updated MNG-8018:
--------------------------------
Description:
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:
{code}
[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)
{code}
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:
{code}
...
<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>
...
{code}
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\}}.
was:
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:
{code}
[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)
{code}
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/main/resources//maven.project}}
such pom section:
{code}
...
<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>
...
{code}
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\}}.
> Maven creates local repo at wrong path
> --------------------------------------
>
> Key: MNG-8018
> URL: https://issues.apache.org/jira/browse/MNG-8018
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, Command Line
> Affects Versions: 3.9.6
> Environment: {code}
> $ mvn -v
> Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: D:\projects\mmm\software\mvn
> Java version: 21.0.1, vendor: Eclipse Adoptium, runtime:
> D:\projects\mmm\software\java
> Default locale: en_US, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> {code}
> Reporter: Jörg Hohwiller
> Priority: Major
>
> 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:
> {code}
> [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)
> {code}
> 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:
> {code}
> ...
> <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>
> ...
> {code}
> 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\}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
