I like the general proposal Jeremy made. I believe we need to make a distinction between things included in the core and baseline vs. contributions. Things in the distribution may go beyond the spec such as monitoring or some thing the community deems to have "wide" applicability to Tuscany users. I would add one extra package in core which is to separate out all of the public APIs related to extension into a separate project. Celtix has done this and this relates to a point below.
In terms of build and process, my preference is to decide on an approach upfront that may be modified based on experience. Here's what I propose: 1. We focus on "clarifying" a public extension API. I don't believe we are going to be in a position to solidify this for some time, but we need to get to a more stable state than we are now since having an extension API is critical to growing the community. People writing contributions should use this API but expect change and the possibility of having to re-work their code. People working on core that introduce breaking changes will help contributors of these extensions make it "functionally whole". So, once we have the API in a "clarified" state, the build should work for extensions but people should not be upset if the API changes and while their extension may build, it may not function properly. In this case, the person responsible for introducing the change as the obligation to help get the extension working with others who are maintaining it. 2. Contributors of these new projects should be prepared to maintain them given changes in the core that are likely to arise. Hopefully this is a community process but people submitting new extension types should be prepared to maintain them. I believe this is part of the responsibility of being a committer but wanted to state it explicitly. 3. I would like to see a process where contributions first go into a sandbox and are worked on for some time prior to being put in extensions. It would be good to have a discussion (not a vote) before that move is made (i.e. to extensions). I think this is reasonably "lightweight" and offers a way to get people to contribute with no bar (the sandbox). 4. I think the project structure should reflect this. For example, I shouldn't need to download the kitchen sink to build and run the refrigerator ;-) More practically, having a project structure that represents distribution structures helps promote proper project hygiene and avoid nasty dependency issues. Thoughts? ------------------------------------------------- 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 > Mime Unnamed multipart/alternative (inline, None, 0 bytes) Unnamed text/plain (inline, Quoted Printable, 5928 bytes) View raw message
