cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Cohen <>
Subject Re: Grr. Maven.
Date Mon, 01 Dec 2008 21:11:32 GMT
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.


View raw message