Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of claus.ibsen@gmail.com
 designates 209.85.218.221 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=PcLBFxhsPL9MPDBzgho5vxLkOn+m3a9XDiJEBCOsY3uZ49DQLqCUKcXPXfmxuCicoU
         NZasiflEYedFTeLZEVRHR+qiun8ec4z8qNV3LudgjbfQ9O7Vxl1Rzkm+qPuEgM/x7tlG
         3HEPgNao+I9N1EVR1d/wvup9YEv37yc9AVK1s=
MIME-Version: 1.0
In-Reply-To: <007701ca9a7d$bf0a8e50$1f02050a@emea.progress.com>
References: <4B56AF4E.1000008@die-schneider.net>
 <000e01ca99b3$66c28420$1f02050a@emea.progress.com>
	<4B57890F.1060505@die-schneider.net>
 <5380c69c1001202245u5bbf9ad0s83cc4bc70ebfe40a@mail.gmail.com>
	<007701ca9a7d$bf0a8e50$1f02050a@emea.progress.com>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Thu, 21 Jan 2010 10:51:46 +0100
Message-ID: <5380c69c1001210151q6f2452fbg9c7e4cbdca93b22f@mail.gmail.com>
Subject: Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
To: dev@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 21, 2010 at 10:40 AM, Sergey Beryozkin
<sberyozk@progress.com> wrote:
> See comments with S.B
>
>
> On Wed, Jan 20, 2010 at 11:51 PM, Christian Schneider
> <chris@die-schneider.net> wrote:
>>
>> Hi Sergey,
>>
>> I am just concerned with the dependencies jaxrs brings into our projects.
>> The architects from the projects at my company that use camel and cxf
>> complain about the many dependencies needed to simply do web services. So
>> I
>> am constantly searching how to have less dependencies.
>>
>> Currently camel-cxf needs 81 jars.
>> When I remove cxf-rt-transports-http-jetty there are 77 jars left.
>> When I also remove cxf-rt-frontend-jaxrs there are only 63 jars left.
>>
>
> I totally agree that CXF / camel-cxf is a having way way to many
> dependencies out of the box.
>
>> S.B : lets limit the scope of the discussion. Christian has not initiated
>> this thread to complain about the fact CXF brings up to 81 jars in total but
>> rather to raise a valid issue to do with the fact that JAXWS only users get
>> up to 10 jars they don't need.
>

CI: I am entitled to pitch in my opinion that camel-cxf which is
supposed to be a layer on top of pure CXF to bridge Camel with CXF is
using to many jars out of the box. It may be the same if I create a
pure CXF java app where being dependent on cxf-core also loads many
jars which I may not be interested in using.

81 jars is a fact. Camel only adds camel-cxf.jar, camel-core.jar,
camel-spring.jar etc. I assume Christian may or may not have counted
those common Spring jars in there as well. And Camel also deps on
commons-logging and commons-management. And if using JDK1.5 some JAXB
+ Activation stuff. But Camel should not bring in more than 8 or so
jars.

So if I am a JAXWS only user, do I really need 71 jars?
Using the old Axis 1.4 did not bring in 71 jars to use.


> Unfortunately Maven makes it to easy to not think on how many jars. In
> the old days you had to download those .jars yourself and thus you
> would notice if using webservice really needs 81 jars?
>
>> S.B : I'm pretty sure a good persentage of those jars is needed by other
>> camel components too.
>

CI: I really doubt it. The only shared jars would be Spring and
commons-logging, JAXB if using JDK1.5 etc.


> I personally want a lightweight webservice stack where I can choose
> whether or not I want SOAP over JMS, Mail stuff, WS Security, REST
> etc.
>
> In terms of camel-cxf I also think its grew to fat.
>
>> S.B : Really ? Just for fun, how about doing a simple calculation and
>> compare a number of jars CXF brings with the number of jars a Camel-based
>> application of moderate complexity brings ?
>

CI: I think you misunderstood me. I am talking about camel-cxf is fat
in terms of java code.
If you see the number of classes it has to bridge Camel with CXF.
Dan Kulp is also confused why so many classes is needed.

Maybe this should be discussed on a different thread as the original
point about 81 jars has nothing to do
with the number of classes/code in camel-cxf.


> I wonder why thereis so much pluming code in there. I would assume less code
> was needed
> to bridge the Camel agnostic API with the world of CXF.
>
>
>> These are still more dependencies than I would like to have but at least a
>> little better. After removing http-jetty the project still compiles
>> without
>> problems so I guess it could be removed.
>> The jaxrs dependency is currently needed and I guess it is not so easy to
>> remove it.
>>
>> While checking the dependencies I found that the java.net repo is added in
>> camel-cxf. I remember that recently Dan added the jaxb jars to maven
>> central
>> so I think this repo can now be removed. I checked with an empty local
>> repo
>> and was able to build camel-cxf.
>>
>> Greetings
>>
>> Christian
>>
>> Am 20.01.2010 10:31, schrieb Sergey Beryozkin:
>>>
>>>
>>>> Hi all,
>>>>
>>>> I am using the camel-cxf component to attach a jaxws service to camel.
>>>> Unfortunatelly the camel-cxf component also depends on
>>>> cxf-rt-frontend-jaxrs. Is this necessary? It would be nice if this
>>>> depdendency could be removed or made optional.
>>>
>>> Does it cause any issues for you ? Or are you just concerned about extra
>>> module being unnecessarily loaded ?
>>>
>>> I'm not sure it makes sense to introduce another camel component
>>> specifically dedicated to handling cxf-rt-frontend-jaxrs.
>>> Some users may have JAXWS and JAXRS services attached through a single
>>> bean with the help of camel-cxf.
>>>
>>> cheers, Sergey
>>
>> --
>>
>> Christian Schneider
>> ---
>> http://www.liquid-reality.de
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>


-- 
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus