I think Raymond and I have the same concern over this is that we
basically take away from the user any control over where artifacts
come from. They don't get portability because different runtimes/
hosts may interpret the attribute differently and we can't specify
behaviour because the concepts may not port from one environment to
another (e.g. what does "classpath" mean in a C++ environment).
I agree that we do want to support declarative contracts but I think
the way to do that is to allow a clear specification of that contract
which can be ported between environments. To do that the contract
must define "what" the user wants rather than "how" it is located.
The parameters to the Artifact API are intended to do that, capturing
name, type, version etc. all of which clearly define "what" artifact
is needed.
For things like scdlLocation and scdlResource that explicitly define
"how" I think its important to clearly define the mechanism being
used rather than conflate mechanisms (by e.g. taking a string value
and then trying various mechanisms with it).
Right now we only allow one to be specified. I would be OK if we
allowed more than one, taking each in turn until the resource was
found. However, that may be more confusing than helpful.
--
Jeremy
On Sep 6, 2006, at 2:30 PM, Yang ZHONG wrote:
My concrete proposal as one of the alternatives to scdlResource
(pro and con
varies of course),
is to enhance from
new URL(current, scdlLocation) // thank Jeremy for clarifying
to trying other resources with the same relative path in ClassPath
after the
new URL fails.
For other programming languages hosted by OS other than Java,
native paths
can be used,
such as execution path for Windows and library path for UNIX.
e.g. the ClassPath is dir1, dir2, jar1, jar2.
and the new URL is dir1/com/example/included.scdl,
we can also search for dir2/com/example/included.scdl and
jar2!/com/example/included.scdl.
Similarly if the new URL is jar2!/org/tuscant/system.scdl,
we can search for jar1!/org/tuscant/system.scdl and
dir2/org/tuscant/system.scdl too.
My philosophy is to separate Business Logic from configuration such as
search path and artifact repository,
it would be nice if a scdl contains only contracts without any
configuration
which may vary on different user hosts.
On 9/6/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
On Sep 6, 2006, at 11:44 AM, Yang ZHONG wrote:
> I assumed "with relative URLs being resolved against the location
> of the
> containing scdl"
> resolves against the full path/URL of the containing scdl. Never
> mind if the
> assumption was wrong.
I think that's the difference - relative URLs are resolved against
the URL (using new URL(current, scdlLocation)) so there is no path to
search.
> The response sounds applying relative path directly to
> classLoader.getResource,
> I wonder if that's the true intention.
> e.g. com/example/a.scdl includes "included.scdl"
> normally people assume com/example/included.scdl because that's
> normally
> "relative" means.
> Direct classLoader.getResource("included.scdl") does *not* meet
normal
> expectation.
For scdlResource, the value is resolved using the classpath using
ClassLoader.getResource() - the value supplied is absolute as that is
all that method takes.
>
> Anyway, the reason I've been trying to help is,
> it would be nice to keep scdl business intact,
> other info such as search path, repository config and so on,
> might need another host.
Could you clarify what you mean here?
I'd also add that both these mechanisms override the use of the
repository. If you wanted to use that you would not use either of
these but would instead supply repository metadata e.g.
<include name="included" group="com.example" version="1.0"/>
I see that as the norm - the scdlLocation and scdlResource variants
would only be used in atypical circumstances (like when we are
loading the system scdl and don't have the repo bootstrapped yet).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
