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

Finally figured it out. Found the solution in this blog post. To find the home directory in Java you do this:

System.getProperty("user.home");

Problem is, for some dumb reason, Java isn't using Windows environment variables or anything like that to find this path. It actually uses the parent directory of the Desktop directory. Since I like to keep certain main folders in my user directory on a separate drive (documents, downloads, music, desktop, etc) I had moved the desktop directory to D:\Desktop. Java then takes that directory, goes one level up and makes Maven and other java applications think D:\ is my home directory.

Gotta say the more I use Java the more i hate it... anyways, hopefully this might help save some hours of head scratching for someone else too.

---

Update

The original blog post is gone, but found on the WaybackMachine (the URL has been updated), but here's the gist from that post in case that goes too...

The issue: So how does Java play into all of this? Well, Java developers sometimes want to store settings for their applications in a folder within the user’s profile directory. It’s the Linux way, and Java tends to do things the Linux way. (As mentioned earlier, Windows’ “AppData” folder servers the same purpose, with some extra separation for data dependent on whether or not it should roam with the user’s profile.) For some reason, Java does not use the Windows environment variable to determine the location of the user’s profile, but instead access a registry key that references the user’s desktop folder. It then takes the parent directory of the desktop and assumes that is the user’s profile folder (assuming the user makes use of the default setup Windows chooses).

Essentially, when a programmer calls the Java command:

System.getProperty("user.home");

Java uses the following idea to determine where my user profile folder is:

PATH_TO_DESKTOP_FOLDER_AS_SET_IN_THE_REGISTRY + "\..\"

This breaks down when the desktop folder has been modified.

So, with my setup, instead of saving settings at:

c:\users\tim\

Java apps tend to save data to:

t:\tim\

In reality, Java apps should save settings to:

c:\users\tim\AppData\Roaming\

or something like that.

To add insult to injury, the Java apps continue to follow the Linux way and use a period at the beginning of the folder name in an attempt to “hide” the folder (as is done on Linux). For Windows users, this simply ensures these folders are listed first in directory listings. (Hiding a folder on Windows is achieved through setting the hidden attribute for the file.)

It looks like NetBeans has addressed the issue for their application, but the root issue remains an unresolved, low priority bug. Somehow I’d bet it would get fixed a lot faster if the mechanism for determining the user’s home path on Linux was wrong.