Hi Jeremy, thanks for that explanation... was really useful.
I think Javascript and maybe even Ruby should be in. Javascript has been up and working for long now. I found it to be a good demonstration of a container extension and that is how I ended up doing Ruby quickly (by my standards :)). It has... - properties, services and references working - extends to support E4X - has an acceptable test coverage - has a working sample Maybe the doc is something that remains to be done or maybe that is also there and am missing that. Thanks - Venkat On 10/12/06, Luciano Resende <[EMAIL PROTECTED]> wrote:
+1 I'll wait for 2 JIRAS to get in and I'll work with a commiter to get DAS branch created. - Luciano Resende On 10/12/06, Rick <[EMAIL PROTECTED]> wrote: > > Generally favorable. Essentially +1 if it were a vote. I have one concern > is on > the sca deliverables. We need to drive to a conclusion soon to figure out > the > exact artifacts a user will download and what each will contain. Not > directly, > related to the branching, but you did touched on it. > > Jeremy Boynes wrote: > > We have had quite a few suggestions over the last couple of days for new > > functionality for the trunk some of which would result in changes to the > > APIs. We have also had the completion of one of the major pieces of code > > (async over axis webservices) that was still outstanding although there > > are still concerns over the amount of test coverage it has. We also have > > RC distros of both SDO and DAS available. > > > > I am concerned that there is enough pent-up energy in the project that > > we may soon see more changes that will destabilize what we have right > > now. In light of that, I would like to suggest that we create a branch > > where we can finish stabilizing M2 so that we can open the trunk for new > > development without concern that it will disrupt a release. This matches > > what has already been done for SDO. > > > > The alternative is to initiate a code-freeze until the M2 release is > > tagged saying that all new work should be done in people's sandboxes. > > This code-freeze is likely to be in place for a while as we also need to > > wait for Axis2 1.1 to be released. I believe that would be less > > acceptable and so unless there is an objection I plan to go down the > > branch path. > > > > Just for the record (and people reading this later), the purpose of this > > branch is to stabilize a milestone. The intention is not to establish a > > branch for the purpose of ongoing maintenance and once the release is > > tagged work on the branch will end. It can always be reopened later if > > someone wants to restart work on it but that is not the intention at > > this time. > > > > The SDO code already has a branch in place and we have basically stable > > versions of the build support artifacts. In light of that, rather than > > copy the entire source tree I'm going to create branches for each of the > > source distributions that we intend to produce as follows: > > > > tags/java/pom/parent/1-incubator > > tags/java/buildtools/1.0-incubator-M2 > > tags/java/spec/sca-api/1.0-incubator-r0.95-M2 > > branches/sdo-java-M2 (already there) > > branches/das-java-M2 > > branches/sca-java-M2 > > > > I moved the tags to a "java" subdirectory as I think over the course of > > time we will be tagging quite a few things and if we put them all in one > > directory it is going to get confusing. > > > > The pom/parent and buildtools tags will correspond to the current > > version in the trunk. These are pre-reqs for all the other projects and > > as such I would like to finalize their release early. I'm going to > > re-initiate the vote from last week based on the new tags. > > > > Once the parent POM is tagged, SDO and DAS can be updated to use it and > > eliminate all SNAPSHOT dependencies. If they are ready to go, we can > > initiate a vote on them either together or separately (my inclination is > > separately as different people may review them). > > > > SCA is a little more complex as we have outstanding issues related to > > the distribution layout, what's in each distro (code, samples, doco > > etc.) and so forth. As such I do not intend to just copy the entire SCA > > tree but instead to build it up as these issues get resolved. This will > > allow us to move things like the samples around in the trunk without > > needing to duplicate work that in the branch (so we only do it once). > > > > Once a module is copied to the branch, the version in the trunk will be > > bumped to 1.0-incubator-SNAPSHOT (removing the M2 designation). This > > will ensure that there are no conflicts in between things built from the > > branch and things built from the trunk (as artifacts from both will be > > placed in your local repo). > > > > The first modules copied to the branch will be those needed to support > > the standalone and webapp runtimes. This will include the kernel, > > commands, runtime modules and the webapp plugin. > > > > The second wave of modules copied would be those for extensions that we > > decide are /IN/ the release. The only reason these are separate from the > > first ones is that we have not defined yet how they will finally be > > packaged (just that they will be in a binary form). The ones I believe > > that are currently in this category are: > > * binding.axis2 > > * binding.rmi > > * idl.wsdl > > * databinding.sdo > > * databinding.axiom > > > > I am not sure on whether javascript, jsonrpc, ruby or spring fall in > > this category or the next - opinions? > > > > A third set of modules will be distributed in source form only. This > > includes groovy, castor, jaxb, xmlbeans and celtix. > > > > Finally, we need to decide how we will distribute supplemental artifacts > > such as javadoc, end-user doc and samples. Once we know that, they can > > be added to the branch in the appropriate places. > > > > Thanks for reading this far. > > -- > > 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] > >
