Why is maven installing to the wrong place?

Question

I try to run a mvn install, it compiles fine, but for some reason maven is trying to install to this location:

[INFO] Installing /home/username/workspace/projectname/pom.xml to 
/home/username/workspace/projectname/?/.m2/repository/artifactname/artifact.pom

Note, the location has a ? in it. This location really needs to be the home directory/.m2. Any idea what's causing it to install to the wrong location?

Edit: Executing mvn --help:effective-settings gives:

  <localRepository xmlns="http://maven.apache.org/SETTINGS/1.0.0"&gt;
      /home/username/workspace/projectname/?/.m2/repository
  </localRepository>

Interestingly enough, if I run mvn --help:effective-settings from a different directory, say: /tmp, it gives:

  <localRepository xmlns="http://maven.apache.org/SETTINGS/1.0.0"&gt;
      /tmp/?/.m2/repository
  </localRepository>

Answer 1

Check out the value of localRepository in settings.xml.

Answer 2

Please run the following goal on your project:

mvn help:effective-settings

And check the value of localRepository (and update the question with the value).

Follow-up: Ok, so far, things are coherent. Next...

The default value of localRepository is supposed to be ${user.home}/.m2/repository. Double check that you aren't overriding it in:

• The settings.xml from the Maven install: $M2_HOME/conf/settings.xml
• The settings.xml from the user's install: ${user.home}/.m2/settings.xml

If you aren't, check the actual value of ${user.home} (run the following command on your project):

mvn org.apache.maven.plugins:maven-help-plugin:2.1.1:evaluate -Dexpression=user.home

If you don't get the expected value, check the actual value of %USERPROFILE% if you're on Windows.

Follow-up 2: I'm not sure how ${user.home} gets valued exactly under Linux but this previous question Java: System.getProperty(“user.home”) returns “?” describes the same weird behavior - and a workaround: using a 64-bit JDK on a 64-bit system.

What JDK are you using exactly? On what platform? Could you be in the same situation (in which case, I really think it's a JDK bug, a 32-bit JDK should return the right value on a 64-bit system too).

Follow-up 3: This is actually Bug ID: 6972329 (which is not confirmed as a JDK bug, it could be a system bug).