We currently release the trunk as one thing, i.e. one distribution we allow people to delete things of course but it's not easy as you can tell what is required in modules for any particular feature
We talked around various options Separate modules Shaded jars including 3rd party dependencies Shaded jars excluding 3rd party dependencies Seems better to have 3rd paty bundled separately so they are easily identifiable and shipped as-is Manifest jars We drew a picture to try and find where the agreement/disagreement is. The thrust of it was... 1/ We have the existing trunk/modules For the time being it seems we can leave as is (parhaps with some tidying) 2/ Groups of these modules can be described in features using Maven These feature pons don't have to be <type>pom</type> poms though. There was a general feeling that we could define a user friendly set of features to start Base + individual extensions We talked about the difference between base and core Core = just the core Tuscany jars which define the SPI Base = a minimum runtime (required to run the otests?) Other features can clearly be defined using the same approach It seems more important to get the base + extension pattern working first though so we have a story for the users. 3/ Maven projects, such as tests or samples, can depend on features This gives us a simple story to demosntrate to users You always need base and then you choose the features named after the extensions you're going to use 4/ The feature poms can be used to generate a number of things 4a/ manifest jars that refer to all of the inidividual modules in the distribution 4b/ OSGi artifacts such as config.ini 4c/ shaded jars 4d/ manifest jars that refer to shaded jars There was general acceptance down to and including point 3. At point 4 there was much discussion. I'm not sure we understood all of the finer points of the different approaches and there was some traction for a combination of approaches. It seems that as long as we get the features set up and start using those we can put the beta out with a suitable set of artifacts that we can review and judge before the final 2.0 release. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com