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
