"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/
