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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
James
-------
http://radio.weblogs.com/0112098/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
