Can we turn this into a lazy consensus vote - if theres no -1s after next
Tuesday I'll make the change.
No one is particularly wedded to this structure, so if you'd rather an
alternative post it. Its also not cast in stone, I don't see why we can't
review it again in some months.
...ant
On 3/23/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> ant elder wrote:
> > Are we any closer to deciding on this now? How about just keeping what
> we
> > have right now in SVN but adding bindings and containers folders to sca
> and
> > moving all the binding and container impls there (and the same for
> policys,
> > services, etc when we have some of those)?
> >
> > ...ant
> >
> Ant, +1 from me. This will keep things simple.
>
> > 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
> >>
> >>
> >
> >
> --
> Jean-Sebastien
>
>
