On Feb 2, 2008 3:23 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> 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
