On Aug 16, 2006, at 1:58 PM, Jeremy Boynes wrote:
SCA provides a much more complex picture as it contains not just
libraries but also host environments, multiple extensions,
potentially multiple extensions providing alternative
implementations of the same function (e.g. the axis and celtix
bindings). To handle this I think we should stage the release
process, stabilizing the core first, then whatever set of
extensions we define as a bundle, finally voting to release the
bundle. During the stabilization process we can published dated
unstable builds to the SNAPSHOT repo so that extensions can rely on
those rather than trunk all the time.
+1
So, having said all that, I would like to propose we start working
toward getting the next release out with the following stages:
1) Specs (sdo-api, sca-api, commonj)
These should be stable now as the specifications have been
published.
I think they are mostly stable but we should recheck to ensure they
are consistent with the specs
2) SCA Core (spi, core, hostutil, test, plus apis once that
refactor is done)
Features I would like to see complete before we consider this
stable are:
Class loading changes
Integration of databinding framework
Support for async callbacks
Support for complex properties
Transitive dependency support
I'd also like to see much better test coverage than what we have.
This is hard to quantify, but while code coverage does not guarantee
good tests, it is an indicator. So, to have a metric, I'd like to see
core (and other extensions) at 75% coverage when run through Clover.
I picked Clover since it is a decent tool and license-friendly but if
someone would like to suggest an alternative we could look at it as
well.
3) Baseline extensions - ones we think are essential for users
idl.wsdl
binding.axis
binding.celtix
binding.rmi
databinding.axiom
databinding.sdo
databinding.jaxb
container.javascript
container.spring
I'm not sure what the difference is between baseline and optional. I
think all extensions are optional unless one is being used and has
dependencies. If the distinction is to deal with voting issues, maybe
we could group things together as long as there is a way to not have
them physically bundled together. Can you explain the linkage between
3,4,5 as I think there may be a terminology issue?
4) Optional extensions - nice to have but which may not be ready to
bundle
binding.jsonrpc
binding.osgi
databinding.xmlbeans
databinding.castor
container.groovy
5) Host distributions - host environments that each form the basis
for each bundle
Standalone (with axis, celtix, rmi, spring)
Web-app (with axis, celtix, rmi, json, spring, javascript)
6) Sample applications
Technology sample framework (subject of another mail)
BigBank application if ready
This is an initial strawman of how I think we can pull this
together. We can certainly move things around depending on what's
ready and what we think are essential modules. If this seems
reasonable I will transfer it to the wiki.
Cheers
--
Jeremy
---------------------------------------------------------------------
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]
