On Thu, Jun 12, 2008 at 4:31 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
> ant elder wrote: > >> 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. >> >> Actually this isn't quite what I was saying. (Sorry that I wasn't > clear.) > I'm talking about the lowest level components that we distribute as > binaries, not about larger groupings that are created from these components > to provide convenient aggregations of functionality. These groupings > might be useful as well, as you are suggesting here and Graham suggested > in his recent post. > > So back to the basic components. I see no value at this level in breaking > things down any lower than a unit of functionality that might be included > or excluded as a whole from some valid scenario. To give an example, > I wouldn't put "everything related to Web services" in a single basic > component, because some users might want to create a minimal Web services > configuration without Web services security and/or Web services policy. > I also wouldn't put assembly and core in the same basic component, > because some users might just want the Tuscany model without the > Tuscany runtime. But I would put interface and assembly together in the > same basic component, because there are no cases where one would be used > without the other, and I would put core, core-databinding and databinding > together in the same basic component for the same reason. > > Simon > > ...ant >> >> > Sure ok i think we're agreeing, those were just initial stabs at some aggregation suggestions, someone embedding Tuscany could well want something more fine grained along the lines of what you have above. ...ant
