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!
--
Jean-Sebastien
