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/[email protected]/msg12291.html >>> >>> http://www.mail-archive.com/[email protected]/msg13445.html >>> >>> http://www.mail-archive.com/[email protected]/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]
