Create the OASIS development stream in trunk
A. Proposal for the Stages
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
...
- Some guidelines for package visibility, cross module dependencies, SPI principles
- We are producing a guide to help develop Tuscany modules with OSGi
3. Get the right set of tools to help us enforce and maintain modularity with clean SPIs.
...
- 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
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
1. Use the Import-Package/Export-Package OSGi headers for Tuscany modules to define cross-module dependencies and enforce SPI contracts
...