Graham Charters wrote:
+1 from me also. We shouldn't confuse modularity purely with
versioning or whether something can be used on its own. It's also
about being able to make different combinations of modules to fit
different deployment profiles.
I agree with that, and this should be considered as part of the
use cases that would determine the granularity of the bundles.
If there is no possible deployment profile that can include A and
not B, or vice versa, then I don't see a case for having A and B
as separate bundles.
I think it was Ant who first brought up the distinction between what
make sense in terms of modularity and what makes sense from a user's
perspective. I think having 1 bundle per Tuscany module and
third-party jar is fine so long as we provide some way of aggregating
those in ways that make sense for how users will consume them. For
example, I as a user might want to think in terms of a core runtime +
implementation type X and binding Y. That's three concepts to me, not
123 bundles.
This might be valuable as well as a higher-level grouping of bundles
into different functional profiles. But it doesn't change the
fundamental question of what is the minimum independently aggregatable
unit of functionality that is encapsulated in a single bundle.
Simon
Hope this make sense.
Regards, Graham.
2008/6/12 Jean-Sebastien Delfino <[EMAIL PROTECTED]>:
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
