Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: general@incubator.apache.org
Subject: Re: Apache Wink Proposal
Date: Wed, 22 Apr 2009 16:25:02 -0400
User-Agent: KMail/1.11.2 (Linux/2.6.29-gentoo; KDE/4.2.2; x86_64; ; )
Cc: Greg Truty <gtruty@us.ibm.com>,
 Bryant Luk <bluk@us.ibm.com>,
 Christopher J Blythe <cjblythe@us.ibm.com>,
 Dustin Amrhein <damrhei@us.ibm.com>,
 "Baram, Eliezer" <ebaram@hp.com>,
 elman@hp.com,
 Jesse A Ramos <jramos@us.ibm.com>,
 "Snitkovsky, Martin" <martin.snitkovsky@hp.com>,
 Michael Rheinheimer <rott@us.ibm.com>,
 nadav.fischer@hp.com,
 Nicholas L Gallardo <nlgallar@us.ibm.com>,
 tali.alsaigh-cohen@hp.com,
 tomer.shadi@hp.com
References: 
 <OFD1D0CFA8.8F5B2A29-ON862575A0.005C694D-862575A0.005E1576@us.ibm.com>
 <200904221514.38916.dkulp@apache.org>
 <OF4E89AA30.ADAFA092-ON862575A0.006A7AC3-862575A0.006DC5B8@us.ibm.com>
In-Reply-To: 
 <OF4E89AA30.ADAFA092-ON862575A0.006A7AC3-862575A0.006DC5B8@us.ibm.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200904221625.04512.dkulp@apache.org>


> 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 kits)
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 probably 
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 information.

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 in
> 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 <dkulp@apache.org>
> 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" <ebaram@hp.com>, elman@hp.com, nadav.fischer@hp.com, "Snitkovsky,
> Martin" <martin.snitkovsky@hp.com>, 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 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 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

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