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: <tuscany-dev@ws.apache.org> 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 > > > --------------------------------------------------------------------- > 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]
