Brett Porter wrote:
On 03/06/2007, at 11:04 PM, Kenney Westerhof wrote:
Yup, just tested it on linux - works fine, though the url is different
(missing '//localhost/').
I don't know wheter this will work on windows.
Yep, had already tested it there. There are several combinations that
work on Windows, but most of them aren't actually legal according to the
RFC. I use the localhost version when constructing by hand because it
tends to be consistently functional across platforms and matches the RFC.
Yeah, I remember that. Still it's a strange format ;) maybe it uses samba
underwater ;)
btw, the jar manifest specification states:
Class-Path:
The value of this attribute specifies the relative URLs of the
extensions or libraries that this application or extension needs. URLs
are separated by one or more spaces. The application or extension
class loader uses the value of this attribute to construct its
internal search path.
so they must be relative.. but still this works. I don't know if this
is really portable, but we'll see.
Yep, noticed that. I guess we'll see how it goes...
If this isn't the default mode of operation and we find some JVMs only
respect relative paths then I guess we could copy the libs to target and
path from there. But only after we encounter a counter-example :)
Exactly ;)
Anyway, is there really such a thing as a "relative" URL? Doesn't seem
very universal :)
:) no it doesn't hehe.. So far it seems urls are accepted. Haven't tried
any urls with other protocols than file though. Could be interesting to
have classpath elements pointing to the central repo..
The main issue is that directories MUST end in a /; I just committed a
comment stating that, since it's
no longer explicit from the call to UrlUtils(file).toExternalForm().
(btw, why isn't File.toURI().toURL() called directly?).
JDK compliance.
ah, toURI isn't in 1.4? pff..
cheers,
Kenney
Thanks,
Brett