+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 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. 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 >
