Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <49345304.7000709@javactivity.org>
Date: Mon, 01 Dec 2008 15:11:32 -0600
From: Steve Cohen <scohen@javactivity.org>
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: users@cxf.apache.org
Subject: Re: Grr. Maven.
References: <492AFA41.9090200@comcast.net>
 <C757E206-41E0-4BF1-878B-9D1CF42EB725@bighillsoftware.com>
 <49330EC6.8070007@javactivity.org> <200812011239.31653.dkulp@apache.org>
In-Reply-To: <200812011239.31653.dkulp@apache.org>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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