On Tue, Nov 4, 2008 at 11:44 AM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I like the idea to build a new trunk from scratch for the 2.x stream (OASIS)
> and harvest things from the sca-equinox branch and 1.x branch (OSOA).
>
> Now we have reasonable parts covering items a, b, c, d on Sebstien's list. I
> see it as a good story for developers to develop Tuscany modules as OSGi
> bundles with the help from Eclipse PDE. The missing feature is the maven
> eclipse compiler doesn't report the OSGi violations yet.
>
> Should we start to branch off the current trunk into 1.4 branch as proposed
> at [1] as the first step?

Let me handle the branching now.
I'd also like to propose we change the equinox branch "artifact
version" to avoid any conflicts with the 1.4 work... would
2.0-snapshot work ?

>
> Thanks,
> Raymond
>
> [1]
> http://markmail.org/message/jfgf4nsvfqw5hdg7?q=Update+on+the+Equinox+branch
>
> --------------------------------------------------
> From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
> Sent: Monday, November 03, 2008 9:52 AM
> To: <[email protected]>
> Subject: Re: Update on the Equinox branch
>
>> Simon Laws wrote:
>>>
>>> snip...
>>> On Fri, Oct 31, 2008 at 6:28 PM, Raymond Feng <[EMAIL PROTECTED]
>>> <mailto:[EMAIL PROTECTED]>> wrote:
>>>
>>>    Hi,
>>>
>>>    I envision that the OSGi enablement will bring a new foundation for
>>>    the Tuscany code base with modularity and formalized SPI visibility
>>>    enforced by the OSGi within both the development IDE and maven build.
>>>
>>>    We are taking a staged approach as I described before and we are
>>>    making good progress. I'm not particularly concerned about where the
>>>    work is being done. If the community is ready to embrace it
>>>    (probably when we get into step 5 and 6), we can move it into trunk.
>>>    It really depends on how comfortable we are with the fact that the
>>>    code will be under construction for a period of time until it's
>>>    solid, consistent and clean enough to serve as a new foundation to
>>>    build other things on top of it.
>>>
>>>    Thanks,
>>>    Raymond
>>>
>>>
>>> Ok, thanks Raymond, your intention is clear.
>>>
>>> So, in summary, the code in branch will be proposed as the new trunk when
>>> it is ready. It is not the intention to take the lessons learned and apply
>>> them to a new trunk bit by bit.
>>>
>>> Filling in the gaps from other ML discussions (I'm not saying it will be
>>> so but I'm painting a picture here).
>>>
>>> The new (2.x) will be our OASIS SCA code base. The intention being that
>>> it will be based on the OSGi foundation from the equinox branch
>>> The existing (1.x) trunk is retained, in a branch, as our OSOA SCA code
>>> base and is further developed as appropriate.
>>>
>>> Simon
>>
>>
>> In my opinion, to get a good foundation in trunk for (a) an OSGi-enabled
>> Tuscany and (b) an implementation of the OASIS SCA, the project needs the
>> following:
>>
>> a) Tuscany modules as first class OSGi bundles with clean imports/exports.
>>
>> b) First class integration with a leading OSGi runtime like Equinox (with
>> the ability to add others later if needed).
>>
>> c) A Modular distribution structure allowing to drop reasonably sized
>> 'feature packages' on top of a core runtime distro.
>>
>> d) An OSGi-aware development environment for Tuscany contributors, mixing
>> Maven, Eclipse tools, custom tools and processes supporting the whole dev
>> lifecycle.
>>
>> e) Less code, as the project has accumulated a lot of stuff over time with
>> various levels of quality, and dead code not used or supported anymore,
>> making it difficult to find your way through the codebase.
>>
>> f) Cleaner code, a pass through all the modules to add comments, adjust
>> the visibility of classes/methods, sort between statics and instance
>> methods, remove deprecated/unused code etc.
>>
>> g) Refreshed clean SPIs, as they've been in maintenance mode for 18 months
>> and have been polluted with workarounds and non-optimal changes.
>>
>> h) A redesign of some problematic or over-complicated areas like policy
>> for example (that's a good one to redesign as it's also impacted by the
>> OASIS chang
>
>



-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Reply via email to