You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2008/02/02 04:23:05 UTC
Re: Distribution zips and what they contain, was: SCA runtimes
Mike Edwards wrote:
[snip]
>> Jean-Sebastien Delfino wrote:
>> I think we could improve our distro scheme to provide:
>> - smaller packages
>> - easier for people to find what they need
>>
>
> I agree with the objectives. The second of the two is more important
> from my perspective.
>
>> 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
>>
>
> 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?
>
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
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distribution zips and what they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
> On Feb 10, 2008 10:06 PM, Simon Nash <na...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Feb 10, 2008 10:06 PM, Simon Nash <na...@apache.org> 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
Re: Distribution zips and what they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distribution zips and what they contain, was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distribution zips and what they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distribution zips and what they contain, was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distribution zips and what they contain, was: SCA runtimes
Posted by Mike Edwards <mi...@gmail.com>.
Jean-Sebastien,
Let's chat some more about objectives, to see why we're seeming to look
at this differently:
Jean-Sebastien Delfino wrote:
> Mike Edwards wrote:
> [snip]
> >> Jean-Sebastien Delfino wrote:
>>> I think we could improve our distro scheme to provide:
>>> - smaller packages
>>> - easier for people to find what they need
>>>
>>
>> I agree with the objectives. The second of the two is more important
>> from my perspective.
>>
>>> 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
>>>
>>
>> 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?
>>
>
> 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
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. 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.
If we don't think that folk can answer questions - and you may be right
on that - then best to assume they need everything and avoid problems
that way.
Hope this helps,
Yours, Mike.
PS I definitely agree with the idea of having a "runtime" bundle
separated from a "demos and samples" bundle.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Feb 3, 2008 7:49 PM, Jean-Sebastien Delfino <js...@apache.org> wrote:
<snip>
> One thing looking at those Spring downloads is that i think they're more
> > comaprable to out SCA, SDO, and DAS downloads.
>
> I don't understand why you're saying that. I was following a scheme
> similar to Spring in my proposal.
>
> - tuscany-core - Spring core framework
> - tuscany-web - Spring web flow / Spring Web services
> - tuscany-process - Spring integration
>
What I was trying to say is that I don't think the Spring Framework does map
to only our tuscany-core as the Spring Framework also includes support for
all those other things i listed out before (ws, scripting,...), so following
the Spring model the tuscany-core, web, and process would be included in the
one distribution. The other Spring downloads are for completely separate
projects with separate release cycles just as our SDO and DAS projects are,
for example, Spring Web services is a complete WS stack comparable to Axis2
or CXF.
...ant
Re: Distribution zips and what they contain, was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
[snip]
> I'm leaning more towards what Mike is suggesting.
OK it doesn't look like we're reaching a consensus as at least two
people don't seem to like the scheme I proposed.
I take it back then, forget about my proposal, but I still think that a
single download containing all kinds of extensions that I don't need
most of the times is overkill.
> One thing looking at those Spring downloads is that i think they're more
> comaprable to out SCA, SDO, and DAS downloads.
I don't understand why you're saying that. I was following a scheme
similar to Spring in my proposal.
- tuscany-core - Spring core framework
- tuscany-web - Spring web flow / Spring Web services
- tuscany-process - Spring integration
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Feb 2, 2008 3:23 AM, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Mike Edwards wrote:
> [snip]
> >> Jean-Sebastien Delfino wrote:
> >> I think we could improve our distro scheme to provide:
> >> - smaller packages
> >> - easier for people to find what they need
> >>
> >
> > I agree with the objectives. The second of the two is more important
> > from my perspective.
> >
> >> 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
> >>
> >
> > 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?
> >
>
> 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
> --
> Jean-Sebastien
>
>
I'm leaning more towards what Mike is suggesting.
One thing looking at those Spring downloads is that i think they're more
comaprable to out SCA, SDO, and DAS downloads. If you look within the main
Spring Framework distribution its actually very similar to our SCA one and,
as we do, it includes code for all sorts of stuff and their dependencies -
aop, beans, caching, context, core, dao, ejb, glassfixh, oc4j, tomcat,
weblogic, websphere, jca, jdbc, jms, jmx, jndi, mail, orm, hibernate,
ibatis, jdo, jpa, toplink, remoting with caucho, jaxrpc, jaxws, rmi and
soap, scheduling and quartz, scripting with bsh, groovy and jruby,
transactions and jta, and ui stuff with freemaker, jasper and velocity, jsf,
portlets, servlets, tiles, struts
...ant
Re: Distribution zips and what they contain, was: SCA runtimes
Posted by sebb <se...@gmail.com>.
On 02/02/2008, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Mike Edwards wrote:
> [snip]
> >> Jean-Sebastien Delfino wrote:
> >> I think we could improve our distro scheme to provide:
> >> - smaller packages
> >> - easier for people to find what they need
> >>
> >
> > I agree with the objectives. The second of the two is more important
> > from my perspective.
> >
> >> 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
> >>
> >
> > 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?
> >
>
> 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?
>
I know nothing about Spring or Tuscany, so take these comments as you wish.
It's not clear to me if Webflow is a part of Framework or independent
- does one have to download both? Similarly for the other
products/addons on the page. There is a long list of Homepages at the
bottom - why do only some of them have download sections on this page?
I find the packaging of the Framework a bit annoying. Suppose I
downloaded the binary only, and then decide I need the documentation -
I've got to download the binary as well. Likewise if I just want the
documentation. Why not just provide the documentation separately?
BTW, the heading
"For More Information Access Spring Project Homepages"
could be clearer, e.g.
For more information on Spring projects, please visit their homepages
> [1] http://www.springframework.org/download
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org