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
