James,
I'm afraid I'm not as familiar with JBI as I probably should be (which is
to say not at all). Would leveraging JBI to do Ode's heavy lifting
introduce a dependency on ServiceMix and/or JBI into Ode, or is it merely a
Java-based interface to BPEL, along the lines of JDBC or JNDI?
Thanks,
On 17 Feb 2006, at 16:17, [EMAIL PROTECTED] wrote:
Thanks, James. I appologize if I am being overly dense... :)
So, to summarize my understanding:
1) JBI defines a number of services that are required to support
process
integration/service orchestration/what have you
It defines an API, co
Thanks, James. I appologize if I am being overly dense... :)
So, to summarize my understanding:
1) JBI defines a number of services that are required to support process
integration/service orchestration/what have you
2) Those same same services will not be incorporated into Apache Ode proper
3)
On 16 Feb 2006, at 23:44, [EMAIL PROTECTED] wrote:
James,
I'm afraid I'm not as familiar with JBI as I probably should be
(which is
to say not at all). Would leveraging JBI to do Ode's heavy lifting
introduce a dependency on ServiceMix and/or JBI into Ode, or is it
merely a
Java-based int
A BPEL engine is integrated within JBI using a JBI component.
In such a case, the BPEL engine should only communicate
with the JBI bus (excluding direct http calls or whatever else).
The JBI container is really a container which communicates
with a component using a set of specified interfaces, bu
Yes, we appear to be to a point where we can move the Ode project forward on
its own merit if the vote supports it and at that point get to an objective
criteria for determining how to work out the internal details. I'm
specifically avoiding judgements about the merit of any overlapping
implementa
I'm not sure it's consensus - more a case of folks getting fed up
with the petty arguing and just want to get things done.
On 16 Feb 2006, at 08:54, Matthieu Riou wrote:
I'm really glad to finally see a consensus emerging!
Matthieu.
Bill,> It seems everybody has exhibited a willingness to
I'm really glad to finally see a consensus emerging!
Matthieu.
>Bill,> It seems everybody has exhibited a willingness to work
togetherI agree. And since we've just gotten off the phone, I'll pass
along thatyou have expressed not only a willingness, but a strong
preference that bothyour group and
James Strachan wrote:
> can you please respond to one of the mails asking for whether
> you are ready to remove your -1 so we can release ActiveMQ
I had.
> Why are you trying to merge the ODE proposal into the Agila proposal
> - which was quite different and based around BPM not BPEL? (FWIW
> Sy
Bill,
> It seems everybody has exhibited a willingness to work together
I agree. And since we've just gotten off the phone, I'll pass along that
you have expressed not only a willingness, but a strong preference that both
your group and Intalio's join together in a single community with both cod
Noel, there are really two aspects to what is being discussed here as I
observe it - willingness to work together and the Apache process. It seems
everybody has exhibited a willingness to work together although from their
own particular vantage point of the same elephant :-).
It's all rather inte
Bill,
> we do seem to be coming together in prinicipal but it might be best to
> achieve our "fresh start" in the practical context of Ode given the
> support exhibited by other folks on the submission.
Am I correct that you are willing to see a new project, Ode, formed that
will start with code
Noel
BTW before I start, can you please respond to one of the mails asking
for whether you are ready to remove your -1 so we can release
ActiveMQ; we've been waiting a while for your response...
http://mail-archives.apache.org/mod_mbox/incubator-general/
200602.mbox/[EMAIL PROTECTED]
On 1
On 15 Feb 2006, at 14:48, Lance Waterman wrote:
In the spirit of nailing down criteria, I would agree with;
... avoid the BPEL
engine having to write a container, a deployment model and a suite of
'binding components' to different SOAP stacks, WS-* policies and
transports - together with all the
In the spirit of nailing down criteria, I would agree with;
> ... avoid the BPEL
> engine having to write a container, a deployment model and a suite of
> 'binding components' to different SOAP stacks, WS-* policies and
> transports - together with all the runtime management.
With regard to "runt
On 14 Feb 2006, at 21:38, Matthieu Riou wrote:
Also, I don't at all agree with your comparison of a BPEL Engine to
Geronimo. I would compare it to the transaction manager within
Geronimo. It's a discrete component, and we're not going to take the
best of 20 different projects to make a transact
Hi Matthieu,
I don't think Aaron would disagree with you. Going back to his
transaction manager analogy, a transaction manager is much more
complicated than geronimo the container. Just like a BPLE engine is
much more complicated than a JBI container. The beautiful thing
geronimo and s
Noel, we do seem to be coming together in prinicipal but it might be best to
achieve our "fresh start" in the practical context of Ode given the support
exhibited by other folks on the submission.
In Apache projects address a certain area of concern (e.g., JAXB, BPEL,
CORBA etc.) but they do so in
Bill,
>From what I am reading today between you, Geir, Lance and Mattieu, it seems
that there is an emerging consensus, so if you are all willing, we could add
your team as committers to Agila and import the code base as soon as we have
the software grant (I haven't checked to see if that is alrea
Glad to have you with us Matthieu.
I agree with a lot of your assessment; BPEL is really only part of the
discussion (as being one language for describing interactions with
WSDL-based constructs) while service orchestration is the larger picture.
In that regard, I can understand the transaction m
Aaron Mulder wrote:
On 2/14/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
In the same way that we built Geronimo from "best of breed" J2EE-ish OSS
projects that are out there, I'm sure we could do a similar thing with BPEL.
Maybe do a "bake off" to help find the best codebase, and have the
> How about making a fresh start then... If the Agila people are
> interested, put out a call for any and all other implementations of BPEL
> that might be donated and build a larger community, mixing the best of
> anything that is donated to get the best BPEL engine and community we can?
I would
> Also, I don't at all agree with your comparison of a BPEL Engine to
> Geronimo. I would compare it to the transaction manager within
> Geronimo. It's a discrete component, and we're not going to take the
> best of 20 different projects to make a transaction manager, and I
> don't see why we'd d
On 2/14/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> In the same way that we built Geronimo from "best of breed" J2EE-ish OSS
> projects that are out there, I'm sure we could do a similar thing with BPEL.
>
> Maybe do a "bake off" to help find the best codebase, and have the
> community colla
Lance Waterman wrote:
As one of the Sybase BPEL developers, this certainly sounds reasonable to
me. Perhaps we can start a discussion around what the "bake off" criteria
will look like ( i.e. what BPEL constructs are fully/half/not supported,
what set of unit tests should be supported, etc ...
Bill Flood wrote:
I'm open to what works best. I think the proposal for Ode is in essence a
fresh starting point for a community. Sybase just happened to submit some
code, which may or may not be accepted and that we thought was passable. In
the end, the community has the last say so we welc
As one of the Sybase BPEL developers, this certainly sounds reasonable to
me. Perhaps we can start a discussion around what the "bake off" criteria
will look like ( i.e. what BPEL constructs are fully/half/not supported,
what set of unit tests should be supported, etc ... ). As an example; in
looki
I'm open to what works best. I think the proposal for Ode is in essence a
fresh starting point for a community. Sybase just happened to submit some
code, which may or may not be accepted and that we thought was passable. In
the end, the community has the last say so we welcome that type of open
Bill Flood wrote:
Geir, approaching Agila was our first avenue. We looked at what they had
and I initiated several conversations about donating to that incubator
project.
We offered a base line upon which to build but there did not seem to be any
uptake although both committers said they were
ibution and our
> >>>>> assessment was that their existing code line would take substantial
> >> work
> >>> to
> >>>>> bring it up to where we thought we already were.
> >>>>>
> >>>>> When we looked at ServiceMix, we fou
eared open to a contribution such as ours but one which would
> help us
> > > > > establish a good affinity with the ESB. The Sybase folks working on
> > > this
> > > > > code line will continue to vigorously support the orchestration
> > > compone
ensure that the interfaces remain clean and the build
granular
enough to be reused and hope to work with you in the future.
Best Regards,
Bill
---Original Message---
From: Davanum Srinivas < [EMAIL PROTECTED] >
Subject: Re: Let's rewind!!! (Re: [VOTE] accept donation of
l continue to vigorously support the orchestration
> > component
> > > > and provide help in adjacent areas related to SCA.
> > > >
> > > > At this point, we feel comfortable in our contribution to the
> ServiceMix
> > > > project based
Incidentally Niclas, you might want to check this page on how to reuse the
Geronimo Transaction Manager and JCA container from inside any Spring
application - irrespective of using a J2EE server at all.
http://jencks.org/Transaction+Manager
http://jencks.org/Home
My only agenda is to make softw
Roy - I agree - it's one of Apache's strengths. My disappointment is
that not all the the comments have been helpful or constructive.
BTW - I in no way mean Geir's comments - I just got a bit lazy and
hit the replyTo on his email :)
On 5 Feb 2006, at 22:03, Roy T. Fielding wrote:
On Feb 5,
On Feb 5, 2006, at 1:29 PM, Rob Davies wrote:
The way this 'debate' has continued has been very embarrassing -
It just makes me wonder why anyone would consider donating code to
Apache in the future ...
Because we care enough to have the debate. If anyone wants silence,
they are free to
There is a process for incubation, this is what happens when the
process(es) are by-passed. A well written through and inclusive
proposal would sail thru in a jiffy.
thanks,
-- dims
On 2/5/06, Rob Davies <[EMAIL PROTECTED]> wrote:
> The way this 'debate' has continued has been very embarrassing
The way this 'debate' has continued has been very embarrassing -
It just makes me wonder why anyone would consider donating code to
Apache in the future ...
On 5 Feb 2006, at 21:03, Geir Magnusson Jr wrote:
James Strachan wrote:
We have received the generous donation of a complete and w
These are the dependencies for building and/or using the whole
transaction module.
For example, the geronimo-system, geronimo-core and geronimo-kernel and
geronimo-j2ee dependencies
are mainly needed to build / use the gbeans for the transaction manager.
The jencks project (www.jencks.org) uses
faces remain clean and the build
> granular
> > enough to be reused and hope to work with you in the future.
> >
> > Best Regards,
> >
> > Bill
> >
> >
> > > ---Original Message---
> > > From: Davanum Srinivas <[EMAIL PROTECTED
Niclas,
Although at one time this was true of the transaction manager in
Geronimo, we have done some very minor work to make this optional. I
designed the Geronimo kernel and consider it a design flaw that the
kernel becomes a dependency of the services it manages. This is
something we
On Friday 03 February 2006 23:53, James Strachan wrote:
> The TM is in a single download-able jar all by itself; so you can
> download only what you need. e.g. here's the latest snapshot of just
> the transaction manager...
IMHO, this is a vast exaggeration that is not entirely fair to make, and
On 2/3/06, David Jencks <[EMAIL PROTECTED]> wrote:
> It seems to me that depending where the code comes into Apache
> different groups of people get to work on it from the start:
>
> -- incubator headed to top level project. IIUC basically any apache
> committer including all the servicemix develo
granular
> enough to be reused and hope to work with you in the future.
>
> Best Regards,
>
> Bill
>
>
> > ---Original Message---
> > From: Davanum Srinivas <[EMAIL PROTECTED] >
> > Subject: Re: Let's rewind!!! (Re: [VOTE] accept donation
On 3 Feb 2006, at 16:47, Justin Erenkrantz wrote:
On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote:
community inside a single project with one overall aim (Geronimo for
J2EE, ServiceMix for JBI, Jakarta Commons / WS Commons for utility
code etc) than to have lots of smaller projects.
Is Ser
On 4 Feb 2006, at 01:38, Sanjiva Weerawarana wrote:
I'm going to remove my original -1 from this thread and vote +1 for
it.
My apologies for helping to create this major ruckus. This type of
heated discussion does not help build communities and cross community
interactions that would benefit a
On 3 Feb 2006, at 23:14, David Jencks wrote:
I'm trying to sort out the issues here. As I understand Sybase
wants to donate the code and keep working on it in a community
larger than the Sybase developers working on it :-)
It seems to me that depending where the code comes into Apache
dif
terfaces remain clean and the build
granular
enough to be reused and hope to work with you in the future.
Best Regards,
Bill
---Original Message---
From: Davanum Srinivas <[EMAIL PROTECTED] >
Subject: Re: Let's rewind!!! (Re: [VOTE] accept donation of a
business
process
I'm going to remove my original -1 from this thread and vote +1 for it.
My apologies for helping to create this major ruckus. This type of
heated discussion does not help build communities and cross community
interactions that would benefit all of us in many ways. That is
especially so because thi
ously support the orchestration
> component
> > > and provide help in adjacent areas related to SCA.
> > >
> > > At this point, we feel comfortable in our contribution to the ServiceMix
> > > project based on the positive uptake. Under the rules of meritocracy,
enough to be reused and hope to work with you in the future.
> >
> > Best Regards,
> >
> > Bill
> >
> >
> > > ---Original Message---
> > > From: Davanum Srinivas < [EMAIL PROTECTED] >
> > > Subject: Re: Let'
Alan D. Cabrera wrote:
> Are there risks to making this a TLP, i.e. do we know that there will be
> enough traction to get it out of the incubator on its own? Wouldn't it
> make sense to incubate it in an existing project and if the community
> grows, graduated it to a TLP? I think that we've se
Cc'ing the incubator list since Dims is no longer on the Geronimo and
ServiceMix lists.
Regards,
Alan
On 2/3/2006 2:05 PM, Aaron Mulder wrote:
Holy crap! What a mess this thread is! I'm not used to being like
the cool voice of reason. :)
For my 2 cents, a JBI container without BPEL is a
: Re: Let's rewind!!! (Re: [VOTE] accept donation of a business
process engine into the ServiceMix project)
Sent: 02 Feb '06 21:12
Cory,
Could you please get James' help and draft a complete proposal?
Please see
http://www.google.com/search?hl=en&lr=&sa
to work with you in the future.
>
> Best Regards,
>
> Bill
>
>
> > -------Original Message-------
> > From: Davanum Srinivas <[EMAIL PROTECTED] >
> > Subject: Re: Let's rewind!!! (Re: [VOTE] accept donation of a business
> process engine into the ServiceMix pro
Let's rewind!!! (Re: [VOTE] accept donation of a business
process engine into the ServiceMix project)
> Sent: 02 Feb '06 21:12
>
> Cory,
>
> Could you please get James' help and draft a complete proposal?
>
> Please see
http://www.google.com/search?hl=en&l
I do agree with your point James, communities built around a narrow
scope are harder to grow and attracting new commiters can become
hazardous. However my feeling is that the failure of Agila in
attracting new committers (for now) is mostly due to a lack of public
exposure and not really to BPEL ha
On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote:
> community inside a single project with one overall aim (Geronimo for
> J2EE, ServiceMix for JBI, Jakarta Commons / WS Commons for utility
> code etc) than to have lots of smaller projects.
Is ServiceMix intended to be a TLP, or will it continu
On 3 Feb 2006, at 16:13, Rodent of Unusual Size wrote:
Incidentally its worth looking at other projects at Apache like Agila
and various projects on http://ws.apache.org like EWS, Mirae, Muse,
WSRF, TSIK etc which are kinda quiet, some near dormant. Making
projects too small and too granular can
Ken,
I apologize!!! it's just like hitting your head on a brick wall and
going around in circles.
James,
I hereby remove my -1 on the contrib to ServiceMix. Go ahead and do
anything you want, however you want, i don't care anymore. If Ken or
Noel or any other Geronimo or Incubator PMC member wants
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Strachan wrote:
>
> The TM is in a single download-able jar all by itself; so you can
> download only what you need. e.g. here's the latest snapshot of just
> the transaction manager...
>
> We use the same approach in ServiceMix; we make lo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Davanum Srinivas wrote:
> 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
On 3 Feb 2006, at 15:38, Rodent of Unusual Size wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Strachan wrote:
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 Geron
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Strachan wrote:
>
> 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 l
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
On 3 Feb 2006, at 15:05, Rodent of Unusual Size wrote:
-BEGIN PGP SIGNED MESSAGE-
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 c
Then by all means go ahead with a proposal to the Geronimo PMC asking
to start a new incubation project for BPEL as you say that there is
enough people to work on it. Not a backdoor "patch" to ServiceMix.
BPEL can be used standalone and BPEL was not in scope of ServiceMix. A
BPEL JBI Component is n
I was speaking with my Geronimo PMC hat on thinking in general about
projects within the Geronimo PMC.
James
On 3 Feb 2006, at 14:26, Davanum Srinivas wrote:
James,
you can make those decisions when ServiceMix is a TLP of its own.
Right now it's not.
thanks,
dims
On 2/3/06, James Strachan
James,
you can make those decisions when ServiceMix is a TLP of its own.
Right now it's not.
thanks,
dims
On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote:
> On 3 Feb 2006, at 13:23, James Strachan wrote:
> > On 3 Feb 2006, at 13:02, Davanum Srinivas wrote:
> >> So, bottom line, Please draw u
On 3 Feb 2006, at 13:23, James Strachan wrote:
On 3 Feb 2006, at 13:02, Davanum Srinivas wrote:
So, bottom line, Please draw up a new proposal for a separate
project.
So here's the thing; no-one involved (the folks donating the code
and the committers on the ServiceMix project) want a new p
Actually I'm a bit surprised by the proposal of making the BPEL engine
part of ServiceMix as well. ESBs and orchestration engines work pretty
well with each other, that's agreed, but so do Tomcat and Struts.
I'm working on Agila BPEL and I agree that the Agila community isn't
the most active aroun
James,
"Why don't you join the Agila project then?" is not the right
attitude. we are trying to be constructive.
thanks,
-- dims
On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote:
> On 3 Feb 2006, at 13:45, Paul Fremantle wrote:
> > James
> >
> > I'm sure you want a single strong community aro
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 J
On 3 Feb 2006, at 13:45, Paul Fremantle wrote:
James
I'm sure you want a single strong community around JBI. But a BPEL
is a
specification that is completely independent of JBI and indeed of
Java.
You're talking about the BPEL XML language; I'm talking about a Java
based orchestration en
James
I'm sure you want a single strong community around JBI. But a BPEL is a
specification that is completely independent of JBI and indeed of Java.
If you make the argument that everything that can be potentially used as a
JBI component is part of ServiceMix then you pretty much include every pa
On 3 Feb 2006, at 13:02, Davanum Srinivas wrote:
James,
There are 2 problems:
- As a Geronimo PMC member i feel a BPEL implemenation is out-of-scope
of what i voted for when i +1'ed incubation for ServiceMix.
The proposal for ServiceMix clearly says...
http://wiki.apache.org/incubator/ServiceM
On 2 Feb 2006, at 20:51, Noel J. Bergman wrote:
James Strachan wrote:
Given it fits nicely with the existing ServiceMix incubation
proposal I see no need for a new proposal for a donation of
code to an existing incubating project.
We don't start to incubate a chicken, and then import a barnya
James,
There are 2 problems:
- As a Geronimo PMC member i feel a BPEL implemenation is out-of-scope
of what i voted for when i +1'ed incubation for ServiceMix. I don't
like what's happening and the way you are doing it.
- Secondly, there just isnt enough information to make a decision one
way or a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Strachan wrote:
> On 3 Feb 2006, at 09:18, Sanjiva Weerawarana wrote:
>
>>Absolutely -1: The first time I ever saw any of this topic was
>>Wed, 1 Feb 2006 12:20:32 -0700 (Thu, 01:20 LKT)
>>and now at
>>Thu, 2 Feb 2006 16:22:28 + (22:22 LKT
If I understand correctly, this will be a code donation like
http://incubator.apache.org/ip-clearance/geronimo-762-ibm-console.html.
Regards,
Alan
On 2/2/2006 1:12 PM, Davanum Srinivas wrote:
Cory,
Could you please get James' help and draft a complete proposal?
Please see
http://www.goog
Cory,
Could you please get James' help and draft a complete proposal?
Please see
http://www.google.com/search?hl=en&lr=&safe=off&q=incubator+proposal+site%3Awiki.apache.org&btnG=Search
for a list of proposals, their format and their content.
Once the proposal is ready, please post it to [EMAIL
James Strachan wrote:
> Given it fits nicely with the existing ServiceMix incubation
> proposal I see no need for a new proposal for a donation of
> code to an existing incubating project.
We don't start to incubate a chicken, and then import a barnyard under the
same proposal, just because it fi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Strachan wrote:
>
> We were first voting to see if the servicemix community and geronimo
> PMC were willing to accept the donation. Given it fits nicely with
> the existing ServiceMix incubation proposal I see no need for a new
> proposal
James,
With my Geronimo PMC member hat on. i've already cast my VOTE
(http://marc.theaimsgroup.com/?l=geronimo-dev&m=113889773909505&w=2).
Now that i have your attention :) and i have a bit more information
that i did not have before, but i still think a standalone BPEL
vibrant project is a neces
On 2 Feb 2006, at 18:36, Davanum Srinivas wrote:
Folks,
There is no proposal, there is just a zip, unless someone is a
clairvoyant, we can't figure out things like.
We were first voting to see if the servicemix community and geronimo
PMC were willing to accept the donation. Given it fits nic
On 2 Feb 2006, at 18:27, Rodent of Unusual Size wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greg Wilkins wrote:
+1
I disagree that all contributions must go via the incubator. This is
clearly within the scope of servicemix and there is no need to
develope a community around this code
Folks,
There is no proposal, there is just a zip, unless someone is a
clairvoyant, we can't figure out things like. *PLEASE* CC
[EMAIL PROTECTED]
- Which specific version of the spec is implemented?
- Where are the list of known issues?
- Where is the TODO list?
- Why is Axis version 1.2 RC1 (and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greg Wilkins wrote:
> +1
>
> I disagree that all contributions must go via the incubator. This is
> clearly within the scope of servicemix and there is no need to
> develope a community around this code.
So who's going to be working on it, then? T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rodent of Unusual Size wrote:
> Greg Wilkins wrote:
>
>>I disagree that all contributions must go via the incubator.
>
> Ah, but all contributions of any size require incubator
> involvement to some degree or other.
>
>>This is clearly within the sc
90 matches
Mail list logo
