Assuming u are talking about the same set that Jeremy posted...+1 from me. 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 On 3/21/06, Jim Marino <[EMAIL PROTECTED]> wrote: > kitchen sink ~ contrib; refrigerator ~ core + baseline (maybe, > although the baseline may not be necessary) > > On Mar 20, 2006, at 8:48 PM, Davanum Srinivas wrote: > > > "kitchen sink to build and run the refrigerator" > > > > So, in your opinion, what's the kitchen sink? Please be extermely > > specific. Please do keep in mind that there needs to be a downloadable > > version on the apache web site / mirrors which people can download and > > run out-of-the-box. > > > > thanks, > > dims > > > > On 3/20/06, James F Marino <[EMAIL PROTECTED]> wrote: > > > >> 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 > >> > >> > > > > > > -- > > Davanum Srinivas : http://wso2.com/blogs/ > > > > -- Davanum Srinivas : http://wso2.com/blogs/
