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 >
