Fails to load when eclipse app has space in file name (Mac OS X)

[kebeda]

Here's how you recreate it:

1. Download latest Eclipse (Mars) & extract the *.app file into your Applications folder.
2. Rename the *.app file "Eclipse 4.5 (Mars).app".
3. Install your plugin.
4. Go to Preferences | Maven | Source Lookup

VM arguments:
Illegal character in path at index 39: /Users/.../Applications/Eclipse 4.5 (Mars).app/Contents/Eclipse/plugins/com.ifedorenko.m2e.sourcelookup_1.1.0.201506181114/com.ifedorenko.m2e.sourcelookup.javaagent.jar

[ifedorenko]

Why do you need to use spaces in eclipse installation directory name? Supporting directories names with spaces and another exotic characters is rather tedious and I would like to avoid this unless absolutely necessary.

[kebeda]

For the same reason you would use any other valid character in a path name?

Are you claiming space is an 'exotic' character? AFAIK, a space is a valid
character on all the file/operating systems Java currently is supported on.

Just out of curiosity, why do you find supporting strings that represent
file names tedious?

On Mon, Jul 6, 2015 at 6:28 PM, ifedorenko notifications@github.com wrote:

Why do you need to use spaces in eclipse installation directory name?
Supporting directories names with spaces and another exotic characters is
rather tedious and I would like to avoid this unless absolutely necessary.

—
Reply to this email directly or view it on GitHub
#12 (comment)
.

[ifedorenko]

Properly quoting command line invocation parameters on all platforms is tricky. Should I use single or double quotes? What happens if the path name happens to include the quote type I chose? Need to escape. What should I do with really exotic characters, non-breaking space anyone? And then we have Windows. Quite frankly, I don't have time/interest to deal with this unless there is a really good reason somebody absolutely must use directory names with spaces.

[kebeda]

If you don't have the time/interest to deal with correct parsing, may I
suggest you delegate that to someone that does? There are many well-tested,
time-proven libraries that handle this: args4j, JewelCLI, Apache Commons
CLI, JOpt Simple, JArgs are a few I can think of off the top of my head,
each has it's pro's/con's depending on the context; it would free you from
the burden of having to deal with it yourself.

I deal with many file names on many platforms many times a day, so I pretty
much restrict myself to A-Z, a-z, numbers, underscores, hyphens, periods,
commas and the space (sometimes even the hash mark). I just don't agree
that space is an exotic character. The other characters you mentioned may
or may not be valid in a path name, but there are time-tested, proven ways
to deal with that too, a quick google search should reveal that for you.
Ditto for the quoting.

I first noticed this problem on Mac OS X, and duplicated on Linux, haven't
tried Windows yet. Is this plugin not supported on Windows?

On Tue, Jul 7, 2015 at 10:33 AM, ifedorenko notifications@github.com
wrote:

Properly quoting command line invocation parameters on all platforms is
tricky. Should I use single or double quotes? What happens if the path name
happens to include the quote type I chose? Need to escape. What should I do
with really exotic characters, non-breaking space anyone? And then we have
Windows. Quite frankly, I don't have time/interest to deal with this unless
there is a really good reason somebody absolutely must use directory names
with spaces.

—
Reply to this email directly or view it on GitHub
#12 (comment)
.

[ifedorenko]

Not sure what you mean by "delegate". This is opensource project under EPL, you are more than welcome to fork this codebase and implement support for command line argument quoting.

Keep in mind that Maven Dev Tools does not launch Maven directly. I think the real permanent fix would be to implement parameter quoting in eclipse debug launch support, but it will likely be very hard to convince eclipse developers to accept this change. m2e launch support is another place where it may make sense to implement this.

As for Windows, I know that people are using this successfully on Windows, but I do not know if there are any specific limitations on that platform. (I mostly work/test on OSX with occasional Linux use)

[ifedorenko]

Default commons-exec behaviour does not correctly quote process parameters. Running the following https://gist.github.com/ifedorenko/39948b6693745ab87e90 results in unnecessary double-quotes passed to TestMain arguments on all three major platforms. Need to explicitly tell commons-exec NOT to quote. Ironic.

[cris-]

I'm also having this problem on windows (and I can reproduce it on Linux): at work, for security reasons, it not possible to run executables in a directory other than C:/Program Files/...
All our development stuff get automatically installed there, and we do not have enough privileges to change this behavior. This is quite common in firms and I hope gives a good reason for a fix.

Anyway, the following fix seems to work for me on windows and linux:
https://gist.github.com/cris-/945283dd40f1878521a0

[berndwaibel]

The problem exists on Windows (8.1), too.
Running
C:\Program Files\eclipse-jee-mars-1-win32-x86_64_GITONLY
leads to
-> Windows -> Preferences -> Maven -> Source Lookup:

Illegal character in path at index 16: file:/C:/Program Files/eclipse-jee-mars-1-win32-x86_64_GITONLY/plugins/com.ifedorenko.m2e.sourcelookup_1.1.0.201506181114/com.ifedorenko.m2e.sourcelookup.javaagent.jar

How do I install the fix? Update eclipse does not help.

[Jurrie]

Also on Windows 10 (unfortunately my user directory contains a space: "C:\Users\Jurrie Overgoor"). Sadly, Windows made this decision for me :(

-> Windows -> Preferences -> Maven -> Source Lookup:
Illegal character in path at index 64: file:/C:/JavaApps/eclipse-jee-neon/eclipse/../../../Users/Jurrie Overgoor/.p2/pool/plugins/com.ifedorenko.m2e.sourcelookup_1.1.0.201506181114/com.ifedorenko.m2e.sourcelookup.javaagent.jar

The only other option I see is to force Windows to use another directory as my user dir... Which means jumping through burning hoops, hacking in the registry and hoping it won't affect AD in any way...

[ifedorenko]

I expect this will be solved when the code is accepted by jdt.debug (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=506149).