incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: [VOTE] accept donation of a business process engine into the ServiceMix project
Date Fri, 03 Feb 2006 15:37:57 GMT
Just what do you define the community as? ws-folks don't count? what
mentor says does not count? existing Agila folks don't count? Looks
like the definition of community is everyone who says yes to you and
everyone else is not part of the community?

Part of the incubation process is to to generate interest, get people
involved, make sure there is wider participation. A proposal and
emails on the general@i are part of that process to get more people
involved. Why is there so much resistance to doing that?

When paul dropped in you asked him to work on Agila. Is this what you
mean by increasing community participation? Is this how you do it?

-- dims

On 2/3/06, James Strachan <> wrote:
> On 3 Feb 2006, at 15:05, Rodent of Unusual Size wrote:
> > Davanum Srinivas wrote:
> >> Why can't you treat an orchestration engine like a component like the
> >> way you treat Axis or XFire? Why does the code have to live within
> >> ServiceMix? Lot of us want a BPEL engine, we don't want a JBI
> >> container. The code coming in does exactly that, it is a BPEL engine
> >> and has no relation to JBI or Java for that matter. Why can't you
> >> have
> >> a separate project for BPEL and add glue code as a JBI component
> >> EXACTLY the way you work with other projects like XFire?
> >       :
> >> We seem to agree on the ends but not on the means. You like a very
> >> good integration with a BPEL engine for ServiceMix. I like a very
> >> good
> >> BPEL engine for its own sake. Am sure we can find people on both
> >> sides
> >> and some who may like both objectives.
> >
> > An interesting point.  There is no reason people in the ServiceMix
> > couldn't also work on a BPEL project.  But if we goes through with
> > this as proposed, and someone wants a BPEL engine, is it going to
> > be necessary to take all of ServiceMix along with it?
> Not at all.
> To use an analogy from Geronimo. You can reuse the Transaction
> Manager inside Geronimo by itself without anything else from
> Geronimo. Everything developed within the Geronimo PMC is modular;
> you can use what you like. Modularity and reuse is a given on all the
> Geronimo projects I'm aware of (which is most of it).
> Geronimo benefited greatly from one project to define the kernel, the
> container, the transaction manager and the other components together
> by one cohesive team - then running the TCKs on it all - than having
> lots of little projects. I think the JBI community (container,
> components, routers and orchestrators of componentes) can get the
> same benefit of community growth.
> > What
> > about versioning?  Is the idea that the BPEL bit within ServiceMix
> > would be versioned/released separately?  Or only when the thing
> > of which it is a part is released?
> I prefer frequent releases of everything in a project as often as
> possible personally but I'm sure if there's a need we could release
> different modules at different times. Lets let the community decide.
> > If the code is of use to more that ServiceMix, and/or there are
> > people who'd like to work on it but aren't interested in working
> > on any part of what ServiceMix is now, then it makes sense to
> > me that it be a separate project.  As proposed, anyone with an
> > interest only in the BPEL aspect would have to join the ServiceMix
> > community despite a lack of interest in it.
> >
> > This is all hypothetical; I don't know if there *are* people
> > who'd want to work on it but not ServiceMix, and I have
> > to take on faith the remarks that there are other packages
> > that would like a BPEL engine without ServiceMix attached.
> Folks can work on the transaction manager in Geronimo and not worry
> about the rest of it (and thats quite a bit 'rest' :); Similarly I
> see no real harm with anyone joining ServiceMix (we're nice folks
> really :).
> But if the community grows to a large enough size of only-
> orchestration-engine-without-caring-about-JBI people, the Geronimo
> PMC can always reconsider and consider splitting the projects up. But
> that'd be a great problem to have; a large healthy community focussed
> only on orchestration wishing to make its own way. Today we have only
> folks interested in ServiceMix wanting to work on the code there - so
> I'm hoping we can bootstrap the community there first - then who
> knows, lets let the community (under the guidance of the Geronimo
> PMC) decide.
> James
> -------

Davanum Srinivas :

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message