On 10/9/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> On 10/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> <snip>
>
> >
> > > Does the spec say anywhere that when there is no
> sca-contribution.xmlthen
> > > composites in a contribution must not be added by default?
> > >
> >
> > Assembly specification V1.0
> >
> > 2867 The contribution optionally contains a document that declares
> > runnable composites, exported
> > 2868 definitions and imported definitions.
> > ...
> > 2887 deployable element: Identifies a composite which is a composite
> > within the contribution that is
> > 2888 a composite intended for potential inclusion into the virtual
> > domain-level composite. Other
> > 2889 composites in the contribution are not intended for inclusion but
> > only for use by other
> > 2890 composites. New composites can be created for a contribution after
> > it is installed, by using the
> > 2891 add Deployment Composite capability and the add To Domain Level
> > Composite capability.
> >
> > This tells me that:
> >
> > - sca-contribution.xml is optional
> > - composites not listed as deployables are not intended for inclusion
> > - composites can be included in the domain after contribution, manually
> > using the addDeploymentComposite and addToDomainLevel operations
> > - the spec says "potential inclusion" and does not even imply that
> > deployable composites should be included in the domain by default
>
>
> But thats all about when the IS an sca-contribution.xml not what happens
> when there is NOT one.
>
> Including all composites in the domain by default when there's no
> > sca-contribution.xml is going to be pretty inconvenient and confusing as
> > it'll force people to ship an empty sca-contribution.xml file in all
> > contributions containing only composites intended for use by other
> > composites (aka implementations).
>
>
> How common will that be? If you look at all the dozens and dozens of
> composites we have in the Tuscany tests and samples the vast majority
> (all?)
> of them are intended to get deployed. Maybe those are 'simple' cases but
> aren't those the cases we should try to keep the API as simple as possible
> for?
>
> Along with the add methods if there's also remove methods then composites
> could still be removed so in those less common simple cases where having
> things added by default is inconvenient then you can simply remove them.
>
> ...ant
>
Can't we go with the approach that says that;
1/ If there is sca-contribution.xml style meta-data it is honored and
referenced composites are deployed
2/ If there is no sca-contribution.xml style meta data then you are required
to explicitly add composites to the domain through the API
There is no magic, i.e. if sca-contribution.xml/generated-
sca-contribution.xml/deplyables doesn't exist it doesn't go looking
elsewhere for contributions. Most of our SCA applications to date fall into
category 1/ I believe and hence we could do away with the need to
startContribution(QName) on a node leaving.
Using a node in its own
nodeA = SCANodeFactory.newInstance().createSCANode("nodeA",
null);
nodeA.addContribution("nodeA", cl.getResource("nodeA/"));
nodeA.start(); or for composite level control
nodeA.startComposite(new QName("http://sample";, "Calculator"));
Or using the domain
domain = SCADomainFactory.newInstance
().createSCADomain(DEFAULT_DOMAIN_URI);
nodeA = SCANodeFactory.newInstance().createSCANode("nodeA",
DEFAULT_DOMAIN_URI);
domain.addContribution("nodeA", cl.getResource("nodeA/");
domain.start(); or for composite level control
domain.startComposite(new QName("http://sample";, "Calculator"));
I'm not clear why the the spec says "potential inclusion" on line 2888.
Possibly to do with a contribution that is a dependent contribution. But for
the purpose of explicit contributions, deployable composites should be
deployed as specified in the meta-data if it is provided.
I think we need to rename our current Domain API methods
addComposite()
removeComposite()
to become
addCompositeToDomain(QName)
removeCompositeFromDomain(QName)
This message needs to be targeted at the node(s) which have the
contribution/composite. This leaves the way clear then for the missing
methods
addComposite(Composite XML)
removeComposite(Composite XML)
Which allows a composite to be added rather than just be deployed.
We would also need to modify the Node API to allow for these rules and allow
the node to report back to the domain which composites it's taking care of
in the case where they are deployed based on meta data.
Regards
Simon
