What are the benefits do we intend to provide for users with the "components"-based aggregation?
IMHO, we can use the "feature" idea to address the requirements of b) in Mike's original e-mail without the restriction of non-overlapping and side-effort of producing new jars. Meanwhile, the alignment of feature/distribution gives us the flexibility to balance the granularities. A distribution is also a feature and we can also easily group features into a distribution. Thanks, Raymond From: ant elder Sent: Monday, July 07, 2008 4:10 AM To: dev@tuscany.apache.org Subject: Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes 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
