ant elder wrote:
On Feb 10, 2008 10:06 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
<snip>
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.
We don't seem to be reaching much consensus on this and i wonder if its
because we don't understand what each of our priorities are. There was an
attempt to find that out over at
http://apache.markmail.org/message/4wldk6zdjxaxz4kf but now here on this
thread I'm a bit lost after the many weeks of discussion so could you say
more about which aspect is "bad enough" now and maybe summarise the
important aspects you'd like the distribution(s) to have?
...ant
From a user perspective, if the user is doing personal development,
I suppose most users these days can put up with a 60MB download and
a 60MB runtime. Where this becomes an issue is for people building
applications or services that depend on the Tuscany runtime and need
to be deployed into various environments.
Examples are packaging the Tuscany runtime packaged inside a webapp,
placing it in a shared library on a JEE appserver, placing it on
the classpath in a J2SE environment, and maybe others. In all these
cases, it's desirable for the deployed runtime to contain only what's
needed to run the deployed applications. This is particularly important
for Tuscany's external library dependencies, partly because of the
number and diversity of these (read: risk), and partly because the
versions of these libraries that we ship could potentially conflict
with other things within the runtime environment.
I also have a number of concerns from the Tuscany architecture, design
and implementation perspective. As a Tuscany developer, I think the
present situation is bad for the following reasons.
1. We claim to have a "modular architecture" but all evidence suggests
that this isn't the case. For Tuscany SCA Java, we have to build it
as one unit, test it as one unit, package it as one unit, and deliver
it as one unit. Where is the modularity? What are the modules?
2. We know that there are dependency issues with some parts of the
current codebase, with various parts of the runtime dragging
dependencies that they shouldn't (either other parts of Tuscany or
external libraries). How much of the Tuscany runtime, and how
many external libraries, are needed to run a simple "Hello World"?
How many of these things are we comfortable with having as
dependencies, and how many do we think are a problem that should
be eliminated? The present structure provides no answers to
these questions.
3. We know that some of the maven modules are directly using
implementation code within other maven modules rather than going
through SPIs, but we don't know exactly what these non-SPI
couplings are. Our claim to have a stable and well-defined SPI
is a little shaky until we get a handle on these exception cases
and address them.
4. To make Tuscany successful, we need a modular architecture and
implementation that addresses all the above issues. This is because
Tuscany needs to run in many different environments with many different
configurations. Without modularity, we won't be able to do this.
This doesn't necessarily mean that we need to split the distribution
right now, but I think it does mean that we need to work on improving
modularity in the code, in at least some of the ways listed above.
This would give us and our users some flexibility to build and deploy
different combinations of capability to meet their needs.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
