Our discussions on modularity have gone quiet and Kelvin and Luciano
have started to build distributions for SDO and DAS. I'd like to open
the discussion up about what should be in our next release, how we
should approach it and when we think it might be ready. As the person
opening this thread, I guess I'm also volunteering to be Release
Manager unless someone else would prefer to do it :-)
One of the things we're achieved with the modularization is the
ability to decompose what we have into separately releasable modules
- we don't have to pull everything together at the same time. We also
have the ability to release artifacts individually through various
maven repositories, publishing specific jars rather than than entire
distribution.
This allows us to structure a release differently from what we did in
M1. Instead of publishing one bundle and then pulling libraries from
it to distribute through Maven, I suggest we focus on the individual
components then group them together into bundled distributions.
Taking SDO as an example, this would mean that we would decide at
some point that we wanted to release the sdo-impl library (that being
the executable part of SDO). We would cut and vote on a version of
that jar and that could then be published through Maven. We could
also bundle that jar in a distribution containing dependencies (e.g.
EMF), samples, documentation, ... The two don't need to be in
permanent lock-step (although alignment is good) - for example, we
could release an updated impl jar with some bugfixes without
respinning the bundle.
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.
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.
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
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
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]
