[DISCUSS] Tuscany SCA Roadmap and next releases
Hi all, We've released v1.0 of Tuscany SCA 2 weeks ago... So it's probably the right time now to ask what people want to do next and try to build a roadmap for the next few releases. Here are a few random thoughts to initiate the discussion. I've just listed the things that came to my mind this morning, but I'm sure that there's much much more to add :) - Support for transaction and reliability policies Several users have asked for it, and there's now a public draft of the transaction policy spec - Webapp and EJB module integration I'd like to track the OASIS work on this and implement it in parallel in Tuscany. Many users have existing J2EE EJB and EAR modules that they'll need to integrate in bigger SCA compositions. Also Webapp developers will need a non-intrusive way to wire a Webapp with other SCA components in an SCA domain. - Conversational and non blocking + callback programming model over Web2.0 bindings Seems like a good fit with JSON for example... in particular Ajax interactions fit really well with the SCA non blocking + callback programming model. - Ability to model client side JavaScript components Looking at the Store sample for example, I'd like to be able to model the client Javascript as a component with SCA references to the ShoppingCart and Catalog services, instead of manually creating JSON and Atom client proxies in the client Javascript code. - Support for Atom using Apache Abdera Abdera just released their 0.3.0, I've started to look at it and it looks pretty good. I think we should try to port our Atom/RSS binding to it and see how it compares with the Rome library which we are currently using. - More modular distributions, in addition to our current all-in-one distribution, distribute smaller packages that people can choose to install or not? - Some clean up of the core runtime invocation and injection mechanism, we can probably simplify and actually remove code in a number of places :) Could people please jump in and say what they want to see in the next few releases? What they need for their Tuscany based projects? What is missing? What needs to be improved or fixed? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Tuscany SCA Roadmap and next releases
As you'll guess from the post on Websphere and Tuscany that I put up a couple of days ago, I would like to see where you want to go in the area of > - Webapp and EJB module integration > I'd like to track the OASIS work on this and implement it in parallel in > Tuscany. Many users have existing J2EE EJB and EAR modules that they'll > need to integrate in bigger SCA compositions. Also Webapp developers > will need a non-intrusive way to wire a Webapp with other SCA components > in an SCA domain. For example when you wire a webapp to an SCA component, how is the SCA domain found, and who starts and stops it? How and when did the components get deployed into it? And wre we ever going to have webapps which *are* SCA components so that we want to do dependency injection directly into a servlet for example? I wish I knew enough to provide answers and not just ask questions :-) :-( Matthew Peters Jean-Sebastien Delfino <[EMAIL PROTECTED]> 10/10/2007 17:03 Please respond to tuscany-user@ws.apache.org To tuscany user cc [EMAIL PROTECTED] Subject [DISCUSS] Tuscany SCA Roadmap and next releases Hi all, We've released v1.0 of Tuscany SCA 2 weeks ago... So it's probably the right time now to ask what people want to do next and try to build a roadmap for the next few releases. Here are a few random thoughts to initiate the discussion. I've just listed the things that came to my mind this morning, but I'm sure that there's much much more to add :) - Support for transaction and reliability policies Several users have asked for it, and there's now a public draft of the transaction policy spec - Webapp and EJB module integration I'd like to track the OASIS work on this and implement it in parallel in Tuscany. Many users have existing J2EE EJB and EAR modules that they'll need to integrate in bigger SCA compositions. Also Webapp developers will need a non-intrusive way to wire a Webapp with other SCA components in an SCA domain. - Conversational and non blocking + callback programming model over Web2.0 bindings Seems like a good fit with JSON for example... in particular Ajax interactions fit really well with the SCA non blocking + callback programming model. - Ability to model client side JavaScript components Looking at the Store sample for example, I'd like to be able to model the client Javascript as a component with SCA references to the ShoppingCart and Catalog services, instead of manually creating JSON and Atom client proxies in the client Javascript code. - Support for Atom using Apache Abdera Abdera just released their 0.3.0, I've started to look at it and it looks pretty good. I think we should try to port our Atom/RSS binding to it and see how it compares with the Rome library which we are currently using. - More modular distributions, in addition to our current all-in-one distribution, distribute smaller packages that people can choose to install or not? - Some clean up of the core runtime invocation and injection mechanism, we can probably simplify and actually remove code in a number of places :) Could people please jump in and say what they want to see in the next few releases? What they need for their Tuscany based projects? What is missing? What needs to be improved or fixed? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [DISCUSS] Tuscany SCA Roadmap and next releases
Hi, In addtion to what Sebastien brought up, I have a few more on the wish list: Core: * Separate the interface declaration (per service or reference) and interface type (can be shared if used by multiple services or references) and enhance the dynamic interface/operation support * Improve exception handling accross bindings * Better support the remote case of binding.sca (marshaling/unmarshaling data, performance optimization, propagation of callable references) Bindings: * Bring binding.jms to spec 1.0 level (and what about JCA as the 1.0 spec is out?) * Add support for JSONRPC reference binding so that SCA components can talk to JSONRPC services * Better align the WSDL2Java tools with Axis2 * Leverage the Axis2 JAX-WS metadata layer for better WSDL/Java interop and the WSDL-less support Tooling: * Improve the Eclipse-based tooling support to facilitate developing and testing Tuscany SCA Java applications. Hosting environment: * Further improve the Tuscany/Geronimo integration to better leverage the SCA domain/node Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: "tuscany user" Cc: <[EMAIL PROTECTED]> Sent: Wednesday, October 10, 2007 9:03 AM Subject: [DISCUSS] Tuscany SCA Roadmap and next releases Hi all, We've released v1.0 of Tuscany SCA 2 weeks ago... So it's probably the right time now to ask what people want to do next and try to build a roadmap for the next few releases. Here are a few random thoughts to initiate the discussion. I've just listed the things that came to my mind this morning, but I'm sure that there's much much more to add :) - Support for transaction and reliability policies Several users have asked for it, and there's now a public draft of the transaction policy spec - Webapp and EJB module integration I'd like to track the OASIS work on this and implement it in parallel in Tuscany. Many users have existing J2EE EJB and EAR modules that they'll need to integrate in bigger SCA compositions. Also Webapp developers will need a non-intrusive way to wire a Webapp with other SCA components in an SCA domain. - Conversational and non blocking + callback programming model over Web2.0 bindings Seems like a good fit with JSON for example... in particular Ajax interactions fit really well with the SCA non blocking + callback programming model. - Ability to model client side JavaScript components Looking at the Store sample for example, I'd like to be able to model the client Javascript as a component with SCA references to the ShoppingCart and Catalog services, instead of manually creating JSON and Atom client proxies in the client Javascript code. - Support for Atom using Apache Abdera Abdera just released their 0.3.0, I've started to look at it and it looks pretty good. I think we should try to port our Atom/RSS binding to it and see how it compares with the Rome library which we are currently using. - More modular distributions, in addition to our current all-in-one distribution, distribute smaller packages that people can choose to install or not? - Some clean up of the core runtime invocation and injection mechanism, we can probably simplify and actually remove code in a number of places :) Could people please jump in and say what they want to see in the next few releases? What they need for their Tuscany based projects? What is missing? What needs to be improved or fixed? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Tuscany SCA Roadmap and next releases
Matthew Peters wrote: As you'll guess from the post on Websphere and Tuscany that I put up a couple of days ago, My response: http://marc.info/?l=tuscany-user&m=119223827124704 I would like to see where you want to go in the area of - Webapp and EJB module integration I'd like to track the OASIS work on this and implement it in parallel in Tuscany. Many users have existing J2EE EJB and EAR modules that they'll need to integrate in bigger SCA compositions. Also Webapp developers will need a non-intrusive way to wire a Webapp with other SCA components in an SCA domain. For example when you wire a webapp to an SCA component, how is the SCA domain found, I think that an SCA-enabled runtime (a JEE runtime or any other form of SCA enabled runtime) needs to be configured with a domain URI that it will belong to. At the moment in Tuscany we just pass that URI when we bootstrap the runtime. If you're up for a long read, see the SCA Domain discussion thread on the tuscany-dev list, here's a pointer to the last email in that thread: http://marc.info/?l=tuscany-dev&m=119196408721454&w=2 and who starts and stops it? The domain administrator :) independent of what JEE or other apps are deployed to it. How and when did the components get deployed into it? I can think of three main scenarios: - An SCA domain administrator goes to his domain management application and uploads a contribution, then adds some composites from the contribution to the domain level composite. At that point the SCA domain management app finds the appropriate runtime node for the contribution, distributes the contribution to the node. - An administrator goes to a node belonging to an SCA domain, uploads a contribution, then adds some composites from the contribution to the domain level composite. - A contribution and composites have already been installed on a node by some mechanisms unknown to Tuscany, the SCA domain administrator goes to the domain management application to register the presence of these composites in the domain. ... and all kinds of variations of the above, but these scenarios are not really specific to JEE integration, it's just how I view an SCA domain being used. And wre we ever going to have webapps which *are* SCA components so that we want to do dependency injection directly into a servlet for example? I guess this is the idea of being able to declare a JEE Web module as an SCA component implementation. You can declare SCA references on the Web module, wire them to SCA services, and invoke them from code running in the Webapp. I'm not very fond of mixing programming models, as it makes tech people happy but usually gets in the way of the business application developer who's trying to achieve something without having to learn 4 programming languages, 12 APIs, and 37 different ways to bind XML to Java. So I hope we can do this in a non-intrusive way without introducing too many SCA programming model artifacts in the JEE Webapp. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Tuscany SCA Roadmap and next releases
>From what you mentioned, I'm very interested in the web 2.0 integration, and the ability to mashup SCA components/services using simple SCA References concept on a web 2.0 client application. I think that we should also add Data Integration to our Roadmap, as I see SCA of great help to simplify exposing data as services to a client application in a simple and flexible way. As for Core capabilities, I think we should improve the error reporting/handling for our data binding framework. On 10/10/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Hi all, > > We've released v1.0 of Tuscany SCA 2 weeks ago... So it's probably the > right time now to ask what people want to do next and try to build a > roadmap for the next few releases. > > Here are a few random thoughts to initiate the discussion. I've just > listed the things that came to my mind this morning, but I'm sure that > there's much much more to add :) > > - Support for transaction and reliability policies > Several users have asked for it, and there's now a public draft of the > transaction policy spec > > - Webapp and EJB module integration > I'd like to track the OASIS work on this and implement it in parallel in > Tuscany. Many users have existing J2EE EJB and EAR modules that they'll > need to integrate in bigger SCA compositions. Also Webapp developers > will need a non-intrusive way to wire a Webapp with other SCA components > in an SCA domain. > > - Conversational and non blocking + callback programming model over > Web2.0 bindings > Seems like a good fit with JSON for example... in particular Ajax > interactions fit really well with the SCA non blocking + callback > programming model. > > - Ability to model client side JavaScript components > Looking at the Store sample for example, I'd like to be able to model > the client Javascript as a component with SCA references to the > ShoppingCart and Catalog services, instead of manually creating JSON and > Atom client proxies in the client Javascript code. > > - Support for Atom using Apache Abdera > Abdera just released their 0.3.0, I've started to look at it and it > looks pretty good. I think we should try to port our Atom/RSS binding to > it and see how it compares with the Rome library which we are currently > using. > > - More modular distributions, in addition to our current all-in-one > distribution, distribute smaller packages that people can choose to > install or not? > > - Some clean up of the core runtime invocation and injection mechanism, > we can probably simplify and actually remove code in a number of places :) > > Could people please jump in and say what they want to see in the next > few releases? What they need for their Tuscany based projects? What is > missing? What needs to be improved or fixed? > > -- > Jean-Sebastien > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Tuscany SCA Roadmap and next releases
Hi, Thank you for participating the discussion. I collected all the input we have so far at the following WIKI page: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion Please feel free to add/update to make it an ongoing community effect. Hopefully we can start to turn them into actions and I believe some specific discussions have been carried on the ML. As always, your contributions are welcome. Thanks, Raymond - Original Message - From: "wang feng" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 16, 2007 7:18 PM Subject: Re: Re: [DISCUSS] Tuscany SCA Roadmap and next releases Hi all, We have used Tuscany 1.0 in our product and found some features is important to us. - Support hot deployable on contribution and composite. This should be have a recursive algorithm to update the correlated component when it has been referenced. - Support SDO namespace when using websservice. Deploy a service to webservice,a schema file used in SDO and have sdo namespace such as commonj.sdo/java or commonj.sdo/xml,we should support the feature when parsing the wsdl. - Support load contribution as a osgi bundle. Thanks, wangfeng On 2007-10-17, Simon Laws <[EMAIL PROTECTED]> wrote: On 10/16/07, Luciano Resende <[EMAIL PROTECTED]> wrote: For implementation.bpel, we need to finalize support for references, and we might want to do introspection of the BPEL process. On 10/16/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > [snip] > ant elder wrote: > > > > - Fix nightly builds (looks like this may be going again now) > > > > Yes it is. > > http://vmbuild1.apache.org/continuum/buildResults.action?projectGroupId=19&projectId=277 > > [snip] > > - Fix all the build issues (maven 2.0.6/2.0.7/JDK6/empty repository) so new > > users building Tuscany have a good experience > > > > After the changes I made last week I think this is now all fixed > (except > for JIRAs TUSCANY-1846 and TUSCANY-1847). I am currently building with > Maven 2.0.7 and both JDK5 and JDK6. > > Could people please try other Maven combinations? 2.0.5, 2.0.6, and > report any errors? Thanks. > > [snip] > > - Get binding.jms and implementation.bpel more spec complete. > > - For JMS maybe have a host-jms module so you don't have to start a separate > > JMS server or can use the the Geronimo one if thats where Tuscany is running > > > > What's missing in binding.jms and implementation.bpel? Could people > working on these modules give a quick overview? > > -- > Jean-Sebastien > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For binding.jms the user guide shows you that most of the options still need to be implemented. http://incubator.apache.org/tuscany/sca-java-bindingjms.html There are a few people either working on this or have expressed an interest in working on it. There is quite a lot on incremental stuff that can be done for anyone else who is interested. Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Tuscany SCA Roadmap and next releases
On 10/17/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Hi, > > Thank you for participating the discussion. I collected all the input we > have so far at the following WIKI page: > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion > > Please feel free to add/update to make it an ongoing community effect. > > Hopefully we can start to turn them into actions and I believe some > specific > discussions have been carried on the ML. As always, your contributions are > welcome. > > Thanks, > Raymond > > - Original Message - > From: "wang feng" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, October 16, 2007 7:18 PM > Subject: Re: Re: [DISCUSS] Tuscany SCA Roadmap and next releases > > > > Hi all, > > > > We have used Tuscany 1.0 in our product and found some features is > > important to us. > > > > - Support hot deployable on contribution and composite. > > This should be have a recursive algorithm to update the correlated > > component when it has been referenced. > > > > - Support SDO namespace when using websservice. > > Deploy a service to webservice,a schema file used in SDO and have sdo > > namespace such as commonj.sdo/java or commonj.sdo/xml,we should support > > the feature when parsing the wsdl. > > > > - Support load contribution as a osgi bundle. > > > > > > Thanks, > > wangfeng > > > > > > On 2007-10-17, Simon Laws <[EMAIL PROTECTED]> wrote: > > > >>On 10/16/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > >>> > >>> For implementation.bpel, we need to finalize support for references, > >>> and we might want to do introspection of the BPEL process. > >>> > >>> On 10/16/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > >>> > [snip] > >>> > ant elder wrote: > >>> > > > >>> > > - Fix nightly builds (looks like this may be going again now) > >>> > > > >>> > > >>> > Yes it is. > >>> > > >>> > > >>> > http://vmbuild1.apache.org/continuum/buildResults.action?projectGroupId=19&projectId=277 > >>> > > >>> > [snip] > >>> > > - Fix all the build issues (maven 2.0.6/2.0.7/JDK6/empty > repository) > >>> so new > >>> > > users building Tuscany have a good experience > >>> > > > >>> > > >>> > After the changes I made last week I think this is now all fixed > >>> > (except > >>> > for JIRAs TUSCANY-1846 and TUSCANY-1847). I am currently building > with > >>> > Maven 2.0.7 and both JDK5 and JDK6. > >>> > > >>> > Could people please try other Maven combinations? 2.0.5, 2.0.6, and > >>> > report any errors? Thanks. > >>> > > >>> > [snip] > >>> > > - Get binding.jms and implementation.bpel more spec complete. > >>> > > - For JMS maybe have a host-jms module so you don't have to start > a > >>> separate > >>> > > JMS server or can use the the Geronimo one if thats where Tuscany > is > >>> running > >>> > > > >>> > > >>> > What's missing in binding.jms and implementation.bpel? Could people > >>> > working on these modules give a quick overview? > >>> > > >>> > -- > >>> > Jean-Sebastien > >>> > > >>> > > >>> > > - > >>> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> > For additional commands, e-mail: [EMAIL PROTECTED] > >>> > > >>> > > >>> > >>> > >>> -- > >>> Luciano Resende > >>> Apache Tuscany Committer > >>> http://people.apache.org/~lresende > >>> http://lresende.blogspot.com/ > >>> > >>> - > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> For binding.jms the user guide shows you that most of the options > still > >>need to be implemented. > >> > >>http://incubator.apache.org/tuscany/sca-java-bindingjms.html > >> > >>There are
Re: [DISCUSS] Tuscany SCA Roadmap and next releases
On 10/18/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > On 10/17/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > Thank you for participating the discussion. I collected all the input we > > have so far at the following WIKI page: > > > > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion > > > > Please feel free to add/update to make it an ongoing community effect. > > > > Hopefully we can start to turn them into actions and I believe some > > specific > > discussions have been carried on the ML. As always, your contributions > are > > welcome. > > > > Thanks, > > Raymond > > > > - Original Message - > > From: "wang feng" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, October 16, 2007 7:18 PM > > Subject: Re: Re: [DISCUSS] Tuscany SCA Roadmap and next releases > > > > > > > Hi all, > > > > > > We have used Tuscany 1.0 in our product and found some features is > > > important to us. > > > > > > - Support hot deployable on contribution and composite. > > > This should be have a recursive algorithm to update the correlated > > > component when it has been referenced. > > > > > > - Support SDO namespace when using websservice. > > > Deploy a service to webservice,a schema file used in SDO and have sdo > > > namespace such as commonj.sdo/java or commonj.sdo/xml,we should > support > > > the feature when parsing the wsdl. > > > > > > - Support load contribution as a osgi bundle. > > > > > > > > > Thanks, > > > wangfeng > > > > > > > > > On 2007-10-17, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > >>On 10/16/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > >>> > > >>> For implementation.bpel, we need to finalize support for references, > > >>> and we might want to do introspection of the BPEL process. > > >>> > > >>> On 10/16/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > >>> > [snip] > > >>> > ant elder wrote: > > >>> > > > > >>> > > - Fix nightly builds (looks like this may be going again now) > > >>> > > > > >>> > > > >>> > Yes it is. > > >>> > > > >>> > > > >>> > > > http://vmbuild1.apache.org/continuum/buildResults.action?projectGroupId=19&projectId=277 > > >>> > > > >>> > [snip] > > >>> > > - Fix all the build issues (maven 2.0.6/2.0.7/JDK6/empty > > repository) > > >>> so new > > >>> > > users building Tuscany have a good experience > > >>> > > > > >>> > > > >>> > After the changes I made last week I think this is now all fixed > > >>> > (except > > >>> > for JIRAs TUSCANY-1846 and TUSCANY-1847). I am currently building > > with > > >>> > Maven 2.0.7 and both JDK5 and JDK6. > > >>> > > > >>> > Could people please try other Maven combinations? 2.0.5, 2.0.6, > and > > >>> > report any errors? Thanks. > > >>> > > > >>> > [snip] > > >>> > > - Get binding.jms and implementation.bpel more spec complete. > > >>> > > - For JMS maybe have a host-jms module so you don't have to > start > > a > > >>> separate > > >>> > > JMS server or can use the the Geronimo one if thats where > Tuscany > > is > > >>> running > > >>> > > > > >>> > > > >>> > What's missing in binding.jms and implementation.bpel? Could > people > > >>> > working on these modules give a quick overview? > > >>> > > > >>> > -- > > >>> > Jean-Sebastien > > >>> > > > >>> > > > >>> > > > - > > >>> > To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>> > For additional commands, e-mail: [EMAIL PROTECTED] > > >>> > > > >>> > > > >>> > > >>> > > >>> -- > > >>> Luciano Resende &
Re: [DISCUSS] Tuscany SCA Roadmap and next releases
On 10/18/07, ant elder <[EMAIL PROTECTED]> wrote: > > On 10/18/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > On 10/17/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > Thank you for participating the discussion. I collected all the input > we > > > have so far at the following WIKI page: > > > > > > > > > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion > > > > > > Please feel free to add/update to make it an ongoing community effect. > > > > > > Hopefully we can start to turn them into actions and I believe some > > > specific > > > discussions have been carried on the ML. As always, your contributions > > are > > > welcome. > > > > > > Thanks, > > > Raymond > > > > > > - Original Message - > > > From: "wang feng" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Tuesday, October 16, 2007 7:18 PM > > > Subject: Re: Re: [DISCUSS] Tuscany SCA Roadmap and next releases > > > > > > > > > > Hi all, > > > > > > > > We have used Tuscany 1.0 in our product and found some features is > > > > important to us. > > > > > > > > - Support hot deployable on contribution and composite. > > > > This should be have a recursive algorithm to update the correlated > > > > component when it has been referenced. > > > > > > > > - Support SDO namespace when using websservice. > > > > Deploy a service to webservice,a schema file used in SDO and have > sdo > > > > namespace such as commonj.sdo/java or commonj.sdo/xml,we should > > support > > > > the feature when parsing the wsdl. > > > > > > > > - Support load contribution as a osgi bundle. > > > > > > > > > > > > Thanks, > > > > wangfeng > > > > > > > > > > > > On 2007-10-17, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > > >>On 10/16/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > > >>> > > > >>> For implementation.bpel, we need to finalize support for > references, > > > >>> and we might want to do introspection of the BPEL process. > > > >>> > > > >>> On 10/16/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > >>> > [snip] > > > >>> > ant elder wrote: > > > >>> > > > > > >>> > > - Fix nightly builds (looks like this may be going again now) > > > >>> > > > > > >>> > > > > >>> > Yes it is. > > > >>> > > > > >>> > > > > >>> > > > > > > http://vmbuild1.apache.org/continuum/buildResults.action?projectGroupId=19&projectId=277 > > > >>> > > > > >>> > [snip] > > > >>> > > - Fix all the build issues (maven 2.0.6/2.0.7/JDK6/empty > > > repository) > > > >>> so new > > > >>> > > users building Tuscany have a good experience > > > >>> > > > > > >>> > > > > >>> > After the changes I made last week I think this is now all fixed > > > >>> > (except > > > >>> > for JIRAs TUSCANY-1846 and TUSCANY-1847). I am currently > building > > > with > > > >>> > Maven 2.0.7 and both JDK5 and JDK6. > > > >>> > > > > >>> > Could people please try other Maven combinations? 2.0.5, 2.0.6, > > and > > > >>> > report any errors? Thanks. > > > >>> > > > > >>> > [snip] > > > >>> > > - Get binding.jms and implementation.bpel more spec complete. > > > >>> > > - For JMS maybe have a host-jms module so you don't have to > > start > > > a > > > >>> separate > > > >>> > > JMS server or can use the the Geronimo one if thats where > > Tuscany > > > is > > > >>> running > > > >>> > > > > > >>> > > > > >>> > What's missing in binding.jms and implementation.bpel? Could > > people > > > >>> > working on t
Re: [DISCUSS] Tuscany SCA Roadmap and next releases
Simon Laws wrote: On 10/17/07, Raymond Feng <[EMAIL PROTECTED]> wrote: I collected all the input we have so far at the following WIKI page: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion Thanks for doing that! Coincidentally there's a recent news article related to the worthwhileness of these types of lists over on INFOQ: http://www.infoq.com/news/2007/10/product-backlogs-wasteful We did try having the "wishlist" jira version but it never really ended up being used very much. ...ant [snip] Thanks for the ref ant. Very interesting. In our case the list we have generated is very much a list of "features desired but not yet implemented".I wasn't suggesting we take the next step and analyse them all in detail though, just that we don't loose these thoughts in case someone decides that they would like to do the analysis in the future. I think this thread is equating the act of creating a "Roadmap" with identifying the ideas that the currently active community agree will add real value to Tuscany SCA and it's users. I'm keen though that we don't create an immutable plan/roadmap and that we have plenty of ideas hanging around that may encourage those not currently contributing to do so. I see the danger of a stated roadmap is that it gives the impression that that is what is going to happen, that all the items are being worked on and encourages people to sit back and wait for features to arrive. Re. the "wish" JIRA type. maybe now is the time. The wiki page is a long list already. Wish list items don't require much management, they may hang around for a long time but they provide inspiration to newcomers and to the active community when we inevitably repeat this exercise. Regards Simon How about trying to understand the use cases for that Wiki page and/or JIRA list? Here are a few: A) I just found out about SCA and Tuscany. I want to know what it does now and what it'll do in the future. B) I'm using Tuscany. I want to know what features will be provided, short, middle and long term. C) I'd like to contribute to Tuscany. Who's working on what and are there any interesting areas that I could jump into? more thoughts? Here are some roadmaps that I found worthwhile and useful as a lurker, user, and potential contributor. There are some good organization + format ideas in these roadmaps: [1] http://harmony.apache.org/roadmap.html [2] http://cwiki.apache.org/GMOxDEV/roadmap-for-21.html [3] http://cwiki.apache.org/GMOxPMGT/geronimo-what-folks-are-working-on.html [4] http://wiki.apache.org/ws/FrontPage/Axis2/post-1%2e3-plans [5] http://ode.apache.org/roadmap.html [6] http://subversion.tigris.org/roadmap.html Going back to the use cases: IMO a roadmap like [3] answers question (C), and questions (A) and (B) too... as seeing people names and the releases that they target shows that the listed features are not just wishes or vaporware. Hope this helps. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
