On Thu, Nov 13, 2008 at 5:18 PM, Simon Laws <[EMAIL PROTECTED]>wrote:
> > > On Thu, Nov 13, 2008 at 4:30 PM, haleh mahbod <[EMAIL PROTECTED]> wrote: > >> As I watch the different threads it is clear that there is a common goal >> of encouraging everyone to be involved in creating the base line for OASIS >> code base and there is also a desire to create a working baseline in a >> timely manner. >> >> Here is an idea that came to my mind that might help. >> 1. Whoever worked on Equinox branch writes down the principles used to >> OSGI enable 1.x in Equinox branch. This becomes the guide. >> 2. Define a subset of the modules *as the goal* of what will first be >> brought to the trunk. >> 3. Of that subset define a few modules that everyone can focus on at a >> time. For example let's bring in module x, y, z into the trunk in the next >> day. This enables everyone to be focused on the same thing and the work >> becomes a group effort. >> 4. Everyone who is interested to get involved will do a diff of the >> selected equinox modules against the latest 1.x. Review the code while also >> remembering the principles that were used to make the changes. >> 5. Post questions if any >> 6. Move on to the next set if there are no major concerns. >> >> This will definitely give people who are interested to be involved a >> chance to participate, learn and ask questions. With everyone involved in >> this important base line work, OASIS base line will come to life faster. >> >> Haleh >> >> ...snip >> > > Re. point 2 running the dependency lister on samples/calculator in trunk > gives. > > tuscany-assembly-1.4-SNAPSHOT.jar > tuscany-assembly-xml-1.4-SNAPSHOT.jar > tuscany-assembly-xsd-1.4-SNAPSHOT.jar > tuscany-binding-sca-1.4-SNAPSHOT.jar > tuscany-binding-sca-xml-1.4-SNAPSHOT.jar > tuscany-contribution-1.4-SNAPSHOT.jar > tuscany-contribution-impl-1.4-SNAPSHOT.jar > tuscany-contribution-java-1.4-SNAPSHOT.jar > tuscany-contribution-namespace-1.4-SNAPSHOT.jar > tuscany-contribution-xml-1.4-SNAPSHOT.jar > tuscany-core-1.4-SNAPSHOT.jar > tuscany-core-databinding-1.4-SNAPSHOT.jar > tuscany-core-spi-1.4-SNAPSHOT.jar > tuscany-databinding-1.4-SNAPSHOT.jar > tuscany-databinding-jaxb-1.4-SNAPSHOT.jar > tuscany-definitions-1.4-SNAPSHOT.jar > tuscany-definitions-xml-1.4-SNAPSHOT.jar > tuscany-endpoint-1.4-SNAPSHOT.jar > tuscany-extensibility-1.4-SNAPSHOT.jar > tuscany-implementation-java-1.4-SNAPSHOT.jar > tuscany-implementation-java-runtime-1.4-SNAPSHOT.jar > tuscany-implementation-java-xml-1.4-SNAPSHOT.jar > tuscany-implementation-node-1.4-SNAPSHOT.jar > tuscany-interface-1.4-SNAPSHOT.jar > tuscany-interface-java-1.4-SNAPSHOT.jar > tuscany-interface-java-jaxws-1.4-SNAPSHOT.jar > tuscany-interface-java-xml-1.4-SNAPSHOT.jar > tuscany-monitor-1.4-SNAPSHOT.jar > tuscany-node-api-1.4-SNAPSHOT.jar > tuscany-node-impl-1.4-SNAPSHOT.jar > tuscany-policy-1.4-SNAPSHOT.jar > tuscany-policy-xml-1.4-SNAPSHOT.jar > tuscany-sca-api-1.4-SNAPSHOT.jar > tuscany-xsd-1.4-SNAPSHOT.jar > > I expect the list from the equinox branch might be slightly different but > it shows the scale of things. It's not a very long list. If we get the > overall principles documented as they stand at the moment the we can review > the individual modules. I realize this sounds like a compromise between > Raymond's and Ant's suggestions but I think we will have to take it module > by module. There are probably some less controversial ones that we can put > in place to start with, sca-api (even this though there were the license > changes in trunk that we need to make sure we get)? However I was just > diffing assembly, which I thought would be straightforward, but noticed that > it has the builder pluggability changes in there in the branch. I think we > want them but we need to understand them. > > So against each of these I think it warrents a summary of the changes > (given this restricted list I hope someone familiar with the branch can just > do this off the top of their heads). +1, i don't think its enough to say we can just look at an svn diff as there are so many changes, even a diff on just a single random module - assembly-xml - gives a 180K diff file which runs at 64 full screens of text to work out. > We may actually find it easier to go from trunk in terms of unpicking all > this but I hold an open mind. > > I'm leaning to that as well, with diffs showing so many changes mixed together or would be easier to understand descrete changes merged into the existing trunk - eg each module needs the correct manifest this merge shows one, now lets do the same for each other module etc. ...ant
