Whats not completely clear from this is the 'rules', specifically when must the 'optional' stuff be built? If code isn't being built in the regular build that everyone runs it quickly goes stale. Look at our old Axis1 binding, been out of the regular build a couple of weeks and already it fails to build.
I'd like to see everything being included in the regular build. If some extension makes building difficult vote it out, don't exclude every extension by default. Is so much structure needed at this stage, or does it just makes things more complicated and make an unnecessary decision now about how Tuscany must be used. Maybe I just don't like the baseline vs extension distinction. I'd go for a more simple hierarchy and leave the structuring to the distributions. More like the way Mule or DOJO do things with various distributions designed for specific environments - minimal, SCA-SPEC, J2EE, the kitchen sink, etc. Perhaps with distributions customizable with a fancy build script to add/remove things - "minimal,+JavaScript". ...ant On 3/18/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > 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 >
