We have had a rush of build problems recently which have stopped
people from being able to contribute effectively. Some of those have
come from the size of the build leading to Jim's proposal to go ahead
with the build refactors we have been talking about. For those to
work we need some way to publish unstable artifacts and that meshes
nicely with this release thread.
There have been no comments on this thread since the original burst
so I plan to start pulling together a release based on the approach
described here (factoring in those comments).
--
Jeremy
On Aug 16, 2006, at 1:58 PM, Jeremy Boynes wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
