One of the challenges we faced with M2 was coordinating the release
of so many components. In the end, it took a very long time to get
the release out because we were waiting for Axis2 1.1 to be released
- a dependency that only affected some modules but for which we had
to hold up everything.
Also, Rick pinged me yesterday as he was having problems building
trunk. I tried and ran into (different) problems. The fix was simple
(thanks Raymond) but it illustrates the problem that trunk has a
whole has become too large for people to easily work with. There's so
much to build and it's fragile enough that people are just building
sub-sections and that is causing another set of problems.
I think an approach to this is to break the project down into a set
of modules along the lines where people typically work and to have a
much looser relationship between those modules. Each module becomes
responsible for its own code, testing, documentation, samples,
releases etc. but organizationally remains part of a single project
(one mailing list, one PMC, one SVN ACL). The boundary between
modules is technical - interfaces and a commitment to maintain them -
rather than social.
We started down this route in M2 with the modularization of Spec,
SDO, DAS and SCA; going forward I think we need to expand this down
into SCA. I'd propose the following:
* SCA Kernel (the apis, spis and default core impl)
* SCA Runtimes (hosts for the kernel that support users' runtime
scenarios)
Standalone
Webapp
Maven I-Test
Eclipse
etc.
* Extensions (components that add function to the bare runtime)
Axis2 web services (axiom, axis2 ws binding, ...)
Scripting and Web2.0 (script container, json databinding, ...)
J2EE integration (ejb container, rmi/iiop binding, ...)
Spring integration
OSGi integration
and many many more
* Distributions (things we'd expect a user to download and install)
* Integration test suites
* Sample applications (compound applications that integrate multiple
technologies)
Key to this is we should not operate as if everyone is always
building everything all the time - let's face it, many people are not
doing that now. Developers should be able to build, commit and
release any of these modules as needed. For that to work, developers
of modules that other people rely on need to make sure that the
changes they make cause as little disruption as possible - basically,
define a interface to the module, strive not to make incompatible
changes, and if you do let people know. To avoid the need to build
everything locally, modules can publish snapshots to the maven repo
that their downstream dependencies can use.
For example, if we publish a snapshot of the kernel module, all
extensions etc. can rely on those jars from the repo rather than
needing to build them ever time. If we keep the SPIs compatible, we
can make changes to the core impl without disrupting any of the
extensions; also we can add features to an extension, or even add a
new extension, without changing the kernel or impacting other
extensions. This does mean more work on both sides - we have to find
ways to add function without making incompatible changes to the SPI -
but it means that more people can get things done as each module can
move at its own pace.
Technically I think we're fairly close to having this already. This
is more of a social change in the project - changing our view away
from "build it all" and being willing to do the work to keep the
looser modules working together. I think though that we need to do
this if we're going to maintain progress.
Thanks
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
