On Sun, Nov 16, 2008 at 1:39 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > Thank you for the assessment. What about we do the following? > > 1. Start with an empty trunk.
+1 > 2. Try a best-effort merge to pull the delta from 1.x branch into > sca-equinox branch (potentially leave some hard-to-merge changes to the > bringup phase) I' m not sure exactly how to handle this as a community effort, maybe the best way would be for each individual that have changes in trunk to verify what needs to be merged and help with that portion ? Well, just a thought... > 3. Copy the sca-equinox branch into the new trunk and move modules into > "java/sca/contrib" I don' t know exactly what' s the benefit of a contrib folder, but I' m ok with this. Note that, we should have all modules loaded in eclipse when doing clean up/refactoring to allow the IDE tools to help with refactoring the dependencies. > 4. Move the core set of module into "java/sca/modules" and clean them up > thoroughly (we already have a list of actions) > 5. Incrementally bring up other modules from contrib into "java/sca/modules" > Overall, sounds like a good strategy... Does anybody have any objections ? What should be our next step ? > Thanks, > Raymond > -------------------------------------------------- > From: "Luciano Resende" <[EMAIL PROTECTED]> > Sent: Friday, November 14, 2008 9:56 PM > To: <dev@tuscany.apache.org>; <[EMAIL PROTECTED]> > Subject: Re: [PROPOSAL] A staged approach to create the OASIS development > stream in trunk > >> On Thu, Nov 13, 2008 at 9:38 AM, ant elder <[EMAIL PROTECTED]> wrote: >>> >>> >>> 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 >>> >>> >> >> >> I did some research around the delta between trunk and the equinox >> branch, and also possible ways to merge, below are my findings : >> >> >> Equinox/Trunk developer streams >> >> >> /---------------------------> 345 commits to equinox branch >> / >> / SVN Revision #694816 - Sep 12 - Equinox branch created >> / >> --------------------------------------> 203 committs to trunk >> >> >> The detailed list of changes that went in equinox branch is available at : >> >> >> http://people.apache.org/~lresende/tuscany/sca-equinox/sca-equinox-changes.txt >> >> Trying to execute a merge from trunk to the equinox branch : >> Conflicted:86 Skipped:227 Added:654 Deleted:11 Updated:370 >> >> The merge details are on the link below >> >> >> http://people.apache.org/~lresende/tuscany/sca-equinox/sca-equinox-merging-from-trunk.txt >> >> Trying to execute a merge from equinox branch to trunk >> Conflicted:159 Skipped:264 Added:570 Deleted:26 Updated:314 >> >> The merge details are on the link below >> >> http://people.apache.org/~lresende/tuscany/sca-equinox/sca-trunk-partially-merging-from-equinox.txt >> >> >> My recommendation would be to start with a clean trunk, move >> sca-equinox/modules/ to the new trunk and then define a subset of >> modules to work on. Having all the modules available would allow us to >> take advantage of IDE tools, and have code refactoring being applied >> to dependent modules easily. Also, any issues in the affected modules >> can be handle when we still have the changes fresh in our heads :) >> >> As for merging, from the exercise described above, starting from the >> equinox branch code makes a less painful merge, but I don't think >> there is any way that we can come up with an easy and simple way to >> execute the merge, and the less painful option that comes to mind is >> to evaluate changes done in a given module when working on it, and >> identify witch changes need to be applied to the current code in the >> new trunk, and then either merge or port the changes. I also have a >> feeling that it's probably not a good idea to try batch-merge of a >> large range of revisions, as this might be timing consuming, bring >> unnecessary changes or changes that need to be refactored to be a good >> citizen in a modular OSGi environment. >> >> >> Thoughts ? >> >> -- >> Luciano Resende >> Apache Tuscany, Apache PhotArk >> http://people.apache.org/~lresende >> http://lresende.blogspot.com/ > > -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/
