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 changes).
i) Processes in the project to keep the code of the foundation clean,
simple and interesting to work with.
The work in the sca-equinox branch is an attempt to cover (a) to (d) and
a little bit of (e), as a side effect of trying to work on (a) to (d) on
a more manageable code base.
Items (e) to (h) are as important, and without addressing them first,
the new foundation will be difficult to build on and grow again.
Finally Item (i) is the most important for a longer term success of that
foundation.
So, I think that the better way to build the new foundation the project
needs in trunk is:
1) Empty trunk.
2) Clean up a small selection of modules and functions, do the above (a)
to (g) thoroughly.
3) Bring these modules to trunk slowly when they are clean and usable again.
4) Do not bring up to trunk the dead weight or the problematic functions
covered by (h). They'll have to be redone for OASIS-SCA anyway.
5) Establish (i) to make sure the foundation stays clean.
Disclaimer: I'm not going to have much time to work on this in the next
few weeks so please take all of the above really just as suggestions.
Hope this helps.
--
Jean-Sebastien
