On 31/01/2008, Simon Nash <[EMAIL PROTECTED]> wrote: > Comments inline. > > Simon > > Mike Edwards wrote: > > > Folks, > > > > As with Simon Nash - sorry for my slow reply but the SCA spec work has > > been a hard master over the past 2 weeks ;-) > > > > Jean-Sebastien Delfino wrote: > > > >> Simon Nash wrote: > >> >> Jean-Sebastien Delfino wrote: > >> > >>>> - What distro Zips are we building and what do they contain? just > >>>> the runtime? samples or not? dependencies or not? are we building > >>>> specialized distros for different use cases? > >> > >> [snip] > >> > >>> With a big topic like this, dividing it into separate threads makes it > >>> easier for people to follow and participate in the discussions. The > >>> split you are suggesting looks good to me. > >> > >> [snip] > >> > >> I'd like to discuss the following: "What distro Zips are we building > >> and what do they contain?" > >> > >> 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 > > > I'd like to focus on "...containing the runtime". This is the heart > of this discussion. What is "the runtime"? If it's about 2 megs of > Tuscany jars, this is a good approach. If it includes about 50 megs > of dependent jars, plus samples/demos/etc., this suffers from all the > problems that we have today. > > > 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) > > > If this script can also pull down the dependencies needed, I am ++1 > with doing this. It can't be too hard, surely, to find the repos > where they all live and pull them down. It shouldn't take any more > time to do this than having them downloaded as part of the Tuscany > distro. Actually, it should take less time because the script could > be more intelligent about only pulling down what's needed and not > already present in the user's environment. >
+1 Just need to be careful with downloading jars that are not released under AL 2.0 that the user is made aware of the license requirements. This might mean having to agree to a prompt. > > - 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? > > > For many end users, it would be a good approach. However, it doesn't > (on its own) solve the issue about making it easier for users to find > what they need, as the scope of Tuscany gets broader and more diverse > over time. I'd like to see some progress on that as well. > > Simon > > >> Note that I'm not trying to tackle release cycles and the potential > >> for releasing the above zips independently in this discussion and I'm > >> assuming that we release all of the above together. > >> > >> I'm also assuming that the relevant samples are included in each zip. > >> > >> Thoughts? > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
