Simon Laws wrote:
On Jan 3, 2008 5:59 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
[snip]
Rajini Sivaram wrote:
Shouldn't resolution be associated with a contribution rather than a
composite contained within it?
Resolution is performed against a set of installed contributions. It
should be performed when it is assumed that all required contributions
are available.
When a composite is assigned to a node,
should the node find out which contribution it came from
Yes
and process all
composites and componentType files from the contribution?
- load in the node the contributions in the contribution dependency tree;
- process only implementations and composites referenced by the
composite deployed on the node.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
And believe it or not this is pretty much what the domain tries to do. I'm
still left with the problem of how to deal with contributions that are added
to the domain in arbitrary orders. I just assume users add them in the
correct order at the moment and return the errors that happen if they don't.
It's a reasonable limitation, for now.
Maybe this is where we need an "installed contribution" concept.
The contribution service should just not trigger any resolution when the
contribution is added.
From there I can walk the tree and present the contributions that are
required by a deployed composite to the node in the correct order. Not well
tested yet though.
there will be no need to figure out the order (as it may not be possible
to figure the order anyway) if the resolution is deferred to after the
contributions are installed.
Simon
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
