I guess Yang was proposing to treat the scdlLocation classpath-aware instead
of adding a new "scdlResource" attribute.
I think it's better to have a separate attribute with clean semantics
because people usually assume location is a URI.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, September 06, 2006 11:24 AM
Subject: Re: Locating SCDL for <include> and other usages
You lost me.
On Sep 6, 2006, at 10:50 AM, Yang ZHONG wrote:
Maybe we can broaden "relative path" semantics therefore it may not
necessarily be mandatory any longer to introduce "scdlResource".
e.g. the ClassPath is dir1, dir2, jar1, jar2.
Even if a resolved relative path is dir1/com/example/included.scdl,
we can also search for dir2/com/example/included.scdl and
jar2!/com/example/included.scdl.
Similarly evev if a resolved relative path is jar2!/org/tuscant/
system.scdl,
we can search for jar1!/org/tuscant/system.scdl and
dir2/org/tuscant/system.scdl
If the classpath is [dir1, dir2, jar1, jar2], ClassLoader.getResource ()
would look in all of those anyway.
The difference between scdLocation and scdlResource is between resolving
on the classpath vs. resolving relative to the current scdl (which may
not be on the classpath at all). What are you proposing to avoid that?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
