On Thu, Jan 21, 2010 at 11:09 AM, Sergey Beryozkin <sbery...@progress.com> 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. >
People doing integration application may very well be accounted for their applications they build and those 3rd part frameworks they chose to use as well. They may very well look into which artifacts they bring into production and license implications using them etc. Also the maturity, quality, activity, etc. for those artifacts as well. Having to go over as few as possible artifacts and using best of breads artifacts is for most people a good thing. Having to trim down from a high number of artifacts may be a time consuming tasks. How can you verify in a reliable manner which artifacts you can trim? Not everybody is maven ninjas or using maven at all. And how do you manage using the most stable of all those jars as well? Project X may by default include older releases containing bugs which could affect your application etc. I will consider it a drawback for product X if it depends on a high number of artifacts. If it did I would like to see some documentation which explains in details why all those artifacts is needed. And if possible which ones are needed in which scenarios. Notice this is a general point of view which is targeted for all projects and not specific camel-cxf or CXF. I have been in charge of integration projects where artifacts must be on a "green" list before it can be used etc. And I am sure this practice is still applied out there. So it may not always be possible to use product X because of conflicts which such a "green" list. >> >>> 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 > > -- 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
