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/[email protected]/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: <[email protected]>
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]
