I guess the idea of a self-provisionning application is somewhat
unrelated to the release cycle of the different bits of the
application. It seems people are a bit scared to split the lifecycle
soon. So let's work on a monolithic release cycle and see how it
goes. i think things should be easier once the API is finished.
As for an example, the components in ServiceMix are mostly independant
of each other, and mostly independant of the core container (they are
closely tied to servicemix-common though), and imho it should be easy
to split these lifecycles... (though I don't want to do that now, I'd
rather work on the 4.0 branch).
On 10/5/07, Chris Custine <[EMAIL PROTECTED]> wrote:
> 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/
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
