Hi, Robert --
> there are different paths to unification. it's not always best to sit down
> and try to come up with single grand unification strategy first. equally,
> it's often not best to ignore the question entirely. it is often hard to hit
> on the best design right away and then contrasting
On 2/18/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
>
> Why are you being so negative? Let's try to make it work. If it does
> not then we decide what do next as a PPMC.
i'm not sure that james is being negative: just excitable :)
there are different paths to unification. it's not always bes
Hiram Chirino wrote:
> Davanum Srinivas wrote:
>
> >Why are you being so negative? Let's try to make it work. If it does
> >not then we decide what do next as a PPMC.
>
> I did not know that technical decisions were the responsibilities of
> the PMC/PPMC. Could you explain further?
See
http:/
Technical decisions do not belong to the PMC/PPMC. Nor do they belong
in [EMAIL PROTECTED] Let's get the ball rolling and attack these on
[EMAIL PROTECTED]
On 2/20/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>
> On Feb 18, 2006, at 2:23 PM, Davanum Srinivas wrote:
>
> > Why are you being so negat
On Feb 18, 2006, at 2:23 PM, Davanum Srinivas wrote:
Why are you being so negative? Let's try to make it work. If it does
not then we decide what do next as a PPMC.
I did not know that technical decisions were the responsibilities of
the PMC/PPMC. Could you explain further?
Being negat
Why are you being so negative? Let's try to make it work. If it does
not then we decide what do next as a PPMC.
Being negative for one second...i can safely say that in the worst
case scenario - Sybase and PXE folks do have other choices
(codehaus,sf etc...) as they own the copyright to the code t
2006/2/18, James Strachan <[EMAIL PROTECTED]>:
> > - If we want to release something now, is it ok to have two separate
> > codebases under the same project?
>
> Yes; lots of other projects do this already. (Agila, Axis, Geronimo etc)
Hi James,
I don't understand your example of Geronimo as a pr
> First, what is the goal of the Ode project?
My preference would be on building, striclty speaking, a BPEL engine.
The whole BPM space is cluttered with different paradigms (classic
workflow, orchestration, document-style workflow...) and specs. BPEL
seems to be getting accepted as THE stand
On 18 Feb 2006, at 04:26, Noel J. Bergman wrote:
Replied to on [EMAIL PROTECTED] Please move discussion to that list.
The one comment to which I'll reply in general, as it effects multiple
projects, is:
The only issue is users of Sybase or PXE will want milestone builds
so they can test again
On 17 Feb 2006, at 23:15, Ismael Ghalimi wrote:
Team,
Before we decide to put both codebases under the same project or under
separate projects, I would like to ask a couple of clarifying
questions.
First, what is the goal of the Ode project? Is it to develop an
implementation of the BPEL
Alex Boisvert wrote:
> I would revise my proposition to:
> Apache Ode => Merge of PXE, Sybase BPE and Agila BPEL
> Apache Agila => Merge of Agila workflow and Intalio BPEL4People
> What do people think about this grouping?
Please feel free to pursue this discussion on [EMAIL
Replied to on [EMAIL PROTECTED] Please move discussion to that list.
The one comment to which I'll reply in general, as it effects multiple
projects, is:
> 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
> t
On Friday 17 February 2006 23:56, James Strachan wrote:
> So I'm wondering if it might make sense to start the incubation
> process as an umbrella project;
"Umbrella" doesn't sound right at all to a layman like me.
Use a single trunk, single build root, perhaps many modules, and do the "IBM
st
Team,
Before we decide to put both codebases under the same project or under
separate projects, I would like to ask a couple of clarifying questions.
First, what is the goal of the Ode project? Is it to develop an
implementation of the BPEL specification, or is it to develop a process
engine
Hi Paul
On 17 Feb 2006, at 18:44, Paul Brown wrote:
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
Hi, James --
> 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 :)...
No comment.
> Then inside the Ode podling we figure out over time what BPEL stuff
> we can merge etc. Over t
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
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
ond. 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
m
.
On 2/17/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>
>
>
> From what I understand to the goal of tight embedding of SybaseBPEL to
> the ServiceMix JBI container, it plays to a different audience - one
> that wants to use JBI, and have BPEL included, versus peopl
n the single project
incubation path. That's a path that'll guarantee that the project will
never graduate IMO.
I have no problem saying we're going to incubate three different BPEL
impls at the same time, but I am sure everyone realizes the reality that
that's likely to mean none of
My concern is that the proposed path is one where there's little
convergence in the near term and where the single incubating project
releases multiple files on their own schedules. That's fine, but that's
not one project.
What's the point of being one project if there's no viable plan to make
the
project
incubation path. That's a path that'll guarantee that the project will
never graduate IMO.
I have no problem saying we're going to incubate three different BPEL
impls at the same time, but I am sure everyone realizes the reality
that
that's likely to mean none of
orce them to merge then let's not go down the single project
incubation path. That's a path that'll guarantee that the project will
never graduate IMO.
I have no problem saying we're going to incubate three different BPEL
impls at the same time, but I am sure everyone realizes the
s restriction - why not let the project
release milestones when it feels it has something useful for its
(already existing) user base?
I too greatly prefer the idea of having one BPEL engine (properly
layered ofcourse .. the part that does the core language vs. the part
that does people-facing ac
t one (Apache
BPELd?)
How about adding BPEL as a suffix?
Apache OpenBPEL is out - (OpenBPEL already exists...)
Apache Fielding? :)
geir
Roy T. Fielding wrote:
On Feb 16, 2006, at 10:08 AM, Geir Magnusson Jr wrote:
Could I presume to suggest something as obvious as "Apache BPEL"
Alright, then I would revise my proposition to:
Apache Ode => Merge of PXE, Sybase BPE and Agila BPEL
Apache Agila => Merge of Agila workflow and Intalio BPEL4People
What do people think about this grouping?
alex
Roy T. Fielding wrote:
> On Feb 16, 2006, at 10:08 AM, Geir Magnusson
Though Apache SOAP was a bit before my time...i agree :)
On 2/16/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> On Feb 16, 2006, at 10:08 AM, Geir Magnusson Jr wrote:
>
> > Could I presume to suggest something as obvious as "Apache BPEL" or
> > similar? makes
On Feb 16, 2006, at 10:08 AM, Geir Magnusson Jr wrote:
Could I presume to suggest something as obvious as "Apache BPEL" or
similar? makes it easier for people to grok what we're doing. I
know it's not terribly imaginative, but might make it easy for
people to re
Bill Flood wrote:
>Likewise, human workflow could be built on BPEL I suppose but there are
>other languages that might be mapped into an engine as well. At any rate,
>keeping the human workflow out of the engine scope is probably worth
>thinking about.
>
>
+1. This is w
and
will take some serious effort and cooperation to make that real.
I too greatly prefer the idea of having one BPEL engine (properly
layered ofcourse .. the part that does the core language vs. the part
that does people-facing activities etc.) as there's little benefit in
having multip
It would seem better to think of the (human) workflow in a different scope
as we disect the problem. There are all kinds of issues in Workflow with
forms, etc. that have little to do with the actual orchestration or even
BPEL. Brings to mind MVC.
It might make sense to divide the problem space
This raises an interesting point. Is the goal of the project to produce
a BPEL engine? If so, then we could have separation between BPEL
(processes) and workflow (human tasks). I think this would help
modularity and clarify project focus.
In order words, workflow-related pieces could go
I agree, we'll need to set both codebases in the repository so we can
start the merge process.
In parallel, we also need to determine what we want from the resulting
merge so we can work together in building the new engine.
alex
James Strachan wrote:
> On 16 Feb 2006, at 16:41, Ismael Ghalimi
On 16 Feb 2006, at 16:41, Ismael Ghalimi wrote:
[snip]
Our primary concern moving forward will be whether we start from one
codebase, or try to merge two existing codebases.
From a purely practical perspective, its probably easiest to start
off with the 2 codebases imported (when the IP & sof
Could I presume to suggest something as obvious as "Apache BPEL" or
similar? makes it easier for people to grok what we're doing. I know
it's not terribly imaginative, but might make it easy for people to
recognize it as a BPEL project. (Like "ActiveBPEL")
e payoff from the initial angst.
>
> Is there a consensus to call this joint project Ode? If so, we can go ahead
> with that. Else, if you wanted we could start with "bpel-wg-dev@", so that
> you can immediately start, and leave "Ode" available for use later at
&
primary concern moving forward will be whether we start from one
codebase, or try to merge two existing codebases. We have no preference on
the matter, but would like to be compliant with the 2.0 version of the
specification as soon as possible. Based on personal experience, moving from
BPEL 1.1 to
of
excitement about this possibility, so hopefully something really great will
be the payoff from the initial angst.
Is there a consensus to call this joint project Ode? If so, we can go ahead
with that. Else, if you wanted we could start with "bpel-wg-dev@", so that
you can imm
ms
> >
> > On 2/15/06, Ismael Ghalimi <[EMAIL PROTECTED]> wrote:
> >
> >>Good afternoon,
> >>
> >>My name is Ismael Ghalimi, and I am the CEO of Intalio. Our company
> would be
> >>interested in participating to the Ode project through a don
gt; would be
> > interested in participating to the Ode project through a donation
> > of the PXE
> > BPEL 2.0 engine and the dedication of development resources to the
> > project.
> > The PXE BPEL 2.0 engine is currently licensed under the CPL open
> > sou
Great stuff Ismael!
James
On 15 Feb 2006, at 22:07, Ismael Ghalimi wrote:
Good afternoon,
My name is Ismael Ghalimi, and I am the CEO of Intalio. Our company
would be
interested in participating to the Ode project through a donation
of the PXE
BPEL 2.0 engine and the dedication of
am the CEO of Intalio. Our company would be
interested in participating to the Ode project through a donation of the PXE
BPEL 2.0 engine and the dedication of development resources to the project.
The PXE BPEL 2.0 engine is currently licensed under the CPL open source
license, and has been integrate
Makes since. Thanks for spending the time to explain this to me.
This really helps.
Thanks,
-dain
On Feb 15, 2006, at 6:56 PM, Noel J. Bergman wrote:
Dain,
Since you brought this public, I'll post my response along with you
original email. I hope you don't mind...
I don't, but you mi
Dain,
> Since you brought this public, I'll post my response along with you
> original email. I hope you don't mind...
I don't, but you might have also included my reply. :-)
> There is no need for the Incubator PMC to sponsor. The Geronimo
> PMC will sponsor the project.
As I had replied to
nyway, no need to respond,
I'm just frustrated.
I'm going to try to stay out of the rest of this discussion, but
before I go, I suggest that ALL of you go back to your open source
roots and reexamine this whole situation. There are a very few
people in this discussion that actually
he Incubator PMC to sponsor. The Geronimo
> PMC will sponsor the project.
>
> Thanks for your understanding.
A number of folks here in the Incubator believe it is best to
establish a community with no prior ties, and have repeated that on a
number of occasions (including Sanjiva's a
On Feb 15, 2006, at 3:09 PM, Noel J. Bergman wrote:
Sanjiva,
- Given the, um, strong feelings expressed by so many people about
this
project, how about if we get the Incubator PMC to sponsor this
poddling?
Agreed. That is what I said to the Geronimo PMC, as well. The
Incubator
PMC wi
It's all good news for the community at large!
On 2/15/06, Ismael Ghalimi <[EMAIL PROTECTED]> wrote:
>
> Good afternoon,
>
> My name is Ismael Ghalimi, and I am the CEO of Intalio. Our company would
> be
> interested in participating to the Ode project through a don
Sanjiva,
> - Given the, um, strong feelings expressed by so many people about this
> project, how about if we get the Incubator PMC to sponsor this poddling?
Agreed. That is what I said to the Geronimo PMC, as well. The Incubator
PMC will sponsor the project.
--- Noel
---
to the Ode project through a donation of the PXE
> BPEL 2.0 engine and the dedication of development resources to the project.
> The PXE BPEL 2.0 engine is currently licensed under the CPL open source
> license, and has been integrated into third-party products/projects such as
> Su
Good afternoon,
My name is Ismael Ghalimi, and I am the CEO of Intalio. Our company would be
interested in participating to the Ode project through a donation of the PXE
BPEL 2.0 engine and the dedication of development resources to the project.
The PXE BPEL 2.0 engine is currently licensed under
C but the new proposal changes things
slightly (being a new podling) so to clear things up I've called
another vote.
- Can we please put out a call to other Open source BPEL engines to
join us with their contributions? (ala, Synapse).
Sure, we're open to other contributions and co
On 15 Feb 2006, at 16:31, Sanjiva Weerawarana wrote:
On Wed, 2006-02-15 at 15:56 +, James Strachan wrote:
Dims & Sanjiva
Given your arguments that the Sybase BPEL donation should be in a new
podling rather than part of ServiceMix - I wonder if you'd like to
join us in the ODE prop
ll to other Open source BPEL engines to
join us with their contributions? (ala, Synapse).
- Can we please add people in a phased manner as committers? based on
their patches/energy on the list? (ala, Harmony)
Thanks,
dims
On 2/15/06, James Strachan <[EMAIL PROTECTED]> wrote:
> Dims & Sanj
On Wed, 2006-02-15 at 15:56 +, James Strachan wrote:
> Dims & Sanjiva
>
> Given your arguments that the Sybase BPEL donation should be in a new
> podling rather than part of ServiceMix - I wonder if you'd like to
> join us in the ODE proposal then we can have a uni
Dims & Sanjiva
Given your arguments that the Sybase BPEL donation should be in a new
podling rather than part of ServiceMix - I wonder if you'd like to
join us in the ODE proposal then we can have a united Apache
community with folks from Agila, Geronimo, ServiceMix, & WS
people (who see "defending turf" as okay
behavior).
The solution to erasing those turf lines is to put *everybody* into
the same pool (the BPEL podling) and to put *all* projects outside of
that pool (no special consideration for Geronimo, WS, or whoever).
The more people play turf battle
On 14 Feb 2006, at 01:25, Noel J. Bergman wrote:
Dain Sundstrom wrote:
I think ServiceMix is the perfect home for a BPEL engine. Every
JBI implementation that I am aware of has and integrated
orchestration
engine exposed via the BPEL specification.
If every JBI implementation has an
On 2/13/2006 6:43 PM, Rodent of Unusual Size wrote:
Dain Sundstrom wrote:
Sybase wants to donate to the service-mix community
In other words, they *don't* want to contribute it to Apache.
They want it to go into a specific and particular niche *at*
Apache. Why the specificity? Why d
I'd like to retract this email. I have doubts on both sides of this
and may try to explain them in a clearer way in another message.
My apologies
david jencks
On Feb 13, 2006, at 6:26 PM, David Jencks wrote:
After being nervous for quite a while I have come to think that the
sybase
comes
> directly to the incubator without a sponsoring PMC and must find one
> (which can be the incubator PMC). This is exactly what is happening
> here with the Geronimo PMC.
No, it not what is happening here. If Geronimo sponsored
BPEL as a new podling, *then* it would b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dain Sundstrom wrote:
>
> I think ServiceMix is the perfect home for a BPEL engine. Every JBI
> implementation that I am aware of has and integrated orchestration
> engine exposed via the BPEL specification. I am not worried about
the requesting PMC (and
that PMC must provide people/time/effort to assist). But the process
runs according to the Incubator's rules. It determines what will best
effect the two-job outcome. IP clearance is easy, and that is
happening now. Community is hard, and that's what we're tal
After being nervous for quite a while I have come to think that the
sybase bpel engine should go in as part of servicemix and if further
uses outside servicemix develop we can see about splitting it off.
more comments inline.
On Feb 13, 2006, at 5:25 PM, Noel J. Bergman wrote:
Dain
problems: the battle, and the people (who see "defending turf" as okay
behavior).
The solution to erasing those turf lines is to put *everybody* into
the same pool (the BPEL podling) and to put *all* projects outside of
that pool (no special consideration for Geronimo, WS, or whoever).
Th
s no one saying the service mix community is biased
against new comers. I think it is the exact opposite. They are very
welcoming and I think this is what excited them to donate the code.
This doesn't apply to just BPEL. I had the same reaction to the recent
Ajax proposals. "oh, sur
On Feb 13, 2006, at 5:25 PM, Noel J. Bergman wrote:
I've heard nothing to provide a reason for not bringing in the
contribution
as a standalone podling, which ServiceMix and others can consume.
This
would be in accord with Ken and Mads.
I really detest it when people try to flip the burde
ank, some communities can bias against newcomers. That isn't
right for the ASF, and it *absolutely* is not write for podling
communities within the Incubator.
This doesn't apply to just BPEL. I had the same reaction to the recent
Ajax proposals. "oh, sure, Dojo can come and join this new co
Dain Sundstrom wrote:
> I think ServiceMix is the perfect home for a BPEL engine. Every
> JBI implementation that I am aware of has and integrated orchestration
> engine exposed via the BPEL specification.
If every JBI implementation has an integrated orchestration engine, then we
shou
was there some crosspost dropped here?
Mads Toftum wrote:
On Mon, Feb 13, 2006 at 02:19:56PM -0800, Dain Sundstrom wrote:
If any project inside or outside of Apache wants their own copy
of this code to develop they can always fork the code (as is allowed
by any open source project).
Wh
On Mon, Feb 13, 2006 at 02:19:56PM -0800, Dain Sundstrom wrote:
>If any project inside or outside of Apache wants their own copy
> of this code to develop they can always fork the code (as is allowed
> by any open source project).
>
Whoa! Are you actively suggesting forks inside the same c
After a quick chat with Dims, I think I need to make a quick
correction to this email
On Feb 13, 2006, at 12:42 PM, Dain Sundstrom wrote:
I think ServiceMix is the perfect home for a BPEL engine. Every
JBI implementation that I am aware of has and integrated
orchestration engine
I agree with Dain; let's get the code running in ServiceMix, and then
we can break it off when it's ready to stand alone.
Thanks,
Aaron
On 2/13/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> I think ServiceMix is the perfect home for a BPEL engine. Every JBI
> im
I think ServiceMix is the perfect home for a BPEL engine. Every JBI
implementation that I am aware of has and integrated orchestration
engine exposed via the BPEL specification. I am not worried about
"barriers" to any committers, "accidental too-tight binding" or
x27;s after also considering the following:
1. The full expanded name of BPEL is 'Business Process
Execution Language for Web Services;'
2. We have a TLP devoted to Web Services; and
3. A BPEL engine would be a component useful to
a broader range of projects that just Geronimo.
I didn't see any response to this from the Agila developers. Did
I just miss it? It seems to me that to get Agila & BPEL married
some significant work is necessary .. and obviously that's not
possible without the committment of the Agila developers!
Sanjiva.
- Original Messa
On Nov 15, 2004, at 5:52 AM, Matthieu Riou wrote:
Hi,
I just looked into Agila in detail and thought it might be interesting
to share my remarks and questions. Of course, most of my comments are
related to BPEL compatibility, or what could be changed to ensure that
making Agila BPEL-compliant
Hi,
I just looked into Agila in detail and thought it might be interesting
to share my remarks and questions. Of course, most of my comments are
related to BPEL compatibility, or what could be changed to ensure that
making Agila BPEL-compliant won't be too hairy.
- Right now Agila is pretty
e end, but lets
> >> decide that later. If we have enough size and strength to be a TLP,
> >> we do it. If not, we don't. Until then, lets try and build some
> >> really great software and a great community.
> >> I do think that working to have BPEL implemen
reat software and a great community.
I do think that working to have BPEL implementation at the ASF is a
great idea, and while I'm 100% committed to seeing it a part of
Agila, it doesn't have to only be in Agila. For example, we could
have a BPEL engine as part of the project that can
earn a lot more as time goes
on. I'm optimistic that we'll go that way at the end, but lets decide
that later. If we have enough size and strength to be a TLP, we do
it. If not, we don't. Until then, lets try and build some really
great software and a great community.
I do think
t we'll go that way at the end, but lets decide
that later. If we have enough size and strength to be a TLP, we do it.
If not, we don't. Until then, lets try and build some really great
software and a great community.
I do think that working to have BPEL implementation at the ASF is
it more like umbrella
> TLP with many subprojects? the reason for this is that i have a
> different opinion about BPEL.
>
> i think there is a clear need *now* for apache-licensed BPEL specific
> engine (there is more than one LGPLed)
>
> moreover building a complete BPEL
i agree that TLP is very important and very good for visibility that
apache has now place for workflows but i look on it more like umbrella
TLP with many subprojects? the reason for this is that i have a
different opinion about BPEL.
i think there is a clear need *now* for apache-licensed BPEL
0.10.
> >
> > Paul
> > --
> > Paul Russell
> > E-mail: [EMAIL PROTECTED]
> > iChat/AIM: [EMAIL PROTECTED]
>
> +1 for going forward as one project and for going for a TLP when
> we are ready!
>
> I already know someone who has a prototype of a BPEL edi
r one well-focused TLP.
>
> As ever, just my $0.10.
>
> Paul
> --
> Paul Russell
> E-mail: [EMAIL PROTECTED]
> iChat/AIM: [EMAIL PROTECTED]
+1 for going forward as one project and for going for a TLP when
we are ready
Guys,
On 22 Oct 2004, at 02:13, Geir Magnusson Jr wrote:
On Oct 21, 2004, at 4:20 PM, Sanjiva Weerawarana wrote:
"Geir Magnusson Jr" <[EMAIL PROTECTED]> writes:
I think that bringing the two concepts together - workflow and WS
orchestration - would be a great goal :)
So as a co-
onsider workitems either, even it's often very
useful for end users. I think that's the sort of things you have in
mind Geir. Am I wrong ?
An implementation that wouldn't accept extension would of course be a
very bad one. Supporting BPEL was just a first goal when we
implemented Tw
On Oct 21, 2004, at 10:41 PM, Uijin Hong (홍의진) wrote:
I hope to see Agila(or Apache-BPM-engine)
could run both BPEL and WS-CDL.
+1!
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
-
To
On Fri, 22 Oct 2004 05:20:09 +0600, Sanjiva Weerawarana
<[EMAIL PROTECTED]> wrote:
>
> However, I think there's room in the WS project for an effort
> focused purely on implementing BPEL. BPEL is a key component of
> the WS-* stack and I for one would be happy to see
On Oct 21, 2004, at 4:20 PM, Sanjiva Weerawarana wrote:
"Geir Magnusson Jr" <[EMAIL PROTECTED]> writes:
The goal is to do BPM, not specifically BPEL. BPEL support is
certainly welcome, but should be a part of the overall project, not
the
dominant focus. There's
"Geir Magnusson Jr" <[EMAIL PROTECTED]> writes:
> The goal is to do BPM, not specifically BPEL. BPEL support is
> certainly welcome, but should be a part of the overall project, not the
> dominant focus. There's more to BPM than BPEL :)
Absolutely :).
Howeve
On Oct 21, 2004, at 11:48 AM, Matthieu Riou wrote:
I proposed to combine Twister into Agila to avoid overlapping. I
thought the main goal of Agila was to develop a BPEL engine. Now if
you think it's more appropriate, I wouldn't mind contributing Twister
as itself.
The goal is to d
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 20, 2004 2:52 PM
Subject: Proposition: Twister WS-BPEL engine and Apache Agila
Hello,
I'm the project leader of Twister, an open source WS-BPEL engine. More
can be found about Twister here:
http://www.smartcomps.org/twister
I'm sending
at
> code with Apache Agila ?
>
> Andreas
>
> - Original Message -
> From: "Matthieu Riou" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, October 20, 2004 2:52 PM
> Subject: Proposition: Twister WS-BPEL engine and Apache Agila
&
t;[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, October 20, 2004 2:52 PM
> Subject: Proposition: Twister WS-BPEL engine and Apache Agila
>
>
> > Hello,
> >
> > I'm the project leader of Twister, an open source WS-BPEL engine. Mo
I proposed to combine Twister into Agila to avoid overlapping. I
thought the main goal of Agila was to develop a BPEL engine. Now if
you think it's more appropriate, I wouldn't mind contributing Twister
as itself.
A workflow engine and a web service orchestration engine have a bit of
o
I noticed that Twister is licensed under the LGPL. Is it possible to merge that
code with Apache Agila ?
Andreas
- Original Message -
From: "Matthieu Riou" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 20, 2004 2:52 PM
Subject: Proposition:
Here is another '+1' for having a BPEL engine inside Apache domain.
BTW, is it legitimately possible to combine Twister(which is not
proposed and review by Apache PMC) into Agila?
How about proposing contribution of Twsiter as itself?
On Wed, 20 Oct 2004 15:24:23 -0500, Aleksander
1 - 100 of 113 matches
Mail list logo
