On Jul 13, 2006, at 4:15 PM, Jeremy Boynes wrote:
On Jul 13, 2006, at 2:31 PM, Oisin Hurley wrote:
The first idea was to have a directory into which people could
place composites (as jar files or whatever the packaging unit is)
which is scanned by a system service included with the boot
runtime. All the composites found there are used to create
components that are added in to the system composite.
The second was to have a file (probably as XML) that contained a
list of maven artifact ids that corresponded to composites that
could be loaded from a maven repository. There would be a system
service included with the boot runtime that would read this file
and create runtime components from the composites it identified.
Do these seem like reasonable ideas? Any others?
It seems reasonable to have both, as well as a loader to grab
composites
from an HTTP endpoint and I'm sure a pile of others - it might be
a good
plan to introduce a notion of composite resolution system service
which
can be optionally activated at boot time and which can then bootstrap
itself to load a chain of composite resolvers. Or maybe that's
cheffing
it up a bit for what's needed :)
According to my wife, I never met I problem I couldn't over-
engineer so if we're cheffing away ...
I'd probably have to agree with her in general but not in this case ;-)
I can envision a service that can load composites using the same
infrastructure maven uses (local first, then remote via HTTP or
anything supported by wagon). With m2 we can use the transitive
dependencies to build a classpath for composites that contain Java
stuff. Maven's dependency mechanism caters for group, version and
identifier decoration of an artifact so we could do things like
look for a particular version of a composite or one intended for
tuscany.
We could pack all that info into the composite name using maven's
convention - so the name of the composite from our eagerinit sample
would be "org.apache.tuscany.samples.sca:sample-eagerinit:1.0-
chianti-SNAPSHOT" (or something like it). There's a couple of
problems with this though. Firstly, I don't think this is a valid
NCName so would fail schema validation (don't know if that's a big
issue or not, probably is for some). Secondly, this is quite a
mouthful and it might be better to break it out into separate parts
e.g.:
<composite name="sample-eagerinit"
groupId="org.apache.tuscany.samples.sca"
version="1.0-chianti-SNAPSHOT">
I prefer this version
<include groupId="com.example" name="inner" version="1.0"/>
A simple form of this that checks the local and HTTP repositories
is probably fairly simple; if we want to do the full maven thing
(proxies, protocols, snapshots caching, ...) then it might be worth
seeing if we can use part of m2 itself (and never mind the bile
that ensues).
API for this could be:
interface CompositeRepository {
URL locate(String name);
URL locate(String groupId, String artifactId, String version,
String identifier);
}
where the URL returned would be the location of the composite archive.
Waddya think?
Sounds good. I'm skeptical of using maven as opposed to just writing
our own simple downloader. Maybe it has some nice features like error
recovery, though, that may be worth the bile we'd get from Hani.
This will be good as it will allow us to keep the core very compact
with a reasonable footprint as opposed to the monolith we wound up
with in M1.
--
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]
