On 10/4/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> I'd like to make ServiceMix 4.0 as modular as possible. This would
> mean that ServiceMix 4.0 main distribution would come with the minimal
> set, while additional features could be provisioned and configured
> using OBR, the Deployment Admin or our provisioning system.
> Such features could include:
> * an activemq broker
> * an apache ds server
> * jbi 1.0 compatibility layer
> * jaxws support
> * ...
>
> Although from a project perspective, if we could split these features
> in different projects, that would make things easier to release: i.e.
> release a single "feature" at a time, rather than releasing everything
> each time. Kinda like maven does with its plugins.
I've always thought the idea of separate release cycles for different
components/features was a good one. This allows for individual
components to be released as they're ready. However, I've begun to
reconsider this recently. Independent component releases seem like a
good idea until the developer has trouble and then begins to upgrade
components independently resulting in a mish-mash of versions which
can cause a laundry list of other problems.
It seems to me that we should not push this responsibility onto the
developer because it causes them more trouble than its worth. Not
unlike recent Eclipse releases, ServiceMix is a container with many
modules and I think *we* should bear the burden of making each module
work together to provide an overall ServiceMix release.
An alternative approach would be to mix independent component releases
with overall ServiceMix releases. This would give us the ability to
release components independently while still providing a major release
of all components packaged together as ServiceMix, say, four times a
year.
Am I crazy?
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
