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.
+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'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?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
