On Mon, Nov 17, 2008 at 3:06 PM, Simon Laws <[EMAIL PROTECTED]>wrote:
> > > On Mon, Nov 17, 2008 at 2:18 PM, ant elder <[EMAIL PROTECTED]> wrote: > >> >> >> On Mon, Nov 17, 2008 at 1:59 PM, Simon Laws <[EMAIL PROTECTED]> >> wrote: >> > >> > >> > On Mon, Nov 17, 2008 at 11:12 AM, ant elder <[EMAIL PROTECTED]> >> wrote: >> >> >> >> I think its important that we understand what changes have been made in >> >> the branch, but I'm having some trouble working out the detail and >> questions >> >> asking for more detail are not getting many answers. >> >> >> >> In the past when asking what would happen with the branch there have >> been >> >> answers like: "we'll have something to look at and reflect on in the >> branch. >> >> It's always much easier to do things a second time, when somebody has >> >> already been through the pain of exploring it for you and you can take >> a >> >> look at the result." >> >> >> >> I think that could be the best approach. Instead of a wholesale >> replacing >> >> of trunk modules with the modules from the branch start with the trunk >> >> modules and try to replicate the functional changes one by one so we >> can all >> >> see and understand the changes. This approach is much more community >> >> friendly and avoids anything like a divisive vote on replacing trunk. >> I'm >> >> going to start trying to do this now. >> >> >> >> ...ant >> >> >> >> On Mon, Nov 17, 2008 at 3:54 AM, Luciano Resende <[EMAIL PROTECTED] >> > >> >> wrote: >> >>> >> >>> 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<http://people.apache.org/%7Elresende/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<http://people.apache.org/%7Elresende/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<http://people.apache.org/%7Elresende/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://people.apache.org/%7Elresende> >> >>> >> http://lresende.blogspot.com/ >> >>> > >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> Luciano Resende >> >>> Apache Tuscany, Apache PhotArk >> >>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende> >> >>> http://lresende.blogspot.com/ >> >> >> > >> > Hi >> > >> > Luciano, thanks for taking a look at the diffs.It does seem that we >> pretty >> > much have agreement on the approach apart from the important question of >> > whether we start from the equinox branch and apply changes from the >> existing >> > trunk or start from the existing trunk and apply changes from equinox. >> > Looking at Luciano's post it looks like which ever way we go we will >> still >> > apply the sequence of changes manually. Can we then take this >> opportunity to >> > go ahead and do that based on the trunk code as it stands taking >> whatever >> > changes we need from the equinox branch. Gives slackers like me who >> haven't >> > caught up with the equinox branch to watch all the changes as they >> happen. >> > I've put time aside this week to help get the 2.0 bring up in trunk >> underway >> > so I can contribute effort as appropriate. >> > >> > So leads to a slight change to Raymond's list of steps; >> > >> > 1. Start with current trunk (will be notionally contain the minimum set >> of >> > modules when we move the majority of modules into /contrib) >> > 2. Try a best-effort merge to pull the delta from sca-equinox branch >> into >> > trunk (potentially leave some hard-to-merge changes to the bringup >> phase) >> > 3. move modules into "java/sca/contrib" >> > 4. Move the core set of module into "java/sca/modules" and clean them up >> > thoroughly (we already have a list of actions). Includes creating >> minimal >> > distriibution directory contents >> > 5. Incrementally bring up other modules from contrib into >> "java/sca/modules" >> > >> > A question based on the comment about using tooling to refactor all the >> > modules. Sounds ok to me and shouldn't be adversely affected by having >> some >> > modules in /contrib. In the equinox branch, as things have been >> refactored, >> > have you been testing all the modules or just committing changes with a >> view >> > to testing them at some point in the future? >> > >> > Simon >> > >> >> That sounds ok to me except i think (2) should be modified or at least >> clarified. I don't think we should just do merges of the current delta of >> modules in the two code streams as that still means we wont necessarily >> understand whats changed. What I think would be better is to look at the >> delta to work out what the functional changes are and apply them one by one >> if they're appropriate including any necessary discussion on the dev list >> for each change. >> >> ...ant >> >> > Luciano has started a list of the point changes that were made [1]. > Personally I don't want to pore over every svn diff independently but would > like to see each new feature explained and given that the explanation is > clear then we apply all those changes. I fully expect that some changes > overlap so I don't want to hold out for each and every change being applied > independently if that is not practical. I do want help understanding the > changes though. So, for example, > > "Develop the Equinox launcher". Would be good to have a description of the > process here, particularly what the issues are with launching a Tuscany > runtime based OSGi bundles in the Equinox runtime. How are 3rd partly > dependencies managed, how is the classpath resolved, are there any concerete > implications for the runtime itself when launching for Equinox as opposed to > the non-OSGi approach etc. > > Simon > > [1] http://www.mail-archive.com/dev%40tuscany.apache.org/msg03415.html > How would we even know what the point changes are without someone going through each diff? If we're not going to look at the diffs in detail we might as well be starting with the modules from the sca-equinox branch, though as i've already said thats not the way i'd prefer to do it. ...ant
