Comments inline.
Simon
Jean-Sebastien Delfino wrote:
Mike Edwards wrote:
Jean-Sebastien,
Let's chat some more about objectives, to see why we're seeming to
look at this differently:
[snip]
Jean-Sebastien Delfino wrote:
I was thinking about the following binary distro zips:
- tuscany-core.zip - The base that everybody needs.
core assembly model and runtime
Java APIs, Java components
- tuscany-web.zip - For WS and Web developers
WS binding, Web 2.0 bindings, Scripting components, Widget
components
- tuscany-jee.zip - For JEE app integration
EJB, RMI and JMS bindings, Spring components
- tuscany-process.zip - For process development
BPEL and XQuery components
- tuscany-all.zip - all of the above
Mike Edwards wrote:
I'm not convinced that this is a particularly useful split. Sorry
to disagree, but it is worth debating this before folk do a lot of
work.
From the perspective of an end-user, their main goal in life is to
get their applications working on their runtime.
I view this as something like:
- give me a Tuscany package (containing the Tuscany runtime
materials) and a way of installing that with my runtime. Then tell
me how and where I put my application stuff so that it will run.
- splitting up the Tuscany package into several packages does not
seem to help me very much. Now I have to go read and understand
what each package does and what I need to do with it.
- let's envisage a series of potential runtimes which I could be using:
a) standalone Tuscany
b) Tomcat
c) Geronimo
d) WebSphere
e) a. n. other runtime
What I think I'd really like is to be told
1) go get this (one) download package containing the runtime
2) have an install script of some kind that knows how to take
content from the download package and put it "in the right place(s)"
for it to be usable with my runtime (may be one script per runtime
type)
- the partitioning which Jean-Sebastien describes above is actually
more appropriately done by the install script. It will either KNOW
that only certain pieces are appropriate for a given runtime (eg no
point in installing JEE related stuff on a non-JEE runtime), or it
will be able to ask some simple questions about whether I will need
some of the less common pieces
- am I asking for too much here, or is this the best approach for
the end users?
Jean-Sebastien Delfino wrote:
Sorry, I'm not convinced:
- The packages I've proposed are relevant to all the runtimes you've
listed (including the JEE one).
- If I'm an application developer or a system administrator and I'm
not able to say if I'm going to use Web 2.0, JEE integration or
business processes, I won't be able to answer the install script
questions either.
I find the organization of the Spring framework download page [1]
clear and useful and I was envisioning a similar download page
organization for Tuscany. Do people find it confusing and can they
say why?
[1] http://www.springframework.org/download
Mike edwards wrote:
The problem I have with the Spring download page, which I think is the
same as the reason I'm not keen on the split you've suggested above,
is that I first have to get to grips with what each download is about.
So, if I'm a newbie to Spring, I first have to learn about "Web Flow",
"Security", "Web Services" and so on, in order to know whether I need
them or not. For someone already familiar with Spring, this split
might be OK.
I was thinking about two categories of users:
A) The user who knows what he wants to achieve:
- I am a Web app developer and want to compose a Web app
- I want to compose Web Services
- I want to integrate existing EJBs from my JEE app server
- I want to develop business processes
These packages would help him get the distro he needs.
B) The lurker who wants to try out Tuscany.
The different packages on the download page would give him an overview
of the high-level features. He'd pick one path and start to explore it,
instead of drowning in a sea of features and JARs that he doesn't need
to start experimenting.
For a newbie, it isn't.
Let's go back to the reason to want to split things up. We've
previously discussed:
- splitting to make the download smaller
- making it easier for people to find what they need
I've said before that I think making things easier for people should
be the more important of the goals. The trouble is that these
requirements are actually in conflict. The simplest package is a
single package that I download and then run as an installer - and I
get everything I want. No more searching. No sudden discovery that
something does not work because I don't have some needed dependency.
I agree that package size is important, but it is less important to me
than making things easy. Even 100Mb ain't too big a deal these days
with Broadband a general commodity. (Microsoft certainly seem to
think so when you look at some of their update bundles !!).
I note Simon Nash's comment about the potential of a small download
package that has some installer that then goes and fetches the rest.
This is a bit like the Eclipse approach. I could live with that - as
long as it's also possible to get a big bundle that I can download for
any offline work.
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.
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'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.
Thoughts?
Simon
[1] http://www.eclipse.org/downloads/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
