Re: [PROPOSAL] A staged approach to create the OASIS development stream in trunk

[Raymond Feng]

Hi,

Thank you for giving me the opportunity to present an better organized view 
of the efforts to enable OSGi for Tuscany runtime even though we had 
scattered information from E-mails and wiki pages before. After I briefly 
went through the commit log for the sca-equinox branch and some of the 
discussions, I added the following wiki page which hopefully will give us 
the level of details for clarification:

http://cwiki.apache.org/confluence/display/TUSCANYWIKI/OSGi+Enablement+for+Tuscany+Runtime

We can probably use the Tuscany IRC to discuss any questions in this area 
that require real-time interactions (see 
http://tuscany.apache.org/getting-involved.html to set up your IRC if you 
haven't used it before). I will be logging into the channel. Please feel 
free to ping me there.

Thanks,
Raymond

From: Simon Laws
Sent: Monday, November 17, 2008 7:43 AM
To: dev@tuscany.apache.org ; [EMAIL PROTECTED]
Subject: Re: [PROPOSAL] A staged approach to create the OASIS development 
stream in trunk





On Mon, Nov 17, 2008 at 3:19 PM, ant elder <[EMAIL PROTECTED]> wrote:




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
>>
>> 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/


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


I'm anticipating that the people who have been working on the equinox branch 
will know what they have changed and why (at least I hope so). The one thing 
I would like to avoid is having to reverse engineer the justification for 
the changes by looking at svn diffs. It would seem to me to be much more 
efficient if someone who knows just goes thorough the list of features of 
the equinox branch and explains, in some detal, what they are on the mailing 
list. I expect that some of the inidividual changes can be applied in 
blocks. I also expect that some changes can't be separated out and will 
either have to bre reworked or applied as one. All part of the fun.

Simon