Jean-Sebastien Delfino wrote:
Raymond Feng wrote:
Hi,
There are a few patterns we use to determine if a maven module is
required. Let's take the contribution stuff as an example.
1) contribution contains the interfaces for the contribution model and
default implementation classes, SPIs and extension points
2) contribution-xml deals with the reading/writing the xml document
for the sca-contribution.xml
3) contribution-java, contribution-namspace, contribution-resource
deal with a specific perspective of the contribution, for example,
namespace, java, resource
4) contribution-osgi, contribution-groovy support specific packaging
schemes of the SCA contributions.
Please note there is a tree-like dependency graph. I don't think it
makes sense to merge the siblings into one module. Since an ancestor
(for example contribution) are shared by mulitple children (-xml,
-osgi, etc), it also not desirable to merge the common ancestor with
other modules.
For databinding related modules, we have a similar strcuture:
1) databinding: The base model, SPIs and transformers for various XML
technologies
2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The
individual databinding technologies
3) core-databinding: A set of hook code that leverage the databinding
framework in the invocation chains (data transformation interceptors)
We can use 1 as the data transformation utility in
binding/implementation or even 3rd party code without 3. We can also
pick one or more modules from 2.
What I'm trying to point out is that our maven module structure
reflects the nature of the feature units and dependencies fairly well.
IMO, each module maps well into an OSGi bundle. IMHO, both the maven
module and OSGi bundle follow the same principles and the results
should be consistent.
Thanks,
Raymond
+1 to all that, makes a lot of sense to me!
Sorry, but it doesn't make sense to me. If there is no user scenario
that can pull in contribution-java but not contribution-resource,
or vice versa, I don't see why we would choose to expose these in
our distro as separate bundles. For the databindings, there are
user scenarios in which a subset would be needed by different users,
so things like databinding-jaxb and databinding-sdo should be in
separate bundles. However, core-databinding and databinding would
always be used together, so should be in the same bundle.
There might be a reason for keeping these modules separate in the
maven build, to reflect an internal functional split. This internal
structure is not relevant to Tuscany users and should not be exposed
to them.
I think our distro should have a bundle for a minimal basic core and
bunldes for additional optional components that can be used in
different combinations. The granularity of these bundles should be
determined by what possible combinations make sense for people using
the binary distro.
Simon
