Sorry for the delay in responding. I have been out sick for a few
days and I am just getting back to my Tuscany mail. Comments inline.
Simon
Jean-Sebastien Delfino wrote:
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.
Yes, the tailored runtime could be based on the needs of a single composite
or on a predefined user-selected list of features.
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.
+1
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 could live with c) only if we start doing baby steps towards better
modularity within a single distro as I proposed here. So I'd like
to try to understand others' views on this baby step towards better
modularity before I take a firm position on a), b) or c).
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?
Please take a look at my other email on this thread responding to Ant.
I think the main piece of work needed is to create a runtime that's
truly modular, and this baby step is a first move towards that. Once
we have that, almost any configuration or reconfiguration will be
possible. Doing a zip repackaging without solving the modularity
isssues might just move us from one inflexible packaging to a different
packaging that's equally inflexible. For me, having the internal
flexibility enabled is the first step that provides the key to many
different scenarios under headings a) and b) above.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
