> I think the only option is to split JAXRS and JAXWS into different maven
projects if number of jars/dependencies is a concern.
Or exclude some of the jars from cxf-frontend-jaxrs as I suggested to Willem
? Thus advanced users will just get a couple of extra jars.
William Tam wrote:
>
> If you look at the runtime dependencies, there are not that many. I
> think the only option is to split JAXRS and JAXWS into different maven
> projects if number of jars/dependencies is a concern.
>
> <dependency>
> <groupId>org.apache.camel</groupId>
> <artifactId>camel-core</artifactId>
> </dependency>
>
> <dependency>
> <groupId>org.apache.camel</groupId>
> <artifactId>camel-spring</artifactId>
> </dependency>
>
> <dependency>
> <groupId>commons-logging</groupId>
> <artifactId>commons-logging-api</artifactId>
> </dependency>
>
> <dependency>
> <groupId>org.apache.cxf</groupId>
> <artifactId>cxf-rt-frontend-jaxrs</artifactId>
> <version>${cxf-version}</version>
> </dependency>
>
> <dependency>
> <groupId>org.apache.cxf</groupId>
> <artifactId>cxf-rt-transports-http-jetty</artifactId>
> <version>${cxf-version}</version>
> </dependency>
>
> <dependency>
> <groupId>org.apache.cxf</groupId>
> <artifactId>cxf-rt-frontend-jaxws</artifactId>
> <version>${cxf-version}</version>
> </dependency>
>
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactId>spring-core</artifactId>
> </dependency>
>
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactId>spring-beans</artifactId>
> </dependency>
>
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactId>spring-context</artifactId>
> </dependency>
>
>
> Hadrian Zbarcea wrote:
>> Chill...
>>
>> Christian made a valid point. There are a few *types* of dependencies in
>> Camel:
>> 1. compile dependencies - which cannot be avoided and should be kept to a
>> minimum
>> 2. test runtime dependencies - needed for tests, which again cannot be
>> avoided but should be tagged as such in the pom, and i am pretty sure
>> some dependencies are only needed by tests, so users don't need to drag
>> them along
>> 3. user runtime dependencies - jars not really needed by camel, not even
>> for tests, but which customers may need to use features in the underlying
>> technology abstracted by camel.
>>
>> Since camel intends to abstract a particular technology, how much of
>> abstraction leak is acceptable? That is how much is it reasonable to
>> expect a user to know about the underlying technology (cxf packaging and
>> dependencies in this case) to effectively use it? The cxf guys made a
>> conscious decision a few years back to use fine grained jars, which are
>> small, can be combined in various ways and make cxf more efficient, with
>> a smaller footprint at runtime and probably faster. Definitely good
>> things for cxf. Does this make things more complicated for Camel? Of
>> course it does. Unfortunately there's no easy solution. Some advanced
>> users, like Christian, would want the optimized minimum, others would
>> prefer the convenience of "throw them all in there and camel will load
>> what it needs".
>>
>> Christian, since you brought this up, what do you think a reasonable
>> solution for you would be?
>>
>> Hadrian
>>
>>
>> On Jan 21, 2010, at 5:09 AM, Sergey Beryozkin wrote:
>>
>>
>>>>> 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.
>>>>
>>> ok...
>>>
>>>
>>>> 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.
>>>>
>>>>
>>> So what ? Users use CXF to get a high quality web services support. Some
>>> of these jars are specs, some are needed to let users do advanced
>>> services. Users can exclude the jars they do not need. Camel can have an
>>> axis 1.4 component for users who like Axis.
>>>
>>>
>>>>> 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.
>>>>
>>> ok...
>>>
>>>
>>>>
>>>>> 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.
>>>>
>>> I see...
>>>
>>>
>>>> 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
>>>>
>>
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/Why-does-camel-cxf-need-cxf-rt-frontend-jaxrs-tp27237712p27260617.html
Sent from the Camel Development mailing list archive at Nabble.com.
