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
