tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Feng" <enjoyj...@gmail.com>
Subject Re: [DISCUSS] Next version - What should be in it
Date Mon, 02 Apr 2007 17:53:35 GMT

Here are a few things for consideration:

1) Databinding framework and a set of databinding extensions incuding SDO, 
JAXB, AXIOM and more
2) A refactored Java Container that handles Java component type
3) A refactored Tuscany Core without the dependency on Java Container
4) Refine the extensibility story for implementation/binding extensions


----- Original Message ----- 
From: "Jean-Sebastien Delfino" <jsdelfino@apache.org>
To: <tuscany-dev@ws.apache.org>
Sent: Saturday, March 31, 2007 12:07 PM
Subject: Re: [DISCUSS] Next version - What should be in it

> Jean-Sebastien Delfino wrote:
>> ant elder wrote:
>>> On 3/30/07, Davanum Srinivas <davanum@gmail.com> wrote:
>>>> Folks,
>>>> Let's keep the ball rolling...Can someone please come up with a master
>>>> list of "extensions, bindings, services, samples" which can then help
>>>> decide what's going to get into the next release. Please start a wiki
>>>> page to document the master list. Once we are done documenting the
>>>> list. We can figure out which ones are MUST, which ones are nice to
>>>> have, which ones are out of scope. Then we can work backwards to
>>>> figure out How tightly or loosely coupled each piece is/should be and
>>>> how we could decouple them if necessary using
>>>> interfaces/spi/whatever...
>>>> Quote from Bert Lamb:
>>>> "I think there should be a voted upon core set of extensions,
>>>> bindings, services, samples, whatever that should be part of a
>>>> monolithic build."
>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html
>>>> Quote from Ant Elder:
>>>> The specifics of what extensions are included in this release is left 
>>>> out
>>>> of
>>>> this vote and can be decided in the release plan discussion. All this 
>>>> vote
>>>> is saying is that all the modules that are to be included in this next
>>>> release will have the same version and that a top level pom.xml will 
>>>> exist
>>>> to enable building all those modules at once.
>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16155.html
>>>> Thanks,
>>>> dims
>>> I've created a minimal wiki page that so far just has a list of all the
>>> modules currently in java/sca:
>>> http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+next+release+planning
>>> I guess everything in contrib is not going to be in the next release 
>>> unless
>>> something changes. How about also moving bpel, celtix and servicemix to
>>> contrib?
>> Makes sense to me. I've not seen any activity in these modules recently, 
>> and they don't seem to build. If people are willing to work on them again 
>> and have them included in the next release, then it won't be a problem to 
>> move them back again.
>>> There's a few script containers now - groovy, javascript, ruby, bsf and
>>> jsr223 - I was planning on focusing just on the jsr223 container and 
>>> hope to
>>> make it support everything the others do. So we could move all the 
>>> others to
>>> contrib if no one is going to be working on them, but i don't see any
>>> problem with having a script language specific container as well as the
>>> jsr223 one if someone wants to work on one of those.
>> +1 I think it is important to have support for scripting languages as 
>> they make it very easy to write the glue between the components in an SCA 
>> composite application.
>>>   ...ant
>> I'd like to add a list of samples. We have various samples in different 
>> places in the tree at the moment, I'll spend some time today sorting out 
>> that list and will update the wiki page with that today or tomorrow.
>> Maybe it will help to add a one-line description of each module to 
>> indicate the main features that it provides? What do you think?
> I added to the Wiki page a table listing the samples we have, with a one 
> line description of each. A few samples are still using old versions of 
> SCDL and APIs but it shouldn't be too much work to port them to the latest 
> spec level.
> I'd also like to have at some point a nice Web 2.0 sample similar to the 
> AlertAggregator sample from the Tuscany SCA native project, but for that 
> we'll need a REST binding (or maybe we can just start with JSON-RPC or the 
> Axis2 support for REST) and more complete support for scripting components 
> in the Java runtime. So I think that running AlertAggregator on the Java 
> runtime will be much more work :)
> I'll spend more time going through the modules we currently have and add a 
> short description of each to the Wiki. In addition to the list of modules, 
> I think it would be good to have a high level list of features as well 
> (like what subset of APIs are we going to support, what SCDL features, 
> bindings, component implementation types, policies, which host 
> environments, deployment tools etc.).
> Any thoughts? Could people start adding to the Wiki page or discuss in 
> this thread what features they'd like to see?
> -- 
> 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

View raw message