On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash <[EMAIL PROTECTED]> wrote:
> 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 > > I do also agree with this despite what i just posted about how if we use the launcher approach then the actual module jars don't matter to users :) One group of "users" we want for Tuscany are those embedding Tuscany in other products, so having some aggregated jars that group modules by functionality would make it easier for them - eg an aggregated jar that contains the minimal Tuscany core runtime modules, another jar with all the web services related modules etc. Its really hard for an outsider (or even insider for that mater) working out what modules are needed for what, look at the tuscany-geronimo integration code which has never managed to keep up with Tuscany changes. I think we could do both, if we go for a new launcher approach and OSGi'ify everything then it might even make it easier to get the aggregated jars working well and its not so much overhead for us to maintain both sets of jars and use which ever are appropriate depending on the circumstances. The key thing will be to get _consensus_ on it so we're all working together instead of what we have now which seems to be we each focus on the bits we're interested in sometimes to the detriment of what other are trying to do. ...ant
