tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luciano Resende" <luckbr1...@gmail.com>
Subject Re: [DISCUSS] Next version - What should be in it
Date Tue, 03 Apr 2007 08:18:12 GMT
All sounds good, I'll continue working on the Contribution Services and get
integrated with the different modules.

On 4/2/07, Raymond Feng <enjoyjava@gmail.com> wrote:
>
> Hi,
>
> 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
>
> Thanks,
> Raymond
>
> ----- 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
>
>


-- 
Luciano Resende
http://people.apache.org/~lresende

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message