On Mon, May 10, 2010 at 6:38 PM, Luciano Resende <[email protected]> wrote: > On Mon, May 10, 2010 at 4:52 AM, ant elder <[email protected]> wrote: >> On Fri, May 7, 2010 at 10:57 AM, Simon Laws <[email protected]> >> wrote: >> >> While the samples thread is ongoing I'll throw out this sugestion: >> >> I think the one huge distribution is becoming too unwieldy so how >> about changing to two binary distributions, a base one, and an extras >> one. >> >> - base (or some other appropriate name) >> - requires JDK6, includes core runtime with Assembly >> - Java impl/interface.java >> - Web Services interface/binding support using JAX-WS >> - distributed domain using Hazelcast >> - impl.web and webapp support >> - binding.jms support (as it has no dependencies in some >> environments or in other environments can have just one ActiveMQ jar >> which is easy to doc) >> - binding.http which is OASIS draft spec with functionality merged >> from binding.rest and binding.jsonp and all json using just Jackson >> >> - extras >> - herarchical directory structure with seperate folders for each option >> extra: >> - JDK 5 dependencies >> - impl.bpel support >> - impl.spring support >> - b.rmi (or maybe in base as it has no dependencies) >> - ... folders for every other extension - corba, atom - etc >> - tomcat deep integration war instead of that being separate download? >> >> That would make the base distribtion work for the majority of what >> most people use, it would be small (< 10Mb) and have less than 10 jars >> so easy to understand and document so you can easily document how to >> delete things like hazelcast or Jackson if you don't want those. >> >> Things change and grow over time so to deal with that we'd say to add >> something to the base distribution that adds more dependencies or size >> or complexity or unusualness requires asking and consensus but anyone >> can add anything to a new folder in the extras distribution. In the >> releases base would be fully tested but the extras distribution would >> be as-is on a best can do basis and the only thing verified is it >> meets ASF legal requirements. >> >> There would still be just one source distribution containing everything. >> >> Comments? >> >> ...ant >> > > Let's step back and look on what we have today : > Code wise : a core runtime, various extensions and different host > environments. > Users : embedders, extenders (heavy users that extend the Tuscany > functionality), end user. > > As I don't know who/what user is the target for what you are > proposing, let's consider what a end-user needs to run a very basic > scenario, to help us identify what a core distribution might have : > - core runtime and basic extensions: > - java implementation > - web services support (needs embedded http tomcat/jetty and/or > webapp support) > Other questions not so easy to get agreement: > - distributed support or not > - OSGi versus non-OSGi > - Databindings (JAXB, JAX-WS, Axiom) > > But then, this will most likely not satisfy embedders, heavy users, > and even some end-users... some users, where they still want to have > their solution based on a given release, they want to tailor very > specific pieces that they want to use from tuscany, and even have the > ability to override some... > > We have had this discussion in the past multiple times, and we never > got to an agreement. To me, having a all distribution that includes > everything solves the problem where we don't have a finer grained > distribution that suites a given scenario, and in addition to that, we > could provide smaller distributions based on usage scenarios (e.g > enterprise would group things such as JMS, BPEL; Web 2.0 would group > things such as JSON-RPC, ATOM, REST, HTTP, etc)... Another approach > would be to have tooling that would help provisioning Tuscany based > applications from a "all distribution", and I think this was one of > the things we discussed for cloud, and Raymond provided this as a GSoC > project idea. We should also consider OSGi when thinking on all these > possible approaches. > > For now, and to avoid the further delay of this release, my preference > would be to defer this for our next release. > > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/ >
I think creating multiple release will be a bridge too far for M5. Not sure how I feel about it generally at the moment. I'd like to see if we can tidy up the current "all" distro structure and pick this discussion up again next time. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
