Steve, just so you understand, CXF is more than just another SOAP
stack. In contains a SOAP stack as a component, but it's "oh so much
more" than that. It may be that it provides too much for what you are
trying to do.
That being said, I do sympathize with your initial impression that the
amount of dependencies is overwhelming, and it would be an interesting
exercise to see how much the CXF "kernel" could be pared down to
having a minimal set of dependencies, and then allow you to bolt on
the parts that you need. The current distribution is a bit monolithic
in that sense ("here are all the jars; go for it"), but it's the tool
that launched this thread (maven) that is really what you should be
using to get your minimal set of dependencies; the internal maven
components are all quite modular.
Though note that there have been discussions on this forum that have
advocated for less granularity, than more ("I just want one jar file
-- what's so hard about that?"). Well it is hard, if you have version
x of lib y, but your customer needs to use version z, no ifs ands or
buts.
-Fred
On Dec 1, 2008, at 4:11 PM, Steve Cohen wrote:
Thanks, Daniel, more inline comments below.
Daniel Kulp wrote:
Interesting discussion. Let me jump in here.....
Cause CXF does use it? Most of the wiring of CXF itself is done
with Spring. CXF can provide limited functionality without
spring, but if you want to do any advanced configuration, you're
most likely going to need Spring. Also, the JMS transport now
uses Spring JMS. Thus, if you need soap/jms, you need spring.
Well, fortunately, I don't need soap/jms so I don't need Spring and
am functioning without it. I am surprised that the CXF folks have
made a deliberate decision to depend on Spring or have drifted into
this. I've not used Spring, so I may be guilty of missing the
greatest thing since Sliced Bread, but it sounds like we are walking
into a Brave New World of competing platforms. My memory of Spring
is hearing about it four years ago and what I took home was how
lightweight it all was.
What, for Pete's sake, is Neethi, and why was it necessary to add
it?
Neethi is the WS-Policy implementation. That said, if you aren't
using any policy assertions we probably could somehow make this
optional. That's definitely something we could look into. For
basic soap/http, this could be removable. However, once we start
getting the WS-SecurityPolicy stuff flushed, it would DEFINITELY be
required for that.
The service I am accessing is using Basic Authentication.
This is actually a "problem" with our "common" and "api" modules.
They pull in a bunch of deps that may not be needed if nothing uses
those parts of the apis. Some of these could be marked "provided"
in the api module and then make them runtime/compile scope in the
modules that really need them. (in this case, the ws-policy module)
That would be good.
In all honesty, the difference between server and client side deps
is almost nill. In fact, I cannot think of anything other than
the tooling stuff. You MAY think that Jetty is not client side,
but if you use WS-RM or WS-Addressing, it IS required on the client
side.
The fault there may be with Jetty, then. THEY may have packaged
their client and server stuff together and not allowed for
separation. Again, I thought the point of SOAP was supposed to be
independence of client from server.
One thing that I ran into last week that could be a big help is to
flush out a useful set of Maven archetypes that would be good
"getting started" points for various things. The poms they
produce could be "minimal deps" type things. While working on a
Maven presentation last week, I discovered our single "hello world,
java first" archetype actually didn't work. I've fixed that on
trunk, but it definitely shows there isn't much work done in that
area. We really should have a several archetypes to use as
getting started things. A "jax-rs" archetype. A "wsdl first
client" archetype, a "wsdl first war" archetype, security, etc....
That would be a good start.
Another thing I started but haven't completed was to get things to
work with the versions of various things built into Java 6.
Specifically JAXB. Right now, if using Java6, you can remove
SOME of the jars, but JAXB isn't one of them. On trunk, the
RUNTIME will work with the in-jdk jaxb, but none of the tooling will.
Dan
Still using 1.5, but this would help if we moved up. Corporate
bureaucracy prevents, see Dilbert, etc.
Steve
