Hi,
Thank you for the assessment. What about we do the following?
1. Start with an empty trunk.
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)
3. Copy the sca-equinox branch into the new trunk and 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)
5. Incrementally bring up other modules from contrib into "java/sca/modules"
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/
