Jeremy, when is your target date for this next release? I hope to get back to the OSGi binding/hosting code within the next week and I'd really like to try and get something into the release.
Thanks, Joel -----Original Message----- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 11:04 AM To: [email protected] Subject: Re: Process and content for next release? 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] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
