On 4/19/07, ant elder <[EMAIL PROTECTED]> wrote:
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
+1 to going for the release. I'm with ant on this re. form over function. I.e. lets swing the balance toward making it understandable and useable rather that craming every last feature in at the expense of doing no work on docs, samples etc. So I would add to the list. - Put a logging strategy in place and doing enough to trap and report the major errors that users will have, i.e. SCDL error and Extension not loaded. - Review of the items from the ML where we have said we will go back and rethink. Here are a few from scanning recent mails (I think this is probably the same as Ant's point aobut reviewing the runtime code and I'm sure there are many more points than these) Composite component wiring and promotion hierarchy Package/Class naming consistency across modules Package dependencies Setting data bindings on interfaces Type scoping and contexts I'm not against adding new features for the release b.t.w, in particular I'm interested in trying to get the distributed support up again, but lets consider the balance. Regards Simon