Duplicated local repository path in the generated .classpath file

Obviously, you'll replace "/projet/MIPIH/repository" by "/path/to/repository" in the text above.

Cheers.

I just re-tested and I can't reproduce it
What is your environment ?
OS, Java, Maven ....

I have the same issue when using maven-eclipse-plugin 2.5 (maven v2.0.8, Java 1.6.0_03, Windows XP)

For example:

mvn eclipse:clean eclipse:eclipse

<settings>
...
<localRepository>/path/to/repo</localRepository>
...
</settings>

2.5 produces:
M2_REPO/path/to/repo/commons-collections/commons-collections/3.2/commons-collections-3.2.jar

2.4 produces:
M2_REPO/commons-collections/commons-collections/3.2/commons-collections-3.2.jar

> I just re-tested and I can't reproduce it
Arf, mince alors .
OK, I'll try creating a testcase project to show it.

> What is your environment ?
Java 1.5.0, OS: WinXP, maven 2.0.8

Cheers.

I'm using Maven 2.0.8 with Java 1.6.0_04 on WinXP and a custom location for the local repo ("U:\Net\Maven-2") but couldn't reproduce this yet...

<localRepository>/path/to/repo</localRepository>

Will, could you please mention your actual path? Maybe there's something about its details (spaces, UNC, ...).

sure...

<localRepository>/nemours/java/maven/repository</localRepository>

<localRepository>/nemours/java/maven/repository</localRepository>

Forgive my dumb question, but what kind of filesytem is this? I mean until now, I only knew absolute Win32 pathes as "C:\..." or "\\server\..." Or was this path meant to be relative to another directory?

On Windows
new File("/nemours/java/maven/repository").isAbsolute()
is false. That might cause the troubles...

I used Unix style paths as well as negating drive names for portability purposes. The paths were getting translated correctly prior to the use of version 2.5 so I'm not sure what has happened since then?

for portability purposes.

Do you copy this one settings.xml around between different machines? Usually, this file is just yours and hence portability shouldn't matter.

Anyway, I still could not figure out what you expect the string "/nemours/java/maven/repository" to resolve to. Is this meant to be relative to your home directory/drive, maven home ...? I mean, what would the final absolute path look like? Will it work if you specify this final string directly in the settings.xml?

In our organization we use a distributed settings.xml that all developers use. Therefore, It still makes sense to have universal paths in settings.xml :o)

I found that if I specify <localRepository>C:\nemours\java\maven\repository</localRepository> it does solve the issue, but imho, we should still be able to use forward slashes as possible prior to 2.5 I have seen that a lot of people in the forum are having the same issue.

we should still be able to use forward slashes

There is nothing wrong with the slashes themselves, "C:\nemours\..." and "C:/nemours/..." wil work equally well on Windows. The important difference is between "C:/nemours/..." and "/nemours/...": The first path being recognized as absolute, the later one as relative.

Up to 2.4, the plugin's EclipseClassPathWriter did not check for a relative path when generating the ".classpath". This has been changed in r616816 to solve MECLIPSE-344.

In our organization we use a distributed settings.xml that all developers use.

To my knowledge, the settings.xml is not meant for such a scenario. In general, there is simply no portable way of specifying an absolute path across Win/Unix with a simple string constant: What the one system considers absolute will the other system consider relative.
Therefore, you might want to consider to replace the localRepository value (or at least some prefix) with an expression, e.g.

<localRepository>${env.M2_REPO}</localRepository>

This way, developers could deal with the different filesystems but still share the rest of the settings.xml.

In the end, that's a general configuration issue... let's see what Arnaud thinks.

I stopped to think a long long time ago
I agree with Benjamin. What you used was an hack over a bug to try to have portable settings.
Why I could recommend instead of trying to have an ugly fix in the plugin is that you use 2 profiles in your settings. Those profiles are activated with the OS and define the good path for the local repository. It will be transparent for your team but it will be in the maven way. WDYT ?

Sounds like a plausible solution, but I would hardly consider what I was doing a hack or bug- I consider it more of a feature :o) All other operations in Maven can evaluate the path properly so I would hate to have something different just for this plug-in :o(

On windows, I always saw /some/path to be resolved by default to c:\some\path.

You might be right about it. However that is not what maven understands.
On my config (WinXP), I put /path/to/repo a long time ago and maven always understood c:\path\to\repo without the slightest warning.

I guess that it would be far better for maven-eclipse-plugin to support this format since maven does, isn't it?

Cheers.

On windows, I always saw /some/path to be resolved by default to c:\some\path.

On Windows, a path like "/path" is known as a drive-relative path, i.e. its effective absolute value depends on your current working directory/drive. Run Maven on a project located somewhere on "C:" and your local repo is assumed to reside in "C:\path". Run Maven on a project located on drive "X:" and it will happily re-download the world to your other local repo at "X:\path"

That's nothing which Maven specifically does, it's just blindly passing the user's config setting to the java.io.File API.

I guess that it would be far better for maven-eclipse-plugin to support this format since maven does, isn't it?

The question is: Is the current behavior of Maven a bug or a feature? I am tempted to call it a missing validation of input parameters but have just mailed the dev list to get some clarification on this path topic.

I checked the behaviour under windows. Actually, it seems like when you use an \ as the beginning of a path, it's always understood as relating to c:\. I guess that's why File has this behaviour.
Example:
C:\Documents and Settings\mathus\Bureau\maven-artifact-manager>dir \
Le volume dans le lecteur C n'a pas de nom.
Le numéro de série du volume est 1405-532F

Répertoire de C:\

08/01/2008 18:39 <REP> apache-ant-1.7.0
12/03/2008 11:46 <REP> apache-tomcat-5.5.26
28/08/2007 16:12 <REP> ATI
...cut...
06/03/2008 14:50 <REP> testmaven
17/03/2008 08:32 <REP> WINDOWS
10 fichier(s) 79 905 octets
21 Rép(s) 460 726 272 octets libres

C:\Documents and Settings\mathus\Bureau\maven-artifact-manager>cd m:
M:\

C:\Documents and Settings\mathus\Bureau\maven-artifact-manager>dir \
Le volume dans le lecteur C n'a pas de nom.
Le numéro de série du volume est 1405-532F

Répertoire de C:\

08/01/2008 18:39 <REP> apache-ant-1.7.0
12/03/2008 11:46 <REP> apache-tomcat-5.5.26
28/08/2007 16:12 <REP> ATI
...cut...
06/03/2008 14:50 <REP> testmaven
17/03/2008 08:32 <REP> WINDOWS
10 fichier(s) 79 905 octets
21 Rép(s) 460 726 272 octets libres

C:\Documents and Settings\mathus\Bureau\maven-artifact-manager>

Cheers.

Actually, it seems like when you use an \ as the beginning of a path, it's always understood as relating to c:\.

That's technically wrong. Please see also 0.

C:\Documents and Settings\mathus\Bureau\maven-artifact-manager>cd m:
M:\
C:\Documents and Settings\mathus\Bureau\maven-artifact-manager>dir \

Please note that your command prompt shows the current working directory and that this is still "C:\..." after "cd m:". In other words, you did not change the current drive. Try the same with "cd /D M:" and you will see that "cd \path" is indeed drive-relative, more precisely relative to the current drive, not necessarily C:

As Benjamin already said, you didn't actually switch to the M drive with that series of commands...

C:\Documents and Settings\Wayne>subst m: "c:\Documents and Settings\Wayne"
C:\Documents and Settings\Wayne>m:
M:\>cd Desktop

M:\Desktop>dir \
Directory of M:\
03/10/2008 03:20 AM <DIR> Desktop
02/09/2008 03:58 PM <DIR> Favorites
02/19/2008 06:15 PM <DIR> My Documents

So, I think we have proven that \ means "the top-root of my current working directory". Thus, it is a relative path.

Despite whether the path is relative or not, doesn't it seem counter intuitive to have "M2_REPO/nemours/java/maven/repository" as the result? Seems like an unexpected behavior seeing that the path is getting repeated.

IMHO, judging by the amount of users that have the same issue, the logical solution would be to maintain the functionality prior to version 2.5 (which is currently how maven behaves). The "look" of double appending the path does not seem natural :o)

I have a very similar issue that i already tried to report at the wrong place [MECLIPSE]. Here is what i wrote:

The local repository was set as follows

<localRepository>${user.home}/.m2/repository</localRepository>

which is documented as the default to do.

When i run "mvn eclipse:eclipse" Maven2 produces entries in .classpath which all contain a superflouous .m2/repository. E.g.

<classpathentry kind="var" path="M2_REPO/.m2/repository/javamail/activation/1.4.1/activation-1.4.1.jar"/>

Of course, the project will not compile under Eclipse.

In a second project i have additionally set this file as the global settings.xml in the Sonatype Maven Integration. In that case, when i run the maven scripts from inside Eclipse, the problem does not appear.

Affects Versions: 0.9.2
Environment: Windows XP, Maven 2.0.7/2.0.8, Eclipse 3.3.2
settings.xml in %USERPROFILE%\.m2 directory