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/[email protected]/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/[email protected]/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?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
