tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: Project structure
Date Tue, 21 Mar 2006 07:26:49 GMT
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 <jim.marino@gmail.com> 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 <jim.marino@gmail.com> 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 <jboynes@apache.org> 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/

Mime
View raw message