To me, the "extension" is just a "feature" that contains only the modules that make up the "extension" :-). For example, I can model the binding.ws extension as feature-binding-ws (a pom project that list feature-base, binding-ws, binding-ws-runtime-axis2, etc.).
I don't know a way to combine more than one config.ini. But if we generate the config.ini per feature, it will contain the bundles from the base. Isn't that good enough? I understand it doesn't support the case where you start Equinox with base and then try to add the extension. Thanks, Raymond ________________________________________________________________ Raymond Feng [email protected] Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com ________________________________________________________________ On Sep 29, 2010, at 10:42 AM, Simon Laws wrote: > On Wed, Sep 29, 2010 at 6:25 PM, Raymond Feng <[email protected]> wrote: >> Hi, >> What's the difference between "feature" and "extension"? >> Thanks, >> Raymond > > In the bundle plugin config you mean? > > In reality in the code nothing at the moment. I had looked on features > as being a somewhat arbitrary but functional collection of jars from > the modules directory. Extensions though have a special meaning in SCA > and Tuscany in that they relate to binding.?, implementation.?, > policy.? etc and "extend" the base SCA function that the Assembly spec > defines. So I kept them separate. > > From a tuscany point of view an extension will typically be made up of > a model, a runtime and any associated dependencies. As you see from > the listing they currently end up generating the same sort of output > and all end up under features at the moment. The meta data that's > generated is consistent on purpose of course as demonstrated by the > examples I included. The idea being that you can specify base + > extension using the same approach for both (whatever the approach > happens to be). > > There is an issue though. The extension meta-data repeats all the > dependencies that base provides. This actually doesn't make a > difference because the duplicates don't have a material impact on the > classpath (other than we might generate a classpath that is too long). > Aesthetically, and possibly for classpath length reasons, though it's > not that pleasing and so it could be useful to know when we're dealing > with extensions to filter our base dependencies from their meta data. > > Another thing this reminds me to ask... > > You'll note that I don't generate config.ini for extensions as I don't > know of a way of loading more than one into Exquinox (other than > possibly a manual merge). Any ideas? > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com
