Return-Path: Delivered-To: apmail-incubator-general-archive@www.apache.org Received: (qmail 67982 invoked from network); 28 Apr 2009 05:18:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 28 Apr 2009 05:18:39 -0000 Received: (qmail 37158 invoked by uid 500); 28 Apr 2009 05:18:39 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 36988 invoked by uid 500); 28 Apr 2009 05:18:38 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Delivered-To: moderator for general@incubator.apache.org Received: (qmail 12134 invoked by uid 99); 27 Apr 2009 21:56:43 -0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=EXTRA_MPART_TYPE,HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) From: "Baram, Eliezer" To: Nicholas L Gallardo CC: Bryant Luk , Christopher J Blythe , Daniel Kulp , Dustin Amrhein , "Elman, Michael" , "general@incubator.apache.org" , Greg Truty , Jesse A Ramos , "Snitkovsky, Martin" , Michael Rheinheimer , "Fischer, Nadav" , "Alsaigh Cohen, Tali" , "Shadi, Tomer" Date: Mon, 27 Apr 2009 21:55:17 +0000 Subject: RE: Apache Wink Proposal Thread-Topic: Apache Wink Proposal Thread-Index: AcnHP4f2CS4K+2B1T+6oqyNmEDJ5sAAQGPeQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_E499EAC45BA18F41837F7D97F123D1C952A6684A1AGVW1118EXCame_"; type="multipart/alternative" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_006_E499EAC45BA18F41837F7D97F123D1C952A6684A1AGVW1118EXCame_ Content-Type: multipart/alternative; boundary="_000_E499EAC45BA18F41837F7D97F123D1C952A6684A1AGVW1118EXCame_" --_000_E499EAC45BA18F41837F7D97F123D1C952A6684A1AGVW1118EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sounds like a good plan, that way we will be able to enjoy the good of both= runtimes. The first phase would deal with selecting/merging the runtime, s= table it under the new environment and make sure that the JAX-RS functional= ity is covered and work. The second phase can deal with the stable/adding the additional functionali= ty over the plain JAX-RS, after finishing this part other projects would be= able to enjoy the added value of the Wink runtime. Of course each phase should be delivered with the related documentation and= examples. Looking forward to start the process, Eli From: Nicholas L Gallardo [mailto:nlgallar@us.ibm.com] Sent: Monday, April 27, 2009 4:53 PM To: Baram, Eliezer Cc: Bryant Luk; Christopher J Blythe; Daniel Kulp; Dustin Amrhein; Elman, M= ichael; general@incubator.apache.org; Greg Truty; Jesse A Ramos; Snitkovsky= , Martin; Michael Rheinheimer; Fischer, Nadav; Alsaigh Cohen, Tali; Shadi, = Tomer Subject: RE: Apache Wink Proposal Thanks Eli... We've had some preliminary discussions about the design of each engine, but= I'll be interested to see how similar the approaches are once we're able t= o get the code out. While we wait for feedback, here's a pass at what some of the short term ob= jectives/priorities of the project would be. Comments are encouraged... - We would drop both code bases to separate sections of the repository so e= ach can be built and have their test buckets run. - After some initial comparisons/evaluations we could start building up a c= ommon runtime based on the parts of each that we think are best. The key is= to get a lightweight runtime up that supports basic targeting, databinding= and resource invocation. It will be tricky trying to smash two runtimes to= gether, so I *could* ultimately see one or the other winning out based on h= ow much we're pulling and just adapt from there. I'm not wed to any one des= ign so long as it's light weight, flexible and pluggable. - Once the initial runtime is together, we can start pulling JAX-RS tests f= rom both test buckets and start driving scenarios through and building out = the JAX-RS functionality. That would be enough for a 0.1 to get things started and to see how we woul= d fit in to some of the other projects that would be looking to consume the= Wink runtime. Thoughts? -Nick Nicholas Gallardo WebSphere - WebServices Development nlgallar@us.ibm.com Phone: 512-286-6258 Building: 901 / 5G-016 [cid:image001.gif@01C9C799.87E4EAE0]"Baram, Eliezer" "Baram, Eliezer" 04/26/2009 01:14 AM To Nicholas L Gallardo/Austin/IBM@IBMUS, Daniel Kulp cc Bryant Luk/Austin/IBM@IBMUS, Christopher J Blythe/Raleigh/IBM@IBMUS, Dustin= Amrhein/Austin/IBM@IBMUS, "Elman, Michael" , "general@incuba= tor.apache.org" , Greg Truty/Austin/IBM@IBMUS= , Jesse A Ramos/Austin/IBM@IBMUS, "Snitkovsky, Martin" , Michael Rheinheimer/Austin/IBM@IBMUS, "Fischer, Nadav" , "Alsaigh Cohen, Tali" , "Shadi, Tome= r" Subject RE: Apache Wink Proposal Hi HP started developing the REST SDK about 2.5 yeas ago, at that time there w= as no suitable REST framework that provided the capabilities we were lookin= g for. When decided to join forces with IBM and go open source, the SDK already ex= isted, so the question was where shell we publish it, rewriting it over oth= er SDK does not seemed justified. Looking forward we see the Wink project as something wider than JAX-RS impl= ementation as it addresses also other REST development issues that are not = covered by the JAX-RS specification. Regards, Eli From: Nicholas L Gallardo [mailto:nlgallar@us.ibm.com] Sent: Thursday, April 23, 2009 1:07 AM To: Daniel Kulp Cc: Bryant Luk; Christopher J Blythe; Dustin Amrhein; Baram, Eliezer; Elman= , Michael; general@incubator.apache.org; Greg Truty; Jesse A Ramos; Snitkov= sky, Martin; Michael Rheinheimer; Fischer, Nadav; Alsaigh Cohen, Tali; Shad= i, Tomer Subject: Re: Apache Wink Proposal > If you would have asked the CXF community, we would have been happy to te= ll > you that the JAX-RS implementation has NO DEPENDENCIES on the JAX-WS > implementation. There is a CXF "core" with various personalities layered = on > top. JAX-WS is one personality. JAX-RS is another. (there are others > like the simple frontend, some javascript thingies, etc...) Given Greg's earlier comments, I am assuming he was referring to pulling ou= t the broader web services related code as opposed to just JAX-WS. That sep= aration is clear via CXF's frontend plugin mechanism. Beyond that, we didn't fork the CXF code with the intent of creating a new = Apache project. Moving to Apache was only decided after the decision was ma= de between HP and IBM to work together. For IBM's purposes, we looked at CX= F and felt that the work to tease apart the JAX-RS pieces from the rest of = the core was about the same as redoing a minimal piece of that core work. S= pecifically, doing nothing more than pulling a request in off of a servlet = and feeding it to the JAX-RS utils. Maybe our assessment was wrong, but we = can't change that now. Personally, I think that JAX-RS is just a means to an end. A number of proj= ects outside of Apache provide this support today. If that was the end goal= , I agree there wouldn't be a need for the project. Ultimately, I see this = as an opportunity to focus on the broader spectrum of issues surrounding Ja= va REST service development. JAX-RS is an important piece, but the project = would be more valuable than just that. -Nick Nicholas Gallardo WebSphere - REST & WebServices Development nlgallar@us.ibm.com Phone: 512-838-1182 Building: 901 / 5G-016 [cid:image001.gif@01C9C799.87E4EAE0]Daniel Kulp Daniel Kulp 04/22/2009 03:25 PM To general@incubator.apache.org cc Greg Truty/Austin/IBM@IBMUS, Bryant Luk/Austin/IBM@IBMUS, Christopher J Bly= the/Raleigh/IBM@IBMUS, Dustin Amrhein/Austin/IBM@IBMUS, "Baram, Eliezer" , elman@hp.com, Jesse A Ramos/Austin/IBM@IBMUS, "Snitkovsky, M= artin" , Michael Rheinheimer/Austin/IBM@IBMUS, na= dav.fischer@hp.com, Nicholas L Gallardo/Austin/IBM@IBMUS, tali.alsaigh-cohe= n@hp.com, tomer.shadi@hp.com Subject Re: Apache Wink Proposal > Apache CXF is both a JAX-WS and JAX-RS > implementation. In IBM, our JAX-WS implementation is based on Apache > Axis2. Therefore, it was prohibitive to pull in CXF as part of our > runtime. IBM wanted/needed something smaller - it's as simple as that. ....... > My question back to you is, do you think we can pull out the JAX-WS > capabilities from CXF? If you would have asked the CXF community, we would have been happy to tell you that the JAX-RS implementation has NO DEPENDENCIES on the JAX-WS implementation. There is a CXF "core" with various personalities layered on top. JAX-WS is one personality. JAX-RS is another. (there are others like the simple frontend, some javascript thingies, etc...) Thus, the answer is "yes", we can pull out the JAX-WS stuff as there are no JAX-WS deps. As examples: 1) The Distributed OSGi subproject in CXF uses the bundle that does not include any JAX-WS things. Only the soap stuff and the simple frontend. 2) We DO provide a JAX-RS only "bundle": (maven only, not really in the kit= s) http://repo1.maven.org/maven2/org/apache/cxf/cxf-bundle-jaxrs/2.2/ that was a starting point for providing stripped down runtime. It doesn't include the jaxws stuff, the simple frontend, etc... It's currently probabl= y larger than you want as it does provide support for Aegis databinding as a JAX-RS Provider. (Although for some reason, the soap code is in there, I believe that's a mistake. Need to log a bug....) In anycase, CXF DOES have a history of providing stripped down bundles. However, it's also very modular. If you just want the JAX-RS implementation from maven, just depend on cxf-rt-frontend-jaxrs. That will pull in the stuff it needs and not the jax-ws, ws-* stuff, etc.... Again, engaging with the CXF community would have given you that informatio= n. Dan On Wed April 22 2009 3:59:01 pm Greg Truty wrote: > Dan, > > Let me address both your comments, and then your questions. > > - Both IBM and HP EACH have an implementation of a REST runtime. We are > bringing both. Speaking for the IBM portion, yes - we have something > which is already compliant. Apache CXF is both a JAX-WS and JAX-RS > implementation. In IBM, our JAX-WS implementation is based on Apache > Axis2. Therefore, it was prohibitive to pull in CXF as part of our > runtime. IBM wanted/needed something smaller - it's as simple as that. > Perhaps the answers to your questions may help me position some of this i= n > a better light... > > 1) > a) IBMs implementation is JAX-RS 1.0 compliant. With the fact that there > is now a 1.1 spec - so that's something that needs to be looked at. > b) one of the things that I see that are missing are more in depth > examples for how to use JAX-RS in a RESTful fashion. Getting these > written up can benefit BOTH projects > c) Some of the message body readers/writers (to handle other mime types > and programming models) can be shared among both projects. They should be > portable > d) There is no client programming model in JAX-RS. This is something > which I think is needed as REST services get pushed deeper into the > enterprise (and away from the presentation tier). These will help feed > back changes for a later update to JAX-RS. Look at Jersey, RESTlet, > RESTeasy, CXF (they all offer a client API). > > This may be a naive assumption, but I do think there are opportunities to > share capabilities amongst the 2 projects - even letting them pull code > back and forth. > > HP was also working on JAX-RS compliance for their implementation (so - > again), it would be a melding of the various runtimes (in a lighter > fashion). > > 2) 1b, c, d) are examples which we should be able to agree - or get very > very close on. Whether we can get to a single implementation (I don't > know). If we can figure out how to tease them apart into pieces - > perhaps. I haven't, myself, seen the HP code (but our IBM participants > are willing to do whatever it takes to try and quickly come to a joint > resolution between the 2 runtimes). > > Getting the various teams together at an ApacheCon is a great idea (but > given the current economic times), I don't know how much it's immediately > practical. I'm think the first step is to at least get things on the > table (i.e. code contributed, discussions formulated, to see how > close/apart we really are) - and go from there. > > My question back to you is, do you think we can pull out the JAX-WS > capabilities from CXF? > > Regards... Greg > > Greg Truty > WebSphere Web Services and REST Architect, IBM Austin > EMail: gtruty@us.ibm.com > Phone: (ext) (512) 286-8985 > (Tie) 363-8985 > > > > From: > Daniel Kulp > To: > general@incubator.apache.org > Cc: > Greg Truty/Austin/IBM@IBMUS, Nicholas L Gallardo/Austin/IBM@IBMUS, Dustin > Amrhein/Austin/IBM@IBMUS, Bryant Luk/Austin/IBM@IBMUS, Jesse A > Ramos/Austin/IBM@IBMUS, Christopher J Blythe/Raleigh/IBM@IBMUS, "Baram, > Eliezer" , elman@hp.com, nadav.fischer@hp.com, "Snitkovsky= , > Martin" , tali.alsaigh-cohen@hp.com, > tomer.shadi@hp.com, Michael Rheinheimer/Austin/IBM@IBMUS > Date: > 04/22/2009 02:15 PM > Subject: > Re: Apache Wink Proposal > > On Wed April 22 2009 1:07:39 pm Greg Truty wrote: > > Hello all, I would like to formally present the incubator proposal for > > Apache Wink, stand-alone REST toolkit supporting JAX-RS (JSR 311), a > > client runtime and test cases (as well as other items). The full > > proposal > > > can be found on the wiki at: > > http://wiki.apache.org/incubator/WinkProposal > > > . We are looking forward to all questions and feedback, positive or > > negative. In addition, we welcome all participants and mentors to help > > support the effort. > > I know you are expecting a response from me (I've talked to Dims about > this > already) so I might as well get it out of the way.... :-) > > So, basically, you wanted a JAX-RS implementation. You looked at Apache > CXF > but it didn't completely meet your needs. Instead of engaging with CXF > (there wasn't any discussion about any of this on the CXF dev/users list) > to > enhance CXF, you fork it in house and update it and enhance it outside of > any > community. Now you want to push it back into Apache, but not with any of > the > CXF community. I just wanted to get that out in the open. Two > implementations isn't a bad thing (think Axis2 and CXF) but the way this > was > approached is a concern. > > Next come the hard questions: > 1) The proposal mentions it's already JAX-RS TCK compliant. From a > JAX-RS > standpoint, were do you see the community "growing"? I've seen several > projects that come in with their stated goals already "complete" and have > a > tough time getting new committers. > > 2) What "advantages" would it have over CXF's implementation and/or > Jersey? > (apart from the TCK compliance which CXF is working on now that we got th= e > > TCK) Since Wink would be Apache licensed, I'd expect anything "cool" > would be > pulled into CXF anyway if possible. One advantage of multiple Apache > licensed implementations is that great ideas can also be pulled back and > forth. :-) Obviously, I haven't seen the Wink code so I don't > know > how easy/hard that would be. > > One "question" I have when I see projects with duplicate goals is to see > if > the differences could be resolved to a point where only one project is > needed. > I remember with CXF and Axis 2 sitting down in a room at some conference > several years ago (ApacheCon Austin maybe? Don't really remember.) with > Dan > Diephouse, myself, Glen Daniels, Sanjiva and several others involved with > both > projects to try and resolve any issues and possibly merge things. In > that > meeting, we really did conclude we had strong differences in opinions on > designs, priorities, and ideas and it really wasn't possible. That is > quite > OK. At least the discussion occurred. I haven't seen discussions > like > that with CXF/Wink. > > > I guess from my standpoint, while I'm not "against" the proposal, I'd > definitely like to see it have the option of "graduating" via a merger > with > the CXF implementation and engagements with that community. -- Daniel Kulp dkulp@apache.org http://www.dankulp.com/blog --_000_E499EAC45BA18F41837F7D97F123D1C952A6684A1AGVW1118EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sounds like a good plan, that way we will be able to e= njoy the good of both runtimes. The first phase would deal with selecting/mergin= g the runtime, stable it under the new environment and make sure that the JAX= -RS functionality is covered and work.

The second phase can deal with the stable/adding the additional functionality over the plain JAX-RS, after finishing this part o= ther projects would be able to enjoy the added value of the Wink runtime.

Of course each phase should be delivered with the rela= ted documentation and examples.

Looking forward to start the process,

Eli

 

 

From: Nicholas L Ga= llardo [mailto:nlgallar@us.ibm.com]
Sent: Monday, April 27, 2009 4:53 PM
To: Baram, Eliezer
Cc: Bryant Luk; Christopher J Blythe; Daniel Kulp; Dustin Amrhein; Elman, Michael; general@incubator.apache.org; Greg Truty; Jesse A Ramos; Snitkovsky, Martin; Michael Rheinheimer; Fischer, Nadav; Alsaigh Cohen, Tal= i; Shadi, Tomer
Subject: RE: Apache Wink Proposal

 

Thanks Eli...

We've had some preliminary discussions about the design of each engine, but I'll be interested to see how similar the approaches are once we're able to= get the code out.

While we wait for feedback, here's a pass at what some of the short term objectives/priorities of the project would be. Comments are encouraged...
- We would drop both code bases to separate sections of the repository so e= ach can be built and have their test buckets run.

- After some initial comparisons/evaluations we could start building up a common runtime based on the parts of each that we think are best. The key i= s to get a lightweight runtime up that supports basic targeting, databinding and resource invocation. It will be tricky trying to smash two runtimes togethe= r, so I *could* ultimately see one or the other winning out based on how much we're pulling and just adapt from there. I'm not wed to any one design so l= ong as it's light weight, flexible and pluggable.

- Once the initial runtime is together, we can start pulling JAX-RS tests f= rom both test buckets and start driving scenarios through and building out the JAX-RS functionality.

That would be enough for a 0.1 to get things started and to see how we woul= d fit in to some of the other projects that would be looking to consume the W= ink runtime.

Thoughts?

-Nick



Nicholas Gallardo
WebSphere - WebServices Development
nlgallar@us.ibm.com
Phone: 512-286-6258
Building: 901 / 5G-016
3D"Inactive"Baram, Eliezer" <ebaram@hp.com>

"Baram, Eliezer" <ebaram@hp.com>

04/26/200= 9 01:14 AM

To


Nicholas L Gallardo/Austin/IBM@IBMUS, = Daniel Kulp <dkulp@apache.org>

cc


Bryant Luk/Austin/IBM@IBMUS, Christoph= er J Blythe/Raleigh/IBM@IBMUS, Dustin Amrhein/Austin/IBM@IBMUS, "Elman, Michael" <elman@hp.com>, "general@incubator.apache.org" <general@incubator.apache.org>, Greg Truty/Austin/IBM@IBMUS, Jess= e A Ramos/Austin/IBM@IBMUS, "Snitkovsky, Martin" <martin.snitkovsky@hp.com>, Michael Rheinheimer/Austin/IBM@IBMUS, "Fischer, Nadav" <nadav.fischer@hp.com>, "Alsaigh Cohen, Tali" <tali.alsaigh-cohen@hp.com>, "Shadi, Tomer" <tomer.shadi@hp.com>

Subject


RE: Apache Wink Proposal

 


Hi
HP started developing the REST SDK about 2= .5 yeas ago, at that time there was no suitable REST framework that provided t= he capabilities we were looking for.
When decided to join forces with IBM and g= o open source, the SDK already existed, so the question was where shell we publish= it, rewriting it over other SDK does not seemed justified.
Looking forward we see the Wink project as something wider than JAX-RS implementation as it addresses also other REST development issues that are not covered by the JAX-RS specification.=
Regards,
Eli

From: Nicholas L Gallardo [mailto:nlgallar@us.ibm.com]
Sent: Thursday, April 23, 2009 1:07 AM
To: Daniel Kulp
Cc: Bryant Luk; Christopher J Blythe; Dustin Amrhein; Baram, Eliezer; Elman, Michael; general@incubator.apache.org; Greg Truty; Jesse A Ramos; Snitkovsky, Martin; Michael Rheinheimer; Fischer, Nadav; Alsaigh Cohen, Tal= i; Shadi, Tomer
Subject: Re: Apache Wink Proposal

> If you would have asked t= he CXF community, we would have been happy to tell
> you that the JAX-RS implementation has NO DEPENDENCIES on the JAX-WS <= br> > implementation. There is a CXF "core" with various personali= ties layered on
> top. JAX-WS is one personality. JAX-RS is another. (there are others <= br> > like the simple frontend, some javascript thingies, etc...)

Given Greg's earlier comments, I am assuming he was referring to pulling ou= t the broader web services related code as opposed to just JAX-WS. That separation is clear via CXF's frontend plugin mechanism.

Beyond that, we didn't fork the CXF code with the intent of creating a new Apache project. Moving to Apache was only decided after the decision was ma= de between HP and IBM to work together. For IBM's purposes, we looked at CXF a= nd felt that the work to tease apart the JAX-RS pieces from the rest of the co= re was about the same as redoing a minimal piece of that core work. Specifical= ly, doing nothing more than pulling a request in off of a servlet and feeding i= t to the JAX-RS utils. Maybe our assessment was wrong, but we can't change that = now.

Personally, I think that JAX-RS is just a means to an end. A number of proj= ects outside of Apache provide this support today. If that was the end goal, I a= gree there wouldn't be a need for the project. Ultimately, I see this as an opportunity to focus on the broader spectrum of issues surrounding Java RES= T service development. JAX-RS is an important piece, but the project would be more valuable than just that.

-Nick



Nicholas Gallardo
WebSphere - REST & WebServices Development
nlgallar@us.ibm.com
Phone: 512-838-1182
Building: 901 / 5G-016
3D"InactiveDaniel Kulp <dkulp@apache.org>=

Daniel Kulp <dkulp@apache.org>

04/22/2009 03:25 PM

To


general@incubator.apache.org

cc


Greg Truty/Austin/IBM@IBMUS, Bryant Luk/Austin/IBM@IBMUS, Christopher J Blythe/Raleigh/IBM@IBMUS, Dustin Amrhein/Austin/IBM@IBMUS, "Baram, Eliezer" <ebaram@hp.com>, elman@hp.com, Jesse A Ramos/Austin/IBM@IBMUS, "Snitkovsky, Martin" <martin.snitkovsky@hp.com>, Michael Rheinheimer/Austin/IBM@IBMUS, nadav.fischer@hp.com, Nicholas L Gallardo/Austin/IBM@IBMUS, tali.alsaigh-cohen@hp.com, tomer.shadi@hp.com

Subject


Re: Apache Wink Proposal

 



> Apache CXF is both a JAX-WS and JAX-RS
> implementation. In IBM, our JAX-WS implementation is based on Apache > Axis2. Therefore, it was prohibitive to pull in CXF as part of our
> runtime. IBM wanted/needed something smaller - it's as simple as that.=
.......
> My question back to you is, do you think we can pull out the JAX-WS > capabilities from CXF?

If you would have asked the CXF community, we would have been happy to tell=
you that the JAX-RS implementation has NO DEPENDENCIES on the JAX-WS
implementation. There is a CXF "core" with various personalities layered on
top. JAX-WS is one personality. JAX-RS is another. (there are others
like the simple frontend, some javascript thingies, etc...)

Thus, the answer is "yes", we can pull out the JAX-WS stuff as th= ere are no
JAX-WS deps. As examples:

1) The Distributed OSGi subproject in CXF uses the bundle that does not include any JAX-WS things. Only the soap stuff and the simple frontend.
2) We DO provide a JAX-RS only "bundle": (maven only, not really = in the kits)
http://repo1.maven.org/maven2/org/apach= e/cxf/cxf-bundle-jaxrs/2.2/
that was a starting point for providing stripped down runtime. It doesn't <= br> include the jaxws stuff, the simple frontend, etc... It's currently probabl= y
larger than you want as it does provide support for Aegis databinding as a =
JAX-RS Provider. (Although for some reason, the soap code is in there, I believe that's a mistake. Need to log a bug....)

In anycase, CXF DOES have a history of providing stripped down bundles. However, it's also very modular. If you just want the JAX-RS implementation=
from maven, just depend on cxf-rt-frontend-jaxrs. That will pull in the stuff it needs and not the jax-ws, ws-* stuff, etc....

Again, engaging with the CXF community would have given you that informatio= n.

Dan



On Wed April 22 2009 3:59:01 pm Greg Truty wrote:
> Dan,
>
> Let me address both your comments, and then your questions.
>
> - Both IBM and HP EACH have an implementation of a REST runtime. We ar= e
> bringing both. Speaking for the IBM portion, yes - we have something > which is already compliant. Apache CXF is both a JAX-WS and JAX-RS
> implementation. In IBM, our JAX-WS implementation is based on Apache > Axis2. Therefore, it was prohibitive to pull in CXF as part of our
> runtime. IBM wanted/needed something smaller - it's as simple as that.=
> Perhaps the answers to your questions may help me position some of thi= s in
> a better light...
>
> 1)
> a) IBMs implementation is JAX-RS 1.0 compliant. With the fact that the= re
> is now a 1.1 spec - so that's something that needs to be looked at. > b) one of the things that I see that are missing are more in depth
> examples for how to use JAX-RS in a RESTful fashion. Getting these
> written up can benefit BOTH projects
> c) Some of the message body readers/writers (to handle other mime type= s
> and programming models) can be shared among both projects. They should= be
> portable
> d) There is no client programming model in JAX-RS. This is something > which I think is needed as REST services get pushed deeper into the > enterprise (and away from the presentation tier). These will help feed=
> back changes for a later update to JAX-RS. Look at Jersey, RESTlet, > RESTeasy, CXF (they all offer a client API).
>
> This may be a naive assumption, but I do think there are opportunities= to
> share capabilities amongst the 2 projects - even letting them pull cod= e
> back and forth.
>
> HP was also working on JAX-RS compliance for their implementation (so = -
> again), it would be a melding of the various runtimes (in a lighter > fashion).
>
> 2) 1b, c, d) are examples which we should be able to agree - or get ve= ry
> very close on. Whether we can get to a single implementation (I don't<= br> > know). If we can figure out how to tease them apart into pieces -
> perhaps. I haven't, myself, seen the HP code (but our IBM participants=
> are willing to do whatever it takes to try and quickly come to a joint=
> resolution between the 2 runtimes).
>
> Getting the various teams together at an ApacheCon is a great idea (bu= t
> given the current economic times), I don't know how much it's immediat= ely
> practical. I'm think the first step is to at least get things on the > table (i.e. code contributed, discussions formulated, to see how
> close/apart we really are) - and go from there.
>
> My question back to you is, do you think we can pull out the JAX-WS > capabilities from CXF?
>
> Regards... Greg
>
> Greg Truty
> WebSphere Web Services and REST Architect, IBM Austin
> EMail: gtruty@us.ibm.com
> Phone: (ext) (512) 286-8985
> (Tie) 363-8985
>
>
>
> From:
> Daniel Kulp <dkulp@apache.org>
> To:
> general@incubator.apache.org
> Cc:
> Greg Truty/Austin/IBM@IBMUS, Nicholas L Gallardo/Austin/IBM@IBMUS, Dus= tin
> Amrhein/Austin/IBM@IBMUS, Bryant Luk/Austin/IBM@IBMUS, Jesse A
> Ramos/Austin/IBM@IBMUS, Christopher J Blythe/Raleigh/IBM@IBMUS, "= Baram,
> Eliezer" <ebaram@hp.com>, elman@hp.com, nadav.fischer@hp.co= m, "Snitkovsky,
> Martin" <martin.snitkovsky@hp.com>, tali.alsaigh-cohen@hp.c= om,
> tomer.shadi@hp.com, Michael Rheinheimer/Austin/IBM@IBMUS
> Date:
> 04/22/2009 02:15 PM
> Subject:
> Re: Apache Wink Proposal
>
> On Wed April 22 2009 1:07:39 pm Greg Truty wrote:
> > Hello all, I would like to formally present the incubator proposa= l for
> > Apache Wink, stand-alone REST toolkit supporting JAX-RS (JSR 311)= , a
> > client runtime and test cases (as well as other items). The full<= br> >
> proposal
>
> > can be found on the wiki at:
>
> http://wiki.apache.org/incubator/WinkPr= oposal
>
> > . We are looking forward to all questions and feedback, positive = or
> > negative. In addition, we welcome all participants and mentors to help
> > support the effort.
>
> I know you are expecting a response from me (I've talked to Dims about=
> this
> already) so I might as well get it out of the way.... :-)
>
> So, basically, you wanted a JAX-RS implementation. You looked at Apach= e
> CXF
> but it didn't completely meet your needs. Instead of engaging with CXF=
> (there wasn't any discussion about any of this on the CXF dev/users li= st)
> to
> enhance CXF, you fork it in house and update it and enhance it outside= of
> any
> community. Now you want to push it back into Apache, but not with any = of
> the
> CXF community. I just wanted to get that out in the open. Two
> implementations isn't a bad thing (think Axis2 and CXF) but the way th= is
> was
> approached is a concern.
>
> Next come the hard questions:
> 1) The proposal mentions it's already JAX-RS TCK compliant. From a
> JAX-RS
> standpoint, were do you see the community "growing"? I've se= en several
> projects that come in with their stated goals already "complete&q= uot; and have
> a
> tough time getting new committers.
>
> 2) What "advantages" would it have over CXF's implementation and/or
> Jersey?
> (apart from the TCK compliance which CXF is working on now that we got= the
>
> TCK) Since Wink would be Apache licensed, I'd expect anything "cool"
> would be
> pulled into CXF anyway if possible. One advantage of multiple Apache > licensed implementations is that great ideas can also be pulled back a= nd
> forth. :-) Obviously, I haven't seen the Wink code so I don't
> know
> how easy/hard that would be.
>
> One "question" I have when I see projects with duplicate goa= ls is to see
> if
> the differences could be resolved to a point where only one project is=
> needed.
> I remember with CXF and Axis 2 sitting down in a room at some conferen= ce
> several years ago (ApacheCon Austin maybe? Don't really remember.) wit= h
> Dan
> Diephouse, myself, Glen Daniels, Sanjiva and several others involved w= ith
> both
> projects to try and resolve any issues and possibly merge things. In > that
> meeting, we really did conclude we had strong differences in opinions = on
> designs, priorities, and ideas and it really wasn't possible. That is<= br> > quite
> OK. At least the discussion occurred. I haven't seen discussions
> like
> that with CXF/Wink.
>
>
> I guess from my standpoint, while I'm not "against" the proposal, I'd
> definitely like to see it have the option of "graduating" vi= a a merger
> with
> the CXF implementation and engagements with that community.

--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

--_000_E499EAC45BA18F41837F7D97F123D1C952A6684A1AGVW1118EXCame_-- --_006_E499EAC45BA18F41837F7D97F123D1C952A6684A1AGVW1118EXCame_--