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 ;-) > > 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), > > 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? > > > 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. - 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. - 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. > > 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. > > > 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 > > > > > >
