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.
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 :)
But that's OK, if people don't like that split I can also live with a
single big runtime distro.
[1] http://www.eclipse.org/downloads/
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
