Here are a few things coming to my mind:
1. Start to implement/fix the OASIS new features or differences against
OSOA. Some of the items are listed at [1].
2. Start to create message files to contain the text from the OASIS
conformance tests and reference them from the validation points in the code
3. Continue to implement the policy spec
4. Continue to implement OSGi RFC 119
5. Start to define our new Domain/Node story
6. Bring up the binding/implementation extensions that defined by OASIS
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/OSOA+SCA+vs+OASIS+SCA
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Thursday, April 09, 2009 3:39 AM
To: <[email protected]>
Subject: 2.0 M3
Now that 2.0-M2 is almost done I'm looking at what to do for M3 which
from the previously discussed schedule would be around the end of May.
Some things I'm interested for M3 right now are:
Finishing off some of the webapp support from M2 - finishing the JSONP
binding and the Wicket integration module, and giving the webapp
runtime support to use contributions outside of the webapp classpath.
There's some work to do on the archetypes still, and it would be good
to add some more, maybe some for tuscany developers to add extensions
- implementation, binding, etc archetypes.
There's the continuing work supporting the OASIS spec's properly -
i've started getting the SCA client API from the latest Assembly spec
working and there's more to do there and that starts touching on
another thing we should start looking at which is distributed domain
support. Hopefully the endpoint changes that went into M2 will help
and I'd like to start looking at that and what we can do to support
proper dynamic operation with nodes coming and going, don't expect
that would get finished for M3 but some start at least would be good.
Not directly related to 2.x i think we should look at trying to use
Hudson for the nightly builds.
...ant
