Jean-Sebastien Delfino wrote:
ant elder wrote:
On 3/30/07, Davanum Srinivas <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
