incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: Ode / BPEL Donation of BPEL 2.0 Engine
Date Fri, 17 Feb 2006 18:10:50 GMT
Looks like it's time for ode-dev@...

Noel, is that setup yet?

thanks,
dims

On 2/17/06, James Strachan <james.strachan@gmail.com> wrote:
> How about this for an idea of how we can get started (particularly if
> the thought of another Jakarta Commons-like project scared some
> people off :)...
>
> Agila already has 2 codebases inside it today; the original BPM and
> Twister BPEL.
>
> So how about we start the Ode podling with the same structure -
> containing the Sybase and PXE code in separate modules.
>
> Then inside the Ode podling we figure out over time what BPEL stuff
> we can merge etc. Over time the Twister code could merge/move into
> Ode. BPM code from Ode could move into Agila. Or we can merge
> everything into Ode, or Agila can become the BPM project again and
> Ode can be the BPEL project - we'll see, we can figure that out
> later. But the structure from day one would be we'd have a new
> podling with a similar structure to the existing Agila project.
>
> The only issue is users of Sybase or PXE will want milestone builds
> so they can test against the incubating code & to give us feedback
> that things are working etc.  (e.g. we already test against PXE in
> ServiceMix and we want to test against Sybase too and use ServiceMix
> as an integration test case for any work done on the merge).
>
> So we don't really need a full "Jakarta Commons" type project
> structure; just a way to allow some level of independent releases of
> the Sybase & PXE codebases until the day when its all one single
> engine. (The Agila project might want to do this too).
>
> I don't see anything in the current release policies that would
> explicitly prohibit a podling from having, say, 2 different kinds of
> release; say 'ode-pxe' and 'ode-bpe' or whatever we call them.
> http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
>
> Does this structure seem reasonable to everyone?
>
>
> On 17 Feb 2006, at 15:56, James Strachan wrote:
> > On 17 Feb 2006, at 12:58, Sanjiva Weerawarana wrote:
> >> My concern is that the proposed path
> >
> > I wasn't proposing a specific path, just highlighting issues we'll
> > have if we assume the "only one engine" approach.
> >
> >
> >> is one where there's little
> >> convergence in the near term
> >
> > FWIW convergence will happen however many projects we use
> >
> >
> >> and where the single incubating project
> >> releases multiple files on their own schedules. That's fine, but
> >> that's
> >> not one project.
> >
> > It depends on how you define a project.
> >
> > There are many moving pieces; today they are all separate, over
> > time they will merge together in some way.  If we're including the
> > Agila code and maybe the BPEL4People code (if thats separate -
> > haven't looked at it yet), we might have 5 completely different
> > code bases all solving different problems in different ways.
> > Turning those into "one engine" might not be possible any time soon
> > - it might not even make sense to do so ever; at the same time each
> > of these 5+ codebases have users somewhere.
> >
> > I don't think in the grand scheme of things it makes a massive
> > difference how many individual modules we have and at what
> > granularity they are released (by release here I'm not necessarily
> > talking post-incubator official release, I just mean making some
> > kinda milestone that users can actually work with). Most reasonably
> > complex Java software is made up of many modules; often different
> > modules that implement the same feature but in different ways.
> >
> > So we could do this in one project if we allow it to be modular and
> > for the parts to be released (even as a milestone) as and when they
> > are ready & have user demand.
> >
> >
> >> What's the point of being one project if there's no viable plan to
> >> make
> >> the code marry?
> >
> > To unite the community and encourage them to work together and
> > share code.
> >
> > I don't think uniting the community under one project necessarily
> > means that we absolutely must force everything into one unified
> > engine just to release some code to users. e.g. what if we never
> > reach agreement? What if X% of the community want engine A and Y%
> > of the community want engine B - imagine the voting fun when folks
> > try to release B?
> >
> > So I'm wondering if it might make sense to start the incubation
> > process as an umbrella project; we let the code move into whatever
> > modules as we think we need (which will change over time) -
> > including allowing multiple implementations to coexist for however
> > long we think is necessary. Then we let the modules have their own
> > lifecycles and see how we get on. It might be we release everything
> > in one go; or release in N different parts. I don't know the answer
> > yet - I'm just raising a red flag that waiting for complete
> > consensus across 5 different codebases as to what the one-true-
> > engine is just doesn't seem practical.
> >
> > e.g. imagine a Jakarta Commons-like model for a second. Its got
> > lots of modules that do lots of different things all developed
> > under one project by one community; now in the orchestration/
> > correlation/bpel/human workflow space we are hopefully talking a
> > much more focussed and less diverse area than Jakarta Commons -
> > there may only be 1-3 modules (who knows when we start adding
> > tooling and human workflow there may be many modules) - but the
> > general principle of different modules that live on their own, yet
> > developed by the community at large - could work well here.
> >
> > Over time I hope we merge modules together and promote code reuse;
> > it may be we need to diversify too (e.g. different persistence
> > modules, state machines v pi calculus etc). If the community
> > decides to split off a piece (like commons-httpclient) then that's
> > all well and good - but generally the community works together and
> > we share code & ideas incrementally without forcing "one engine".
> >
> > If we don't go for some kind of umbrella project then I'd suggest
> > starting things with separate podlings to begin with and then
> > seeing where the common areas for reuse lie during the incubation
> > process. But given the problem space I think an umbrella-style
> > project (restricted to all things orchestration/correlation/bpel/
> > workflow) could well work.
> >
> > One of the aims of the incubator is to develop communities; why
> > don't we start with one community with the goal to make
> > orchestration/bpel/workflow software in a single project, import
> > all the modules, let each module have its own lifecycle and see
> > what happens. Then further down the road we can start deciding
> > whether or not we should split parts of into separate podlings or
> > not. I think its gonna take quite a bit of incubation before we
> > really know what all the parts are gonna be - so why don't we stay
> > as flexible as we can be in the early stages of incubation and see
> > what happens? We then can always change our minds further down the
> > line once we've had a chance to work together as a community on the
> > code.
> >
> >
> >> I of course know the task is complex and indeed was
> >> quite surprised when everyone was willing to say "merge 'em all"
> >
> > I think the desire is more to unite the community together - than
> > to "merge them all into one engine". I'm not sure if anyone
> > seriously thinks there will ever be one single engine for all use
> > cases of orchestration/correlation/BPEL/human workflow; whether or
> > not there is one single engine or several doesn't matter much
> > really - whats more important is we try to work together and share
> > as much code and ideas as possible.
> >
> >
> >> but
> >> there's no point at all in pretending we're merging if the task is
> >> indeed too complex.
> >
> > I think we're all agreed that merging is complex; will take a lot
> > of time and we've no real idea as yet how much code will get merged
> > and what code we'll be left with at the end. Though as well I think
> > we're all agreed that uniting the community together is a good
> > thing too - I just think we need to keep things flexible and modular.
> >
> > BTW its worth mentioning that currently Agila consists of 2
> > completely different code bases existing side-by-side - they have
> > been separate code bases for 1 year or so. So I don't see a problem
> > with starting the incubation process as a single umbrella project -
> > unless folks think it will restrict the ability for us to make
> > milestone releases of the Sybase & PXE code during incubation?
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


--
Davanum Srinivas : http://wso2.com/blogs/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message