I agree that eventually you will have certain components that have their own
release cycles seperate from the core components. I think it will take
several releases of all components as an entire system before you will be
comfortable splitting things into seperate sub-projects, but as the core
components mature and stabilize I think it will be a natural desire to have
more frequent releases of the optional components.
The dependency management issues mentioned by Bruce and Kit are valid, but
don't forget that the bundles are able to specify required version
information for their own dependencies. So the dependency management issue
is more about shipping a properly working default configuration with the
main ServiceMix distribution than about the seperate releases of components.
I like Guillaume's idea of offering a basic image that is capable of
provisioning itself from a managed OBR repository. This could also allow a
user to configure their own customized provisioning configuration similar to
kickstart files for Linux distributions. I think you will also want to
offer a fully loaded and self contained image that already has all of the
components available, but the auto-provisioned basic image will be very
useful for a lot of users I would think.
Thanks,
Chris
On 10/4/07, Kit Plummer <[EMAIL PROTECTED]> wrote:
>
> Yes you are crazy.
>
> I have to agree - dependency hell is not something I'd like to have to
> overcome. Eclipse's deal is a nice example.
>
> Kit
>
> Sent from my iPhone
>
> On Oct 4, 2007, at 4:31 PM, "Bruce Snyder" <[EMAIL PROTECTED]>
> wrote:
>
> > 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/
>
