[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651875#comment-17651875
]
Petr Široký commented on MNG-7631:
----------------------------------
I did a bit more digging into the changes from
[https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
and I _believe_ I found the reason for the changed behavior.
The user settings and global settings and being merged at some point, using the
{{MavenSettingsMerger}} -
[https://github.com/apache/maven/blob/maven-4.0.0-alpha-3/maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java#L71|https://github.com/apache/maven/blob/maven-4.0.0-alpha-3/maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java#L71.].
The code for {{localRepository}} merge specifically checks if the user value
is either {{null}} or empty string (via {{{}StringUtils.isEmpty(){}}})and if it
is, it replaces it with the global value (which is {{null}} by default). So at
this point, the empty string gets replaced by {{{}null{}}}. This could be
called a bug / inconsistent behavior by itself (as [~michael-o] pointed out
above). However, this actually has not changed between Maven 3.x and 4.x – the
behavior is the same.
What changed is the way the user and global {{Settings}} objects are getting
merged. Since Maven 4.x uses immutable {{Settings}} class, the code changed
quite a bit – from just calling {{settings.setLocalRepository()}} in Maven
3.8.x
([https://github.com/apache/maven/blob/maven-3.8.6/maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java#L95|https://github.com/apache/maven/blob/maven-3.8.6/maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java#L95).])
to using a builder and creating a new instance of {{Settings}} class if needed
(e.g. if things actually changed). The "problem" here is that the builder does
not really differentiate between the default {{null}} value for
{{localRepository}} and one that has been set explicitly
([https://github.com/apache/maven/blob/maven-4.0.0-alpha-3/maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java#L74|https://github.com/apache/maven/blob/maven-4.0.0-alpha-3/maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java#L74).]).
This results in the {{localRepository}} being empty string after the merge
(since that's the original value from user settings and is not replaced by
{{null}} coming from global settings).
>From the above discussion I am still not sure if the preferred solution is to
>somehow revert the new behavior (which could be considered a bug fix), or just
>document that Maven 4.x behaves differently for this edge case. The "fix"
>would probably need to happen in the merger class, as it would need to somehow
>differentiate between the default {{null}} and one that is being set
>explicitly.
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty <localRepository/> element
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
> Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
> Reporter: Petr Široký
> Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{<localRepository/>}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> <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/>
> </settings>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty element {{<localRepository/>}} from the
> {{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the
> same as in Maven 3.x.
> I was doing some quick testing and git bisecting and assuming I did not mess
> anything up, the commit causing this behavior is
> [https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
> - MNG-7553 New clean API with immutable model
> ([#703|https://github.com/apache/maven/pull/703])
> (and it's huge, so I haven't yet looked in detail at the changes).
> I am not 100% sure this is a bug, but it is at least a difference in behavior
> comparing to Maven 3.x.
>
> Edit: I also tried with {{{}-f <path-to-pom.xml>{}}}, so the local repository
> root really is {{{}<current-working-dir>{}}}, not {{<project-dir>}} (even if
> they are the same usually).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
