On 4/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Davanum Srinivas 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
> >
> >
>
> Hi all,
>
> I think we have made good progress since we initially started this
> discussion. We have a simpler structure in trunk with a working
top-down
> build. Samples and integration tests from the integration branch have
> been integrated back in trunk and most are now working.
>
> We have a more modular runtime with a simpler extension mechanism. For
> example we have separate modules for the various models, the core
> runtime and the Java component support. SPIs between the models and
the
> rest of the runtime have been refactored and should become more
stable.
> We need to do more work to further simplify the core runtime SPIs and
> improve the core runtime but I think this is going in the right
direction.
>
> I'm also happy to see better support for the SCA 1.0 spec, with
support
> for most of the SCA 1.0 assembly XML, and some of the SCA 1.0 APIs. It
> looks like extensions are starting to work again in the trunk,
including
> Web Services, Java and scripting components. It shouldn't be too
> difficult to port some of the other extensions - Spring, JMS, JSON-RPC
> - to the latest code base as well.
>
> So, the JavaOne conference is in three weeks, would it make sense
to try
> to have a Tuscany release by then?
>
> We could integrate in that release what we already have working in
> trunk, mature and stabilize our SPIs and our extensibility story, and
> this would be a good foundation for people to use, embed or extend.
>
> On top of that, I think it would be really cool to do some work to:
> - Make it easier to assemble a distributed SCA domain with components
> running on different runtimes / machines.
> - Improve our scripting and JSON-RPC support a little and show how to
> build Web 2.0 applications with Tuscany.
> - Improve our integration story with Tomcat and also start looking
at an
> integration with Geronimo.
> - Improve our Spring-based core variant implementation, as I think
it's
> a good example to show how to integrate Tuscany with other IoC
containers.
> - Maybe start looking at the equivalent using Google Guice.
> - Start looking again at some of the extensions that we have in
contrib
> or sandboxes (OSGI, ServiceMix, I think there's a Fractal extension in
> sandbox, more databindings etc).
> - ...
>
> I'm not sure we can do all of that in the next few weeks :) but I'd
like
> to get your thoughts and see what people in the community would
like to
> have in that next release...
I'm not sure we could do all that in three weeks either :)
+1 to a release soon, but to be honest, attempting all the above seems
rushed to me, I think it would be good to focus on a small core of
things
and getting them working and tested and documented, and then use that
as a
stable base to build on and to attract others in the community to come
help
us with all the above work.
The website is starting to look much better these days, but there's
still
a
a lot we can do to give each bit of supported function clear user
documentation. So as one example, for each feature we support - Tomcat,
Jetty, Java components, scripting, Axis2 etc - a page about what it does
and
how to use it. ServiceMix does this quite well I think, eg:
http://incubator.apache.org/servicemix/servicemix-http.html. Once we
have
some good doc and an obvious website structure in place it will be much
easier for people adding new function to Tuscany to also add doc to the
website instead of leaving things undocumented.
There's been a ton of work on the runtime code of the last few weeks and
some of it was done a bit hastily just to get things working again,
so it
may be good to spend a bit of time tidying that up a bit before
encouraging
people back to help on new work.
One big thing I think we should do for this release is try to come up
with
a
good extension SPI and make a commitment that we'll then try to maintain
backward compatibility with deprecation instead of making breaking
changes
all the time. We're not 1.0 yet so we don't have to be religious
about it,
but when making SPI changes at least have some discussion about whether
its
possible to do the change in a backward compatible way. We had a ML
thread
about the SPI a while back, I'll start that going again. I'd like to
finish
up more the Axis2 binding and script implementation I've been working
on,
a
big reason for this is I think it will help with showing what the SPI
requirements are.
...ant
