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
