maven - Maven reads user configuration from wrong location

Question

I just discovered why Maven doesn't work properly on my machine. For some reason it reads the user configuration from the completely wrong location. And I don't understand why. When I run maven with the -X switch I get the following output in the beginning:

[DEBUG] Reading global settings from D:\dev\maven\active\conf\settings.xml
[DEBUG] Reading user settings from D:\.m2\settings.xml
[DEBUG] Using local repository at D:\dev\maven_repo

Why is it reading user settings from D:\.m2 and not my actual user directory like it normally should? It worked fine on my old computer. Does it have something to do with me having installed maven on a different drive this time? On my old computer it was installed on the C drive.

Where does it get this D:\.m2 from? How can I make it read the user settings file from the actual default location, %userprofile%\.m2?

Answer 1

终于想通了。在这篇博文中找到了解决方案。要在 Java 中查找主目录，请执行以下操作：

System.getProperty("user.home");

问题是，出于某种愚蠢的原因，Java 没有使用 Windows 环境变量或类似的东西来查找此路径。它实际上使用桌面目录的父目录。由于我喜欢将某些主文件夹保留在单独驱动器上的用户目录中（文档、下载、音乐、桌面等），因此我将桌面目录移动到D:\Desktop. 然后 Java 使用该目录，向上一级，使 Maven 和其他 Java 应用程序认为D:\是我的主目录。

不得不说，我使用 Java 的次数越多，我就越讨厌它……无论如何，希望这也有助于为其他人节省一些时间。

---

更新

原来的博文不见了，但在 WaybackMachine 上找到了（URL 已更新），但这里是那篇博文的要点，以防万一……

问题：那么 Java 如何在这一切中发挥作用？嗯，Java 开发人员有时希望将其应用程序的设置存储在用户配置文件目录中的文件夹中。这是 Linux 的方式，Java 倾向于以 Linux 的方式做事。（如前所述，Windows 的“AppData”文件夹服务于相同的目的，根据是否应该与用户的配置文件一起漫游，对数据进行了一些额外的分隔。）出于某种原因，Java 不使用 Windows 环境变量来确定用户配置文件的位置，而是访问引用用户桌面文件夹的注册表项。然后它获取桌面的父目录并假定这是用户的配置文件文件夹（假定用户使用 Windows 选择的默认设置）。

本质上，当程序员调用 Java 命令时：

System.getProperty("user.home");

Java 使用以下想法来确定我的用户配置文件文件夹的位置：

PATH_TO_DESKTOP_FOLDER_AS_SET_IN_THE_REGISTRY + "\..\"

当桌面文件夹被修改时，这会发生故障。

因此，使用我的设置，而不是将设置保存在：

c:\users\tim\

Java 应用程序倾向于将数据保存到：

t:\tim\

实际上，Java 应用程序应该将设置保存到：

c:\users\tim\AppData\Roaming\

或类似的东西。

雪上加霜的是，Java 应用程序继续遵循 Linux 的方式，并在文件夹名称的开头使用句点，以试图“隐藏”文件夹（就像在 Linux 上所做的那样）。对于 Windows 用户，这只是确保这些文件夹在目录列表中首先列出。（在 Windows 上隐藏文件夹是通过设置文件的隐藏属性来实现的。）

看起来 NetBeans 已经为他们的应用程序解决了这个问题，但根本问题仍然是一个未解决的低优先级错误。不知何故，我敢打赌，如果在 Linux 上确定用户主路径的机制是错误的，它会修复得更快。