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)
>

Ok and thats all included in the base distribution (excluding axiom
which isn't needed as JAXWS is used for WS) so thats perfect right?

> 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...

You don't give any reason or explanation for why they would not be
satisfied??? Whats the problem, its all still there so anything anyone
may want to do is still possible.

>
> 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.
>

...but no one has yet written any tooling, and to be honest IMHO that
seems like over engineering and adding yet more complexity,  it would
be simpler to just add a bit of aggregations and structure to the
distributions and then you don't need any tooling as its obvious what
things are for.


> 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/
>

Reply via email to