Hi,
Please see my comments below.
Thanks,
Raymond
From: Simon Laws
Sent: Thursday, November 13, 2008 3:20 AM
To: dev@tuscany.apache.org
Subject: Re: [PROPOSAL] A staged approach to create the OASIS development
stream in trunk
Hi Raymond
Thinking about two phases sounds right. Creating the basis for future
development and then exploiting it. Comments in line.
Simon
snip...
Stage 1: Foundation under Construction
Community expectations
- Focus on cleaning up the core areas (such as assembly model, contribution,
core, core-spi, and implementation-java).
- Good amount of refactoring may occur
- Not ready for adding new functional features before the core is settled.
Don't rush to bring it up to the same functionalities as 1.x.
- Code will be unstable and/or broken for a couple of weeks
1. Start from empty trunk (after the current trunk is branched off to 1.x)
* This gives us the opportunity to start from fresh without being
contaminated by what we have in 1.x.
I would probably say that this gives us an opportunity to improve what we
have in 1,x ;-)
<rfeng>+1</rfeng>.
2. Establish processes in the project to keep the code of the foundation
clean, simple and interesting to work with.
* Some guidelines for package visibility, cross module dependencies, SPI
principles
* We are producing a guide to help develop Tuscany modules with OSGi
-
http://cwiki.apache.org/confluence/display/TUSCANY/OSGi+Aware+Programming+in+Tuscany
Agreed. If you have some of these in mind already from the equinox branch I
would like to see them documented. I would also say there there are plenty
of existing "patterns" and "processes" that we should add to the list from
1.x that are embodied in the Tuscany code base but which are not documented.
E.g. provider pattern, separation of model from runtime, model
relationships, runtime creation pattern(although I hope we change this last
one),
<rfeng>+1 to document the key patterns we use, including the code structure
and runtime. In equinox, we only finished the first run, basically, removed
obvious "incorrect" dependencies and fixed the OSGi access violations
following the basic OSGi principles.</rfeng>
3. Get the right set of tools from sca-equinox branch to help us enforce and
maintain modularity with clean SPIs.
* We already have a fairly good developer story in sca-equinox branch:
- Leverage Eclipse PDE to develop Tuscany modules as OSGi bundles
- Adopt Eclipse JDT compiler with OSGi bundle resolution in maven build
Does this approach mandate these tools or are they optional?
<rfeng>The Eclipse PDE part is optional. The Eclipse JDT based compiler is
now enforced to speed up the compilation for maven build while the OSGi
validation part is optional. It is not easy for us human being to be always
well disciplined. I more view these tools as watchdog. :-)</rfeng>
4. Copy modules from sca-equinox branch into trunk
* Most of the modules in sca-equinox branch has been converted into OSGi
bundles
* We have fixed the access violations reported by PDE OSGi validation
* Some level of clean-ups have been done
* No functional deviations from the modules in the current trunk (1.x)
I personally don't mind using the modules that from the branch as a starting
point however one of my objectives here would be to make sure everyone is on
board and feels able to contribute to the future development. I would
propose the following
- Have the minimum set of modules only in trunk to start with. This allows
us to focus, without distraction, on what changes are really required and
also gives us the opportunity to think about how these modules should be
(re)structured.
<rfeng>I agree with you in principle but I have a practical concern about
just copying a small set of modules into trunk physically because it will
lose the refactoring advantages (provided by IDEs such as Eclipse) to evolve
the other modules as we clean up the core areas. It could lead to much
bigger efforts to port other modules over later on. If we agree it's worth
to take longer time rather than being distracted by other modules, I'm fine
with your proposal. Is it a good compromise that we physically copy most of
the modules but logically work with the key modules first?
</rfeng>
- Have a detailed explanation of how these modules differ from those in 1.x
so that those of us who haven't been intimately involved in the equinox work
can be brought up to speed with what changes were made and why.
<rfeng>svn diff will do :-). You will see there are pretty much fix for
package visibilities and cleanups. I can help to walk through a few examples
and I'm happy to explain why if you have any questions.</rfeng>
- Review this minimum set of modules in for the various issues from the
"themes" thread that we think need to come in stage 1.
- Once done we are ready to move to stage 2 with a set of bet practice in
place.
5. Perform thorough cleanup for the core set of modules
* Identify a subset of the modules (i.e., the core) as the focus for the
cleanup as proposed below in section C. (Note: Having other modules in the
trunk so that they can be refactored with the core to minimize porting
efforts).
* Some of the items can be progressed independently. We may have to accept
the fact that some require good coordination or even controlled mode.
Stage 2: Functional Bring-up
Community expectations
- Stable SPIs
- Stable core to integrate extensions
- Good foundation to add new functions
1. Merge changes from the 1.x branch into trunk
I would like us to do stage 1 as quickly as possible to minimize this.
<rfeng>+1. I thought about this after I sent out the initial proposal. I'll
try to do dry-run soon to understand the complexity. Let's assume we can
merge the changes in the current trunk into sca-equinox branch, then we
don't have to argue which one will be used as a baseline.</rfeng>
2. Further apply the OSGi modularity to extension modules
3. Bring up the unit tests
4. Bring up the samples, itests, vtests, demos and tutorials
5. 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).
B. Some TODO items for Stage 1
A good list. We will bet through this, and any other things people want to
add, most quickly by concentrating on the smallest set of modules,
documenting the full list of best pracitice and then, once done, applying
this to the wider set of modules in stage2.
<rfeng>Feel free to add your pain points to work with the core.<rfeng>
1. Use the Import-Package/Export-Package OSGi headers for Tuscany modules to
define cross-module dependencies and enforce SPI contracts
* Developers will be responsible for authoring and maintaining
META-INF/MANIFEST.MF files
2. Reduce the Import-Package/Export-Package to be only a minimum set of SPIs
* Some implementation classes are still referenced across modules, for
example, org.apache.tuscany.sca.databinding.impl package is exported.
3. SPIs have not changed for over 18 months and a new base gives us a chance
to clean up the SPIS that have been polluted with workarounds and
non-optimal changes.
4. Extract SPI layers for some modules
* For example, tuscany-core has quite a few packages that are exported. We
need to define a SPI layer if these exports are required.
* implementation-java: extract out the annotation processing so that they
can be reused for introspecting other java-based implementation technologies
such as Spring or EJB
* implementation-java-runtime: extract out the IoC
* add common modules such as common-java and common-xml to host java or XML
related utilities
5. Cleaner code, a pass through all the modules to add comments, adjust the
visibility of classes/methods, sort between static and instance methods,
remove deprecated/unused code, organize imports, etc.
* As we went through OSGI enablement, we discovered quite a few cases where
unused imports brought in unnecessary dependencies. It would be good to
adjust visibility of classes/methods, clean up static and instance methods,
add comments for maintainability.
6.The project has accumulated a lot of dead code over time. The dead code
makes it difficult to find your way through the code base and causes more
complication.
* For example, we have different ways to read/resolve SCA contributions
* Rationalize and clean up the SCA contribution classloading strategy
7. A consistent separation of extension modules into model and runtime
* For example, implementation-spring should be split into
implementation-spring and implementation-spring-runtime
8. Convert test cases from Junit 3 style to Junit 4 style
* Avoid redundant setup/destroy steps to reduce build time
* Cleaner way to ignore tests
