This sounds like a bug needs to be opened, so that the URL is correctly
encoded so that spaces are converted to %20.

podenski wrote:
> This post is in reference to
> < http://dev.eclipse.org/newslists/news.eclipse.webtools/msg17 065.html>
> where I was having problems entering an XML Catalog entry in which the
> file resides in the local Maven repository on a Windows machine. The
> path the local Maven repository included both spaces and a '.' character:
>
> C:\Documents and Settings\username\.m2
>
> It turned out that the solution was to map the above path to a drive:
>
> subst Z: "C:\Documents and Settings\ username\.m2"
>
> Once this mapping was in place it was possible to reference the jar file
> location with no spaces or '.' character which worked correctly in the
> dialog for entering an XML Catalog entry in Eclipse.
>
>
>
>

It sounds to me like a URI should have been used in the first place. Is
it clear whether an entry in the catalog is supposed to be a file system
path verse a URI. Characters like \ can occur in file system names on
Linux, i.e., they're not path separators in a URI, URL, nor in Linux
file system paths, so treating them with the assumption that they are to
be converted to /, is not entirely correctly. I wonder if specifying a
URI, i., file:/C:/Documents%20and%20Settings/username/.m2, would have
made it work in the first place? I wonder if this is supposed to denote
a file or a folder? In the latter case,
file:/C:/Documents%20and%20Settings/username/.m2/ would have been better...

Certainly the entry processing could be more friendly and do obviously
conversions, such as turning space into %20, but turning \ into / is
more dubious...

David Carver wrote:
> This sounds like a bug needs to be opened, so that the URL is
> correctly encoded so that spaces are converted to %20.
>
>
> podenski wrote:
>> This post is in reference to
>> < http://dev.eclipse.org/newslists/news.eclipse.webtools/msg17 065.html>
>> where I was having problems entering an XML Catalog entry in which
>> the file resides in the local Maven repository on a Windows machine.
>> The path the local Maven repository included both spaces and a '.'
>> character:
>>
>> C:\Documents and Settings\username\.m2
>>
>> It turned out that the solution was to map the above path to a drive:
>>
>> subst Z: "C:\Documents and Settings\ username\.m2"
>>
>> Once this mapping was in place it was possible to reference the jar
>> file location with no spaces or '.' character which worked correctly
>> in the dialog for entering an XML Catalog entry in Eclipse.
>>
>>
>>
>>

Ed Merks wrote:
> David,
>
> It sounds to me like a URI should have been used in the first place. Is
> it clear whether an entry in the catalog is supposed to be a file system
> path verse a URI. Characters like \ can occur in file system names on
> Linux, i.e., they're not path separators in a URI, URL, nor in Linux
> file system paths, so treating them with the assumption that they are to
> be converted to /, is not entirely correctly. I wonder if specifying a
> URI, i., file:/C:/Documents%20and%20Settings/username/.m2, would have
> made it work in the first place? I wonder if this is supposed to denote
> a file or a folder? In the latter case,
> file:/C:/Documents%20and%20Settings/username/.m2/ would have been better...
>
> Certainly the entry processing could be more friendly and do obviously
> conversions, such as turning space into %20, but turning \ into / is
> more dubious...
>

Correct...however, if going through the user interface of the XML
Catalog in WTP it should store that information as a URI so that it gets
converted. I'm not sure it is actually doing or that the platform
URL/URI items are completely compliant.

I remember a big discussion in the platforms URI handler where some
encoding was not happening correctly and this was causing issues. If
you encode as a URI even under windows the \ get converted to a /
otherwise it isn't a correct URI.