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. Thanks, Raymond From: ant elder Sent: Wednesday, July 02, 2008 9:05 AM To: tuscany-dev 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]> 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
