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
