Content for next milestone
Now that we have a list of requirements on our Wiki at http://cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what+folks+are+working+on, and a number of people are signing up for some of the corresponding work, I'd like to start a discussion on the content of our next milestone. Given that our last milestone was in December, I'd like to have another milestone soon, by March. Here's the function that people have already signed up for on the Wiki page + what I'm interested in for this milestone: - Support for complex properties and multi valued properties - Support for SCA deployment-contributions, and in particular support for JAR based deployment contributions - Ability to reference and resolve composites in an SCA domain (would be nice to support recursive composition but I'm not particularly interested in it) - Ability to configure and override the configuration of References, Services and Properties (again here I'd be happy if this works with just one or two levels of composition) - Support for wiring inside an SCA domain references to services with bindings and have the wiring decide the endpoints to use - Support for business exceptions in end to end interactions - Support for promoting services and references out of a composite (without having to wire a reference to a reference or a service to a service) - Support for defining and configuring services and references directly on components - Interchangeability / mapping between Java and WSDL interfaces - Ability to use, alter and write an SCDL model at deployment - WSDL2Java and Java2WSDL support using the SDO databinding - Core support for non-blocking invocations playing nicely with bindings, and without having to send complete routing paths to the services/references - Databinding framework with support for conversions between JAXB and SDO - Working and modular build allowing to build subsets of the project - Services to add(/remove/query) compositions to an SCA domain - Services to add(/remove/query) SCA deployment contributions to an SCA domain - Core support for addressing, resolving, loading artifacts from SCA deployment contributions Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
Sebastien, I'm a little surprised that you have not referenced the previous release discussion thread or any of the work that has been ongoing in core over the past month and a half: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12291.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13445.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12238.html Most of the work in core during this period has been aimed at getting a release of kernel out that supports features outlined in the first referenced thread. How does your proposal relate to that release? I'm happy to have two simultaneous release processes going at once and think it could even be beneficial. However, it would be helpful if you put your proposal in context so others such as myself can understand it a bit better. Jim On Feb 5, 2007, at 5:19 PM, Jean-Sebastien Delfino wrote: Now that we have a list of requirements on our Wiki at http:// cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what +folks+are+working+on, and a number of people are signing up for some of the corresponding work, I'd like to start a discussion on the content of our next milestone. Given that our last milestone was in December, I'd like to have another milestone soon, by March. Here's the function that people have already signed up for on the Wiki page + what I'm interested in for this milestone: - Support for complex properties and multi valued properties - Support for SCA deployment-contributions, and in particular support for JAR based deployment contributions - Ability to reference and resolve composites in an SCA domain (would be nice to support recursive composition but I'm not particularly interested in it) - Ability to configure and override the configuration of References, Services and Properties (again here I'd be happy if this works with just one or two levels of composition) - Support for wiring inside an SCA domain references to services with bindings and have the wiring decide the endpoints to use - Support for business exceptions in end to end interactions - Support for promoting services and references out of a composite (without having to wire a reference to a reference or a service to a service) - Support for defining and configuring services and references directly on components - Interchangeability / mapping between Java and WSDL interfaces - Ability to use, alter and write an SCDL model at deployment - WSDL2Java and Java2WSDL support using the SDO databinding - Core support for non-blocking invocations playing nicely with bindings, and without having to send complete routing paths to the services/references - Databinding framework with support for conversions between JAXB and SDO - Working and modular build allowing to build subsets of the project - Services to add(/remove/query) compositions to an SCA domain - Services to add(/remove/query) SCA deployment contributions to an SCA domain - Core support for addressing, resolving, loading artifacts from SCA deployment contributions Thoughts? -- 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: Content for next milestone
Jim Marino wrote: Sebastien, I'm a little surprised that you have not referenced the previous release discussion thread or any of the work that has been ongoing in core over the past month and a half: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12291.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13445.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12238.html Most of the work in core during this period has been aimed at getting a release of kernel out that supports features outlined in the first referenced thread. How does your proposal relate to that release? I'm happy to have two simultaneous release processes going at once and think it could even be beneficial. However, it would be helpful if you put your proposal in context so others such as myself can understand it a bit better. Jim On Feb 5, 2007, at 5:19 PM, Jean-Sebastien Delfino wrote: Now that we have a list of requirements on our Wiki at http://cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what+folks+are+working+on, and a number of people are signing up for some of the corresponding work, I'd like to start a discussion on the content of our next milestone. Given that our last milestone was in December, I'd like to have another milestone soon, by March. Here's the function that people have already signed up for on the Wiki page + what I'm interested in for this milestone: - Support for complex properties and multi valued properties - Support for SCA deployment-contributions, and in particular support for JAR based deployment contributions - Ability to reference and resolve composites in an SCA domain (would be nice to support recursive composition but I'm not particularly interested in it) - Ability to configure and override the configuration of References, Services and Properties (again here I'd be happy if this works with just one or two levels of composition) - Support for wiring inside an SCA domain references to services with bindings and have the wiring decide the endpoints to use - Support for business exceptions in end to end interactions - Support for promoting services and references out of a composite (without having to wire a reference to a reference or a service to a service) - Support for defining and configuring services and references directly on components - Interchangeability / mapping between Java and WSDL interfaces - Ability to use, alter and write an SCDL model at deployment - WSDL2Java and Java2WSDL support using the SDO databinding - Core support for non-blocking invocations playing nicely with bindings, and without having to send complete routing paths to the services/references - Databinding framework with support for conversions between JAXB and SDO - Working and modular build allowing to build subsets of the project - Services to add(/remove/query) compositions to an SCA domain - Services to add(/remove/query) SCA deployment contributions to an SCA domain - Core support for addressing, resolving, loading artifacts from SCA deployment contributions Thoughts? --Jean-Sebastien Jim, The idea is to bring together a number of pieces from the core runtime, extensions like databinding and WSDL support, tools like WSDL2Java and Java2WSDL etc. and stabilize them to get some of the basic function that I listed in my earlier email working in end to end scenarios. As a first step, we probably need a very small subset of the new deployment story that is being built in the trunk, starting with the ability to work with one SCA composite and one JAR contribution. To have a stable integration by March, I think we need to start this effort now. In order to not disrupt the wider and more innovative work going on in the trunk I'd like to do the integration/stabilization work in a branch, starting with the kernel from the pre-spec-changes branch or a stable level from last week. This will allow the trunk to continue to evolve in parallel and at a faster pace to support things like federated deployment, new management services, JMX support, multiparent classloading, and the latest changes to the Java C&I APIs. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
Guys, I'm a little confused here - so far we seem to have 3 different people volunteering to manage 3 different releases. We now have a very very long list of "requirements" many of which have not been discussed on the list and most of which do not have names against them or really relate to the coding that is actually going on; they also don't seem to apply to two out of the three releases. Version numbers are being assigned to milestones, we have stabilization branches and end-to-end scenarios, all without meaningful discussion on this list. I think we need to stop and figure out what we are doing as a community. Here, on this list, with everyone involved. -- Jeremy On Feb 6, 2007, at 3:58 PM, Jean-Sebastien Delfino wrote: Jim Marino wrote: Sebastien, I'm a little surprised that you have not referenced the previous release discussion thread or any of the work that has been ongoing in core over the past month and a half: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12291.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13445.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12238.html Most of the work in core during this period has been aimed at getting a release of kernel out that supports features outlined in the first referenced thread. How does your proposal relate to that release? I'm happy to have two simultaneous release processes going at once and think it could even be beneficial. However, it would be helpful if you put your proposal in context so others such as myself can understand it a bit better. Jim On Feb 5, 2007, at 5:19 PM, Jean-Sebastien Delfino wrote: Now that we have a list of requirements on our Wiki at http:// cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what +folks+are+working+on, and a number of people are signing up for some of the corresponding work, I'd like to start a discussion on the content of our next milestone. Given that our last milestone was in December, I'd like to have another milestone soon, by March. Here's the function that people have already signed up for on the Wiki page + what I'm interested in for this milestone: - Support for complex properties and multi valued properties - Support for SCA deployment-contributions, and in particular support for JAR based deployment contributions - Ability to reference and resolve composites in an SCA domain (would be nice to support recursive composition but I'm not particularly interested in it) - Ability to configure and override the configuration of References, Services and Properties (again here I'd be happy if this works with just one or two levels of composition) - Support for wiring inside an SCA domain references to services with bindings and have the wiring decide the endpoints to use - Support for business exceptions in end to end interactions - Support for promoting services and references out of a composite (without having to wire a reference to a reference or a service to a service) - Support for defining and configuring services and references directly on components - Interchangeability / mapping between Java and WSDL interfaces - Ability to use, alter and write an SCDL model at deployment - WSDL2Java and Java2WSDL support using the SDO databinding - Core support for non-blocking invocations playing nicely with bindings, and without having to send complete routing paths to the services/references - Databinding framework with support for conversions between JAXB and SDO - Working and modular build allowing to build subsets of the project - Services to add(/remove/query) compositions to an SCA domain - Services to add(/remove/query) SCA deployment contributions to an SCA domain - Core support for addressing, resolving, loading artifacts from SCA deployment contributions Thoughts? --Jean-Sebastien Jim, The idea is to bring together a number of pieces from the core runtime, extensions like databinding and WSDL support, tools like WSDL2Java and Java2WSDL etc. and stabilize them to get some of the basic function that I listed in my earlier email working in end to end scenarios. As a first step, we probably need a very small subset of the new deployment story that is being built in the trunk, starting with the ability to work with one SCA composite and one JAR contribution. To have a stable integration by March, I think we need to start this effort now. In order to not disrupt the wider and more innovative work going on in the trunk I'd like to do the integration/stabilization work in a branch, starting with the kernel from the pre-spec-changes branch or a stable level from last week. This will allow the trunk to continue to evolve in parallel and at a faster pace to support things like federated deployment, new management services, JMX support, multiparent classloading, and the latest changes to the Java C&I APIs. -- Jean-Seb
Re: Content for next milestone
A March release with basic functional improvements in a consumable package (kernel, selected extensions, and tools) makes sense to me. As well as the items suggested by Sebastien, I'm interested in adding flexible ordering of elements in SCDL files as required by the SCA spec. Having work on these items proceed in a branch so that it does not conflict with the restructuring and distributed deployment work going on in trunk would allow people to be more productive, with less interference between the different activities in progress. Simon Jeremy Boynes wrote: Guys, I'm a little confused here - so far we seem to have 3 different people volunteering to manage 3 different releases. We now have a very very long list of "requirements" many of which have not been discussed on the list and most of which do not have names against them or really relate to the coding that is actually going on; they also don't seem to apply to two out of the three releases. Version numbers are being assigned to milestones, we have stabilization branches and end-to-end scenarios, all without meaningful discussion on this list. I think we need to stop and figure out what we are doing as a community. Here, on this list, with everyone involved. -- Jeremy On Feb 6, 2007, at 3:58 PM, Jean-Sebastien Delfino wrote: Jim Marino wrote: Sebastien, I'm a little surprised that you have not referenced the previous release discussion thread or any of the work that has been ongoing in core over the past month and a half: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12291.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13445.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12238.html Most of the work in core during this period has been aimed at getting a release of kernel out that supports features outlined in the first referenced thread. How does your proposal relate to that release? I'm happy to have two simultaneous release processes going at once and think it could even be beneficial. However, it would be helpful if you put your proposal in context so others such as myself can understand it a bit better. Jim On Feb 5, 2007, at 5:19 PM, Jean-Sebastien Delfino wrote: Now that we have a list of requirements on our Wiki at http:// cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what +folks+are+working+on, and a number of people are signing up for some of the corresponding work, I'd like to start a discussion on the content of our next milestone. Given that our last milestone was in December, I'd like to have another milestone soon, by March. Here's the function that people have already signed up for on the Wiki page + what I'm interested in for this milestone: - Support for complex properties and multi valued properties - Support for SCA deployment-contributions, and in particular support for JAR based deployment contributions - Ability to reference and resolve composites in an SCA domain (would be nice to support recursive composition but I'm not particularly interested in it) - Ability to configure and override the configuration of References, Services and Properties (again here I'd be happy if this works with just one or two levels of composition) - Support for wiring inside an SCA domain references to services with bindings and have the wiring decide the endpoints to use - Support for business exceptions in end to end interactions - Support for promoting services and references out of a composite (without having to wire a reference to a reference or a service to a service) - Support for defining and configuring services and references directly on components - Interchangeability / mapping between Java and WSDL interfaces - Ability to use, alter and write an SCDL model at deployment - WSDL2Java and Java2WSDL support using the SDO databinding - Core support for non-blocking invocations playing nicely with bindings, and without having to send complete routing paths to the services/references - Databinding framework with support for conversions between JAXB and SDO - Working and modular build allowing to build subsets of the project - Services to add(/remove/query) compositions to an SCA domain - Services to add(/remove/query) SCA deployment contributions to an SCA domain - Core support for addressing, resolving, loading artifacts from SCA deployment contributions Thoughts? --Jean-Sebastien Jim, The idea is to bring together a number of pieces from the core runtime, extensions like databinding and WSDL support, tools like WSDL2Java and Java2WSDL etc. and stabilize them to get some of the basic function that I listed in my earlier email working in end to end scenarios. As a first step, we probably need a very small subset of the new deployment story that is being built in the trunk, starting with the ability to work with one SCA composite and one JAR contribution. To have a
Re: Content for next milestone
Hi, Heres my opinion from the perspective of some items that I have owned up to do quite a while back - support for complex properties and multivalued properties. I'd see them as some fundamental things that a user might expect to see out of our next milestone and am happy that they are a part of this list that Sebastien has proposed. Now to complete this, I am in dire need for a stable runtime and client API. I need this for two reasons i) to figure out the workings of the kernel through debugging so that I may implement these features according to the framework's design (with loaders, builders, etc.) and ii) to test if the whole thing sews up together and works as expected. I am just not able to figure out how to do this from the current trunk andI have already started to plead for help in this regard from the community I have no complaints about the work that is going on presently in the kernel - infact I am excited about the vision with which its being driven. But then, I'd be happy if I could do my parts as well alongside. Here are my thoughts for the path forward... - I'd like us to plan for the next milestone release ideally by end of March to feed the curiosity of our users. Having a long gap will kill their interest in our technology. - I'd deem the current kernel work as well as the items listed by Sebastien as equally important, but we probably need to figure out how we can do both parallely. Can we not do an incremental development of both? For example we could baseline a stable and functioning version of the kernel and runtime and then choose those items from Sebastien's list that can be implemented over this baseline. Or maybe do the viceversa, choose the items and bring the kernel up to a level to be able to support its implementation. Going forward with both in increments will also help us to merge forward easily, I would imagine. - I don't think its would be a good idea for the items in Sebastien's list to wait until the ongoing work in the kernel and runtime is complete. I think Jeremy's point that we have to stop and now look what we are doing as a community is valid. We must have to get things around so that everybody in the community is able to contribute effectively. Thanks - Venkat On 2/7/07, Simon Nash <[EMAIL PROTECTED]> wrote: A March release with basic functional improvements in a consumable package (kernel, selected extensions, and tools) makes sense to me. As well as the items suggested by Sebastien, I'm interested in adding flexible ordering of elements in SCDL files as required by the SCA spec. Having work on these items proceed in a branch so that it does not conflict with the restructuring and distributed deployment work going on in trunk would allow people to be more productive, with less interference between the different activities in progress. Simon Jeremy Boynes wrote: > Guys, > > I'm a little confused here - so far we seem to have 3 different people > volunteering to manage 3 different releases. We now have a very very > long list of "requirements" many of which have not been discussed on > the list and most of which do not have names against them or really > relate to the coding that is actually going on; they also don't seem to > apply to two out of the three releases. Version numbers are being > assigned to milestones, we have stabilization branches and end-to-end > scenarios, all without meaningful discussion on this list. > > I think we need to stop and figure out what we are doing as a > community. Here, on this list, with everyone involved. > -- > Jeremy > > On Feb 6, 2007, at 3:58 PM, Jean-Sebastien Delfino wrote: > >> Jim Marino wrote: >> >>> Sebastien, >>> >>> I'm a little surprised that you have not referenced the previous >>> release discussion thread or any of the work that has been ongoing >>> in core over the past month and a half: >>> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12291.html >>> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13445.html >>> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12238.html >>> >>> Most of the work in core during this period has been aimed at >>> getting a release of kernel out that supports features outlined in >>> the first referenced thread. How does your proposal relate to that >>> release? I'm happy to have two simultaneous release processes going >>> at once and think it could even be beneficial. However, it would be >>> helpful if you put your proposal in context so others such as myself >>> can understand it a bit better. >>> >>> Jim >>> >>> >>> On Feb 5, 2007, at 5:19 PM, Jean-Sebastien Delfino wrote: >>> Now that we have a list of requirements on our Wiki at http:// cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what +folks+are+working+on, and a number of people are signing up for some of the corresponding work, I'd like to start a discussion on the content of our next milestone. Give
Re: Content for next milestone
I'm fine with the content that both the list that Sebastien produced to bring up Tuscany to an SCA 1.0 spec and the work that was previously discussed for the improving the kernel referenced by Jim. I think both sets add value for our users. However, for me the branch is not about what content is right, or even how it's implemented, but more how it would be developed. I find I need to be able to work with running user samples and a complete systems to help figure out how pieces and part fit together. The current split between prespec published and snapshot core, and using mostly an old kernel for the rest of Tuscany truly hampers that and makes anything outside of the kernel confusing as what is belonging where. If it must be, I prefer a branch that can give the alternative back to where Tuscany SCA as a whole can run without published snapshot kernels and kernel functionality can be added and run immediately with remaining Tuscany without having to republish it. I see this even with some of the instability we had as a reason for moving to the current approach still a preferable environment to work in. Simon Nash wrote: A March release with basic functional improvements in a consumable package (kernel, selected extensions, and tools) makes sense to me. As well as the items suggested by Sebastien, I'm interested in adding flexible ordering of elements in SCDL files as required by the SCA spec. Having work on these items proceed in a branch so that it does not conflict with the restructuring and distributed deployment work going on in trunk would allow people to be more productive, with less interference between the different activities in progress. Simon Jeremy Boynes wrote: Guys, I'm a little confused here - so far we seem to have 3 different people volunteering to manage 3 different releases. We now have a very very long list of "requirements" many of which have not been discussed on the list and most of which do not have names against them or really relate to the coding that is actually going on; they also don't seem to apply to two out of the three releases. Version numbers are being assigned to milestones, we have stabilization branches and end-to-end scenarios, all without meaningful discussion on this list. I think we need to stop and figure out what we are doing as a community. Here, on this list, with everyone involved. -- Jeremy On Feb 6, 2007, at 3:58 PM, Jean-Sebastien Delfino wrote: Jim Marino wrote: Sebastien, I'm a little surprised that you have not referenced the previous release discussion thread or any of the work that has been ongoing in core over the past month and a half: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12291.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13445.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12238.html Most of the work in core during this period has been aimed at getting a release of kernel out that supports features outlined in the first referenced thread. How does your proposal relate to that release? I'm happy to have two simultaneous release processes going at once and think it could even be beneficial. However, it would be helpful if you put your proposal in context so others such as myself can understand it a bit better. Jim On Feb 5, 2007, at 5:19 PM, Jean-Sebastien Delfino wrote: Now that we have a list of requirements on our Wiki at http:// cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what +folks+are+working+on, and a number of people are signing up for some of the corresponding work, I'd like to start a discussion on the content of our next milestone. Given that our last milestone was in December, I'd like to have another milestone soon, by March. Here's the function that people have already signed up for on the Wiki page + what I'm interested in for this milestone: - Support for complex properties and multi valued properties - Support for SCA deployment-contributions, and in particular support for JAR based deployment contributions - Ability to reference and resolve composites in an SCA domain (would be nice to support recursive composition but I'm not particularly interested in it) - Ability to configure and override the configuration of References, Services and Properties (again here I'd be happy if this works with just one or two levels of composition) - Support for wiring inside an SCA domain references to services with bindings and have the wiring decide the endpoints to use - Support for business exceptions in end to end interactions - Support for promoting services and references out of a composite (without having to wire a reference to a reference or a service to a service) - Support for defining and configuring services and references directly on components - Interchangeability / mapping between Java and WSDL interfaces - Ability to use, alter and write an SCDL mode
Re: Content for next milestone
On Feb 7, 2007, at 10:48 AM, Venkata Krishnan wrote: Hi, Heres my opinion from the perspective of some items that I have owned up to do quite a while back - support for complex properties and multivalued properties. I'd see them as some fundamental things that a user might expect to see out of our next milestone and am happy that they are a part of this list that Sebastien has proposed. I think this is good - there's a lot of value in this feature. But as far as it being on "Sebastien's list", to be blunt from a community perspective that's irrelevant. It's on /your/ list of things that are important and that's what matters. Now to complete this, I am in dire need for a stable runtime and client API. I need this for two reasons i) to figure out the workings of the kernel through debugging so that I may implement these features according to the framework's design (with loaders, builders, etc.) and ii) to test if the whole thing sews up together and works as expected. I am just not able to figure out how to do this from the current trunk andI have already started to plead for help in this regard from the community I have no complaints about the work that is going on presently in the kernel - infact I am excited about the vision with which its being driven. But then, I'd be happy if I could do my parts as well alongside. It's important that we can work together on this and the modules in the codebase are intended to allow this. The feature you are talking about seems, to me, to be a kernel feature and as such should be integrated in and tested with the kernel. The kernel can be build, tested and debugged without any runtime at all and in terms of kernel development that is an important aspect to maintain. This feature should work in every runtime that picks up the kernel and hence testing should not depend on any runtime. I hadn't picked up from previous mails that you were looking for help testing and debugging the kernel - to me they seemed to be about running application code. Please can you repost them in kernel terms and let's figure them out. Here are my thoughts for the path forward... - I'd like us to plan for the next milestone release ideally by end of March to feed the curiosity of our users. Having a long gap will kill their interest in our technology. I agree, I think frequent releases are important. That seems to be inline with what Jim and Ant were proposing (smaller and sooner). - I'd deem the current kernel work as well as the items listed by Sebastien as equally important, but we probably need to figure out how we can do both parallely. Can we not do an incremental development of both? For example we could baseline a stable and functioning version of the kernel and runtime and then choose those items from Sebastien's list that can be implemented over this baseline. Or maybe do the viceversa, choose the items and bring the kernel up to a level to be able to support its implementation. Going forward with both in increments will also help us to merge forward easily, I would imagine. I don't get the issue here. We have several people working in the kernel at the moment on different features - commits from me, jmarino, meerajk, rfeng, svkrish in the last 24 hours. This is all evolutionary development of stuff which will be in the next /kernel/ release. - I don't think its would be a good idea for the items in Sebastien's list to wait until the ongoing work in the kernel and runtime is complete. I really don't give a flying rat's patootie about what's on a list developed outside the community. I think Jeremy's point that we have to stop and now look what we are doing as a community is valid. We must have to get things around so that everybody in the community is able to contribute effectively. Those are concrete issues that we can tackle. The pre-spec branch was meant to provide an environment that would let people develop extensions whilst the kernel was evolving given we know having everything merged does not work. If it's not working either, let's do something different. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
Hi Venkat, Thanks for the write-up, comments inline. Jim On Feb 7, 2007, at 10:48 AM, Venkata Krishnan wrote: Hi, Heres my opinion from the perspective of some items that I have owned up to do quite a while back - support for complex properties and multivalued properties. I'd see them as some fundamental things that a user might expect to see out of our next milestone and am happy that they are a part of this list that Sebastien has proposed. Now to complete this, I am in dire need for a stable runtime and client API. I need this for two reasons i) to figure out the workings of the kernel through debugging so that I may implement these features according to the framework's design (with loaders, builders, etc.) Debugging and understanding the kernel architecture should be orthogonal to a stable "runtime" and client API. Otherwise, we have failed with our architecture design. The kernel architecture should not be dependent on either the runtime (e.g. how it is embedded) or the client API. For example, you should be able to debug various subsystems through the existing testcases. These, coupled with the posts to the mailing list describing some of the new work being done, should provide you with a starting point. Of course, documentation and write-up could always be better...If you are still having trouble after working through the testcases, I'm sure people working in particular areas of concern would be happy to answer any questions you pose. In terms of the specific work you are interested in, e.g. complex properties, you should be able to go ahead and work off kernel without issue. I would follow-up with Meeraj and Jeremy on the loader side to sync with what they are doing. and ii) to test if the whole thing sews up together and works as expected. I am just not able to figure out how to do this from the current trunk andI have already started to plead for help in this regard from the community I believe Jeremy responded in his launcher post. If not could you send specifics to the list and someone will try and help out? We need to update the Maven iTest plugin. I don't think you need to wait for this, however, to start any of the work you are interested in. I have no complaints about the work that is going on presently in the kernel - infact I am excited about the vision with which its being driven. But then, I'd be happy if I could do my parts as well alongside. Here are my thoughts for the path forward... - I'd like us to plan for the next milestone release ideally by end of March to feed the curiosity of our users. Having a long gap will kill their interest in our technology. Agreed that a long gap will kill momentum. That's why I suggested a compact kernel release back in January, and that's what several of us are working towards. I think it would be great to have additional features others may be interested in. What I'm not too keen on is holding up the kernel release for extensions - that will put us back in the position we are attempting to get out of with the modularity work. That said, having a follow-on release that uses a prior-released kernel version sounds like a great idea. - I'd deem the current kernel work as well as the items listed by Sebastien as equally important, but we probably need to figure out how we can do both parallely. Can we not do an incremental development of both? Don't we get that with modularizing the build as we have done? Extensions work off a release or snapshot of kernel that evolves over time. I'm not sure why work on kernel cannot be done in parallel assuming people coordinate on list. For example we could baseline a stable and functioning version of the kernel and runtime and then choose those items from Sebastien's list that can be implemented over this baseline. I don't think this is appropriate or really needed. All development should be done against trunk. Extensions may chose not to use kernel directly, in which case they can point to a snapshot. Or maybe do the viceversa, choose the items and bring the kernel up to a level to be able to support its implementation. I'm not sure I follow this. If we need the kernel to support certain features, I'm happy to help out as best I can. However, I'm really not for participating in another release that repeats the M1 process where we concocted a long list of "requirements" that people marched to and took months to deliver. I'd rather have smaller, incremental releases. If people want to have a release that follows this longer process, they should do so as long as we can release kernel in accordance with the "release early, release often" mantra. Going forward with both in increments will also help us to merge forward easily, I would imagine. If development is not done against the trunk I think this will be very problematic both from a technical as well as a community
Re: Content for next milestone
Venkata Krishnan wrote: Hi, Heres my opinion from the perspective of some items that I have owned up to do quite a while back - support for complex properties and multivalued properties. I'd see them as some fundamental things that a user might expect to see out of our next milestone and am happy that they are a part of this list that Sebastien has proposed. Now to complete this, I am in dire need for a stable runtime and client API. I need this for two reasons i) to figure out the workings of the kernel through debugging so that I may implement these features according to the framework's design (with loaders, builders, etc.) and ii) to test if the whole thing sews up together and works as expected. I am just not able to figure out how to do this from the current trunk andI have already started to plead for help in this regard from the community I have no complaints about the work that is going on presently in the kernel - infact I am excited about the vision with which its being driven. But then, I'd be happy if I could do my parts as well alongside. Here are my thoughts for the path forward... - I'd like us to plan for the next milestone release ideally by end of March to feed the curiosity of our users. Having a long gap will kill their interest in our technology. - I'd deem the current kernel work as well as the items listed by Sebastien as equally important, but we probably need to figure out how we can do both parallely. Can we not do an incremental development of both? For example we could baseline a stable and functioning version of the kernel and runtime and then choose those items from Sebastien's list that can be implemented over this baseline. Or maybe do the viceversa, choose the items and bring the kernel up to a level to be able to support its implementation. Going forward with both in increments will also help us to merge forward easily, I would imagine. - I don't think its would be a good idea for the items in Sebastien's list to wait until the ongoing work in the kernel and runtime is complete. I think Jeremy's point that we have to stop and now look what we are doing as a community is valid. We must have to get things around so that everybody in the community is able to contribute effectively. Thanks - Venkat On 2/7/07, Simon Nash <[EMAIL PROTECTED]> wrote: A March release with basic functional improvements in a consumable package (kernel, selected extensions, and tools) makes sense to me. As well as the items suggested by Sebastien, I'm interested in adding flexible ordering of elements in SCDL files as required by the SCA spec. Having work on these items proceed in a branch so that it does not conflict with the restructuring and distributed deployment work going on in trunk would allow people to be more productive, with less interference between the different activities in progress. Simon Jeremy Boynes wrote: > Guys, > > I'm a little confused here - so far we seem to have 3 different people > volunteering to manage 3 different releases. We now have a very very > long list of "requirements" many of which have not been discussed on > the list and most of which do not have names against them or really > relate to the coding that is actually going on; they also don't seem to > apply to two out of the three releases. Version numbers are being > assigned to milestones, we have stabilization branches and end-to-end > scenarios, all without meaningful discussion on this list. > > I think we need to stop and figure out what we are doing as a > community. Here, on this list, with everyone involved. > -- > Jeremy > > On Feb 6, 2007, at 3:58 PM, Jean-Sebastien Delfino wrote: > >> Jim Marino wrote: >> >>> Sebastien, >>> >>> I'm a little surprised that you have not referenced the previous >>> release discussion thread or any of the work that has been ongoing >>> in core over the past month and a half: >>> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12291.html >>> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13445.html >>> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12238.html >>> >>> Most of the work in core during this period has been aimed at >>> getting a release of kernel out that supports features outlined in >>> the first referenced thread. How does your proposal relate to that >>> release? I'm happy to have two simultaneous release processes going >>> at once and think it could even be beneficial. However, it would be >>> helpful if you put your proposal in context so others such as myself >>> can understand it a bit better. >>> >>> Jim >>> >>> >>> On Feb 5, 2007, at 5:19 PM, Jean-Sebastien Delfino wrote: >>> Now that we have a list of requirements on our Wiki at http:// cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what +folks+are+working+on, and a number of people are signing up for some of the corresponding work, I'd like to start
Re: Content for next milestone
On 2/7/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Like Venkat I'm also looking for a more stable runtime environment. I want that stable environment to bring-up end to end scenarios, including Bigbank, variations of BigBank and Calculator similar to what we've been running with the C++ runtime, our integration test suite, and the new integration test cases that I want to add to cover the requirements on the Wiki. Right now I can't get even simple samples working with the trunk and we can't run any integration tests as the itest plugin does not even compile. I understand why the kernel is evolving so much and so quickly and this is good and exciting, but integrating all the pieces and making the fixes and improvements here and there to get the end to end story working is difficult enough... that we can't be distracted or broken all the time by the refactoring and ongoing changes in the trunk. So I think we need a branch to do this stabilization work, with the goal of having the scenarios and integration tests in place by March. I think that it will be good for the project if people interested in stabilizing and improving basic function can do it in a more stable environment while the kernel is getting refactored in parallel. When the trunk settles I'll be happy to synchronize with pieces of it, as long as the samples and integration tests work. I'll try to create the branch some time tomorrow morning (Thursday) PST. I'm disturbed by this proposal as I don't think we have consensus in the community yet on this issue. If the issue here is that trunk is unstable, then we should stabilize trunk. None of the current samples will run against trunk because they are still using the 0.95 apis. I have updated kernel to use the 1.0 ones and I am in the process of implementing the proposal I made on the list on how to migrate the runtime. I could certainly use help migrating the samples and itests to 1.0. If the purpose of the stabilization branch is to prep for a release (like we did with M2), I would like to know what we are planning to release. There's a list of "requirements" on the wiki but we've not discussed those as a community at all. Most of them pertain to new functionality and I struggle to see how we can "stabilize" code that is not yet written. If the purpose is to implement new features, we have a place for that: trunk. Things like complex properties, XML ordering, contribution processing, and assembly changes are all kernel features and can all be implemented in the kernel's trunk without dependency on any runtime. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
Does it do any actual harm to have a branch, even if not everyone thinks it's necessary? Presumably that gives the people that want stability a place to work and at worst they've bought themselves some extra work merging back into the main development stream later. My previous experience (3 major occasions) has been that code branches often turn out to be more trouble than they are worth, but just occasionally they can be the right answer. Geoff. On 08/02/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On 2/7/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Like Venkat I'm also looking for a more stable runtime environment. > > I want that stable environment to bring-up end to end scenarios, > including Bigbank, variations of BigBank and Calculator similar to what > we've been running with the C++ runtime, our integration test suite, and > the new integration test cases that I want to add to cover the > requirements on the Wiki. Right now I can't get even simple samples > working with the trunk and we can't run any integration tests as the > itest plugin does not even compile. I understand why the kernel is > evolving so much and so quickly and this is good and exciting, but > integrating all the pieces and making the fixes and improvements here > and there to get the end to end story working is difficult enough... > that we can't be distracted or broken all the time by the refactoring > and ongoing changes in the trunk. > > So I think we need a branch to do this stabilization work, with the goal > of having the scenarios and integration tests in place by March. I think > that it will be good for the project if people interested in stabilizing > and improving basic function can do it in a more stable environment > while the kernel is getting refactored in parallel. When the trunk > settles I'll be happy to synchronize with pieces of it, as long as the > samples and integration tests work. I'll try to create the branch some > time tomorrow morning (Thursday) PST. I'm disturbed by this proposal as I don't think we have consensus in the community yet on this issue. If the issue here is that trunk is unstable, then we should stabilize trunk. None of the current samples will run against trunk because they are still using the 0.95 apis. I have updated kernel to use the 1.0 ones and I am in the process of implementing the proposal I made on the list on how to migrate the runtime. I could certainly use help migrating the samples and itests to 1.0. If the purpose of the stabilization branch is to prep for a release (like we did with M2), I would like to know what we are planning to release. There's a list of "requirements" on the wiki but we've not discussed those as a community at all. Most of them pertain to new functionality and I struggle to see how we can "stabilize" code that is not yet written. If the purpose is to implement new features, we have a place for that: trunk. Things like complex properties, XML ordering, contribution processing, and assembly changes are all kernel features and can all be implemented in the kernel's trunk without dependency on any runtime. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
I think I've asked this indirectly, but I'll be more blunt: Would one of the proposed objectives of the branch be to eliminate the current mix of kernel being published as snapshots and the rest of Tuscany to use those snapshots ? To be able at the head of this branch check out all of Tuscany SCA (not SDO/DAS) and do a build from the top of that and expect all of Tuscany to be running the code just compiled? To try and to stabilize this to run most of the samples and iTest and keep them running? To go forth from there to add the features we said we were interested to work on this branch? Then later at some point when those features that require more involved refactoring of the kernel on the trunk have stabilized and can run on a relatively regular basis the iTest and samples to merge them? If the answers to these are yes, I think that would work out better for me and would prefer that approach. Thanks. Rick Rineholt wrote: I'm fine with the content that both the list that Sebastien produced to bring up Tuscany to an SCA 1.0 spec and the work that was previously discussed for the improving the kernel referenced by Jim. I think both sets add value for our users. However, for me the branch is not about what content is right, or even how it's implemented, but more how it would be developed. I find I need to be able to work with running user samples and a complete systems to help figure out how pieces and part fit together. The current split between prespec published and snapshot core, and using mostly an old kernel for the rest of Tuscany truly hampers that and makes anything outside of the kernel confusing as what is belonging where. If it must be, I prefer a branch that can give the alternative back to where Tuscany SCA as a whole can run without published snapshot kernels and kernel functionality can be added and run immediately with remaining Tuscany without having to republish it. I see this even with some of the instability we had as a reason for moving to the current approach still a preferable environment to work in. Simon Nash wrote: A March release with basic functional improvements in a consumable package (kernel, selected extensions, and tools) makes sense to me. As well as the items suggested by Sebastien, I'm interested in adding flexible ordering of elements in SCDL files as required by the SCA spec. Having work on these items proceed in a branch so that it does not conflict with the restructuring and distributed deployment work going on in trunk would allow people to be more productive, with less interference between the different activities in progress. Simon Jeremy Boynes wrote: Guys, I'm a little confused here - so far we seem to have 3 different people volunteering to manage 3 different releases. We now have a very very long list of "requirements" many of which have not been discussed on the list and most of which do not have names against them or really relate to the coding that is actually going on; they also don't seem to apply to two out of the three releases. Version numbers are being assigned to milestones, we have stabilization branches and end-to-end scenarios, all without meaningful discussion on this list. I think we need to stop and figure out what we are doing as a community. Here, on this list, with everyone involved. -- Jeremy On Feb 6, 2007, at 3:58 PM, Jean-Sebastien Delfino wrote: Jim Marino wrote: Sebastien, I'm a little surprised that you have not referenced the previous release discussion thread or any of the work that has been ongoing in core over the past month and a half: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12291.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13445.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12238.html Most of the work in core during this period has been aimed at getting a release of kernel out that supports features outlined in the first referenced thread. How does your proposal relate to that release? I'm happy to have two simultaneous release processes going at once and think it could even be beneficial. However, it would be helpful if you put your proposal in context so others such as myself can understand it a bit better. Jim On Feb 5, 2007, at 5:19 PM, Jean-Sebastien Delfino wrote: Now that we have a list of requirements on our Wiki at http:// cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what +folks+are+working+on, and a number of people are signing up for some of the corresponding work, I'd like to start a discussion on the content of our next milestone. Given that our last milestone was in December, I'd like to have another milestone soon, by March. Here's the function that people have already signed up for on the Wiki page + what I'm interested in for this milestone: - Support for complex properties and multi valued properties - Support for SCA depl
Re: Content for next milestone
On Feb 8, 2007, at 6:28 AM, Geoffrey Winn wrote: Does it do any actual harm to have a branch, even if not everyone thinks it's necessary? I would say it depends on the purpose of the branch. If the intent is stabilization for a release where only bug fixes are introduced, then I think it is a good thing since it allows development (e.g. new features) to continue in trunk without disrupting the release. There is also the case of revolution or experimentation where people want to try out radically new ideas; it seems like sandbox is a better place for that type of work. Another case is new development on an existing codeline, e.g. SCA .95, which seems appropriate for a branch. However, I'm not sure either of those are a goal of the current branch proposal. The list of "requirements" posted to the wiki entail a significant number of new features that are intended to be done in trunk (e.g. "support for SCA 1.0"). It doesn't seem like the goal is revolution. For example, Sebastien mentioned his criteria for integrating new code developed in trunk: "I'll be happy to synchronize with pieces of it [kernel trunk], as long as the samples and integration tests work". Maybe someone could explain the goals of the branch? Specifically, it would help me if someone could answer a few questions: - Is development going to take place there or is it just to "stabilize" for a release? - If development is going to take place, is it for SCA .95 or SCA 1.0? - Why can't new development be done in trunk? It would be particularly helpful to understand specifics so that people working in kernel and other areas can resolve them. - What code would serve as the basis of the branch? For example, M2 or another tag? Presumably that gives the people that want stability a place to work and at worst they've bought themselves some extra work merging back into the main development stream later. My previous experience (3 major occasions) has been that code branches often turn out to be more trouble than they are worth, but just occasionally they can be the right answer. My experience has been the same. I'd really like to understand the intent of branching a little more, and specifically how it relates to the release work already underway in trunk. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
My comments inline. Rick Rineholt wrote: I think I've asked this indirectly, but I'll be more blunt: Would one of the proposed objectives of the branch be to eliminate the current mix of kernel being published as snapshots and the rest of Tuscany to use those snapshots ? I am finding the current mix confusing and difficult to work with in my Eclipse environment, even with source attached to the JARs, so I'm not particularly interested in repeating this in a branch. To be able at the head of this branch check out all of Tuscany SCA (not SDO/DAS) and do a build from the top of that and expect all of Tuscany to be running the code just compiled? To try and to stabilize this to run most of the samples and iTest and keep them running? Yes that's one of the main goals, build and test the integration of all the pieces in a stable environment. To go forth from there to add the features we said we were interested to work on this branch? Then later at some point when those features that require more involved refactoring of the kernel on the trunk have stabilized and can run on a relatively regular basis the iTest and samples to merge them? I think people should be able to work on code in the environment that works best for them and the community (trunk, branch or a sandbox), then merge when possible. The main goal of this branch is integration and stabilization, so I'd prefer to not use it for big new features that would destabilize it, but I'm sure that we'll need incremental improvements and fixes to the existing features in that branch to get the end to end integration working. If the answers to these are yes, I think that would work out better for me and would prefer that approach. Thanks. Rick Rineholt wrote: I'm fine with the content that both the list that Sebastien produced to bring up Tuscany to an SCA 1.0 spec and the work that was previously discussed for the improving the kernel referenced by Jim. I think both sets add value for our users. However, for me the branch is not about what content is right, or even how it's implemented, but more how it would be developed. I find I need to be able to work with running user samples and a complete systems to help figure out how pieces and part fit together. The current split between prespec published and snapshot core, and using mostly an old kernel for the rest of Tuscany truly hampers that and makes anything outside of the kernel confusing as what is belonging where. If it must be, I prefer a branch that can give the alternative back to where Tuscany SCA as a whole can run without published snapshot kernels and kernel functionality can be added and run immediately with remaining Tuscany without having to republish it. I see this even with some of the instability we had as a reason for moving to the current approach still a preferable environment to work in. Simon Nash wrote: A March release with basic functional improvements in a consumable package (kernel, selected extensions, and tools) makes sense to me. As well as the items suggested by Sebastien, I'm interested in adding flexible ordering of elements in SCDL files as required by the SCA spec. Having work on these items proceed in a branch so that it does not conflict with the restructuring and distributed deployment work going on in trunk would allow people to be more productive, with less interference between the different activities in progress. Simon Jeremy Boynes wrote: Guys, I'm a little confused here - so far we seem to have 3 different people volunteering to manage 3 different releases. We now have a very very long list of "requirements" many of which have not been discussed on the list and most of which do not have names against them or really relate to the coding that is actually going on; they also don't seem to apply to two out of the three releases. Version numbers are being assigned to milestones, we have stabilization branches and end-to-end scenarios, all without meaningful discussion on this list. I think we need to stop and figure out what we are doing as a community. Here, on this list, with everyone involved. -- Jeremy On Feb 6, 2007, at 3:58 PM, Jean-Sebastien Delfino wrote: Jim Marino wrote: Sebastien, I'm a little surprised that you have not referenced the previous release discussion thread or any of the work that has been ongoing in core over the past month and a half: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12291.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13445.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12238.html Most of the work in core during this period has been aimed at getting a release of kernel out that supports features outlined in the first referenced thread. How does your proposal relate to that release? I'm happy to have two simultaneous release processes going at once and think it could ev
Re: Content for next milestone
I'd tend to agree with Rick, where he said that he needs to be able to work with a running user samples and a complete system to help better understand and figure out how pieces and parts fit together, and I believe this would be the expectation of somebody trying to joying the Tuscany community, in particular SCA. Current trunk code does not allow for a end-to-end working system, and the build profiles are building only a very small subset of the code when you try to build from trunk top-level giving you a false impression that all is fine and working. I think that, as Geoff said, occasionally a branch might be the right answer. -- Luciano Resende http://people.apache.org/~lresende On 2/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: My comments inline. Rick Rineholt wrote: > I think I've asked this indirectly, but I'll be more blunt: > Would one of the proposed objectives of the branch be to eliminate the > current mix of kernel being published as snapshots and the rest of > Tuscany to use those snapshots ? I am finding the current mix confusing and difficult to work with in my Eclipse environment, even with source attached to the JARs, so I'm not particularly interested in repeating this in a branch. > > To be able at the head of this branch check out all of Tuscany SCA > (not SDO/DAS) and do a build from the top of that and expect all of > Tuscany to be running the code just compiled? > To try and to stabilize this to run most of the samples and iTest and > keep them running? Yes that's one of the main goals, build and test the integration of all the pieces in a stable environment. > > To go forth from there to add the features we said we were interested > to work on this branch? > > Then later at some point when those features that require more > involved refactoring of the kernel on the trunk have stabilized and > can run on a relatively regular basis the iTest and samples to merge > them? I think people should be able to work on code in the environment that works best for them and the community (trunk, branch or a sandbox), then merge when possible. The main goal of this branch is integration and stabilization, so I'd prefer to not use it for big new features that would destabilize it, but I'm sure that we'll need incremental improvements and fixes to the existing features in that branch to get the end to end integration working. > > If the answers to these are yes, I think that would work out better > for me and would prefer that approach. > > Thanks. > > Rick Rineholt wrote: >> I'm fine with the content that both the list that Sebastien produced >> to bring up Tuscany to an SCA 1.0 spec and the work that was >> previously discussed for the improving the kernel referenced by Jim. >> I think both sets add value for our users. However, for me the >> branch is not about what content is right, or even how it's >> implemented, but more how it would be developed. >> I find I need to be able to work with running user samples and a >> complete systems to help figure out how pieces and part fit together. >> The current split between prespec published and snapshot core, and >> using mostly an old kernel for the rest of Tuscany truly hampers that >> and makes anything outside of the kernel confusing as what is >> belonging where. >> If it must be, I prefer a branch that can give the alternative back >> to where Tuscany SCA as a whole can run without published snapshot >> kernels and kernel functionality can be added and run immediately >> with remaining Tuscany without having to republish it. I see this >> even with some of the instability we had as a reason for moving to >> the current approach still a preferable environment to work in. >> >> Simon Nash wrote: >>> A March release with basic functional improvements in a consumable >>> package >>> (kernel, selected extensions, and tools) makes sense to me. >>> >>> As well as the items suggested by Sebastien, I'm interested in adding >>> flexible ordering of elements in SCDL files as required by the SCA >>> spec. >>> >>> Having work on these items proceed in a branch so that it does not >>> conflict >>> with the restructuring and distributed deployment work going on in >>> trunk >>> would allow people to be more productive, with less interference >>> between >>> the different activities in progress. >>> >>> Simon >>> >>> Jeremy Boynes wrote: Guys, I'm a little confused here - so far we seem to have 3 different people volunteering to manage 3 different releases. We now have a very very long list of "requirements" many of which have not been discussed on the list and most of which do not have names against them or really relate to the coding that is actually going on; they also don't seem to apply to two out of the three releases. Version numbers are being assigned to milestones, we have stabilization branches and end-to-end scenarios, all without meaningful discussion on this
Re: Content for next milestone
Hi, First of all, I think it's really helpful to have a public list which is collaboratively maintained by the community to capture the To-Dos in one place instead of having them being buried in thousands of notes on the ML. I would appreciate the compilation effort. AFAIK, some of the items are known issues which have been either reported by JIRA issues or discussed on the ML. The others reflect the latest changes from the SCA spec. I don't treat it as a private list as it has been posted publicly and made open to the community (via wiki) and quite a few of us have started to sign up for the tasks by updating the list. To me, the list is a collection of items that either have been discussed and or being discussed in the community. In term of the contents, it seems to me that most of them are really to fill the gaps in Tuscany to better align with the latest SCA spec (AFAIK, it's getting close to 1.0 level). I think these pieces are critical (or must-have) for Tuscany to reach the SCA spec 1.0 level in the near future. Secondly, I tend to agree with the proposal to create a branch with all the stable code so that we can work on it to get some changes done quickly without breaking each other base on the observations I had below: 1) When I tried to apply incremental changes to the pre-spec-changes, but the dependencies across the two streams just slow me down.The samples, itest suites and "test" in the trunk has dependencies on the kernel and databindings in the pre-spec-changes branch. And most of the time, I have to jump between the two streams to build modules and refresh my Eclipse workspace (the dependencies are now referenced using jars instead of projects) to see through the effects. 2) When I feel ready to start to evolve an extension on top of the latest kernel in the trunk, I have to branch the code again as other things in the pre-spec-changes might depend on it. Please see the ML thread at http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13572.html. I wish we have copied all the code into the pre-spec-changes branch, then we won't have the pains in 1) and 2). 3) The kernel is NOT stable and we cannot even run basic things beyond the unit tests. It's very hard to verify the fixes are good for a JIRA. And it's very painful to refresh the kernel with breaking changes and it takes us time to understand the new code. I would think it will be more efficient to work off a stable branch and later on merge the changes back to the trunk. Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Monday, February 05, 2007 5:19 PM Subject: Content for next milestone Now that we have a list of requirements on our Wiki at http://cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what+folks+are+working+on, and a number of people are signing up for some of the corresponding work, I'd like to start a discussion on the content of our next milestone. Given that our last milestone was in December, I'd like to have another milestone soon, by March. Here's the function that people have already signed up for on the Wiki page + what I'm interested in for this milestone: - Support for complex properties and multi valued properties - Support for SCA deployment-contributions, and in particular support for JAR based deployment contributions - Ability to reference and resolve composites in an SCA domain (would be nice to support recursive composition but I'm not particularly interested in it) - Ability to configure and override the configuration of References, Services and Properties (again here I'd be happy if this works with just one or two levels of composition) - Support for wiring inside an SCA domain references to services with bindings and have the wiring decide the endpoints to use - Support for business exceptions in end to end interactions - Support for promoting services and references out of a composite (without having to wire a reference to a reference or a service to a service) - Support for defining and configuring services and references directly on components - Interchangeability / mapping between Java and WSDL interfaces - Ability to use, alter and write an SCDL model at deployment - WSDL2Java and Java2WSDL support using the SDO databinding - Core support for non-blocking invocations playing nicely with bindings, and without having to send complete routing paths to the services/references - Databinding framework with support for conversions between JAXB and SDO - Working and modular build allowing to build subsets of the project - Services to add(/remove/query) compositions to an SCA domain - Services to add(/remove/query) SCA deployment contributions to an SCA domain - Core support for addressing, resolving, loading artifacts from SCA deployment contributions Thoughts? -- Jean-Sebastien -
Re: Content for next milestone
I think Raymond makes some good points. It's very difficult to consume, extend and test the runtime with all of the volatility. A bunch of itests have been contributed, but they don't work. These tests are a concrete way to measure stability, and I'm sure there will be more contributed over time. I think there's a difference between stability for the sake of producing a milestone and stability for the sake of consumers and extenders to utilize and be productive with the runtime, which is a lower bar. The branch will help in this regard. Dave - Original Message - From: "Raymond Feng" <[EMAIL PROTECTED]> To: Sent: Thursday, February 08, 2007 2:28 PM Subject: Re: Content for next milestone Hi, First of all, I think it's really helpful to have a public list which is collaboratively maintained by the community to capture the To-Dos in one place instead of having them being buried in thousands of notes on the ML. I would appreciate the compilation effort. AFAIK, some of the items are known issues which have been either reported by JIRA issues or discussed on the ML. The others reflect the latest changes from the SCA spec. I don't treat it as a private list as it has been posted publicly and made open to the community (via wiki) and quite a few of us have started to sign up for the tasks by updating the list. To me, the list is a collection of items that either have been discussed and or being discussed in the community. In term of the contents, it seems to me that most of them are really to fill the gaps in Tuscany to better align with the latest SCA spec (AFAIK, it's getting close to 1.0 level). I think these pieces are critical (or must-have) for Tuscany to reach the SCA spec 1.0 level in the near future. Secondly, I tend to agree with the proposal to create a branch with all the stable code so that we can work on it to get some changes done quickly without breaking each other base on the observations I had below: 1) When I tried to apply incremental changes to the pre-spec-changes, but the dependencies across the two streams just slow me down.The samples, itest suites and "test" in the trunk has dependencies on the kernel and databindings in the pre-spec-changes branch. And most of the time, I have to jump between the two streams to build modules and refresh my Eclipse workspace (the dependencies are now referenced using jars instead of projects) to see through the effects. 2) When I feel ready to start to evolve an extension on top of the latest kernel in the trunk, I have to branch the code again as other things in the pre-spec-changes might depend on it. Please see the ML thread at http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13572.html. I wish we have copied all the code into the pre-spec-changes branch, then we won't have the pains in 1) and 2). 3) The kernel is NOT stable and we cannot even run basic things beyond the unit tests. It's very hard to verify the fixes are good for a JIRA. And it's very painful to refresh the kernel with breaking changes and it takes us time to understand the new code. I would think it will be more efficient to work off a stable branch and later on merge the changes back to the trunk. Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Monday, February 05, 2007 5:19 PM Subject: Content for next milestone Now that we have a list of requirements on our Wiki at http://cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what+folks+are+working+on, and a number of people are signing up for some of the corresponding work, I'd like to start a discussion on the content of our next milestone. Given that our last milestone was in December, I'd like to have another milestone soon, by March. Here's the function that people have already signed up for on the Wiki page + what I'm interested in for this milestone: - Support for complex properties and multi valued properties - Support for SCA deployment-contributions, and in particular support for JAR based deployment contributions - Ability to reference and resolve composites in an SCA domain (would be nice to support recursive composition but I'm not particularly interested in it) - Ability to configure and override the configuration of References, Services and Properties (again here I'd be happy if this works with just one or two levels of composition) - Support for wiring inside an SCA domain references to services with bindings and have the wiring decide the endpoints to use - Support for business exceptions in end to end interactions - Support for promoting services and references out of a composite (without having to wire a reference to a reference or a service to a service) - Support for defining and configuring services and references directly on components - Interchangeabilit
Re: Content for next milestone
On 2/8/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > So I think we need a branch to do this stabilization work I'm disturbed by this proposal as I don't think we have consensus in the community yet on this issue. This is not an issue that requires consensus. I've referred previously to a memo tited 'rules for revolutionaries'[1] which addresses the need to reduce friction in times like these. If the issue here is that trunk is unstable, then we should stabilize trunk. That would be wonderful. But let's put that in concrete terms. At least one individual (and possibly several) is interested in working on the 'BigBank' end to end scenario. Other (others?) are interested in verifying fixes to issues reported in JIRA. Which would minimize friction more? Allowing that work to proceed in a branch, or for that individual (or individuals) to start exercising their right to veto any change that impedes their progress? The latter approach would put a significant, albeit short term, damper on refactoring efforts, independent of the long term value in said refactoring. So, to put a not so fine point on it, it would represent essentially a moratorium on all but the most insignificant refactoring efforts. Is that what this group wants? If so, another way to proceed is for the project to adopt a 'review then commit model', whereby all changes are proposed for discussion and voted on before commits are made. Projects which place a high premium on stability, like the Apache HTTPD project operate in this way everyday. - Sam Ruby [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
On Feb 8, 2007, at 11:41 AM, Sam Ruby wrote: On 2/8/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > So I think we need a branch to do this stabilization work I'm disturbed by this proposal as I don't think we have consensus in the community yet on this issue. This is not an issue that requires consensus. I've referred previously to a memo tited 'rules for revolutionaries'[1] which addresses the need to reduce friction in times like these. Consensus may have been the wrong word - common understanding of what the branch is for might have been better phrasing. There's been talk about stabilizing for a release (which is often when branches are used for), but also about developing new features (which is usually done in trunk). Is this someone's personal environment, or a revolution? I simply don't know. I think consensus here though is important - not on whether we create a branch but in the impact this has on how we develop as a community. We were working together, all of a sudden something has changed and now we have friction. That's what we need to fix. If the issue here is that trunk is unstable, then we should stabilize trunk. That would be wonderful. But let's put that in concrete terms. At least one individual (and possibly several) is interested in working on the 'BigBank' end to end scenario. Other (others?) are interested in verifying fixes to issues reported in JIRA. Which would minimize friction more? Allowing that work to proceed in a branch, or for that individual (or individuals) to start exercising their right to veto any change that impedes their progress? The latter approach would put a significant, albeit short term, damper on refactoring efforts, independent of the long term value in said refactoring. So, to put a not so fine point on it, it would represent essentially a moratorium on all but the most insignificant refactoring efforts. Is that what this group wants? I don't know. One of the factors here is the change in the spec APIs from 0.95 to 1.0 which had many incompatible changes. I think we all want to support 1.0 but reality is that all of our samples, "end-to-end scenarios" and itests are written against the 0.95 level. We knew evolution to 1.0 would be disruptive which is why we have a "pre- spec" branch as a baseline for ongoing development at the 0.95 level; it seems like some friction is coming because this is not working and perhaps tackling that will make things smoother. People have talked about working on scenarios and Jira issues, but it's not clear if they are intending to do that at the 0.95 level or at the 1.0 level. If at the 1.0 level, the harsh reality is that we don't have a 1.0 level runtime yet to support them - some of us are working on it but it's not done yet. I think joining in that work is the most effective way to get something that can run 1.0 level scenarios, but if people want to start a branch and do it there that's cool too. If so, another way to proceed is for the project to adopt a 'review then commit model', whereby all changes are proposed for discussion and voted on before commits are made. Projects which place a high premium on stability, like the Apache HTTPD project operate in this way everyday. I've been wondering about that too - not for stability, but for the community-building aspect. It's certainly a better option than throwing vetos around. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
On 2/8/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Feb 8, 2007, at 11:41 AM, Sam Ruby wrote: > On 2/8/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> > >> > So I think we need a branch to do this stabilization work >> >> I'm disturbed by this proposal as I don't think we have consensus in >> the community yet on this issue. > > This is not an issue that requires consensus. I've referred > previously to a memo tited 'rules for revolutionaries'[1] which > addresses the need to reduce friction in times like these. Consensus may have been the wrong word - common understanding of what the branch is for might have been better phrasing. There's been talk about stabilizing for a release (which is often when branches are used for), but also about developing new features (which is usually done in trunk). Is this someone's personal environment, or a revolution? I simply don't know. It actually is unknowable. It is the nature of the work. The branch could go nowhere. It could become the basis for people to quickly these scenarios to the trunk. It could expose problems earlier than would otherwise be found on the trunk. At a minimum, it will not disrupt continued progress on the trunk, and by being done in the open and under a compatible license, it can be readily cannibalized at any point. I think consensus here though is important - not on whether we create a branch but in the impact this has on how we develop as a community. We were working together, all of a sudden something has changed and now we have friction. That's what we need to fix. Reviewing the archives, what I see is mounting frustration, one that would benefit from a release valve. No-one seems to be questioning that the work that is going on in the trunk is necessary, the only is growing recognition that more parallelism is required. >> If the issue here is that trunk is unstable, then we should stabilize >> trunk. > > That would be wonderful. But let's put that in concrete terms. At > least one individual (and possibly several) is interested in working > on the 'BigBank' end to end scenario. Other (others?) are interested > in verifying fixes to issues reported in JIRA. > > Which would minimize friction more? Allowing that work to proceed in > a branch, or for that individual (or individuals) to start exercising > their right to veto any change that impedes their progress? The > latter approach would put a significant, albeit short term, damper on > refactoring efforts, independent of the long term value in said > refactoring. > > So, to put a not so fine point on it, it would represent essentially a > moratorium on all but the most insignificant refactoring efforts. > > Is that what this group wants? I don't know. Actually, I would seriously doubt it. One of the factors here is the change in the spec APIs from 0.95 to 1.0 which had many incompatible changes. I think we all want to support 1.0 but reality is that all of our samples, "end-to-end scenarios" and itests are written against the 0.95 level. We knew evolution to 1.0 would be disruptive which is why we have a "pre- spec" branch as a baseline for ongoing development at the 0.95 level; it seems like some friction is coming because this is not working and perhaps tackling that will make things smoother. Perhaps. But it is also possible that a branch that is closer to the current trunk would be less disruptive long term. And not necessarily just one branch, this process could conceivably even repeat periodically, and eventually converge. People have talked about working on scenarios and Jira issues, but it's not clear if they are intending to do that at the 0.95 level or at the 1.0 level. If at the 1.0 level, the harsh reality is that we don't have a 1.0 level runtime yet to support them - some of us are working on it but it's not done yet. I think joining in that work is the most effective way to get something that can run 1.0 level scenarios, but if people want to start a branch and do it there that's cool too. At some point you hit the mythical man month "nine women, one baby" issue. re: "if people want to start a branch and do it there that's cool too." +1 > If so, another way to proceed is for the project to adopt a 'review > then commit model', whereby all changes are proposed for discussion > and voted on before commits are made. Projects which place a high > premium on stability, like the Apache HTTPD project operate in this > way everyday. I've been wondering about that too - not for stability, but for the community-building aspect. It's certainly a better option than throwing vetos around. Geronimo recently had this imposed on them. It was just the jolt that they needed, but once that was accomplished, it was quickly disposed of. My thoughts are that it is an option to consider, but one not to be taken lightly. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: Content for next milestone
On 2/8/07, Sam Ruby <[EMAIL PROTECTED]> wrote: On 2/8/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > On Feb 8, 2007, at 11:41 AM, Sam Ruby wrote: > > > On 2/8/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > >> > > >> > So I think we need a branch to do this stabilization work > >> > >> I'm disturbed by this proposal as I don't think we have consensus in > >> the community yet on this issue. > > > > This is not an issue that requires consensus. I've referred > > previously to a memo tited 'rules for revolutionaries'[1] which > > addresses the need to reduce friction in times like these. > > Consensus may have been the wrong word - common understanding of what > the branch is for might have been better phrasing. There's been talk > about stabilizing for a release (which is often when branches are > used for), but also about developing new features (which is usually > done in trunk). Is this someone's personal environment, or a > revolution? I simply don't know. It actually is unknowable. It is the nature of the work. The branch could go nowhere. It could become the basis for people to quickly these scenarios to the trunk. It could expose problems earlier than would otherwise be found on the trunk. At a minimum, it will not disrupt continued progress on the trunk, and by being done in the open and under a compatible license, it can be readily cannibalized at any point. > I think consensus here though is important - not on whether we create > a branch but in the impact this has on how we develop as a community. > We were working together, all of a sudden something has changed and > now we have friction. That's what we need to fix. Reviewing the archives, what I see is mounting frustration, one that would benefit from a release valve. No-one seems to be questioning that the work that is going on in the trunk is necessary, the only is growing recognition that more parallelism is required. > >> If the issue here is that trunk is unstable, then we should stabilize > >> trunk. > > > > That would be wonderful. But let's put that in concrete terms. At > > least one individual (and possibly several) is interested in working > > on the 'BigBank' end to end scenario. Other (others?) are interested > > in verifying fixes to issues reported in JIRA. > > > > Which would minimize friction more? Allowing that work to proceed in > > a branch, or for that individual (or individuals) to start exercising > > their right to veto any change that impedes their progress? The > > latter approach would put a significant, albeit short term, damper on > > refactoring efforts, independent of the long term value in said > > refactoring. > > > > So, to put a not so fine point on it, it would represent essentially a > > moratorium on all but the most insignificant refactoring efforts. > > > > Is that what this group wants? > > I don't know. Actually, I would seriously doubt it. > One of the factors here is the change in the spec APIs from 0.95 to > 1.0 which had many incompatible changes. I think we all want to > support 1.0 but reality is that all of our samples, "end-to-end > scenarios" and itests are written against the 0.95 level. We knew > evolution to 1.0 would be disruptive which is why we have a "pre- > spec" branch as a baseline for ongoing development at the 0.95 level; > it seems like some friction is coming because this is not working and > perhaps tackling that will make things smoother. Perhaps. But it is also possible that a branch that is closer to the current trunk would be less disruptive long term. And not necessarily just one branch, this process could conceivably even repeat periodically, and eventually converge. > People have talked about working on scenarios and Jira issues, but > it's not clear if they are intending to do that at the 0.95 level or > at the 1.0 level. If at the 1.0 level, the harsh reality is that we > don't have a 1.0 level runtime yet to support them - some of us are > working on it but it's not done yet. I think joining in that work is > the most effective way to get something that can run 1.0 level > scenarios, but if people want to start a branch and do it there > that's cool too. At some point you hit the mythical man month "nine women, one baby" issue. re: "if people want to start a branch and do it there that's cool too." +1 > > If so, another way to proceed is for the project to adopt a 'review > > then commit model', whereby all changes are proposed for discussion > > and voted on before commits are made. Projects which place a high > > premium on stability, like the Apache HTTPD project operate in this > > way everyday. > > I've been wondering about that too - not for stability, but for the > community-building aspect. It's certainly a better option than > throwing vetos around. Geronimo recently had this imposed on them. It was just the jolt that they needed, but once that was accomplished, it was quickly disposed of. My thoughts are that it is an option to
Re: Content for next milestone
It actually is unknowable. It is the nature of the work. The branch could go nowhere. It could become the basis for people to quickly these scenarios to the trunk. It could expose problems earlier than would otherwise be found on the trunk. At a minimum, it will not disrupt continued progress on the trunk, and by being done in the open and under a compatible license, it can be readily cannibalized at any point. I wanted to know if the goal was to develop against trunk or to develop against branch. Wouldn't people know this at the outset, i.e. what the purpose of branching is? I realize goals may change as things evolve but it would be nice to know what the initial objectives are. Those are still unclear to me. Sebastien mentioned, "The main goal of this branch is integration and stabilization, so I'd prefer to not use it for big new features that would destabilize it, but I'm sure that we'll need incremental improvements and fixes to the existing features in that branch". Yet the list of "requirements" he put on the wiki entail significant additions to the existing architecture. For example, the runtime and client api are changed in the SCA specifications, which means none of the existing samples (e.g. BigBank) or runtimes work on any revision of the code base. So, what would really help me is for someone to clarify for me the following: - To satisfy those requirements, is the intent to do that significant work in branch and how will it be moved into trunk? Or, is it intended that the work be done in trunk and rolled into branch? - If it is the latter, how is this any different than the process of using Maven snapshots that we have already set up? - If the goal is to do significant work in branch, what happens when changes in trunk are incompatible with new work in the branch? I'm all for people doing revolutions or blowing off steam but more clarity and discussion about what is going on would be helpful for me. The other question I had is how this relates to the release process others of us are working toward that was started back in January. I think having this branch called the "next milestone" release is confusing. I'm all for simultaneous release processes if that helps ease friction or provides people what they need but what then do we call the work going on in trunk? In keeping with our Italian theme and the idea of blowing off smoke, maybe the branch can be tagged "fumo" :-) Are there some precedents for this in other projects? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
away in PHP and C++ land. But I've only this week started again to think about looking back at getting the various runtimes to play together having not looked at Java SCA since M1 days. That would be cool. We're getting the federated pieces in place and are using JXTA which has a C++ implementation. Back then I got put off because of the revolution moving from M1 to the M2 approach made it very difficult, for the Java SCA novice like me at least, to do anything sensible. My timing must be really messed up because I'm now looking at this thread with a certain sense of Deja Vu. I'm interested in being able to test running Java SCA composites over the coming weeks. Not absolutely convinced I need a system supporting all the 1.0 features this minute but clearly it would be good not to be prevented from moving in that direction. You probably have several options we'd be happy to help get you spun up with: - If you want a (relatively) stable, tested release, I would try M2. The downside is it is based of the .95 SCA spec. For starting our and developing apps, I would use this. - If you want a slightly more updated version for creating runtime extensions, the pre-spec snapshot should be relatively stable. The changes from the M2 release are constrained so if you were more interested in developing an extension on a stable release, I would go with it. - If you want to develop against the 1.0 spec, we're pretty close in trunk to getting support for a good chunk of the 1.0 client APIs. Meeraj has also made a lot of progress on defining the discovery and federation messages. Perhaps we could work together on those so the Java and C++ runtime can federate as a starting point? I'm happy to help so drop a line on the list. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
On 2/8/07, Jim Marino <[EMAIL PROTECTED]> wrote: - To satisfy those requirements, is the intent to do that significant work in branch and how will it be moved into trunk? Or, is it intended that the work be done in trunk and rolled into branch? In times like these, generally the intent is to do the work and then to assess based on taking a look at the actual code what the best path forward is. Until that code is written, it is premature to speculate what the outcome will be. - If it is the latter, how is this any different than the process of using Maven snapshots that we have already set up? - If the goal is to do significant work in branch, what happens when changes in trunk are incompatible with new work in the branch? As I understand it, the goal is to do whatever it takes to get some specific user scenarios working. Whatever it takes generally includes changes. Given the discussion to date, I think that it is taken as a given that some portion of the changes in the trunk will be incompatible with the work done in this branch. The only way to prevent this is to either cease work on the trunk, continue to impede progress towards getting these scenarios working, or a branch. I'm all for people doing revolutions or blowing off steam but more clarity and discussion about what is going on would be helpful for me. Referring to this as "blowing off steam" is counter productive. Getting the scenarios working is productive, even if only 85%, 65%, or 35% of the work ultimately ends up being reusable. The other question I had is how this relates to the release process others of us are working toward that was started back in January. I think having this branch called the "next milestone" release is confusing. I'm all for simultaneous release processes if that helps ease friction or provides people what they need but what then do we call the work going on in trunk? In keeping with our Italian theme and the idea of blowing off smoke, maybe the branch can be tagged "fumo" :-) Are there some precedents for this in other projects? This I agree with. Statements or nomenclature that imply any form of succession cause friction. Jim - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
Sam Ruby wrote: On 2/8/07, Jim Marino <[EMAIL PROTECTED]> wrote: - To satisfy those requirements, is the intent to do that significant work in branch and how will it be moved into trunk? Or, is it intended that the work be done in trunk and rolled into branch? In times like these, generally the intent is to do the work and then to assess based on taking a look at the actual code what the best path forward is. Until that code is written, it is premature to speculate what the outcome will be. - If it is the latter, how is this any different than the process of using Maven snapshots that we have already set up? - If the goal is to do significant work in branch, what happens when changes in trunk are incompatible with new work in the branch? As I understand it, the goal is to do whatever it takes to get some specific user scenarios working. Whatever it takes generally includes changes. Given the discussion to date, I think that it is taken as a given that some portion of the changes in the trunk will be incompatible with the work done in this branch. The only way to prevent this is to either cease work on the trunk, continue to impede progress towards getting these scenarios working, or a branch. I'm all for people doing revolutions or blowing off steam but more clarity and discussion about what is going on would be helpful for me. Referring to this as "blowing off steam" is counter productive. Getting the scenarios working is productive, even if only 85%, 65%, or 35% of the work ultimately ends up being reusable. The other question I had is how this relates to the release process others of us are working toward that was started back in January. I think having this branch called the "next milestone" release is confusing. I'm all for simultaneous release processes if that helps ease friction or provides people what they need but what then do we call the work going on in trunk? In keeping with our Italian theme and the idea of blowing off smoke, maybe the branch can be tagged "fumo" :-) Are there some precedents for this in other projects? This I agree with. Statements or nomenclature that imply any form of succession cause friction. I had not seen your "fumo" proposal as I was busy creating the branch and assessing what will need to be adjusted to be able to build it, but I agree too. I couldn't think of a good name like "fumo" :) so I called it sca-java-integration, a branch where I'd like to start integration work and get end to end scenarios and integration tests going. Jim - Sam Ruby -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
Hi All, Are there any plans for Tuscany to actually use the Axis2 runtime (whole infrastructure), not only its libs for specific parts of the SOAP processing? I think it is very important to use one uniform stack, and not have different runtimes. The axis2 WS runtime is more mature, and more advanced. Could you comment on what the efforts are to do this migration? Maybe I can also help... Thanks. Best, Angel On 2/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Sam Ruby wrote: > On 2/8/07, Jim Marino <[EMAIL PROTECTED]> wrote: >> >> - To satisfy those requirements, is the intent to do that significant >> work in branch and how will it be moved into trunk? Or, is it >> intended that the work be done in trunk and rolled into branch? > > In times like these, generally the intent is to do the work and then > to assess based on taking a look at the actual code what the best path > forward is. Until that code is written, it is premature to speculate > what the outcome will be. > >> - If it is the latter, how is this any different than the process of >> using Maven snapshots that we have already set up? >> >> - If the goal is to do significant work in branch, what happens when >> changes in trunk are incompatible with new work in the branch? > > As I understand it, the goal is to do whatever it takes to get some > specific user scenarios working. Whatever it takes generally includes > changes. > > Given the discussion to date, I think that it is taken as a given that > some portion of the changes in the trunk will be incompatible with the > work done in this branch. The only way to prevent this is to either > cease work on the trunk, continue to impede progress towards getting > these scenarios working, or a branch. > >> I'm all for people doing revolutions or blowing off steam but more >> clarity and discussion about what is going on would be helpful for me. > > Referring to this as "blowing off steam" is counter productive. > Getting the scenarios working is productive, even if only 85%, 65%, or > 35% of the work ultimately ends up being reusable. > >> The other question I had is how this relates to the release process >> others of us are working toward that was started back in January. I >> think having this branch called the "next milestone" release is >> confusing. I'm all for simultaneous release processes if that helps >> ease friction or provides people what they need but what then do we >> call the work going on in trunk? In keeping with our Italian theme >> and the idea of blowing off smoke, maybe the branch can be tagged >> "fumo" :-) Are there some precedents for this in other projects? > > This I agree with. Statements or nomenclature that imply any form of > succession cause friction. > I had not seen your "fumo" proposal as I was busy creating the branch and assessing what will need to be adjusted to be able to build it, but I agree too. I couldn't think of a good name like "fumo" :) so I called it sca-java-integration, a branch where I'd like to start integration work and get end to end scenarios and integration tests going. >> Jim > > - Sam Ruby > -- 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: Content for next milestone
On 08/02/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, First of all, I think it's really helpful to have a public list which is collaboratively maintained by the community to capture the To-Dos in one place instead of having them being buried in thousands of notes on the ML. I would appreciate the compilation effort. +1 I did a similar thing for SDO, and would have been delighted if it had captured so much attention. the purpose was to collate and to generate discussion and to provide a single point of reference for any existing or future member of the community that might want to contribute to the project. AFAIK, some of the items are known issues which have been either reported by JIRA issues or discussed on the ML. The others reflect the latest changes from the SCA spec. I don't treat it as a private list as it has been posted publicly and made open to the community (via wiki) and quite a few of us have started to sign up for the tasks by updating the list. To me, the list is a collection of items that either have been discussed and or being discussed in the community. similarly my list was composed of my assessment of high priority jiras, spec updates and anything that has been discussed on the list. It was intended as a straw man for discussion that could be extended and altered by the normal community processes. --- Kelvin. In term of the contents, it seems to me that most of them are really to fill the gaps in Tuscany to better align with the latest SCA spec (AFAIK, it's getting close to 1.0 level). I think these pieces are critical (or must-have) for Tuscany to reach the SCA spec 1.0 level in the near future. Secondly, I tend to agree with the proposal to create a branch with all the stable code so that we can work on it to get some changes done quickly without breaking each other base on the observations I had below: 1) When I tried to apply incremental changes to the pre-spec-changes, but the dependencies across the two streams just slow me down.The samples, itest suites and "test" in the trunk has dependencies on the kernel and databindings in the pre-spec-changes branch. And most of the time, I have to jump between the two streams to build modules and refresh my Eclipse workspace (the dependencies are now referenced using jars instead of projects) to see through the effects. 2) When I feel ready to start to evolve an extension on top of the latest kernel in the trunk, I have to branch the code again as other things in the pre-spec-changes might depend on it. Please see the ML thread at http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13572.html. I wish we have copied all the code into the pre-spec-changes branch, then we won't have the pains in 1) and 2). 3) The kernel is NOT stable and we cannot even run basic things beyond the unit tests. It's very hard to verify the fixes are good for a JIRA. And it's very painful to refresh the kernel with breaking changes and it takes us time to understand the new code. I would think it will be more efficient to work off a stable branch and later on merge the changes back to the trunk. Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Monday, February 05, 2007 5:19 PM Subject: Content for next milestone > Now that we have a list of requirements on our Wiki at > http://cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what+folks+are+working+on , > and a number of people are signing up for some of the corresponding work, > I'd like to start a discussion on the content of our next milestone. Given > that our last milestone was in December, I'd like to have another > milestone soon, by March. > > Here's the function that people have already signed up for on the Wiki > page + what I'm interested in for this milestone: > - Support for complex properties and multi valued properties > - Support for SCA deployment-contributions, and in particular support for > JAR based deployment contributions > - Ability to reference and resolve composites in an SCA domain (would be > nice to support recursive composition but I'm not particularly interested > in it) > - Ability to configure and override the configuration of References, > Services and Properties (again here I'd be happy if this works with just > one or two levels of composition) > - Support for wiring inside an SCA domain references to services with > bindings and have the wiring decide the endpoints to use > - Support for business exceptions in end to end interactions > - Support for promoting services and references out of a composite > (without having to wire a reference to a reference or a service to a > service) > - Support for defining and configuring services and references directly on > components > - Interchangeability / mapping be
Re: Content for next milestone
Angel Todorov wrote: Hi All, Are there any plans for Tuscany to actually use the Axis2 runtime (whole infrastructure), not only its libs for specific parts of the SOAP processing? I think it is very important to use one uniform stack, and not have different runtimes. The axis2 WS runtime is more mature, and more advanced. Could you comment on what the efforts are to do this migration? Maybe I can also help... Thanks. Best, Angel We are already using parts of the Axis2 infrastructure in addition to the obvious use of the Axis2 runtime in our WS/SOAP binding: - Our Axiom databinding can be used independent of SOAP, to convert from another databinding to an Axiom model - We are using the Axis2 WSDL2Java code generators, and this goes beyond Web Services as with SCA all components can mix WSDL portTypes and Java interfaces. We could probably reuse more from Axis2 or improve how we use it... and we could use help as well :) What did you have in mind? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multi language system - from: Content for next milestone
On 2/9/07, Jim Marino <[EMAIL PROTECTED]> wrote: > away in PHP and C++ land. But I've only this week started again to > think > about looking back at getting the various runtimes to play together > having > not looked at Java SCA since M1 days. That would be cool. We're getting the federated pieces in place and are using JXTA which has a C++ implementation. > Back then I got put off because of > the revolution moving from M1 to the M2 approach made it very > difficult, for > the Java SCA novice like me at least, to do anything sensible. My > timing > must be really messed up because I'm now looking at this thread with a > certain sense of Deja Vu. I'm interested in being able to test > running Java > SCA composites over the coming weeks. Not absolutely convinced I > need a > system supporting all the 1.0 features this minute but clearly it > would be > good not to be prevented from moving in that direction. You probably have several options we'd be happy to help get you spun up with: - If you want a (relatively) stable, tested release, I would try M2. The downside is it is based of the .95 SCA spec. For starting our and developing apps, I would use this. - If you want a slightly more updated version for creating runtime extensions, the pre-spec snapshot should be relatively stable. The changes from the M2 release are constrained so if you were more interested in developing an extension on a stable release, I would go with it. - If you want to develop against the 1.0 spec, we're pretty close in trunk to getting support for a good chunk of the 1.0 client APIs. Meeraj has also made a lot of progress on defining the discovery and federation messages. Perhaps we could work together on those so the Java and C++ runtime can federate as a starting point? I'm happy to help so drop a line on the list. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks Jim for pointing me in the right direction. I'll go and catch up on the deployment work you've highlighted. I don't know if this is currently in scope but I would like to have as a target the ability to wire components from different (language) runtimes together. Next week I'll see If I can get Java up with the options you've outline and see what works for me. Simon
sca-java-integration branch, was: Content for next milestone
[snip] People have talked about working on scenarios and Jira issues, but it's not clear if they are intending to do that at the 0.95 level or at the 1.0 level. If at the 1.0 level, the harsh reality is that we don't have a 1.0 level runtime yet to support them - some of us are working on it but it's not done yet. I think joining in that work is the most effective way to get something that can run 1.0 level scenarios, but if people want to start a branch and do it there that's cool too. At some point you hit the mythical man month "nine women, one baby" issue. re: "if people want to start a branch and do it there that's cool too." +1 +1 I have copied java/spec/, sca/, samples/, sampleapps/, testing/, buildtools/ and pom/ from revision r502852 to a new branch under branches/sca-java-integration/. I would like to start using this branch for integration and stabilization of our runtime and get a complete system and end to end scenarios incl. Bigbank plus our integration tests working again. As a starting point I'd like to see a smooth top-down build of all the pieces so I'm going to start adjusting a little the pom.xml files. If anybody is interested in helping with this effort, please jump in. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi language system - from: Content for next milestone
On Feb 9, 2007, at 5:59 AM, Simon Laws wrote: Thanks Jim for pointing me in the right direction. I'll go and catch up on the deployment work you've highlighted. I don't know if this is currently in scope but I would like to have as a target the ability to wire components from different (language) runtimes together. Next week I'll see If I can get Java up with the options you've outline and see what works for me. It's definitely in scope, in fact it's a key design issue and one reason kernel is changing. The design is that there is a "master" node that is working out which "physical" nodes components are going to run on. It then passes PhysicalComponentDefinition's to the worker nodes to get them to create the component and any transport bindings it needs to talk to other nodes. The PCDs are portable, independent of the type of runtime, instead tied to the type of component. Picking on Ruby as an example as we know we can run that on Java and Native runtimes, there could be one common PCD for a Ruby component that was supported by all container implementations. The master could send that to any node to have it run a Ruby component. A runtime could also offer "enhanced" Ruby support with additional features that required additional configuration. If would offer support for a different PCD with that additional metadata. Which one is selected by the master would be part of its component allocation algorithm. So basically, any runtime that can connect to the federated fabric and handle a PCD can join the SCA domain. We picked JXTA and XML for the fabric and PCD encoding as there is support for those in both Java and C++. Adding support for that to the Native runtime would also be good if you were skeptical of all the Java stuff. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi language system - from: Content for next milestone
On 2/9/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Feb 9, 2007, at 5:59 AM, Simon Laws wrote: > Thanks Jim for pointing me in the right direction. I'll go and > catch up on > the deployment work you've highlighted. I don't know if this is > currently in > scope but I would like to have as a target the ability to wire > components > from different (language) runtimes together. Next week I'll see If > I can > get Java up with the options you've outline and see what works for me. It's definitely in scope, in fact it's a key design issue and one reason kernel is changing. The design is that there is a "master" node that is working out which "physical" nodes components are going to run on. It then passes PhysicalComponentDefinition's to the worker nodes to get them to create the component and any transport bindings it needs to talk to other nodes. The PCDs are portable, independent of the type of runtime, instead tied to the type of component. Picking on Ruby as an example as we know we can run that on Java and Native runtimes, there could be one common PCD for a Ruby component that was supported by all container implementations. The master could send that to any node to have it run a Ruby component. A runtime could also offer "enhanced" Ruby support with additional features that required additional configuration. If would offer support for a different PCD with that additional metadata. Which one is selected by the master would be part of its component allocation algorithm. So basically, any runtime that can connect to the federated fabric and handle a PCD can join the SCA domain. We picked JXTA and XML for the fabric and PCD encoding as there is support for those in both Java and C++. Adding support for that to the Native runtime would also be good if you were skeptical of all the Java stuff. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks Jeremy for commenting. I am of course now looking back through the archive and seeing that discussions are underway. Doh, sorry about that. From the distributed assembly [1], federated deployment [2], physical component definition [3] threads I think I'm starting to appreciate the proposed direction. There is a fair amount of detail to digest and I'm struggling a little to separate out the generic bits from guts of what's changing in Java. From a native point of view I guess we need to understand 1/ How we employ JXTA to join the SCA federation 2/ The format of the physical model 3/ How we advertise our capabilities (supported components etc.) in order that "scheduling" decisions can be made. 4/ The nature of command and control system, start, stop etc. You'll note I'm not proffering an opinion here. I've much to learn yet:-)Maybe we can start getting a more generic description up on the Cwiki. I looked and couldn't see one. I may of course be looking in the wrong place. If there isn't one I'll start putting notes up there as I find out things. Am I right in saying that you consider deployment, i.e. actually getting component implementations onto distributed boxes, to be a separate issue from the federation of active runtimes already configured with implementations. I'm not immediately sceptical of the java stuff. I have to say I don't understand the details. I think the value though is if we can have the native runtime play too so I'll look there first. I note from the mail trail that Pete is also interested in this. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg12900.html [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg13607.html [3] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg13830.html
Re: Multi language system - from: Content for next milestone
On Feb 12, 2007, at 2:48 AM, Simon Laws wrote: Thanks Jeremy for commenting. I am of course now looking back through the archive and seeing that discussions are underway. Doh, sorry about that. From the distributed assembly [1], federated deployment [2], physical component definition [3] threads I think I'm starting to appreciate the proposed direction. There is a fair amount of detail to digest and I'm struggling a little to separate out the generic bits from guts of what's changing in Java. From a native point of view I guess we need to understand 1/ How we employ JXTA to join the SCA federation Can't help there - there's allegedly a C++ implementation which is why we picked it but I don't know much about it 2/ The format of the physical model On the wire where interop matters, it is a set of XML objects. The runtimes exchange simple XML messages over JXTA to communicate. We use strict versioning of the elements to identify model elements, and tie them to the actual implementation. 3/ How we advertise our capabilities (supported components etc.) in order that "scheduling" decisions can be made. Still thinking about that :-) Meeraj had some ideas. 4/ The nature of command and control system, start, stop etc. More messages, probably using JXTA multicast. You'll note I'm not proffering an opinion here. I've much to learn yet:-)Maybe we can start getting a more generic description up on the Cwiki. I looked and couldn't see one. I may of course be looking in the wrong place. If there isn't one I'll start putting notes up there as I find out things. As you can tell, we are still in the early stages with a lot of this. The discussion is on the mailing list and through code but capturing stuff on the wiki/website would be good. Am I right in saying that you consider deployment, i.e. actually getting component implementations onto distributed boxes, to be a separate issue from the federation of active runtimes already configured with implementations. I hate "deployment" as it means different things to different people. My view is that federation is about running and managing components in a distributed environment. It's the components we are interested in from a domain perspective. Those components have dependencies on code artifacts in order to run (e.g. their implementation code) and so that needs to be present. How it gets there is the responsibility of the federation - it may be pre-installed, or it may be installed on demand. The spec is taking a similar tack with the separation of Contributions from Assembly. I'm not immediately sceptical of the java stuff. I have to say I don't understand the details. I think the value though is if we can have the native runtime play too so I'll look there first. I note from the mail trail that Pete is also interested in this. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/ msg12900.html [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/ msg13607.html [3] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/ msg13830.html Yeah. No need to get Java cooties when there is a lot to do on the native side too :-) Agreeing on the macro-architecture for the federation is the key - the runtimes themselves should be able to evolve separately based on different physical issues. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sca-java-integration branch, was: Content for next milestone
To prevent confusion with trunk, please change the artifactIds for this branch (I'd suggest using a different groupId or version). Thanks -- Jeremy On Feb 8, 2007, at 7:05 PM, Jean-Sebastien Delfino wrote: [snip] People have talked about working on scenarios and Jira issues, but it's not clear if they are intending to do that at the 0.95 level or at the 1.0 level. If at the 1.0 level, the harsh reality is that we don't have a 1.0 level runtime yet to support them - some of us are working on it but it's not done yet. I think joining in that work is the most effective way to get something that can run 1.0 level scenarios, but if people want to start a branch and do it there that's cool too. At some point you hit the mythical man month "nine women, one baby" issue. re: "if people want to start a branch and do it there that's cool too." +1 +1 I have copied java/spec/, sca/, samples/, sampleapps/, testing/, buildtools/ and pom/ from revision r502852 to a new branch under branches/sca-java-integration/. I would like to start using this branch for integration and stabilization of our runtime and get a complete system and end to end scenarios incl. Bigbank plus our integration tests working again. As a starting point I'd like to see a smooth top-down build of all the pieces so I'm going to start adjusting a little the pom.xml files. If anybody is interested in helping with this effort, please jump in. -- 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: sca-java-integration branch, was: Content for next milestone
Hi, I have changed the branch to use "0.1-integration-incubating-SNAPSHOT" as the version id. Thanks, Raymond - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Sent: Friday, February 09, 2007 8:36 AM Subject: Re: sca-java-integration branch, was: Content for next milestone To prevent confusion with trunk, please change the artifactIds for this branch (I'd suggest using a different groupId or version). Thanks -- Jeremy On Feb 8, 2007, at 7:05 PM, Jean-Sebastien Delfino wrote: [snip] People have talked about working on scenarios and Jira issues, but it's not clear if they are intending to do that at the 0.95 level or at the 1.0 level. If at the 1.0 level, the harsh reality is that we don't have a 1.0 level runtime yet to support them - some of us are working on it but it's not done yet. I think joining in that work is the most effective way to get something that can run 1.0 level scenarios, but if people want to start a branch and do it there that's cool too. At some point you hit the mythical man month "nine women, one baby" issue. re: "if people want to start a branch and do it there that's cool too." +1 +1 I have copied java/spec/, sca/, samples/, sampleapps/, testing/, buildtools/ and pom/ from revision r502852 to a new branch under branches/sca-java-integration/. I would like to start using this branch for integration and stabilization of our runtime and get a complete system and end to end scenarios incl. Bigbank plus our integration tests working again. As a starting point I'd like to see a smooth top-down build of all the pieces so I'm going to start adjusting a little the pom.xml files. If anybody is interested in helping with this effort, please jump in. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sca-java-integration branch, was: Content for next milestone
On Feb 9, 2007, at 5:48 PM, Raymond Feng wrote: Hi, I have changed the branch to use "0.1-integration-incubating- SNAPSHOT" as the version id. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]