That all sounds reasonable to me. To help anyone else hunting around for "Mike's original note on this" the link is: http://apache.markmail.org/message/nplwkkncelkwwrrk
...ant On Mon, Jul 7, 2008 at 11:59 AM, Simon Nash <[EMAIL PROTECTED]> wrote: > Raymond Feng wrote: > >> Hi, >> It seems that the fundamental difference we're having is whether two >> tuscany features can contain the same module. For example, if I build the >> web service feature and jsonrpc feature, both of them would contain core-spi >> and databinding modules. >> The other thing is that I see a feature can contain other features too. >> >> > I don't think the "components" that Ant has described and started > to produce are at the same level as the "features" that Raymond has > proposed and the "distributions" that Sebastien has produced. > > Going back to Mike's original note on this, I see the components > playing the role described for level b) and the features/distributions > playing the role described for level c). > > If the component split is correct, it would have the following > properties: > 1. Each maven module would belong to exactly one component. > 2. Features/distributions would be assembled from components and > not from maven modules directly. > 3. The assembly of a feature/distribution from components would > not drag in "too much" that is not needed by the feature or > distribution. > > How much in point 3 above is "too much" is a subjective judgment > and some might have different views on this. I'd suggest the > following criteria as a starting point for discussion: > a. No unnecessary third party dependencies. > b. No additional system resources (e.g., ports, threads) consumed. > c. No slowdown on any code paths. > > If we can achieve the above, then I don't see any problem with > physically aggregating modules together into component jars/bundles > and using these component jars/bundles to build features or > distributions. > > If the component approach works out, I'd like to add support > for it in the build, so that a specified selection of components > could be built without building other components. Also, when > building a component, it should not be necessary to build the > other components on which the component depends, if these are > available in binary form. > > Simon > > Thanks, >> Raymond >> >> *From:* ant elder <mailto:[EMAIL PROTECTED]> >> *Sent:* Wednesday, July 02, 2008 9:05 AM >> *To:* tuscany-dev <mailto:[EMAIL PROTECTED]> >> *Subject:* Re: Grouping/Aggregating tuscany modules, was: Re: Tracking >> Tuscany extensions, was: Distribution zips and what they contain, was: SCA >> runtimes >> >> This went to me not the dev list, comments in line >> >> ...ant >> >> On Wed, Jul 2, 2008 at 4:57 PM, Raymond Feng <[EMAIL PROTECTED]<mailto: >> [EMAIL PROTECTED]>> wrote: >> >> Hi, >> Can you provide us some use cases for the aggregated jars? >> I think it's very important that we don't physically merge module >> jars into a feature jar. >> Let's assume we have two features: f1 and f2. f1 contains modules >> m1 >> and m2, f2 contains m1 and m3. >> >> If that happens then likely we don't have the aggregation granularity >> correct. Could you provide an example of that using actual Tuscany modules >> and the aggregations suggested so far? >> >> If we produce f1.jar and f2.jar, what's going to happen if my >> application uses both f1 and f2? If we declare maven dependencies to >> f1 and f2, we end up with a classpath containing f1.jar and f2.jar. >> All the classes/resources from module m1 will be duplicate in these >> two jars. The jar aggregation also prevents a feature to be depended >> by another feature for the same reason. Even when we put maven on >> the side, do you expect the user to download both f1.jar and f2.jar >> to support both features? If so, we still have the duplicating >> artifacts issue. >> Also thinking about OSGi, adding feature jars will be problematic >> too. If it's just a descriptor, then adding a feature just pulls >> into the contained module bundles. >> >> >> I'm not seeing the problems you're hinting at, could you be more specific >> or give concrete examples? >> >> ...ant >> >> >
