I see the value to have a module/utility to process the contributions without starting a runtime. The node runtime can call this utility to load/build the contributions. Later on, the domain manager can leverage that too. I anticipate the following layers:

1) Tuscany Kernel that sets up the extension point registry
2) Tuscany Deployer that processes the contributions (We used to have a workspace module that provides such capability)
3) Tuscany Domain Manager that calls Tuscany deployer
4) Tuscany Node that calls Tuscany deployer

But I don't think this is the right approach by adding hard dependencies to all the modules that contribute models and processors. Such modules should be brought into the picture through the extension point/extension discovery. The modules on the same layer are still subject to selections. A new offering can be composed by picking needed modules from the layers and below (like a subtree).

IMO, bundling a set of modules should be addressed at a higher level with the profile/feature idea. That lead to different packages of distributions to download. I don't think there is a need to physically group modules (like this scdl module) in the runtime.

Thanks,
Raymond

--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Thursday, October 01, 2009 1:18 AM
To: <[email protected]>
Subject: Module to use scdl without all runtime

I've added an scdl module and itest so you can process composites and
contributions without starting a runtime, and cleaned up all the
varrious dependencies so it works now. We keep saying the module
structure is as it is to enable doing that so having this makes sure
it will keep working. The scdl module has a large amount of code
copied from NodeFactory which would be good to make shared, i'll have
a look at doing that, perhaps starting by using the sca-domain module
and then looking at how to merge that with the node modules.

...ant

Reply via email to