The OASIS SCA spec seems to be clearer on the deployment composite. It has
to be attached to an installed contribution so that it can be resolved in
the context of the "host" contribution. IMO, this is similar to the OSGi
"fragment" concept which can be attached to a host bundle.
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <[email protected]>
Sent: Monday, April 27, 2009 5:40 AM
To: "ant elder (JIRA)" <[email protected]>
Subject: Re: [jira] Commented: (TUSCANY-2989) Bogus Code in NodeImpl
configureNode(...)
ant elder (JIRA) wrote:
[
https://issues.apache.org/jira/browse/TUSCANY-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703008#action_12703008 ]
ant elder commented on TUSCANY-2989:
------------------------------------
See http://apache.markmail.org/message/jcscho3frvslpm44. Would be good to
have the ASM_8001 testcase part of the build.
Ant,
Sure - and Kelvin is working on pulling the OASIS conformance tests into
the regular build - but Tuscany fails about 30% of them currently :-( -
mainly due to not treating errors seriously enough - continues and runs
SCA composites containing significant errors that the specs say should not
run.
Regarding your other email. If a composite is handed to the Node "by
value" and is not part of any contribution, then what is it supposed to be
resolved against? Where are all its "bits" supposed to come from? I can
see one possible solution is to treat it as if it is part of one of the
contributions - say the first in the list. If that isn't done, how does
the runtime know where to look for its implementations, etc?
Yours, Mike.
