One theme that came out of the recent project promotion thread was a need to establish what our project structure should be. Part of that also is the level of "support" between parts of that project structure. I'd like to propose a strawman, not only of the structure but also of the rules.
A project "core" that: * is as small as possible with carefully controlled dependencies * provides the fabric for the runtime (Contexts) * provides APIs for providing plugin extensions * provides SPIs for embedding in host environments * can be built separately and used by extensions in binary form (implying versioning and stability on the extension APIs) * has a rule that incompatible changes to the API require the changer to upgrade and test all extensions in the Tuscany project and with a specific vote to accept them Baseline services that are distributed with the core that: * provide a deployment model for extensions (include loading, context building, package handling (classpath)) * provide critical system services (monitoring, admin enablement) * provide system services needed to support baseline extensions (security provider, transaction manager, work manager, ...) * has the same rule on API changes for those services as the core Baseline extensions that are distributed with the core: * programming models that are part of the specification (currently Java, futures being C++, Spring, J2EE, BPEL, ...) * transport bindings that are part of the specification (currently WS, futures being JMS, ...) * data bindings that are part of the specification (currently SDO, futures being JAXB, ...) * policy handlers that are part of the specification (futures being Security, Transaction, ...) Optional services that can be used to extend the runtime: * programming models that are not part of the specification (currently JavaScript, future being PHP, ???) * transport bindings that are not part of the specification (currently JSON-RPC, future being ???) * data bindings that are not part of the specification (currently JSON, future being ???) * services for use by applications (database access, DAS implementations, directory access, ...) * these would be released separately and could be deployed to a host environment by a user Host integrations that provide installable distributions: * provide implementations of the core's SPIs that allow Tuscany to run in different environments. (currently J2SE, J2EE WAR and Tomcat, future being full J2EE, Geronimo, OSGi(Eclipse), ...) * provide installable distributions that include all the baseline compoments applicable to that environment * provide "extended" distributions tailored to different user communities that include selected optional services Sample and demo applications that: * show key concepts from the SCA programming model (currently helloworld) * show how to build a large scale application (currently bigbank) * show how to use Tuscany in different environments Testing * compliance test for the specification (when available) * pre-release tests for Tuscany * ALL modules above should test their own functionality (at both the unit and integration levels) as part of their own build. No manual setup should be required. Given that, I would suggest the following changes to the project layout: sca/ # "core" system sca/system/common sca/system/model sca/system/core # "baseline" services and extensions sca/baseline/service/monitor sca/baseline/service/security sca/baseline/service/transaction sca/baseline/service/work sca/baseline/container/java sca/baseline/transport/axis2 sca/baseline/data/sdo sca/baseline/policy/security # "optional" services and extensions sca/extension/container/rhino sca/extension/transport/jsonrpc sca/extension/data/json sca/extension/service/jndi sca/extension/service/jdbc # host environment integration sca/host/tomcat/runtime # integration code sca/host/tomcat/testing # integration testing sca/host/tomcat/win32 # packaging for release sca/host/j2se/runtime # etc... # samples and testing modules that are not part of a developer build sca/samples/helloworld/j2se sca/samples/helloworld/war sca/samples/bigbank sca/testing/compliance Thoughts? -- Jeremy
