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/
