tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <jsdelf...@apache.org>
Subject Re: Distribution zips and what they contain, was: SCA runtimes
Date Tue, 12 Feb 2008 03:36:18 GMT
Comments inline.

Simon Nash wrote:
>> Well, I think the smart installer approach will be a nightmare. We had 
>> a similar approach in M2 and people didn't like it.
> The M2 approach was very different from what I was proposing.  M2
> downloaded everything on demand at runtime.  A smart installer would
> set things up ahead of time with the necessary features for the
> desired runtime configuration.  This is much more manageable if
> there are any problems with the downloads.

OK, you scared me :)

If you're talking about analyzing the features required by a composite 
at deployment time, calculating the set of JARs providing these 
features, and making them available for installation, then you get my +1.

The work I've started with the Maven Ant generator plugin is a step in 
that direction. If you hook it with a composite model analyzer and 
remove the Ant specifics you get what I just described, allowing you to 
tailor a minimal runtime for a particular SCA application.

>> You're right that the Eclipse feature install approach is a little 
>> like that. IMHO it has been a nightmare and probably one of the 
>> reasons why their download page [1] now shows targeted distros :)
>> - for Java developers
>> - for Java EE developers
>> - for Plugin developers
>> - for C++ developers
>> - for Web developers (on a separate page).
>> - and the classic IDE mix
>> Very similar to the approach I was proposing... I'm just seeing Spring 
>> and Eclipse, two extensible and successful projects adopt similar 
>> approaches, and thought they'd be good examples to follow :)
> I think these are good examples to follow.  Tuscany is rather similar
> in that it contains a base framework and many optional extensions, and
> there is probably no user who wants to use all the optional features.


>> But that's OK, if people don't like that split I can also live with a 
>> single big runtime distro.
> Over time, we will add more and more optional features and this will
> become more and more of a problem.  IMO, it's bad enough now that we
> need to do something.

I agree with you, but there is no consensus on this.

I see several options:
a) a vote to pick a common direction now
b) have people develop their different visions to get user feedback
c) continue with the current distro scheme

Like I said I could live with (c). However, I would prefer (a) or (b).

> I'd like to suggest a first baby step towards partitioning the contents
> of the distro.  In this first step, there's still a single binary distro
> with all the dependencies.  The difference is that the modules and lib
> directories are broken down into subdirectories along the lines that
> Sebastien and others have suggested.  Based on earlier discussions, the
> subdirectories could be:
> core - The base that everybody needs
>   core assembly model and runtime
>   Java APIs, Java components, SCA binding, Web Service binding
> web - For Web developers
>   Web 2.0 bindings, Scripting components, Widget components
> JEE - For JEE app integration
>   EJB, RMI and JMS bindings, Spring components
> process - For process development
>   BPEL and XQuery components
> Each of these could be built and tested separately.  Dependencies
> between them would only use documented SPIs.  There would no
> longer be a single catch-all tuscany-manifest jar or a single
> tuscany-all jar.  If this first step is successful, we could think
> about what further steps we could take to improve modularity.

I don't see what that baby step buys us. If we think that partitioning 
is the right approach, why not just simply do it cleanly and partition 
the distro?


To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

View raw message