Re: Grr. Maven.

[Mick Knutson <mk...@baselogic.com>]

To compile in Maven, you might need to reference all these jars. But you
will not need to deploy all those jars. There are many things behind the
scenes that you don't see that require many other jars than you are used to.
The more you mes with Maven, the more you will totally fall in love with
everything it is providing. Even if you don't understand it right now.

Once you download those jars, they are local and you do NOT have to
re-download everything each time.



On Mon, Nov 24, 2008 at 2:02 PM, Steve Cohen <st...@comcast.net> wrote:

> I am trying to build a client to a web-service using their vendor-supplied
> WSDL.  The vendor-recommended approach is to use Maven with their pom.xml.
>
> building the source code brings in something like 50 jars.  Only three
> appear to be needed for compilation, but at runtime, I am adding jar after
> jar to get my code over each succeeding hurdle.
>
> Is this really the way software is developed now?  Call me old fashioned,
> but I like to know what I'm depending on.  It shouldn't require 50 jars to
> run a simple SOAP client.  What is the thinking behind this?  Must I bite
> the bullet, load all this crap, and stop thinking about it?
>



-- 
Thank You…

Mick Knutson
BASE Logic, inc.
(415) 685-4233

Website: http://baselogic.com
Blog: http://baselogic.com/blog
BLiNC Magazine: http://blincmagazine.com
Linked IN: http://linkedin.com/in/mickknutson
DJ Mick: http://djmick.com
MySpace: http://myspace.com/mickknutson
Vacation Rental: http://tahoe.baselogic.com

coming soon: 866-BLiNC-411: (254-6241-1)
---

Re: Updating the CXF roadmap page

[Daniel Kulp <dk...@apache.org>]

On Wednesday 03 December 2008 12:27:16 pm Rao, Sameer V wrote:
> Hi
>
> The CXF RoadMap page http://cxf.apache.org/roadmap.html still contains
> reference to 2.1.1 and 2.0.7.
> Also the Future version section says some will go in 2.1.x however, the
> SNAPSHOT repo shows next version after 2.1.3 to be 2.2.
>
> Is it possible to get the roadmap updated based on current plans?

I've updated it a little.   It should sync in a couple hours or see the source 
at:
http://cwiki.apache.org/confluence/display/CXF/Roadmap




-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Updating the CXF roadmap page

["Rao, Sameer V" <SR...@amfam.com>]

Hi 

The CXF RoadMap page http://cxf.apache.org/roadmap.html still contains
reference to 2.1.1 and 2.0.7.
Also the Future version section says some will go in 2.1.x however, the
SNAPSHOT repo shows next version after 2.1.3 to be 2.2.

Is it possible to get the roadmap updated based on current plans?



Thanks,
Sameer

Re: Grr. Maven.

[Steve Cohen <sc...@javactivity.org>]

Daniel Kulp wrote:
> On Monday 01 December 2008 12:39:31 pm Daniel Kulp wrote:
>   
>>> 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.
>>     
>
> Actually, the JAX-WS 2.1 spec requires processing of the ws-addressing policy 
> assertions in the wsdl.   Thus, neethi wouldn't be optional for JAX-WS 
> frontend.
>
>
>   
Neethi is the least of my worries.  It's just one jar and seems to 
fulfill one clearly-defined purpose.  But its unusual (and 
non-descriptive) name made it rise to the top of my list of questions 
when I saw that it was required.   My initial reaction was "what the f 
is this Neethi"?

Re: Grr. Maven.

[Daniel Kulp <dk...@apache.org>]

On Monday 01 December 2008 12:39:31 pm Daniel Kulp wrote:
> > 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.

Actually, the JAX-WS 2.1 spec requires processing of the ws-addressing policy 
assertions in the wsdl.   Thus, neethi wouldn't be optional for JAX-WS 
frontend.


-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Grr. Maven.

[Steve Cohen <sc...@javactivity.org>]

Thanks for understanding Fred. I got into CXF when a vendor recommended 
I use it. I was initially quite pleased with the quality of client-side 
code it generated, you know, human-readable and all that. The footprint 
issue only hit me later.

And of course I'm under the gun.

I can't help thinking that a minimum-footprint tool engineered for the 
client side specifically, that generated client-side code of the same 
quality as what CXF generates, would be a wonderful thing.

Web-Service Client-siders merely want to connect to someone else's web 
service. They don't want the fuss, the muss, or the heavy footprint that 
builders of the web services have to be concerned with by necessity. For 
us, the web service is just a tool to do a particular job, like 
Hibernate or Log4j. We tend to rebel when we're told about the 
complexity that needs to happen "behind the scenes". "Shouldn't be my 
problem", we think. We have our own server-side issues to worry about.

If it's impossible for CXF to be that kind of tool, what would you 
recommend instead as the simple but high-quality SOAP-stack I'm looking for?

Steve

Fred Dushin wrote:
> 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
>

Re: Grr. Maven.

[Fred Dushin <fr...@dushin.net>]

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
>

Re: Grr. Maven.

[Steve Cohen <sc...@javactivity.org>]

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

Re: Grr. Maven.

[Daniel Kulp <dk...@apache.org>]

Interesting discussion.   Let me jump in here.....

In the "lib" directory of our distribution, there is a "WHICH_JARS" file which 
lists which jars are required for various bits of functionality: 
http://svn.apache.org/repos/asf/cxf/trunk/distribution/src/main/release/lib/WHICH_JARS

That MAY help a bit.   However, it probably would be good to document what 
each jar really provides and why it's needed.

On Sunday 30 November 2008 5:08:06 pm Steve Cohen wrote:
> My "problem" is more philosophical than anything, and I'm not sure it's
> really a problem.  But, consider that by adding a web service client, a
> small new piece of my application's functionality, the WAR file size has
> ballooned in size from 3MB to over 10MB.  Additionally, as I look at the
> 33 or so jars it was necessary to add to the war in order to get the
> thing to run (and I manually hacked 14 out of the dependencies generated
> by Maven which I found NOT to be needed), I can't say I know what most
> of them do.  Why, for example, was it necessary to include pieces of the
> Spring framework, even though my application doesn't use that
> framework?  

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.


> 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.

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)

> Quite a lot of stuff for the "simple" task of marshalling 
> and unmarshalling data into SOAP-XML packets and sending them across the
> wire.  From their names, it looks as though some of them repeat
> functionality that is available in other jars - but who has time to
> investigate?  I also have a little nagging fear that down the road a few
> weeks, when I have to add my NEXT web service client to this app (and
> this one uses AXIS) I will end up adding another bunch of jars, some of
> which may conflict with the ones just added.
>
> In other words I feel that I've lost control of my application.
>
> Prior to this, I understood my dependencies.  I understand that there's
> a tradeoff here.  In return for letting go of control of my
> dependencies, I have a potentially much simpler and more automated build
> process - and I know that's  a good thing - especially when and if I
> convert the project's entire build process to Maven.  And speaking of
> CXF in particular, I like that the client code I need to write is not
> particularly ugly, as it is with some other SOAP platforms (AXIS - grr
> grr).  But I continue to wonder whether it isn't a problem that Maven
> encourages these chains of dependencies that grow geometrically without
> appropriate consideration to developer understanding being given.  For
> the sake of developer understanding, would it perhaps be a good thing if
> pom.xml dependency elements had a required <comment> element that the
> composer of a POM would have to think about before issuing a POM to the
> world?  Or maybe a newer version of CXF will pare the dependencies down
> to what is truly needed to run client-side and server-side apps.

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.   


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....     


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


>
> <end of rant>
>
> Brad O'Hearne wrote:
> > Steve,
> >
> > So that I understand the problem properly, is your problem that
> > building downloads jars from maven repositories, or that these jars
> > are getting packaged into your WAR file, and you don't want that to
> > happen, due to some proprietary approach to deploying dependencies in
> > your app server environment?
> >
> > Thanks,
> >
> > Brad
> >
> > On Nov 24, 2008, at 4:02 PM, Christian Schneider wrote:
> >> In this case you can perhaps use the following maven plugin.
> >> It copies all jars you depend on into a folder target/lib. This is
> >> probably what you need to build your war file the old way.
> >>
> >>     <plugin>
> >>       <groupId>org.codehaus.mojo</groupId>
> >>       <artifactId>dependency-maven-plugin</artifactId>
> >>       <executions>
> >>         <execution>
> >>           <id>copy-dependencies</id>
> >>           <phase>package</phase>
> >>           <goals>
> >>             <goal>copy-dependencies</goal>
> >>           </goals>
> >>           <configuration>
> >>
> >> <outputDirectory>${project.build.directory}/lib</outputDirectory>
> >>           </configuration>
> >>         </execution>
> >>       </executions>
> >>     </plugin>
> >>
> >> Greetings
> >>
> >> Christian
> >>
> >> Steve Cohen schrieb:
> >>> Yeah, that's where I'm at.
> >>> 1) in a BIG company with a Dilbert-style "Productivity Prevention
> >>> Department" :-)
> >>> 2) on the other hand, in a small, practically invisible backwaterish
> >>> part of the BIG company so that there is nothing like an SCM team,
> >>> application not deployed in data center, etc.
> >>> 3) Preexisting product with preexisting handbuilt war including some
> >>> VERY nonstandard proprietary jars and shared libraries that have to
> >>> be included.
> >>> 4) Deadlines
> >>>
> >>> The chances of rewriting the build process anytime soon to use Maven
> >>> in this context are next to nil, notwithstanding the value that
> >>> Maven nonetheless would undoubtedly provide.
> >>>
> >>> But, since the advantages of using CXF here are great, my temporary
> >>> solution is going to have to be
> >>>
> >>>   * build the test project my vendor has supplied me with maven,
> >>>   * transfer the jars maven downloads for me to another location
> >>>   * build the new war incorporating the old stuff and the now stuff
> >>>
> >>> It would be nice to port the whole mess to Maven but I don't have
> >>> the time for it now.
> >>
> >> --
> >>
> >> Christian Schneider
> >> ---
> >> http://www.liquid-reality.de



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Grr. Maven.

[Andrew Clegg <an...@gmail.com>]

2008/12/1 Christian Schneider <ch...@die-schneider.net>:

> I would vote for making cleaning out dependencies a high priority issue.
> What do other CXF developers think?

Well I'm not a CXF developer (as in a developer *of* CXF) but as a
user I think it's a discussion that should be had.

I raised the subject in October but no-one replied, so I'm going to
take this opportunity to repost below (sorry for the threadjack) as I
had issues similar to Steve's... Grateful for any feedback.

Andrew.

---8<---

Morning all,

I'm working on a sample client app (just a command line thing) to
distribute to our collaborators, to demonstrate usage of our services.

To keep things simple, I've built a single jar using Maven's assembly
plugin, which contains all the dependencies. This weighs in at a not
inconsiderable 9.9Mb, which is quite impressive considering the app
essentially just dispatches a single request to a remote service, and
parses the response payload before printing it in a tabular format. It
doesn't even use databinding.

Is this kind of size normal or have I misconfigured something? Is
there an easy way to reduce this?

Unzipping the jar I find 3.5Mb of Spring, a hefty 11Mb in org/apache,
just over half of which is CXF itself, and another 11Mb in com/sun.

I can't help thinking this won't be a particularly good advert for
Java (and/or CXF) if I distribute it to people who'll say, I can get
exactly the same functionality with half a meg of Perl or Python (or
less)...

I know there are tools like ProGuard and Autojar which can strip out
unused classes from jars, but I'm having problems getting them to work
correctly, and I'm a little worried about how they'll deal with
dynamic class loading, dependency injection etc.

Any thoughts?

Andrew.

Re: Grr. Maven.

[Daniel Kulp <dk...@apache.org>]

On Monday 01 December 2008 9:24:53 am Benson Margulies wrote:
> Unless you need RPC encoding, which Axis preserves and CXF hasn't got.

Just to be clear.....    Axis 1 supports RPC encoding.  Axis 2, like CXF, does 
not.

Dan


>
> On Mon, Dec 1, 2008 at 9:23 AM, Steve Cohen <sc...@javactivity.org> wrote:
> > Christian Schneider wrote:
> >> ...
> >>
> >> BTW. If you have CXF in your project it does not make a lot of sense to
> >> also use Axis. I think you should decide on time for your project which
> >> webservice stack to use and stick with it.
> >
> > I agree with this, basically, but it's a question of time.  I have a CXF
> > client going for one WS and an Axis client going for the other, both with
> > vendor-provided help/sample classes.  I haven't yet tried to put them
> > together into a single application yet.  If you have war stories that can
> > dissuade me from trying, I'd certainly be willing to listen and thankful
> > for it.
> >
> > Steve



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Grr. Maven.

[Brad O'Hearne <br...@bighillsoftware.com>]

A couple of observations:

- This is an issue not isolated to CXF, it is a common issue with any  
API. Take the Java SDK API, for that matter -- over the years I've  
seen this same exact discussion take place about the Java API, and the  
many portions of it that some didn't put to use in their applications,  
and why they had to incur the full size of the runtime libraries in  
their application. And upgrade any packages on Linux lately? Same  
thing there....

- While this may indeed point to documentation issues in CXF, it also  
likely points a little to available time and resource. I'm not sure  
what it takes to decouple all of these libraries from one another, but  
I'm guessing doing so may require a little extra work . It also may be  
related to the easiest and quickest way to bring CXF to the masses  
(but then again, I don't know, maybe not).

- That said, the point of the thread is a good one. Perhaps the  
biggest challenge is determining the common configuration use cases.  
Perhaps if the developers with a longer tenure with CXF could list the  
common configuration scenarios they see, a Maven dependency  
configuration could be accomplished which minimized unneeded excess.

Brad

On Dec 1, 2008, at 7:24 AM, Benson Margulies wrote:

> Unless you need RPC encoding, which Axis preserves and CXF hasn't got.
>
> On Mon, Dec 1, 2008 at 9:23 AM, Steve Cohen <sc...@javactivity.org>  
> wrote:
>> Christian Schneider wrote:
>>>
>>> ...
>>>
>>> BTW. If you have CXF in your project it does not make a lot of  
>>> sense to
>>> also use Axis. I think you should decide on time for your project  
>>> which
>>> webservice stack to use and stick with it.
>>
>> I agree with this, basically, but it's a question of time.  I have  
>> a CXF
>> client going for one WS and an Axis client going for the other,  
>> both with
>> vendor-provided help/sample classes.  I haven't yet tried to put them
>> together into a single application yet.  If you have war stories  
>> that can
>> dissuade me from trying, I'd certainly be willing to listen and  
>> thankful for
>> it.
>>
>> Steve
>>
>>

Re: Grr. Maven.

[Benson Margulies <bi...@gmail.com>]

Unless you need RPC encoding, which Axis preserves and CXF hasn't got.

On Mon, Dec 1, 2008 at 9:23 AM, Steve Cohen <sc...@javactivity.org> wrote:
> Christian Schneider wrote:
>>
>> ...
>>
>> BTW. If you have CXF in your project it does not make a lot of sense to
>> also use Axis. I think you should decide on time for your project which
>> webservice stack to use and stick with it.
>
> I agree with this, basically, but it's a question of time.  I have a CXF
> client going for one WS and an Axis client going for the other, both with
> vendor-provided help/sample classes.  I haven't yet tried to put them
> together into a single application yet.  If you have war stories that can
> dissuade me from trying, I'd certainly be willing to listen and thankful for
> it.
>
> Steve
>
>

Re: Grr. Maven.

[Steve Cohen <sc...@javactivity.org>]

Christian Schneider wrote:
> ...
>
> BTW. If you have CXF in your project it does not make a lot of sense 
> to also use Axis. I think you should decide on time for your project 
> which webservice stack to use and stick with it.

I agree with this, basically, but it's a question of time.  I have a CXF 
client going for one WS and an Axis client going for the other, both 
with vendor-provided help/sample classes.  I haven't yet tried to put 
them together into a single application yet.  If you have war stories 
that can dissuade me from trying, I'd certainly be willing to listen and 
thankful for it.

Steve

Re: Grr. Maven.

[Daniel Kulp <dk...@apache.org>]

On Thursday 04 December 2008 2:44:24 am Christian Schneider wrote:
> Hi Dan,
>
> I think this really makes sense. Is there already an issue for this task?

Not yet.  I really haven't had any time to really think about a 3.0 version.   
Too busy on 2.x tasks.  :-(

Dan


>
> I would combine the following modules:
>
> cxf-api
> cxf-common-schemas
> cxf-common-utilities
> cxf-rt-core:jar
>
> That would at least make the set of dependencies cxf produces by itself
> smaller.
>
> The set above depends on:
>
> [INFO] [dependency:list]
> [INFO]
> [INFO] The following files have been resolved:
> [INFO]    aopalliance:aopalliance:jar:1.0:compile
> [INFO]    com.sun.xml.bind:jaxb-impl:jar:2.1.7:compile
> [INFO]    com.sun.xml.fastinfoset:FastInfoset:jar:1.2.2:compile
> [INFO]    commons-lang:commons-lang:jar:2.4:compile
> [INFO]    commons-logging:commons-logging:jar:1.1.1:compile
> [INFO]    javax.xml.bind:jaxb-api:jar:2.1:compile
> [INFO]    javax.xml.stream:stax-api:jar:1.0-2:compile
> [INFO]    org.apache.cxf:cxf-api:jar:2.2-SNAPSHOT:compile
> [INFO]    org.apache.cxf:cxf-common-schemas:jar:2.2-SNAPSHOT:compile
> [INFO]    org.apache.cxf:cxf-common-utilities:jar:2.2-SNAPSHOT:compile
> [INFO]    org.apache.cxf:cxf-rt-core:jar:2.2-SNAPSHOT:compile
> [INFO]
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
> [INFO]
> org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
> [INFO]
> org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.5:compile
> [INFO]
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
> [INFO]    org.apache.neethi:neethi:jar:2.0.4:compile
> [INFO]    org.apache.ws.commons.schema:XmlSchema:jar:1.4.2:compile
> [INFO]    org.codehaus.woodstox:wstx-asl:jar:3.2.6:compile
> [INFO]    org.springframework:spring-beans:jar:2.5.5:compile
> [INFO]    org.springframework:spring-context:jar:2.5.5:compile
> [INFO]    org.springframework:spring-core:jar:2.5.5:compile
> [INFO]    wsdl4j:wsdl4j:jar:1.6.2:compile
> [INFO]    xml-resolver:xml-resolver:jar:1.2:compile
>
> Btw. I have found the dependency:analyze goal. This looks like it could
> help us. For cxf-rt-core it reported that jaxb-impl is declared but not
> used.
>
> Interestingly it says the following about cxf-api:
>
> [INFO] [dependency:analyze]
> [WARNING] Used undeclared dependencies found:
> [WARNING]
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
> [WARNING]    commons-lang:commons-lang:jar:2.4:compile
> [WARNING]    javax.xml.bind:jaxb-api:jar:2.1:compile
> [WARNING]    org.easymock:easymock:jar:2.4:test
> [WARNING]    wsdl4j:wsdl4j:jar:1.6.2:compile
> [WARNING] Unused declared dependencies found:
> [WARNING]
> org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
> [WARNING]    com.sun.xml.bind:jaxb-xjc:jar:2.1.9:test
> [WARNING]    org.apache.cxf:cxf-common-schemas:jar:2.2-SNAPSHOT:compile
> [WARNING]    org.codehaus.woodstox:wstx-asl:jar:3.2.6:compile
> [WARNING]    com.sun.xml.bind:jaxb-impl:jar:2.1.9:test
> [WARNING]    org.apache.cxf:cxf-xjc-dv:jar:2.2-SNAPSHOT:test
>
> and for cxf-common-utilities:
> [INFO] [dependency:analyze]
> [WARNING] Used undeclared dependencies found:
> [WARNING]    org.easymock:easymock:jar:2.4:test
> [WARNING]    cglib:cglib-nodep:jar:2.1_3:test
> [WARNING] Unused declared dependencies found:
> [WARNING]    org.codehaus.woodstox:wstx-asl:jar:3.2.6:test
> [WARNING]
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:test
> [WARNING]    com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.2:test
> [WARNING]    xml-resolver:xml-resolver:jar:1.2:compile
>
> Greetings
>
> Christian
>
> Daniel Kulp schrieb:
> > Honestly, one of the things I keep thinking about for 3.0 is combining
> > common-utilities, api, and rt/core into a single "cxf-kernel" or
> > something. common-utilities and api seperation is pretty much useless.  
> > The utilities are as much a part of the api as the stuff in the api
> > module is.   The reason they were separated goes WAY WAY back to M1 days
> > when the tools didn't depend on core.   That reason is now long gone and
> > having them separate is almost pointless.
> >
> > But to this discussion, making the API module depend on less things
> > really won't solve  the problem at all.   You cannot really do anything
> > without depending on cxf-rt-core.   Thus, if you move a dependency from
> > API to core, it doesn't change the fact that it would get pulled in for
> > any cxf application.
> >
> > Dan



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Grr. Maven.

[Daniel Kulp <dk...@apache.org>]

On Thursday 04 December 2008 3:59:05 pm Brad O'Hearne wrote:
> I'm guessing dependency analyze wouldn't be able to properly report
> dependencies that result from dynamic loading,

I'm guessing not.

> > [WARNING] Unused declared dependencies found:
.....
> > [WARNING]    org.codehaus.woodstox:wstx-asl:jar:3.2.6:compile
> > [WARNING]    com.sun.xml.bind:jaxb-impl:jar:2.1.9:test
....
On java5, not much will work without those two jars.  They are both 
dynamically loaded from the api jars so I'm going to assume that is why they 
aren't being picked up.


Dan




>
> Brad
>
> On Dec 4, 2008, at 12:44 AM, Christian Schneider wrote:
> > Hi Dan,
> >
> > I think this really makes sense. Is there already an issue for this
> > task?
> >
> > I would combine the following modules:
> >
> > cxf-api
> > cxf-common-schemas
> > cxf-common-utilities
> > cxf-rt-core:jar
> >
> > That would at least make the set of dependencies cxf produces by
> > itself smaller.
> >
> > The set above depends on:
> >
> > [INFO] [dependency:list]
> > [INFO]
> > [INFO] The following files have been resolved:
> > [INFO]    aopalliance:aopalliance:jar:1.0:compile
> > [INFO]    com.sun.xml.bind:jaxb-impl:jar:2.1.7:compile
> > [INFO]    com.sun.xml.fastinfoset:FastInfoset:jar:1.2.2:compile
> > [INFO]    commons-lang:commons-lang:jar:2.4:compile
> > [INFO]    commons-logging:commons-logging:jar:1.1.1:compile
> > [INFO]    javax.xml.bind:jaxb-api:jar:2.1:compile
> > [INFO]    javax.xml.stream:stax-api:jar:1.0-2:compile
> > [INFO]    org.apache.cxf:cxf-api:jar:2.2-SNAPSHOT:compile
> > [INFO]    org.apache.cxf:cxf-common-schemas:jar:2.2-SNAPSHOT:compile
> > [INFO]    org.apache.cxf:cxf-common-utilities:jar:2.2-SNAPSHOT:compile
> > [INFO]    org.apache.cxf:cxf-rt-core:jar:2.2-SNAPSHOT:compile
> > [INFO]    org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:
> > 1.0.2:compile
> > [INFO]    org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:
> > 1.1.1:compile
> > [INFO]    org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:
> > 1.5:compile
> > [INFO]    org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:
> > 1.0.1:compile
> > [INFO]    org.apache.neethi:neethi:jar:2.0.4:compile
> > [INFO]    org.apache.ws.commons.schema:XmlSchema:jar:1.4.2:compile
> > [INFO]    org.codehaus.woodstox:wstx-asl:jar:3.2.6:compile
> > [INFO]    org.springframework:spring-beans:jar:2.5.5:compile
> > [INFO]    org.springframework:spring-context:jar:2.5.5:compile
> > [INFO]    org.springframework:spring-core:jar:2.5.5:compile
> > [INFO]    wsdl4j:wsdl4j:jar:1.6.2:compile
> > [INFO]    xml-resolver:xml-resolver:jar:1.2:compile
> >
> > Btw. I have found the dependency:analyze goal. This looks like it
> > could help us. For cxf-rt-core it reported that jaxb-impl is
> > declared but not used.
> >
> > Interestingly it says the following about cxf-api:
> >
> > [INFO] [dependency:analyze]
> > [WARNING] Used undeclared dependencies found:
> > [WARNING]    org.apache.geronimo.specs:geronimo-stax-
> > api_1.0_spec:jar:1.0.1:compile
> > [WARNING]    commons-lang:commons-lang:jar:2.4:compile
> > [WARNING]    javax.xml.bind:jaxb-api:jar:2.1:compile
> > [WARNING]    org.easymock:easymock:jar:2.4:test
> > [WARNING]    wsdl4j:wsdl4j:jar:1.6.2:compile
> > [WARNING] Unused declared dependencies found:
> > [WARNING]    org.apache.geronimo.specs:geronimo-
> > annotation_1.0_spec:jar:1.1.1:compile
> > [WARNING]    com.sun.xml.bind:jaxb-xjc:jar:2.1.9:test
> > [WARNING]    org.apache.cxf:cxf-common-schemas:jar:2.2-
> > SNAPSHOT:compile
> > [WARNING]    org.codehaus.woodstox:wstx-asl:jar:3.2.6:compile
> > [WARNING]    com.sun.xml.bind:jaxb-impl:jar:2.1.9:test
> > [WARNING]    org.apache.cxf:cxf-xjc-dv:jar:2.2-SNAPSHOT:test
> >
> > and for cxf-common-utilities:
> > [INFO] [dependency:analyze]
> > [WARNING] Used undeclared dependencies found:
> > [WARNING]    org.easymock:easymock:jar:2.4:test
> > [WARNING]    cglib:cglib-nodep:jar:2.1_3:test
> > [WARNING] Unused declared dependencies found:
> > [WARNING]    org.codehaus.woodstox:wstx-asl:jar:3.2.6:test
> > [WARNING]    org.apache.geronimo.specs:geronimo-
> > activation_1.1_spec:jar:1.0.2:test
> > [WARNING]    com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.2:test
> > [WARNING]    xml-resolver:xml-resolver:jar:1.2:compile
> >
> > Greetings
> >
> > Christian
> >
> > Daniel Kulp schrieb:
> >> Honestly, one of the things I keep thinking about for 3.0 is
> >> combining common-utilities, api, and rt/core into a single "cxf-
> >> kernel" or something.   common-utilities and api seperation is
> >> pretty much useless.   The utilities are as much a part of the api
> >> as the stuff in the api module is.   The reason they were separated
> >> goes WAY WAY back to M1 days when the tools didn't depend on
> >> core.   That reason is now long gone and having them separate is
> >> almost pointless.
> >>
> >> But to this discussion, making the API module depend on less things
> >> really won't solve  the problem at all.   You cannot really do
> >> anything without depending on cxf-rt-core.   Thus, if you move a
> >> dependency from API to core, it doesn't change the fact that it
> >> would get pulled in for any cxf application.
> >> Dan
> >
> > --
> >
> > Christian Schneider
> > ---
> > http://www.liquid-reality.de



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Grr. Maven.

[Brad O'Hearne <br...@bighillsoftware.com>]

I'm guessing dependency analyze wouldn't be able to properly report  
dependencies that result from dynamic loading, though I don't know if  
there are any of those in CXF.

Brad

On Dec 4, 2008, at 12:44 AM, Christian Schneider wrote:

> Hi Dan,
>
> I think this really makes sense. Is there already an issue for this  
> task?
>
> I would combine the following modules:
>
> cxf-api
> cxf-common-schemas
> cxf-common-utilities
> cxf-rt-core:jar
>
> That would at least make the set of dependencies cxf produces by  
> itself smaller.
>
> The set above depends on:
>
> [INFO] [dependency:list]
> [INFO]
> [INFO] The following files have been resolved:
> [INFO]    aopalliance:aopalliance:jar:1.0:compile
> [INFO]    com.sun.xml.bind:jaxb-impl:jar:2.1.7:compile
> [INFO]    com.sun.xml.fastinfoset:FastInfoset:jar:1.2.2:compile
> [INFO]    commons-lang:commons-lang:jar:2.4:compile
> [INFO]    commons-logging:commons-logging:jar:1.1.1:compile
> [INFO]    javax.xml.bind:jaxb-api:jar:2.1:compile
> [INFO]    javax.xml.stream:stax-api:jar:1.0-2:compile
> [INFO]    org.apache.cxf:cxf-api:jar:2.2-SNAPSHOT:compile
> [INFO]    org.apache.cxf:cxf-common-schemas:jar:2.2-SNAPSHOT:compile
> [INFO]    org.apache.cxf:cxf-common-utilities:jar:2.2-SNAPSHOT:compile
> [INFO]    org.apache.cxf:cxf-rt-core:jar:2.2-SNAPSHOT:compile
> [INFO]    org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar: 
> 1.0.2:compile
> [INFO]    org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar: 
> 1.1.1:compile
> [INFO]    org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar: 
> 1.5:compile
> [INFO]    org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar: 
> 1.0.1:compile
> [INFO]    org.apache.neethi:neethi:jar:2.0.4:compile
> [INFO]    org.apache.ws.commons.schema:XmlSchema:jar:1.4.2:compile
> [INFO]    org.codehaus.woodstox:wstx-asl:jar:3.2.6:compile
> [INFO]    org.springframework:spring-beans:jar:2.5.5:compile
> [INFO]    org.springframework:spring-context:jar:2.5.5:compile
> [INFO]    org.springframework:spring-core:jar:2.5.5:compile
> [INFO]    wsdl4j:wsdl4j:jar:1.6.2:compile
> [INFO]    xml-resolver:xml-resolver:jar:1.2:compile
>
> Btw. I have found the dependency:analyze goal. This looks like it  
> could help us. For cxf-rt-core it reported that jaxb-impl is  
> declared but not used.
>
> Interestingly it says the following about cxf-api:
>
> [INFO] [dependency:analyze]
> [WARNING] Used undeclared dependencies found:
> [WARNING]    org.apache.geronimo.specs:geronimo-stax- 
> api_1.0_spec:jar:1.0.1:compile
> [WARNING]    commons-lang:commons-lang:jar:2.4:compile
> [WARNING]    javax.xml.bind:jaxb-api:jar:2.1:compile
> [WARNING]    org.easymock:easymock:jar:2.4:test
> [WARNING]    wsdl4j:wsdl4j:jar:1.6.2:compile
> [WARNING] Unused declared dependencies found:
> [WARNING]    org.apache.geronimo.specs:geronimo- 
> annotation_1.0_spec:jar:1.1.1:compile
> [WARNING]    com.sun.xml.bind:jaxb-xjc:jar:2.1.9:test
> [WARNING]    org.apache.cxf:cxf-common-schemas:jar:2.2- 
> SNAPSHOT:compile
> [WARNING]    org.codehaus.woodstox:wstx-asl:jar:3.2.6:compile
> [WARNING]    com.sun.xml.bind:jaxb-impl:jar:2.1.9:test
> [WARNING]    org.apache.cxf:cxf-xjc-dv:jar:2.2-SNAPSHOT:test
>
> and for cxf-common-utilities:
> [INFO] [dependency:analyze]
> [WARNING] Used undeclared dependencies found:
> [WARNING]    org.easymock:easymock:jar:2.4:test
> [WARNING]    cglib:cglib-nodep:jar:2.1_3:test
> [WARNING] Unused declared dependencies found:
> [WARNING]    org.codehaus.woodstox:wstx-asl:jar:3.2.6:test
> [WARNING]    org.apache.geronimo.specs:geronimo- 
> activation_1.1_spec:jar:1.0.2:test
> [WARNING]    com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.2:test
> [WARNING]    xml-resolver:xml-resolver:jar:1.2:compile
>
> Greetings
>
> Christian
>
>
>
> Daniel Kulp schrieb:
>> Honestly, one of the things I keep thinking about for 3.0 is  
>> combining common-utilities, api, and rt/core into a single "cxf- 
>> kernel" or something.   common-utilities and api seperation is  
>> pretty much useless.   The utilities are as much a part of the api  
>> as the stuff in the api module is.   The reason they were separated  
>> goes WAY WAY back to M1 days when the tools didn't depend on  
>> core.   That reason is now long gone and having them separate is  
>> almost pointless.
>>
>> But to this discussion, making the API module depend on less things  
>> really won't solve  the problem at all.   You cannot really do  
>> anything without depending on cxf-rt-core.   Thus, if you move a  
>> dependency from API to core, it doesn't change the fact that it  
>> would get pulled in for any cxf application.
>> Dan
>>
>>
>>
>
>
> -- 
>
> Christian Schneider
> ---
> http://www.liquid-reality.de
>

Re: Grr. Maven.

[Christian Schneider <ch...@die-schneider.net>]

Hi Dan,

I think this really makes sense. Is there already an issue for this task?

I would combine the following modules:

cxf-api
cxf-common-schemas
cxf-common-utilities
cxf-rt-core:jar

That would at least make the set of dependencies cxf produces by itself 
smaller.

The set above depends on:

[INFO] [dependency:list]
[INFO]
[INFO] The following files have been resolved:
[INFO]    aopalliance:aopalliance:jar:1.0:compile
[INFO]    com.sun.xml.bind:jaxb-impl:jar:2.1.7:compile
[INFO]    com.sun.xml.fastinfoset:FastInfoset:jar:1.2.2:compile
[INFO]    commons-lang:commons-lang:jar:2.4:compile
[INFO]    commons-logging:commons-logging:jar:1.1.1:compile
[INFO]    javax.xml.bind:jaxb-api:jar:2.1:compile
[INFO]    javax.xml.stream:stax-api:jar:1.0-2:compile
[INFO]    org.apache.cxf:cxf-api:jar:2.2-SNAPSHOT:compile
[INFO]    org.apache.cxf:cxf-common-schemas:jar:2.2-SNAPSHOT:compile
[INFO]    org.apache.cxf:cxf-common-utilities:jar:2.2-SNAPSHOT:compile
[INFO]    org.apache.cxf:cxf-rt-core:jar:2.2-SNAPSHOT:compile
[INFO]    
org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
[INFO]    
org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
[INFO]    
org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.5:compile
[INFO]    
org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
[INFO]    org.apache.neethi:neethi:jar:2.0.4:compile
[INFO]    org.apache.ws.commons.schema:XmlSchema:jar:1.4.2:compile
[INFO]    org.codehaus.woodstox:wstx-asl:jar:3.2.6:compile
[INFO]    org.springframework:spring-beans:jar:2.5.5:compile
[INFO]    org.springframework:spring-context:jar:2.5.5:compile
[INFO]    org.springframework:spring-core:jar:2.5.5:compile
[INFO]    wsdl4j:wsdl4j:jar:1.6.2:compile
[INFO]    xml-resolver:xml-resolver:jar:1.2:compile

Btw. I have found the dependency:analyze goal. This looks like it could 
help us. For cxf-rt-core it reported that jaxb-impl is declared but not 
used.

Interestingly it says the following about cxf-api:

[INFO] [dependency:analyze]
[WARNING] Used undeclared dependencies found:
[WARNING]    
org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
[WARNING]    commons-lang:commons-lang:jar:2.4:compile
[WARNING]    javax.xml.bind:jaxb-api:jar:2.1:compile
[WARNING]    org.easymock:easymock:jar:2.4:test
[WARNING]    wsdl4j:wsdl4j:jar:1.6.2:compile
[WARNING] Unused declared dependencies found:
[WARNING]    
org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
[WARNING]    com.sun.xml.bind:jaxb-xjc:jar:2.1.9:test
[WARNING]    org.apache.cxf:cxf-common-schemas:jar:2.2-SNAPSHOT:compile
[WARNING]    org.codehaus.woodstox:wstx-asl:jar:3.2.6:compile
[WARNING]    com.sun.xml.bind:jaxb-impl:jar:2.1.9:test
[WARNING]    org.apache.cxf:cxf-xjc-dv:jar:2.2-SNAPSHOT:test

and for cxf-common-utilities:
[INFO] [dependency:analyze]
[WARNING] Used undeclared dependencies found:
[WARNING]    org.easymock:easymock:jar:2.4:test
[WARNING]    cglib:cglib-nodep:jar:2.1_3:test
[WARNING] Unused declared dependencies found:
[WARNING]    org.codehaus.woodstox:wstx-asl:jar:3.2.6:test
[WARNING]    
org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:test
[WARNING]    com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.2:test
[WARNING]    xml-resolver:xml-resolver:jar:1.2:compile

Greetings

Christian



Daniel Kulp schrieb:
> Honestly, one of the things I keep thinking about for 3.0 is combining 
> common-utilities, api, and rt/core into a single "cxf-kernel" or something.   
> common-utilities and api seperation is pretty much useless.   The utilities 
> are as much a part of the api as the stuff in the api module is.   The reason 
> they were separated goes WAY WAY back to M1 days when the tools didn't depend 
> on core.   That reason is now long gone and having them separate is almost 
> pointless.
>
> But to this discussion, making the API module depend on less things really 
> won't solve  the problem at all.   You cannot really do anything without 
> depending on cxf-rt-core.   Thus, if you move a dependency from API to core, 
> it doesn't change the fact that it would get pulled in for any cxf 
> application.  
>
> Dan
>
>
>   


-- 

Christian Schneider
---
http://www.liquid-reality.de

Re: Grr. Maven.

[Daniel Kulp <dk...@apache.org>]

Honestly, one of the things I keep thinking about for 3.0 is combining 
common-utilities, api, and rt/core into a single "cxf-kernel" or something.   
common-utilities and api seperation is pretty much useless.   The utilities 
are as much a part of the api as the stuff in the api module is.   The reason 
they were separated goes WAY WAY back to M1 days when the tools didn't depend 
on core.   That reason is now long gone and having them separate is almost 
pointless.

But to this discussion, making the API module depend on less things really 
won't solve  the problem at all.   You cannot really do anything without 
depending on cxf-rt-core.   Thus, if you move a dependency from API to core, 
it doesn't change the fact that it would get pulled in for any cxf 
application.  

Dan



On Tuesday 02 December 2008 2:50:14 am Christian Schneider wrote:
> Hi Dan,
>
> I can imagine that every single jar is needed right now but I think the
> dependencies show that there are things in the api that do not belong
> there.
>
> For example I tried to find out why cxf-common-utilities is needed. It
> seems it is only used in one class: TransportURIResolver.
> This class is an implementation class and also seems not to be
> referenced from the rest of the API module. So I guess it should be
> moved  to  cxf-common-utils  or cxf-rt-core.
>
> I think the neethi package is really not that critical.
>
> Greetings
>
> Christian
>
> > Honesly, I'm not sure if anything there is actually removable.   MAYBE
> > mark Neethi as provided, but it would still be pulled in later.  
> > xml-resolve could potentially be pulled if we add code to detect it's not
> > there and then not support catalogs in that case.



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Grr. Maven.

[Christian Schneider <ch...@die-schneider.net>]

Hi Dan,

I can imagine that every single jar is needed right now but I think the 
dependencies show that there are things in the api that do not belong there.

For example I tried to find out why cxf-common-utilities is needed. It 
seems it is only used in one class: TransportURIResolver.
This class is an implementation class and also seems not to be 
referenced from the rest of the API module. So I guess it should be  
moved  to  cxf-common-utils  or cxf-rt-core.

I think the neethi package is really not that critical.

Greetings

Christian
>
>
> Honesly, I'm not sure if anything there is actually removable.   MAYBE mark 
> Neethi as provided, but it would still be pulled in later.   xml-resolve 
> could potentially be pulled if we add code to detect it's not there and then 
> not support catalogs in that case.
>
>   

-- 

Christian Schneider
---
http://www.liquid-reality.de

Re: Grr. Maven.

[Daniel Kulp <dk...@apache.org>]

And if you use "mvn dependency:tree":

[dependency:tree]
org.apache.cxf:cxf-api:jar:2.2-SNAPSHOT
+- junit:junit:jar:4.4:test
+- org.easymock:easymockclassextension:jar:2.4:test
|  +- org.easymock:easymock:jar:2.4:test
|  \- cglib:cglib-nodep:jar:2.1_3:test
+- org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
+- org.apache.cxf:cxf-common-utilities:jar:2.2-SNAPSHOT:compile
|  +- org.springframework:spring-core:jar:2.5.5:compile
|  +- org.springframework:spring-beans:jar:2.5.5:compile
|  +- org.springframework:spring-context:jar:2.5.5:compile
|  |  \- aopalliance:aopalliance:jar:1.0:compile
|  +- javax.xml.bind:jaxb-api:jar:2.1:compile
|  +- org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
|  +- wsdl4j:wsdl4j:jar:1.6.2:compile
|  +- xml-resolver:xml-resolver:jar:1.2:compile
|  \- commons-lang:commons-lang:jar:2.4:compile
+- org.apache.ws.commons.schema:XmlSchema:jar:1.4.2:compile
+- com.sun.xml.bind:jaxb-xjc:jar:2.1.9:test
+- com.sun.xml.bind:jaxb-impl:jar:2.1.9:test
+- org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
+- 
org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:jar:2.0.0:provided
+- org.codehaus.woodstox:wstx-asl:jar:3.2.6:compile
+- org.apache.neethi:neethi:jar:2.0.4:compile
|  \- commons-logging:commons-logging:jar:1.1.1:compile
+- org.apache.cxf:cxf-common-schemas:jar:2.2-SNAPSHOT:compile
\- org.apache.cxf:cxf-xjc-dv:jar:2.2-SNAPSHOT:test


And then pull out the "test" and "provided" scoped deps:
org.apache.cxf:cxf-api:jar:2.2-SNAPSHOT
+- org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
+- org.apache.cxf:cxf-common-utilities:jar:2.2-SNAPSHOT:compile
|  +- org.springframework:spring-core:jar:2.5.5:compile
|  +- org.springframework:spring-beans:jar:2.5.5:compile
|  +- org.springframework:spring-context:jar:2.5.5:compile
|  |  \- aopalliance:aopalliance:jar:1.0:compile
|  +- javax.xml.bind:jaxb-api:jar:2.1:compile
|  +- org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
|  +- wsdl4j:wsdl4j:jar:1.6.2:compile
|  +- xml-resolver:xml-resolver:jar:1.2:compile
|  \- commons-lang:commons-lang:jar:2.4:compile
+- org.apache.ws.commons.schema:XmlSchema:jar:1.4.2:compile
+- org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
+- org.codehaus.woodstox:wstx-asl:jar:3.2.6:compile
+- org.apache.neethi:neethi:jar:2.0.4:compile
|  \- commons-logging:commons-logging:jar:1.1.1:compile
+- org.apache.cxf:cxf-common-schemas:jar:2.2-SNAPSHOT:compile


Honesly, I'm not sure if anything there is actually removable.   MAYBE mark 
Neethi as provided, but it would still be pulled in later.   xml-resolve 
could potentially be pulled if we add code to detect it's not there and then 
not support catalogs in that case.

Dan





On Monday 01 December 2008 3:03:08 pm Christian Schneider wrote:
> Hi Benson,
>
> I think a good example is cxf-api. It depends on:
> - neethi
> - cxf-common utilities
> - cxf-common-schemas
> - geronimo-activation
> - geronimo-j2ee-connector_1.5_spec
> - XmlSchema
> - wstx-asl
> - geronimo-annotation_1.0_spec
>
> When you include transitive dependencies it is even worse:
>
> - wsdl4j
> - commons-lang
> - geronimo-stax-api_1.0_spec
> - spring-context
> - jaxb-api
> - xml-resolver
> - spring-beans
> - aopaliance
> - spring-core
> - commons-logging
>
> No one can tell me that an api package needs all this. ;-)
> Most transitive dependencies come from cxf-common-utilities. So I think
> a good starting point would be to try to remove the dependency to
> commons-utilities.
>
> To keep track of dependencies we could do some metrics. For example we
> could track the number of direct and transitive dependencies for each
> module over time. Then we could set the goal for us all to try to lower
> the dependency numbers over time.
>
> Greetings
>
> Christian
>
> Benson Margulies schrieb:
> > Christian,
> >
> > This perhaps ought to move to dev, but ...
> >
> > What exactly do you have in mind when you say, 'clean out'?
> >
> > It might be one of several things.
> >
> > 1) Divorce CXF entirely from some of its dependencies.
> > 2) Document much more carefully what you actually have to have to
> > operate in various popular scenarios.
> > 3) tweak the Maven dependencies so that a vanilla user doing a vanilla
> > build downloads a less stuff?
> >
> > --benson
> >
> >> --
> >>
> >> Christian Schneider
> >> ---
> >> http://www.liquid-reality.de



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Grr. Maven.

[Christian Schneider <ch...@die-schneider.net>]

I think instead of profiles it should be enough to provide artifacts for 
e.g. Rest. Mostly this is already there.

Greetings

Christian

Benson Margulies schrieb:
> CXF already delivers a host of individual artifacts to maven. We
> can't, as I understand maven, define profiles for users. So, as of
> now, anyone who doesn't like 11mb of Sun JAXB RI can leave out the
> JAXB data binding by listing a lot of little CXF dependencies instead
> of one big one.
>
> If we try to imagine a level of aggregation above the many individual
> pieces and below the giant bundles, then we arrive at an explosion of
> possibilities. However, if someone wants to propose a few really
> popular more svelte alternatives, I for one would be OK with them.
>
>
> On Mon, Dec 1, 2008 at 8:21 AM, Adrian Corcoran
> <ad...@gmail.com> wrote:
>   


-- 

Christian Schneider
---
http://www.liquid-reality.de

Re: Grr. Maven.

[Adrian Corcoran <ad...@gmail.com>]

what way are the delivered - are they not delivered as part of a super pom?

Could that super pom not define the different profiles (they don't need to
be user profiles).

I think that these sort of profiles should cover the 80/20 rule. To my mind
the basic profiles would be something along the lines of:

tooling
jax-ws
rest
rest & jetty
jax-ws & jetty
jms & jax-ws
xmlbeans & soap


On Mon, Dec 1, 2008 at 1:28 PM, Benson Margulies <bi...@gmail.com>wrote:

> CXF already delivers a host of individual artifacts to maven. We
> can't, as I understand maven, define profiles for users. So, as of
> now, anyone who doesn't like 11mb of Sun JAXB RI can leave out the
> JAXB data binding by listing a lot of little CXF dependencies instead
> of one big one.
>
> If we try to imagine a level of aggregation above the many individual
> pieces and below the giant bundles, then we arrive at an explosion of
> possibilities. However, if someone wants to propose a few really
> popular more svelte alternatives, I for one would be OK with them.
>
>
> On Mon, Dec 1, 2008 at 8:21 AM, Adrian Corcoran
> <ad...@gmail.com> wrote:
> > would it be possible to use different maven profiles to manage different
> > dependancy sets. e.g. CXF without Rest support / CXF REST only / CXF
> without
> > WS-Security etc...
> >
> > On Mon, Dec 1, 2008 at 1:16 PM, Benson Margulies <bimargulies@gmail.com
> >wrote:
> >
> >> Christian,
> >>
> >> This perhaps ought to move to dev, but ...
> >>
> >> What exactly do you have in mind when you say, 'clean out'?
> >>
> >> It might be one of several things.
> >>
> >> 1) Divorce CXF entirely from some of its dependencies.
> >> 2) Document much more carefully what you actually have to have to
> >> operate in various popular scenarios.
> >> 3) tweak the Maven dependencies so that a vanilla user doing a vanilla
> >> build downloads a less stuff?
> >>
> >> --benson
> >>
> >>
> >> On Mon, Dec 1, 2008 at 2:13 AM, Christian Schneider
> >> <ch...@die-schneider.net> wrote:
> >> > Hi Steve,
> >> >
> >> > I basically think you are right. CXF introduces a lot of dependencies
> >> when
> >> > you add it to your application. For a project manager at the company I
> >> work
> >> > this was almost a reason to throw CXF out and do
> >> > the parsing by hand. While many maven projects tend to collect
> >> dependencies
> >> > CXF is an especially bad example here.
> >> >
> >> > I would vote for making cleaning out dependencies a high priority
> issue.
> >> > What do other CXF developers think?
> >> >
> >> > BTW. If you have CXF in your project it does not make a lot of sense
> to
> >> also
> >> > use Axis. I think you should decide on time for your project which
> >> > webservice stack to use and stick with it.
> >> >
> >> > Greetings
> >> >
> >> > Christian
> >> >
> >> > Steve Cohen schrieb:
> >> >>
> >> >> My "problem" is more philosophical than anything, and I'm not sure
> it's
> >> >> really a problem.  But, consider that by adding a web service client,
> a
> >> >> small new piece of my application's functionality, the WAR file size
> has
> >> >> ballooned in size from 3MB to over 10MB.  Additionally, as I look at
> the
> >> 33
> >> >> or so jars it was necessary to add to the war in order to get the
> thing
> >> to
> >> >> run (and I manually hacked 14 out of the dependencies generated by
> Maven
> >> >> which I found NOT to be needed), I can't say I know what most of them
> >> do.
> >> >>  Why, for example, was it necessary to include pieces of the Spring
> >> >> framework, even though my application doesn't use that framework?
>  What,
> >> for
> >> >> Pete's sake, is Neethi, and why was it necessary to add it?  Quite a
> lot
> >> of
> >> >> stuff for the "simple" task of marshalling and unmarshalling data
> into
> >> >> SOAP-XML packets and sending them across the wire.  From their names,
> it
> >> >> looks as though some of them repeat functionality that is available
> in
> >> other
> >> >> jars - but who has time to investigate?  I also have a little nagging
> >> fear
> >> >> that down the road a few weeks, when I have to add my NEXT web
> service
> >> >> client to this app (and this one uses AXIS) I will end up adding
> another
> >> >> bunch of jars, some of which may conflict with the ones just added.
> >> >> In other words I feel that I've lost control of my application.
> >> >>
> >> >> Prior to this, I understood my dependencies.  I understand that
> there's
> >> a
> >> >> tradeoff here.  In return for letting go of control of my
> dependencies,
> >> I
> >> >> have a potentially much simpler and more automated build process -
> and I
> >> >> know that's  a good thing - especially when and if I convert the
> >> project's
> >> >> entire build process to Maven.  And speaking of CXF in particular, I
> >> like
> >> >> that the client code I need to write is not particularly ugly, as it
> is
> >> with
> >> >> some other SOAP platforms (AXIS - grr grr).  But I continue to wonder
> >> >> whether it isn't a problem that Maven encourages these chains of
> >> >> dependencies that grow geometrically without appropriate
> consideration
> >> to
> >> >> developer understanding being given.  For the sake of developer
> >> >> understanding, would it perhaps be a good thing if pom.xml dependency
> >> >> elements had a required <comment> element that the composer of a POM
> >> would
> >> >> have to think about before issuing a POM to the world?  Or maybe a
> newer
> >> >> version of CXF will pare the dependencies down to what is truly
> needed
> >> to
> >> >> run client-side and server-side apps.
> >> >>
> >> >> <end of rant>
> >> >
> >> >
> >> > --
> >> >
> >> > Christian Schneider
> >> > ---
> >> > http://www.liquid-reality.de
> >> >
> >> >
> >>
> >
>

Re: Grr. Maven.

[Benson Margulies <bi...@gmail.com>]

CXF already delivers a host of individual artifacts to maven. We
can't, as I understand maven, define profiles for users. So, as of
now, anyone who doesn't like 11mb of Sun JAXB RI can leave out the
JAXB data binding by listing a lot of little CXF dependencies instead
of one big one.

If we try to imagine a level of aggregation above the many individual
pieces and below the giant bundles, then we arrive at an explosion of
possibilities. However, if someone wants to propose a few really
popular more svelte alternatives, I for one would be OK with them.


On Mon, Dec 1, 2008 at 8:21 AM, Adrian Corcoran
<ad...@gmail.com> wrote:
> would it be possible to use different maven profiles to manage different
> dependancy sets. e.g. CXF without Rest support / CXF REST only / CXF without
> WS-Security etc...
>
> On Mon, Dec 1, 2008 at 1:16 PM, Benson Margulies <bi...@gmail.com>wrote:
>
>> Christian,
>>
>> This perhaps ought to move to dev, but ...
>>
>> What exactly do you have in mind when you say, 'clean out'?
>>
>> It might be one of several things.
>>
>> 1) Divorce CXF entirely from some of its dependencies.
>> 2) Document much more carefully what you actually have to have to
>> operate in various popular scenarios.
>> 3) tweak the Maven dependencies so that a vanilla user doing a vanilla
>> build downloads a less stuff?
>>
>> --benson
>>
>>
>> On Mon, Dec 1, 2008 at 2:13 AM, Christian Schneider
>> <ch...@die-schneider.net> wrote:
>> > Hi Steve,
>> >
>> > I basically think you are right. CXF introduces a lot of dependencies
>> when
>> > you add it to your application. For a project manager at the company I
>> work
>> > this was almost a reason to throw CXF out and do
>> > the parsing by hand. While many maven projects tend to collect
>> dependencies
>> > CXF is an especially bad example here.
>> >
>> > I would vote for making cleaning out dependencies a high priority issue.
>> > What do other CXF developers think?
>> >
>> > BTW. If you have CXF in your project it does not make a lot of sense to
>> also
>> > use Axis. I think you should decide on time for your project which
>> > webservice stack to use and stick with it.
>> >
>> > Greetings
>> >
>> > Christian
>> >
>> > Steve Cohen schrieb:
>> >>
>> >> My "problem" is more philosophical than anything, and I'm not sure it's
>> >> really a problem.  But, consider that by adding a web service client, a
>> >> small new piece of my application's functionality, the WAR file size has
>> >> ballooned in size from 3MB to over 10MB.  Additionally, as I look at the
>> 33
>> >> or so jars it was necessary to add to the war in order to get the thing
>> to
>> >> run (and I manually hacked 14 out of the dependencies generated by Maven
>> >> which I found NOT to be needed), I can't say I know what most of them
>> do.
>> >>  Why, for example, was it necessary to include pieces of the Spring
>> >> framework, even though my application doesn't use that framework?  What,
>> for
>> >> Pete's sake, is Neethi, and why was it necessary to add it?  Quite a lot
>> of
>> >> stuff for the "simple" task of marshalling and unmarshalling data into
>> >> SOAP-XML packets and sending them across the wire.  From their names, it
>> >> looks as though some of them repeat functionality that is available in
>> other
>> >> jars - but who has time to investigate?  I also have a little nagging
>> fear
>> >> that down the road a few weeks, when I have to add my NEXT web service
>> >> client to this app (and this one uses AXIS) I will end up adding another
>> >> bunch of jars, some of which may conflict with the ones just added.
>> >> In other words I feel that I've lost control of my application.
>> >>
>> >> Prior to this, I understood my dependencies.  I understand that there's
>> a
>> >> tradeoff here.  In return for letting go of control of my dependencies,
>> I
>> >> have a potentially much simpler and more automated build process - and I
>> >> know that's  a good thing - especially when and if I convert the
>> project's
>> >> entire build process to Maven.  And speaking of CXF in particular, I
>> like
>> >> that the client code I need to write is not particularly ugly, as it is
>> with
>> >> some other SOAP platforms (AXIS - grr grr).  But I continue to wonder
>> >> whether it isn't a problem that Maven encourages these chains of
>> >> dependencies that grow geometrically without appropriate consideration
>> to
>> >> developer understanding being given.  For the sake of developer
>> >> understanding, would it perhaps be a good thing if pom.xml dependency
>> >> elements had a required <comment> element that the composer of a POM
>> would
>> >> have to think about before issuing a POM to the world?  Or maybe a newer
>> >> version of CXF will pare the dependencies down to what is truly needed
>> to
>> >> run client-side and server-side apps.
>> >>
>> >> <end of rant>
>> >
>> >
>> > --
>> >
>> > Christian Schneider
>> > ---
>> > http://www.liquid-reality.de
>> >
>> >
>>
>

Re: Grr. Maven.

[Benson Margulies <bi...@gmail.com>]

Steve,

Evidence here increasingly suggests that our problem is documentation.
You can certainly enumerate a set of CXF artifacts in your POM that
don't ever, ever, drag in jetty or other server-specific large lumps.

--benson


On Mon, Dec 1, 2008 at 9:04 AM, Steve Cohen <sc...@javactivity.org> wrote:
> My two cents:
>
> Speaking from my point of view, and I don't think I'm unique, it might be a
> good thing to separate the bundles for CXF-based Clients from those for
> CXF-based servers.   As a client-side developer, I shouldn't need and don't
> want all the flexibility that a server-side WS developer would need.  After
> all, is client independence of server not practically the whole point of
> SOAP?  If someone writes a dot-net client for a CXF based web service, all
> this java would certainly not be carried over from the server side.  Why
> should the java client have to carry that burden?
>
> Jetty, for example, comes to mind.  Jetty, as I understand it, is a server
> technology that shouldn't be necessary in a client.  If they have some
> useful utilities, those ought to be packaged separately or else replaced.
>  Same goes for Spring.
> Take these for what they're worth.  I am merely a CXF newbie with lots (too
> much?) software development experience.  I know the devil is in the details
> and I don't know the details.
>
>
> Benson Margulies wrote:
>>
>> Sergey,
>>
>> What is the maven artifact name of the minimal bundle? And what have
>> we got for Confluence advertising thereof?
>>
>> --benson
>>
>>
>> On Mon, Dec 1, 2008 at 8:29 AM, Sergey Beryozkin
>> <se...@progress.com> wrote:
>>
>>>
>>> At least, in trunk/distribution, a similar idea is followed.
>>> We have a standard all-inclusive CXF bundle, then we have a minimal one
>>> which excludes the tools, rest, xmlbeans and it's only about soap really,
>>> etc and we also have a jaxrs bundle...
>>>
>>> Cheers, Sergey
>>>
>>>
>>>>
>>>> would it be possible to use different maven profiles to manage different
>>>> dependancy sets. e.g. CXF without Rest support / CXF REST only / CXF
>>>> without
>>>> WS-Security etc...
>>>>
>>>> On Mon, Dec 1, 2008 at 1:16 PM, Benson Margulies
>>>> <bi...@gmail.com>wrote:
>>>>
>>>>
>>>>>
>>>>> Christian,
>>>>>
>>>>> This perhaps ought to move to dev, but ...
>>>>>
>>>>> What exactly do you have in mind when you say, 'clean out'?
>>>>>
>>>>> It might be one of several things.
>>>>>
>>>>> 1) Divorce CXF entirely from some of its dependencies.
>>>>> 2) Document much more carefully what you actually have to have to
>>>>> operate in various popular scenarios.
>>>>> 3) tweak the Maven dependencies so that a vanilla user doing a vanilla
>>>>> build downloads a less stuff?
>>>>>
>>>>> --benson
>>>>>
>>>>>
>>>>> On Mon, Dec 1, 2008 at 2:13 AM, Christian Schneider
>>>>> <ch...@die-schneider.net> wrote:
>>>>>
>>>>>>
>>>>>> Hi Steve,
>>>>>>
>>>>>> I basically think you are right. CXF introduces a lot of dependencies
>>>>>>
>>>>>
>>>>> when
>>>>>
>>>>>>
>>>>>> you add it to your application. For a project manager at the company I
>>>>>>
>>>>>
>>>>> work
>>>>>
>>>>>>
>>>>>> this was almost a reason to throw CXF out and do
>>>>>> the parsing by hand. While many maven projects tend to collect
>>>>>>
>>>>>
>>>>> dependencies
>>>>>
>>>>>>
>>>>>> CXF is an especially bad example here.
>>>>>>
>>>>>> I would vote for making cleaning out dependencies a high priority
>>>>>> issue.
>>>>>> What do other CXF developers think?
>>>>>>
>>>>>> BTW. If you have CXF in your project it does not make a lot of sense
>>>>>> to
>>>>>>
>>>>>
>>>>> also
>>>>>
>>>>>>
>>>>>> use Axis. I think you should decide on time for your project which
>>>>>> webservice stack to use and stick with it.
>>>>>>
>>>>>> Greetings
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>> Steve Cohen schrieb:
>>>>>>
>>>>>>>
>>>>>>> My "problem" is more philosophical than anything, and I'm not sure
>>>>>>> it's
>>>>>>> really a problem.  But, consider that by adding a web service client,
>>>>>>> a
>>>>>>> small new piece of my application's functionality, the WAR file size
>>>>>>> has
>>>>>>> ballooned in size from 3MB to over 10MB.  Additionally, as I look at
>>>>>>> the
>>>>>>>
>>>>>
>>>>> 33
>>>>>
>>>>>>>
>>>>>>> or so jars it was necessary to add to the war in order to get the
>>>>>>> thing
>>>>>>>
>>>>>
>>>>> to
>>>>>
>>>>>>>
>>>>>>> run (and I manually hacked 14 out of the dependencies generated by
>>>>>>> Maven
>>>>>>> which I found NOT to be needed), I can't say I know what most of them
>>>>>>>
>>>>>
>>>>> do.
>>>>>
>>>>>>>
>>>>>>>  Why, for example, was it necessary to include pieces of the Spring
>>>>>>> framework, even though my application doesn't use that framework?
>>>>>>>  What,
>>>>>>>
>>>>>
>>>>> for
>>>>>
>>>>>>>
>>>>>>> Pete's sake, is Neethi, and why was it necessary to add it?  Quite a
>>>>>>> lot
>>>>>>>
>>>>>
>>>>> of
>>>>>
>>>>>>>
>>>>>>> stuff for the "simple" task of marshalling and unmarshalling data
>>>>>>> into
>>>>>>> SOAP-XML packets and sending them across the wire.  From their names,
>>>>>>> it
>>>>>>> looks as though some of them repeat functionality that is available
>>>>>>> in
>>>>>>>
>>>>>
>>>>> other
>>>>>
>>>>>>>
>>>>>>> jars - but who has time to investigate?  I also have a little nagging
>>>>>>>
>>>>>
>>>>> fear
>>>>>
>>>>>>>
>>>>>>> that down the road a few weeks, when I have to add my NEXT web
>>>>>>> service
>>>>>>> client to this app (and this one uses AXIS) I will end up adding
>>>>>>> another
>>>>>>> bunch of jars, some of which may conflict with the ones just added.
>>>>>>> In other words I feel that I've lost control of my application.
>>>>>>>
>>>>>>> Prior to this, I understood my dependencies.  I understand that
>>>>>>> there's
>>>>>>>
>>>>>
>>>>> a
>>>>>
>>>>>>>
>>>>>>> tradeoff here.  In return for letting go of control of my
>>>>>>> dependencies,
>>>>>>>
>>>>>
>>>>> I
>>>>>
>>>>>>>
>>>>>>> have a potentially much simpler and more automated build process -
>>>>>>> and
>>>>>>> I
>>>>>>> know that's  a good thing - especially when and if I convert the
>>>>>>>
>>>>>
>>>>> project's
>>>>>
>>>>>>>
>>>>>>> entire build process to Maven.  And speaking of CXF in particular, I
>>>>>>>
>>>>>
>>>>> like
>>>>>
>>>>>>>
>>>>>>> that the client code I need to write is not particularly ugly, as it
>>>>>>> is
>>>>>>>
>>>>>
>>>>> with
>>>>>
>>>>>>>
>>>>>>> some other SOAP platforms (AXIS - grr grr).  But I continue to wonder
>>>>>>> whether it isn't a problem that Maven encourages these chains of
>>>>>>> dependencies that grow geometrically without appropriate
>>>>>>> consideration
>>>>>>>
>>>>>
>>>>> to
>>>>>
>>>>>>>
>>>>>>> developer understanding being given.  For the sake of developer
>>>>>>> understanding, would it perhaps be a good thing if pom.xml dependency
>>>>>>> elements had a required <comment> element that the composer of a POM
>>>>>>>
>>>>>
>>>>> would
>>>>>
>>>>>>>
>>>>>>> have to think about before issuing a POM to the world?  Or maybe a
>>>>>>> newer
>>>>>>> version of CXF will pare the dependencies down to what is truly
>>>>>>> needed
>>>>>>>
>>>>>
>>>>> to
>>>>>
>>>>>>>
>>>>>>> run client-side and server-side apps.
>>>>>>>
>>>>>>> <end of rant>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Christian Schneider
>>>>>> ---
>>>>>> http://www.liquid-reality.de
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>
>>
>>
>
>

Re: Grr. Maven.

[Daniel Kulp <dk...@apache.org>]

On Monday 01 December 2008 9:04:03 am Steve Cohen wrote:
> Speaking from my point of view, and I don't think I'm unique, it might
> be a good thing to separate the bundles for CXF-based Clients from those
> for CXF-based servers.   As a client-side developer, I shouldn't need
> and don't want all the flexibility that a server-side WS developer would
> need.  After all, is client independence of server not practically the
> whole point of SOAP?  If someone writes a dot-net client for a CXF based
> web service, all this java would certainly not be carried over from the
> server side.  Why should the java client have to carry that burden?
>
> Jetty, for example, comes to mind.  Jetty, as I understand it, is a
> server technology that shouldn't be necessary in a client.  If they have
> some useful utilities, those ought to be packaged separately or else
> replaced.  Same goes for Spring.

Except both Jetty and Spring are required client side with CXF as well for 
certain use cases.

1) Jetty is needed client side if you use WS-Addressing or WS-RM with 
decoupled endpoints/responses.   Those specs require the client to bring up 
and HTTP server that the server will send the responses to.      Also, the 
JAX-WS spec specifically dictates that in your own code, you can do 
a "Endpoint.publish(...)"  in you application (even a standalone application) 
to startup an endpoint.   (combined with WS-Addressing, it allows a callback 
pattern)

2) Spring is pretty much required (kind of, I suppose you COULD do it all 
programatically) if you are going to configure anything about the clients.  
Things like https certs, policies, etc...    That all requires the spring 
configs.

> Take these for what they're worth.  I am merely a CXF newbie with lots
> (too much?) software development experience.  I know the devil is in the
> details and I don't know the details.

There definitely is some stuff in CXF that is "server side or tooling" only 
that could be pulled from a client install.   Things like the javascript 
generation, the JAXRS stuff right now, probably management, but it's really 
not much and still have enough there to pass the JAX-WS TCK.

Dan


>
> Benson Margulies wrote:
> > Sergey,
> >
> > What is the maven artifact name of the minimal bundle? And what have
> > we got for Confluence advertising thereof?
> >
> > --benson
> >
> >
> > On Mon, Dec 1, 2008 at 8:29 AM, Sergey Beryozkin
> >
> > <se...@progress.com> wrote:
> >> At least, in trunk/distribution, a similar idea is followed.
> >> We have a standard all-inclusive CXF bundle, then we have a minimal one
> >> which excludes the tools, rest, xmlbeans and it's only about soap
> >> really, etc and we also have a jaxrs bundle...
> >>
> >> Cheers, Sergey
> >>
> >>> would it be possible to use different maven profiles to manage
> >>> different dependancy sets. e.g. CXF without Rest support / CXF REST
> >>> only / CXF without
> >>> WS-Security etc...
> >>>
> >>> On Mon, Dec 1, 2008 at 1:16 PM, Benson Margulies
> >>>
> >>> <bi...@gmail.com>wrote:
> >>>> Christian,
> >>>>
> >>>> This perhaps ought to move to dev, but ...
> >>>>
> >>>> What exactly do you have in mind when you say, 'clean out'?
> >>>>
> >>>> It might be one of several things.
> >>>>
> >>>> 1) Divorce CXF entirely from some of its dependencies.
> >>>> 2) Document much more carefully what you actually have to have to
> >>>> operate in various popular scenarios.
> >>>> 3) tweak the Maven dependencies so that a vanilla user doing a vanilla
> >>>> build downloads a less stuff?
> >>>>
> >>>> --benson
> >>>>
> >>>>
> >>>> On Mon, Dec 1, 2008 at 2:13 AM, Christian Schneider
> >>>>
> >>>> <ch...@die-schneider.net> wrote:
> >>>>> Hi Steve,
> >>>>>
> >>>>> I basically think you are right. CXF introduces a lot of dependencies
> >>>>
> >>>> when
> >>>>
> >>>>> you add it to your application. For a project manager at the company
> >>>>> I
> >>>>
> >>>> work
> >>>>
> >>>>> this was almost a reason to throw CXF out and do
> >>>>> the parsing by hand. While many maven projects tend to collect
> >>>>
> >>>> dependencies
> >>>>
> >>>>> CXF is an especially bad example here.
> >>>>>
> >>>>> I would vote for making cleaning out dependencies a high priority
> >>>>> issue.
> >>>>> What do other CXF developers think?
> >>>>>
> >>>>> BTW. If you have CXF in your project it does not make a lot of sense
> >>>>> to
> >>>>
> >>>> also
> >>>>
> >>>>> use Axis. I think you should decide on time for your project which
> >>>>> webservice stack to use and stick with it.
> >>>>>
> >>>>> Greetings
> >>>>>
> >>>>> Christian
> >>>>>
> >>>>> Steve Cohen schrieb:
> >>>>>> My "problem" is more philosophical than anything, and I'm not sure
> >>>>>> it's
> >>>>>> really a problem.  But, consider that by adding a web service
> >>>>>> client, a
> >>>>>> small new piece of my application's functionality, the WAR file size
> >>>>>> has
> >>>>>> ballooned in size from 3MB to over 10MB.  Additionally, as I look at
> >>>>>> the
> >>>>
> >>>> 33
> >>>>
> >>>>>> or so jars it was necessary to add to the war in order to get the
> >>>>>> thing
> >>>>
> >>>> to
> >>>>
> >>>>>> run (and I manually hacked 14 out of the dependencies generated by
> >>>>>> Maven
> >>>>>> which I found NOT to be needed), I can't say I know what most of
> >>>>>> them
> >>>>
> >>>> do.
> >>>>
> >>>>>>  Why, for example, was it necessary to include pieces of the Spring
> >>>>>> framework, even though my application doesn't use that framework?
> >>>>>>  What,
> >>>>
> >>>> for
> >>>>
> >>>>>> Pete's sake, is Neethi, and why was it necessary to add it?  Quite a
> >>>>>> lot
> >>>>
> >>>> of
> >>>>
> >>>>>> stuff for the "simple" task of marshalling and unmarshalling data
> >>>>>> into SOAP-XML packets and sending them across the wire.  From their
> >>>>>> names, it
> >>>>>> looks as though some of them repeat functionality that is available
> >>>>>> in
> >>>>
> >>>> other
> >>>>
> >>>>>> jars - but who has time to investigate?  I also have a little
> >>>>>> nagging
> >>>>
> >>>> fear
> >>>>
> >>>>>> that down the road a few weeks, when I have to add my NEXT web
> >>>>>> service client to this app (and this one uses AXIS) I will end up
> >>>>>> adding another
> >>>>>> bunch of jars, some of which may conflict with the ones just added.
> >>>>>> In other words I feel that I've lost control of my application.
> >>>>>>
> >>>>>> Prior to this, I understood my dependencies.  I understand that
> >>>>>> there's
> >>>>
> >>>> a
> >>>>
> >>>>>> tradeoff here.  In return for letting go of control of my
> >>>>>> dependencies,
> >>>>
> >>>> I
> >>>>
> >>>>>> have a potentially much simpler and more automated build process -
> >>>>>> and I
> >>>>>> know that's  a good thing - especially when and if I convert the
> >>>>
> >>>> project's
> >>>>
> >>>>>> entire build process to Maven.  And speaking of CXF in particular, I
> >>>>
> >>>> like
> >>>>
> >>>>>> that the client code I need to write is not particularly ugly, as it
> >>>>>> is
> >>>>
> >>>> with
> >>>>
> >>>>>> some other SOAP platforms (AXIS - grr grr).  But I continue to
> >>>>>> wonder whether it isn't a problem that Maven encourages these chains
> >>>>>> of dependencies that grow geometrically without appropriate
> >>>>>> consideration
> >>>>
> >>>> to
> >>>>
> >>>>>> developer understanding being given.  For the sake of developer
> >>>>>> understanding, would it perhaps be a good thing if pom.xml
> >>>>>> dependency elements had a required <comment> element that the
> >>>>>> composer of a POM
> >>>>
> >>>> would
> >>>>
> >>>>>> have to think about before issuing a POM to the world?  Or maybe a
> >>>>>> newer
> >>>>>> version of CXF will pare the dependencies down to what is truly
> >>>>>> needed
> >>>>
> >>>> to
> >>>>
> >>>>>> run client-side and server-side apps.
> >>>>>>
> >>>>>> <end of rant>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Christian Schneider
> >>>>> ---
> >>>>> http://www.liquid-reality.de



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Grr. Maven.

[Steve Cohen <sc...@javactivity.org>]

My two cents:

Speaking from my point of view, and I don't think I'm unique, it might 
be a good thing to separate the bundles for CXF-based Clients from those 
for CXF-based servers.   As a client-side developer, I shouldn't need 
and don't want all the flexibility that a server-side WS developer would 
need.  After all, is client independence of server not practically the 
whole point of SOAP?  If someone writes a dot-net client for a CXF based 
web service, all this java would certainly not be carried over from the 
server side.  Why should the java client have to carry that burden?

Jetty, for example, comes to mind.  Jetty, as I understand it, is a 
server technology that shouldn't be necessary in a client.  If they have 
some useful utilities, those ought to be packaged separately or else 
replaced.  Same goes for Spring. 

Take these for what they're worth.  I am merely a CXF newbie with lots 
(too much?) software development experience.  I know the devil is in the 
details and I don't know the details.

 
Benson Margulies wrote:
> Sergey,
>
> What is the maven artifact name of the minimal bundle? And what have
> we got for Confluence advertising thereof?
>
> --benson
>
>
> On Mon, Dec 1, 2008 at 8:29 AM, Sergey Beryozkin
> <se...@progress.com> wrote:
>   
>> At least, in trunk/distribution, a similar idea is followed.
>> We have a standard all-inclusive CXF bundle, then we have a minimal one
>> which excludes the tools, rest, xmlbeans and it's only about soap really,
>> etc and we also have a jaxrs bundle...
>>
>> Cheers, Sergey
>>
>>     
>>> would it be possible to use different maven profiles to manage different
>>> dependancy sets. e.g. CXF without Rest support / CXF REST only / CXF
>>> without
>>> WS-Security etc...
>>>
>>> On Mon, Dec 1, 2008 at 1:16 PM, Benson Margulies
>>> <bi...@gmail.com>wrote:
>>>
>>>       
>>>> Christian,
>>>>
>>>> This perhaps ought to move to dev, but ...
>>>>
>>>> What exactly do you have in mind when you say, 'clean out'?
>>>>
>>>> It might be one of several things.
>>>>
>>>> 1) Divorce CXF entirely from some of its dependencies.
>>>> 2) Document much more carefully what you actually have to have to
>>>> operate in various popular scenarios.
>>>> 3) tweak the Maven dependencies so that a vanilla user doing a vanilla
>>>> build downloads a less stuff?
>>>>
>>>> --benson
>>>>
>>>>
>>>> On Mon, Dec 1, 2008 at 2:13 AM, Christian Schneider
>>>> <ch...@die-schneider.net> wrote:
>>>>         
>>>>> Hi Steve,
>>>>>
>>>>> I basically think you are right. CXF introduces a lot of dependencies
>>>>>           
>>>> when
>>>>         
>>>>> you add it to your application. For a project manager at the company I
>>>>>           
>>>> work
>>>>         
>>>>> this was almost a reason to throw CXF out and do
>>>>> the parsing by hand. While many maven projects tend to collect
>>>>>           
>>>> dependencies
>>>>         
>>>>> CXF is an especially bad example here.
>>>>>
>>>>> I would vote for making cleaning out dependencies a high priority
>>>>> issue.
>>>>> What do other CXF developers think?
>>>>>
>>>>> BTW. If you have CXF in your project it does not make a lot of sense to
>>>>>           
>>>> also
>>>>         
>>>>> use Axis. I think you should decide on time for your project which
>>>>> webservice stack to use and stick with it.
>>>>>
>>>>> Greetings
>>>>>
>>>>> Christian
>>>>>
>>>>> Steve Cohen schrieb:
>>>>>           
>>>>>> My "problem" is more philosophical than anything, and I'm not sure
>>>>>> it's
>>>>>> really a problem.  But, consider that by adding a web service client,
>>>>>> a
>>>>>> small new piece of my application's functionality, the WAR file size
>>>>>> has
>>>>>> ballooned in size from 3MB to over 10MB.  Additionally, as I look at
>>>>>> the
>>>>>>             
>>>> 33
>>>>         
>>>>>> or so jars it was necessary to add to the war in order to get the
>>>>>> thing
>>>>>>             
>>>> to
>>>>         
>>>>>> run (and I manually hacked 14 out of the dependencies generated by
>>>>>> Maven
>>>>>> which I found NOT to be needed), I can't say I know what most of them
>>>>>>             
>>>> do.
>>>>         
>>>>>>  Why, for example, was it necessary to include pieces of the Spring
>>>>>> framework, even though my application doesn't use that framework?
>>>>>>  What,
>>>>>>             
>>>> for
>>>>         
>>>>>> Pete's sake, is Neethi, and why was it necessary to add it?  Quite a
>>>>>> lot
>>>>>>             
>>>> of
>>>>         
>>>>>> stuff for the "simple" task of marshalling and unmarshalling data into
>>>>>> SOAP-XML packets and sending them across the wire.  From their names,
>>>>>> it
>>>>>> looks as though some of them repeat functionality that is available in
>>>>>>             
>>>> other
>>>>         
>>>>>> jars - but who has time to investigate?  I also have a little nagging
>>>>>>             
>>>> fear
>>>>         
>>>>>> that down the road a few weeks, when I have to add my NEXT web service
>>>>>> client to this app (and this one uses AXIS) I will end up adding
>>>>>> another
>>>>>> bunch of jars, some of which may conflict with the ones just added.
>>>>>> In other words I feel that I've lost control of my application.
>>>>>>
>>>>>> Prior to this, I understood my dependencies.  I understand that
>>>>>> there's
>>>>>>             
>>>> a
>>>>         
>>>>>> tradeoff here.  In return for letting go of control of my
>>>>>> dependencies,
>>>>>>             
>>>> I
>>>>         
>>>>>> have a potentially much simpler and more automated build process - and
>>>>>> I
>>>>>> know that's  a good thing - especially when and if I convert the
>>>>>>             
>>>> project's
>>>>         
>>>>>> entire build process to Maven.  And speaking of CXF in particular, I
>>>>>>             
>>>> like
>>>>         
>>>>>> that the client code I need to write is not particularly ugly, as it
>>>>>> is
>>>>>>             
>>>> with
>>>>         
>>>>>> some other SOAP platforms (AXIS - grr grr).  But I continue to wonder
>>>>>> whether it isn't a problem that Maven encourages these chains of
>>>>>> dependencies that grow geometrically without appropriate consideration
>>>>>>             
>>>> to
>>>>         
>>>>>> developer understanding being given.  For the sake of developer
>>>>>> understanding, would it perhaps be a good thing if pom.xml dependency
>>>>>> elements had a required <comment> element that the composer of a POM
>>>>>>             
>>>> would
>>>>         
>>>>>> have to think about before issuing a POM to the world?  Or maybe a
>>>>>> newer
>>>>>> version of CXF will pare the dependencies down to what is truly needed
>>>>>>             
>>>> to
>>>>         
>>>>>> run client-side and server-side apps.
>>>>>>
>>>>>> <end of rant>
>>>>>>             
>>>>> --
>>>>>
>>>>> Christian Schneider
>>>>> ---
>>>>> http://www.liquid-reality.de
>>>>>
>>>>>
>>>>>           
>>
>>     
>
>
>   

Re: Grr. Maven.

[Sergey Beryozkin <se...@progress.com>]

Hi Benson

Eoghan and myself introduced this seperate bundle as part of DOSGi work - just to minimize the overall DOSGi RI size. Arguably the 
difference in sizes between all-inclusive and cxf-minimal bundles is negligible on 2.0.x line, but it's becoming a bit more 
noticeable on 2.1.x and and indeed on 2.2.

have a look here please

http://svn.apache.org/repos/asf/cxf/trunk/distribution/bundle

Eoghan reported some issues with a cxf-minimal bundle but these issues are OSGI-related, that is some unexpected Import-Package 
instructions are present in the bundle manifest - so it should not prevent users from using it in a non-OSGI environment. That said, 
perhaps we need to sort out an OSGi issue first before starting to document about this bundle (see, I found an excuse why this 
bundle has not been mentioned yet on the wiki :-))

Cheers, Sergey

----- Original Message ----- 
From: "Benson Margulies" <bi...@gmail.com>
To: <us...@cxf.apache.org>
Sent: Monday, December 01, 2008 1:33 PM
Subject: Re: Grr. Maven.


> Sergey,
>
> What is the maven artifact name of the minimal bundle? And what have
> we got for Confluence advertising thereof?
>
> --benson
>
>
> On Mon, Dec 1, 2008 at 8:29 AM, Sergey Beryozkin
> <se...@progress.com> wrote:
>> At least, in trunk/distribution, a similar idea is followed.
>> We have a standard all-inclusive CXF bundle, then we have a minimal one
>> which excludes the tools, rest, xmlbeans and it's only about soap really,
>> etc and we also have a jaxrs bundle...
>>
>> Cheers, Sergey
>>
>>> would it be possible to use different maven profiles to manage different
>>> dependancy sets. e.g. CXF without Rest support / CXF REST only / CXF
>>> without
>>> WS-Security etc...
>>>
>>> On Mon, Dec 1, 2008 at 1:16 PM, Benson Margulies
>>> <bi...@gmail.com>wrote:
>>>
>>>> Christian,
>>>>
>>>> This perhaps ought to move to dev, but ...
>>>>
>>>> What exactly do you have in mind when you say, 'clean out'?
>>>>
>>>> It might be one of several things.
>>>>
>>>> 1) Divorce CXF entirely from some of its dependencies.
>>>> 2) Document much more carefully what you actually have to have to
>>>> operate in various popular scenarios.
>>>> 3) tweak the Maven dependencies so that a vanilla user doing a vanilla
>>>> build downloads a less stuff?
>>>>
>>>> --benson
>>>>
>>>>
>>>> On Mon, Dec 1, 2008 at 2:13 AM, Christian Schneider
>>>> <ch...@die-schneider.net> wrote:
>>>> > Hi Steve,
>>>> >
>>>> > I basically think you are right. CXF introduces a lot of dependencies
>>>> when
>>>> > you add it to your application. For a project manager at the company I
>>>> work
>>>> > this was almost a reason to throw CXF out and do
>>>> > the parsing by hand. While many maven projects tend to collect
>>>> dependencies
>>>> > CXF is an especially bad example here.
>>>> >
>>>> > I would vote for making cleaning out dependencies a high priority
>>>> > issue.
>>>> > What do other CXF developers think?
>>>> >
>>>> > BTW. If you have CXF in your project it does not make a lot of sense to
>>>> also
>>>> > use Axis. I think you should decide on time for your project which
>>>> > webservice stack to use and stick with it.
>>>> >
>>>> > Greetings
>>>> >
>>>> > Christian
>>>> >
>>>> > Steve Cohen schrieb:
>>>> >>
>>>> >> My "problem" is more philosophical than anything, and I'm not sure
>>>> >> it's
>>>> >> really a problem.  But, consider that by adding a web service client,
>>>> >> a
>>>> >> small new piece of my application's functionality, the WAR file size
>>>> >> has
>>>> >> ballooned in size from 3MB to over 10MB.  Additionally, as I look at
>>>> >> the
>>>> 33
>>>> >> or so jars it was necessary to add to the war in order to get the
>>>> >> thing
>>>> to
>>>> >> run (and I manually hacked 14 out of the dependencies generated by
>>>> >> Maven
>>>> >> which I found NOT to be needed), I can't say I know what most of them
>>>> do.
>>>> >>  Why, for example, was it necessary to include pieces of the Spring
>>>> >> framework, even though my application doesn't use that framework?
>>>> >>  What,
>>>> for
>>>> >> Pete's sake, is Neethi, and why was it necessary to add it?  Quite a
>>>> >> lot
>>>> of
>>>> >> stuff for the "simple" task of marshalling and unmarshalling data into
>>>> >> SOAP-XML packets and sending them across the wire.  From their names,
>>>> >> it
>>>> >> looks as though some of them repeat functionality that is available in
>>>> other
>>>> >> jars - but who has time to investigate?  I also have a little nagging
>>>> fear
>>>> >> that down the road a few weeks, when I have to add my NEXT web service
>>>> >> client to this app (and this one uses AXIS) I will end up adding
>>>> >> another
>>>> >> bunch of jars, some of which may conflict with the ones just added.
>>>> >> In other words I feel that I've lost control of my application.
>>>> >>
>>>> >> Prior to this, I understood my dependencies.  I understand that
>>>> >> there's
>>>> a
>>>> >> tradeoff here.  In return for letting go of control of my
>>>> >> dependencies,
>>>> I
>>>> >> have a potentially much simpler and more automated build process - and
>>>> >> I
>>>> >> know that's  a good thing - especially when and if I convert the
>>>> project's
>>>> >> entire build process to Maven.  And speaking of CXF in particular, I
>>>> like
>>>> >> that the client code I need to write is not particularly ugly, as it
>>>> >> is
>>>> with
>>>> >> some other SOAP platforms (AXIS - grr grr).  But I continue to wonder
>>>> >> whether it isn't a problem that Maven encourages these chains of
>>>> >> dependencies that grow geometrically without appropriate consideration
>>>> to
>>>> >> developer understanding being given.  For the sake of developer
>>>> >> understanding, would it perhaps be a good thing if pom.xml dependency
>>>> >> elements had a required <comment> element that the composer of a POM
>>>> would
>>>> >> have to think about before issuing a POM to the world?  Or maybe a
>>>> >> newer
>>>> >> version of CXF will pare the dependencies down to what is truly needed
>>>> to
>>>> >> run client-side and server-side apps.
>>>> >>
>>>> >> <end of rant>
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> > Christian Schneider
>>>> > ---
>>>> > http://www.liquid-reality.de
>>>> >
>>>> >
>>>>
>>>
>>
>>
>>
> 

Re: Grr. Maven.

[Benson Margulies <bi...@gmail.com>]

Sergey,

What is the maven artifact name of the minimal bundle? And what have
we got for Confluence advertising thereof?

--benson


On Mon, Dec 1, 2008 at 8:29 AM, Sergey Beryozkin
<se...@progress.com> wrote:
> At least, in trunk/distribution, a similar idea is followed.
> We have a standard all-inclusive CXF bundle, then we have a minimal one
> which excludes the tools, rest, xmlbeans and it's only about soap really,
> etc and we also have a jaxrs bundle...
>
> Cheers, Sergey
>
>> would it be possible to use different maven profiles to manage different
>> dependancy sets. e.g. CXF without Rest support / CXF REST only / CXF
>> without
>> WS-Security etc...
>>
>> On Mon, Dec 1, 2008 at 1:16 PM, Benson Margulies
>> <bi...@gmail.com>wrote:
>>
>>> Christian,
>>>
>>> This perhaps ought to move to dev, but ...
>>>
>>> What exactly do you have in mind when you say, 'clean out'?
>>>
>>> It might be one of several things.
>>>
>>> 1) Divorce CXF entirely from some of its dependencies.
>>> 2) Document much more carefully what you actually have to have to
>>> operate in various popular scenarios.
>>> 3) tweak the Maven dependencies so that a vanilla user doing a vanilla
>>> build downloads a less stuff?
>>>
>>> --benson
>>>
>>>
>>> On Mon, Dec 1, 2008 at 2:13 AM, Christian Schneider
>>> <ch...@die-schneider.net> wrote:
>>> > Hi Steve,
>>> >
>>> > I basically think you are right. CXF introduces a lot of dependencies
>>> when
>>> > you add it to your application. For a project manager at the company I
>>> work
>>> > this was almost a reason to throw CXF out and do
>>> > the parsing by hand. While many maven projects tend to collect
>>> dependencies
>>> > CXF is an especially bad example here.
>>> >
>>> > I would vote for making cleaning out dependencies a high priority
>>> > issue.
>>> > What do other CXF developers think?
>>> >
>>> > BTW. If you have CXF in your project it does not make a lot of sense to
>>> also
>>> > use Axis. I think you should decide on time for your project which
>>> > webservice stack to use and stick with it.
>>> >
>>> > Greetings
>>> >
>>> > Christian
>>> >
>>> > Steve Cohen schrieb:
>>> >>
>>> >> My "problem" is more philosophical than anything, and I'm not sure
>>> >> it's
>>> >> really a problem.  But, consider that by adding a web service client,
>>> >> a
>>> >> small new piece of my application's functionality, the WAR file size
>>> >> has
>>> >> ballooned in size from 3MB to over 10MB.  Additionally, as I look at
>>> >> the
>>> 33
>>> >> or so jars it was necessary to add to the war in order to get the
>>> >> thing
>>> to
>>> >> run (and I manually hacked 14 out of the dependencies generated by
>>> >> Maven
>>> >> which I found NOT to be needed), I can't say I know what most of them
>>> do.
>>> >>  Why, for example, was it necessary to include pieces of the Spring
>>> >> framework, even though my application doesn't use that framework?
>>> >>  What,
>>> for
>>> >> Pete's sake, is Neethi, and why was it necessary to add it?  Quite a
>>> >> lot
>>> of
>>> >> stuff for the "simple" task of marshalling and unmarshalling data into
>>> >> SOAP-XML packets and sending them across the wire.  From their names,
>>> >> it
>>> >> looks as though some of them repeat functionality that is available in
>>> other
>>> >> jars - but who has time to investigate?  I also have a little nagging
>>> fear
>>> >> that down the road a few weeks, when I have to add my NEXT web service
>>> >> client to this app (and this one uses AXIS) I will end up adding
>>> >> another
>>> >> bunch of jars, some of which may conflict with the ones just added.
>>> >> In other words I feel that I've lost control of my application.
>>> >>
>>> >> Prior to this, I understood my dependencies.  I understand that
>>> >> there's
>>> a
>>> >> tradeoff here.  In return for letting go of control of my
>>> >> dependencies,
>>> I
>>> >> have a potentially much simpler and more automated build process - and
>>> >> I
>>> >> know that's  a good thing - especially when and if I convert the
>>> project's
>>> >> entire build process to Maven.  And speaking of CXF in particular, I
>>> like
>>> >> that the client code I need to write is not particularly ugly, as it
>>> >> is
>>> with
>>> >> some other SOAP platforms (AXIS - grr grr).  But I continue to wonder
>>> >> whether it isn't a problem that Maven encourages these chains of
>>> >> dependencies that grow geometrically without appropriate consideration
>>> to
>>> >> developer understanding being given.  For the sake of developer
>>> >> understanding, would it perhaps be a good thing if pom.xml dependency
>>> >> elements had a required <comment> element that the composer of a POM
>>> would
>>> >> have to think about before issuing a POM to the world?  Or maybe a
>>> >> newer
>>> >> version of CXF will pare the dependencies down to what is truly needed
>>> to
>>> >> run client-side and server-side apps.
>>> >>
>>> >> <end of rant>
>>> >
>>> >
>>> > --
>>> >
>>> > Christian Schneider
>>> > ---
>>> > http://www.liquid-reality.de
>>> >
>>> >
>>>
>>
>
>
>

Re: Grr. Maven.

[Sergey Beryozkin <se...@progress.com>]

At least, in trunk/distribution, a similar idea is followed.
We have a standard all-inclusive CXF bundle, then we have a minimal one which excludes the tools, rest, xmlbeans and it's only about 
soap really, etc and we also have a jaxrs bundle...

Cheers, Sergey

> would it be possible to use different maven profiles to manage different
> dependancy sets. e.g. CXF without Rest support / CXF REST only / CXF without
> WS-Security etc...
>
> On Mon, Dec 1, 2008 at 1:16 PM, Benson Margulies <bi...@gmail.com>wrote:
>
>> Christian,
>>
>> This perhaps ought to move to dev, but ...
>>
>> What exactly do you have in mind when you say, 'clean out'?
>>
>> It might be one of several things.
>>
>> 1) Divorce CXF entirely from some of its dependencies.
>> 2) Document much more carefully what you actually have to have to
>> operate in various popular scenarios.
>> 3) tweak the Maven dependencies so that a vanilla user doing a vanilla
>> build downloads a less stuff?
>>
>> --benson
>>
>>
>> On Mon, Dec 1, 2008 at 2:13 AM, Christian Schneider
>> <ch...@die-schneider.net> wrote:
>> > Hi Steve,
>> >
>> > I basically think you are right. CXF introduces a lot of dependencies
>> when
>> > you add it to your application. For a project manager at the company I
>> work
>> > this was almost a reason to throw CXF out and do
>> > the parsing by hand. While many maven projects tend to collect
>> dependencies
>> > CXF is an especially bad example here.
>> >
>> > I would vote for making cleaning out dependencies a high priority issue.
>> > What do other CXF developers think?
>> >
>> > BTW. If you have CXF in your project it does not make a lot of sense to
>> also
>> > use Axis. I think you should decide on time for your project which
>> > webservice stack to use and stick with it.
>> >
>> > Greetings
>> >
>> > Christian
>> >
>> > Steve Cohen schrieb:
>> >>
>> >> My "problem" is more philosophical than anything, and I'm not sure it's
>> >> really a problem.  But, consider that by adding a web service client, a
>> >> small new piece of my application's functionality, the WAR file size has
>> >> ballooned in size from 3MB to over 10MB.  Additionally, as I look at the
>> 33
>> >> or so jars it was necessary to add to the war in order to get the thing
>> to
>> >> run (and I manually hacked 14 out of the dependencies generated by Maven
>> >> which I found NOT to be needed), I can't say I know what most of them
>> do.
>> >>  Why, for example, was it necessary to include pieces of the Spring
>> >> framework, even though my application doesn't use that framework?  What,
>> for
>> >> Pete's sake, is Neethi, and why was it necessary to add it?  Quite a lot
>> of
>> >> stuff for the "simple" task of marshalling and unmarshalling data into
>> >> SOAP-XML packets and sending them across the wire.  From their names, it
>> >> looks as though some of them repeat functionality that is available in
>> other
>> >> jars - but who has time to investigate?  I also have a little nagging
>> fear
>> >> that down the road a few weeks, when I have to add my NEXT web service
>> >> client to this app (and this one uses AXIS) I will end up adding another
>> >> bunch of jars, some of which may conflict with the ones just added.
>> >> In other words I feel that I've lost control of my application.
>> >>
>> >> Prior to this, I understood my dependencies.  I understand that there's
>> a
>> >> tradeoff here.  In return for letting go of control of my dependencies,
>> I
>> >> have a potentially much simpler and more automated build process - and I
>> >> know that's  a good thing - especially when and if I convert the
>> project's
>> >> entire build process to Maven.  And speaking of CXF in particular, I
>> like
>> >> that the client code I need to write is not particularly ugly, as it is
>> with
>> >> some other SOAP platforms (AXIS - grr grr).  But I continue to wonder
>> >> whether it isn't a problem that Maven encourages these chains of
>> >> dependencies that grow geometrically without appropriate consideration
>> to
>> >> developer understanding being given.  For the sake of developer
>> >> understanding, would it perhaps be a good thing if pom.xml dependency
>> >> elements had a required <comment> element that the composer of a POM
>> would
>> >> have to think about before issuing a POM to the world?  Or maybe a newer
>> >> version of CXF will pare the dependencies down to what is truly needed
>> to
>> >> run client-side and server-side apps.
>> >>
>> >> <end of rant>
>> >
>> >
>> > --
>> >
>> > Christian Schneider
>> > ---
>> > http://www.liquid-reality.de
>> >
>> >
>>
> 

Re: Grr. Maven.

[Adrian Corcoran <ad...@gmail.com>]

would it be possible to use different maven profiles to manage different
dependancy sets. e.g. CXF without Rest support / CXF REST only / CXF without
WS-Security etc...

On Mon, Dec 1, 2008 at 1:16 PM, Benson Margulies <bi...@gmail.com>wrote:

> Christian,
>
> This perhaps ought to move to dev, but ...
>
> What exactly do you have in mind when you say, 'clean out'?
>
> It might be one of several things.
>
> 1) Divorce CXF entirely from some of its dependencies.
> 2) Document much more carefully what you actually have to have to
> operate in various popular scenarios.
> 3) tweak the Maven dependencies so that a vanilla user doing a vanilla
> build downloads a less stuff?
>
> --benson
>
>
> On Mon, Dec 1, 2008 at 2:13 AM, Christian Schneider
> <ch...@die-schneider.net> wrote:
> > Hi Steve,
> >
> > I basically think you are right. CXF introduces a lot of dependencies
> when
> > you add it to your application. For a project manager at the company I
> work
> > this was almost a reason to throw CXF out and do
> > the parsing by hand. While many maven projects tend to collect
> dependencies
> > CXF is an especially bad example here.
> >
> > I would vote for making cleaning out dependencies a high priority issue.
> > What do other CXF developers think?
> >
> > BTW. If you have CXF in your project it does not make a lot of sense to
> also
> > use Axis. I think you should decide on time for your project which
> > webservice stack to use and stick with it.
> >
> > Greetings
> >
> > Christian
> >
> > Steve Cohen schrieb:
> >>
> >> My "problem" is more philosophical than anything, and I'm not sure it's
> >> really a problem.  But, consider that by adding a web service client, a
> >> small new piece of my application's functionality, the WAR file size has
> >> ballooned in size from 3MB to over 10MB.  Additionally, as I look at the
> 33
> >> or so jars it was necessary to add to the war in order to get the thing
> to
> >> run (and I manually hacked 14 out of the dependencies generated by Maven
> >> which I found NOT to be needed), I can't say I know what most of them
> do.
> >>  Why, for example, was it necessary to include pieces of the Spring
> >> framework, even though my application doesn't use that framework?  What,
> for
> >> Pete's sake, is Neethi, and why was it necessary to add it?  Quite a lot
> of
> >> stuff for the "simple" task of marshalling and unmarshalling data into
> >> SOAP-XML packets and sending them across the wire.  From their names, it
> >> looks as though some of them repeat functionality that is available in
> other
> >> jars - but who has time to investigate?  I also have a little nagging
> fear
> >> that down the road a few weeks, when I have to add my NEXT web service
> >> client to this app (and this one uses AXIS) I will end up adding another
> >> bunch of jars, some of which may conflict with the ones just added.
> >> In other words I feel that I've lost control of my application.
> >>
> >> Prior to this, I understood my dependencies.  I understand that there's
> a
> >> tradeoff here.  In return for letting go of control of my dependencies,
> I
> >> have a potentially much simpler and more automated build process - and I
> >> know that's  a good thing - especially when and if I convert the
> project's
> >> entire build process to Maven.  And speaking of CXF in particular, I
> like
> >> that the client code I need to write is not particularly ugly, as it is
> with
> >> some other SOAP platforms (AXIS - grr grr).  But I continue to wonder
> >> whether it isn't a problem that Maven encourages these chains of
> >> dependencies that grow geometrically without appropriate consideration
> to
> >> developer understanding being given.  For the sake of developer
> >> understanding, would it perhaps be a good thing if pom.xml dependency
> >> elements had a required <comment> element that the composer of a POM
> would
> >> have to think about before issuing a POM to the world?  Or maybe a newer
> >> version of CXF will pare the dependencies down to what is truly needed
> to
> >> run client-side and server-side apps.
> >>
> >> <end of rant>
> >
> >
> > --
> >
> > Christian Schneider
> > ---
> > http://www.liquid-reality.de
> >
> >
>

Re: Grr. Maven.

[Daniel Kulp <dk...@apache.org>]

On Tuesday 02 December 2008 6:50:00 am Ian Roberts wrote:
> I can see why CXF has so many *compile-time* dependencies, but I think
> the original question was more like how many of these dependencies are
> actually required at run time if you're only doing simple stuff like a
> single JAX-WS client that doesn't use WS-anything?  Presumably this case
> would only use a subset of the classes in each CXF module.

The JAX-WS TCK/Compliance statement that we have actually throws the biggest 
wrinkle in things.   To claim compliance, the "out of the box"/"default" 
experience HAS to be completely compliant.   Thus, anything that JAX-WS 
REQUIRES would have to be "runtime" scope dependencies, not "provided" 
or "optional".   Thus, things like WS-Addressing, catalogs, etc.... would 
have to be full runtime deps.

Thus, for JAX-WS stuff, it may really be a "documentation" exercise to state 
which deps you should be able to "exclude".

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Grr. Maven.

[Ian Roberts <i....@dcs.shef.ac.uk>]

I can see why CXF has so many *compile-time* dependencies, but I think
the original question was more like how many of these dependencies are
actually required at run time if you're only doing simple stuff like a
single JAX-WS client that doesn't use WS-anything?  Presumably this case
would only use a subset of the classes in each CXF module.

Ian

-- 
Ian Roberts               | Department of Computer Science
i.roberts@dcs.shef.ac.uk  | University of Sheffield, UK

Re: Grr. Maven.

[Christian Schneider <ch...@die-schneider.net>]

Hi Benson,

I think a good example is cxf-api. It depends on:
- neethi
- cxf-common utilities
- cxf-common-schemas
- geronimo-activation
- geronimo-j2ee-connector_1.5_spec
- XmlSchema
- wstx-asl
- geronimo-annotation_1.0_spec

When you include transitive dependencies it is even worse:

- wsdl4j
- commons-lang
- geronimo-stax-api_1.0_spec
- spring-context
- jaxb-api
- xml-resolver
- spring-beans
- aopaliance
- spring-core
- commons-logging

No one can tell me that an api package needs all this. ;-)
Most transitive dependencies come from cxf-common-utilities. So I think 
a good starting point would be to try to remove the dependency to 
commons-utilities.

To keep track of dependencies we could do some metrics. For example we 
could track the number of direct and transitive dependencies for each 
module over time. Then we could set the goal for us all to try to lower 
the dependency numbers over time.

Greetings

Christian


Benson Margulies schrieb:
> Christian,
>
> This perhaps ought to move to dev, but ...
>
> What exactly do you have in mind when you say, 'clean out'?
>
> It might be one of several things.
>
> 1) Divorce CXF entirely from some of its dependencies.
> 2) Document much more carefully what you actually have to have to
> operate in various popular scenarios.
> 3) tweak the Maven dependencies so that a vanilla user doing a vanilla
> build downloads a less stuff?
>
> --benson
>
>   
>> --
>>
>> Christian Schneider
>> ---
>> http://www.liquid-reality.de
>>
>>
>>     
>
>   


-- 

Christian Schneider
---
http://www.liquid-reality.de

Re: Grr. Maven.

[Benson Margulies <bi...@gmail.com>]

Christian,

This perhaps ought to move to dev, but ...

What exactly do you have in mind when you say, 'clean out'?

It might be one of several things.

1) Divorce CXF entirely from some of its dependencies.
2) Document much more carefully what you actually have to have to
operate in various popular scenarios.
3) tweak the Maven dependencies so that a vanilla user doing a vanilla
build downloads a less stuff?

--benson


On Mon, Dec 1, 2008 at 2:13 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> Hi Steve,
>
> I basically think you are right. CXF introduces a lot of dependencies when
> you add it to your application. For a project manager at the company I work
> this was almost a reason to throw CXF out and do
> the parsing by hand. While many maven projects tend to collect dependencies
> CXF is an especially bad example here.
>
> I would vote for making cleaning out dependencies a high priority issue.
> What do other CXF developers think?
>
> BTW. If you have CXF in your project it does not make a lot of sense to also
> use Axis. I think you should decide on time for your project which
> webservice stack to use and stick with it.
>
> Greetings
>
> Christian
>
> Steve Cohen schrieb:
>>
>> My "problem" is more philosophical than anything, and I'm not sure it's
>> really a problem.  But, consider that by adding a web service client, a
>> small new piece of my application's functionality, the WAR file size has
>> ballooned in size from 3MB to over 10MB.  Additionally, as I look at the 33
>> or so jars it was necessary to add to the war in order to get the thing to
>> run (and I manually hacked 14 out of the dependencies generated by Maven
>> which I found NOT to be needed), I can't say I know what most of them do.
>>  Why, for example, was it necessary to include pieces of the Spring
>> framework, even though my application doesn't use that framework?  What, for
>> Pete's sake, is Neethi, and why was it necessary to add it?  Quite a lot of
>> stuff for the "simple" task of marshalling and unmarshalling data into
>> SOAP-XML packets and sending them across the wire.  From their names, it
>> looks as though some of them repeat functionality that is available in other
>> jars - but who has time to investigate?  I also have a little nagging fear
>> that down the road a few weeks, when I have to add my NEXT web service
>> client to this app (and this one uses AXIS) I will end up adding another
>> bunch of jars, some of which may conflict with the ones just added.
>> In other words I feel that I've lost control of my application.
>>
>> Prior to this, I understood my dependencies.  I understand that there's a
>> tradeoff here.  In return for letting go of control of my dependencies, I
>> have a potentially much simpler and more automated build process - and I
>> know that's  a good thing - especially when and if I convert the project's
>> entire build process to Maven.  And speaking of CXF in particular, I like
>> that the client code I need to write is not particularly ugly, as it is with
>> some other SOAP platforms (AXIS - grr grr).  But I continue to wonder
>> whether it isn't a problem that Maven encourages these chains of
>> dependencies that grow geometrically without appropriate consideration to
>> developer understanding being given.  For the sake of developer
>> understanding, would it perhaps be a good thing if pom.xml dependency
>> elements had a required <comment> element that the composer of a POM would
>> have to think about before issuing a POM to the world?  Or maybe a newer
>> version of CXF will pare the dependencies down to what is truly needed to
>> run client-side and server-side apps.
>>
>> <end of rant>
>
>
> --
>
> Christian Schneider
> ---
> http://www.liquid-reality.de
>
>

Re: Grr. Maven.

[Christian Schneider <ch...@die-schneider.net>]

Hi Steve,

I basically think you are right. CXF introduces a lot of dependencies 
when you add it to your application. For a project manager at the 
company I work this was almost a reason to throw CXF out and do
the parsing by hand. While many maven projects tend to collect 
dependencies CXF is an especially bad example here.

I would vote for making cleaning out dependencies a high priority issue. 
What do other CXF developers think?

BTW. If you have CXF in your project it does not make a lot of sense to 
also use Axis. I think you should decide on time for your project which 
webservice stack to use and stick with it.

Greetings

Christian

Steve Cohen schrieb:
> My "problem" is more philosophical than anything, and I'm not sure 
> it's really a problem.  But, consider that by adding a web service 
> client, a small new piece of my application's functionality, the WAR 
> file size has ballooned in size from 3MB to over 10MB.  Additionally, 
> as I look at the 33 or so jars it was necessary to add to the war in 
> order to get the thing to run (and I manually hacked 14 out of the 
> dependencies generated by Maven which I found NOT to be needed), I 
> can't say I know what most of them do.  Why, for example, was it 
> necessary to include pieces of the Spring framework, even though my 
> application doesn't use that framework?  What, for Pete's sake, is 
> Neethi, and why was it necessary to add it?  Quite a lot of stuff for 
> the "simple" task of marshalling and unmarshalling data into SOAP-XML 
> packets and sending them across the wire.  From their names, it looks 
> as though some of them repeat functionality that is available in other 
> jars - but who has time to investigate?  I also have a little nagging 
> fear that down the road a few weeks, when I have to add my NEXT web 
> service client to this app (and this one uses AXIS) I will end up 
> adding another bunch of jars, some of which may conflict with the ones 
> just added.
> In other words I feel that I've lost control of my application.
>
> Prior to this, I understood my dependencies.  I understand that 
> there's a tradeoff here.  In return for letting go of control of my 
> dependencies, I have a potentially much simpler and more automated 
> build process - and I know that's  a good thing - especially when and 
> if I convert the project's entire build process to Maven.  And 
> speaking of CXF in particular, I like that the client code I need to 
> write is not particularly ugly, as it is with some other SOAP 
> platforms (AXIS - grr grr).  But I continue to wonder whether it isn't 
> a problem that Maven encourages these chains of dependencies that grow 
> geometrically without appropriate consideration to developer 
> understanding being given.  For the sake of developer understanding, 
> would it perhaps be a good thing if pom.xml dependency elements had a 
> required <comment> element that the composer of a POM would have to 
> think about before issuing a POM to the world?  Or maybe a newer 
> version of CXF will pare the dependencies down to what is truly needed 
> to run client-side and server-side apps.
>
> <end of rant>


-- 

Christian Schneider
---
http://www.liquid-reality.de

Re: Grr. Maven.

[Benson Margulies <bi...@gmail.com>]

This is a very interesting rant, and it raises a number of interesting
questions.

It seems to me that there is a missing maven feature that would lessen
your misery. If POM's had a slot for an explanation of each
dependency, and there was a 'dependency-report' goal that produced an
annotated tree, you would at least be able to answer the question 'Why
is Neethi in here?'

Outside of Maven, I see an issue of development style. The Web Service
world grows and grows. WS-this, WS-that. These things are far more
complex than ye old original SOAP format. CXF gets bigger, and it
grows dependencies on things. Even relatively basic things are not so
simple. To get XML in and out and around at speed, we use WoodStoX.

Even more basically, we have a low activation energy for adding
dependencies. If there's something we need, and someone's got a
package out there that does it, we add a dependency. We rarely ask,
'and how many megabytes of extraneous byte code are we dragging in to
get what we want?'

After all disk space is cheap, and life is short, and some of us are
doing this more for fun than for work. (To Ars Longa, Vita Brevis, add
Discus Cheapus?)



On Sun, Nov 30, 2008 at 5:08 PM, Steve Cohen <sc...@javactivity.org> wrote:
> My "problem" is more philosophical than anything, and I'm not sure it's
> really a problem.  But, consider that by adding a web service client, a
> small new piece of my application's functionality, the WAR file size has
> ballooned in size from 3MB to over 10MB.  Additionally, as I look at the 33
> or so jars it was necessary to add to the war in order to get the thing to
> run (and I manually hacked 14 out of the dependencies generated by Maven
> which I found NOT to be needed), I can't say I know what most of them do.
>  Why, for example, was it necessary to include pieces of the Spring
> framework, even though my application doesn't use that framework?  What, for
> Pete's sake, is Neethi, and why was it necessary to add it?  Quite a lot of
> stuff for the "simple" task of marshalling and unmarshalling data into
> SOAP-XML packets and sending them across the wire.  From their names, it
> looks as though some of them repeat functionality that is available in other
> jars - but who has time to investigate?  I also have a little nagging fear
> that down the road a few weeks, when I have to add my NEXT web service
> client to this app (and this one uses AXIS) I will end up adding another
> bunch of jars, some of which may conflict with the ones just added.
> In other words I feel that I've lost control of my application.
>
> Prior to this, I understood my dependencies.  I understand that there's a
> tradeoff here.  In return for letting go of control of my dependencies, I
> have a potentially much simpler and more automated build process - and I
> know that's  a good thing - especially when and if I convert the project's
> entire build process to Maven.  And speaking of CXF in particular, I like
> that the client code I need to write is not particularly ugly, as it is with
> some other SOAP platforms (AXIS - grr grr).  But I continue to wonder
> whether it isn't a problem that Maven encourages these chains of
> dependencies that grow geometrically without appropriate consideration to
> developer understanding being given.  For the sake of developer
> understanding, would it perhaps be a good thing if pom.xml dependency
> elements had a required <comment> element that the composer of a POM would
> have to think about before issuing a POM to the world?  Or maybe a newer
> version of CXF will pare the dependencies down to what is truly needed to
> run client-side and server-side apps.
>
> <end of rant>
>
>
> Brad O'Hearne wrote:
>>
>> Steve,
>>
>> So that I understand the problem properly, is your problem that building
>> downloads jars from maven repositories, or that these jars are getting
>> packaged into your WAR file, and you don't want that to happen, due to some
>> proprietary approach to deploying dependencies in your app server
>> environment?
>>
>> Thanks,
>>
>> Brad
>>
>> On Nov 24, 2008, at 4:02 PM, Christian Schneider wrote:
>>
>>> In this case you can perhaps use the following maven plugin.
>>> It copies all jars you depend on into a folder target/lib. This is
>>> probably what you need to build your war file the old way.
>>>
>>>    <plugin>
>>>      <groupId>org.codehaus.mojo</groupId>
>>>      <artifactId>dependency-maven-plugin</artifactId>
>>>      <executions>
>>>        <execution>
>>>          <id>copy-dependencies</id>
>>>          <phase>package</phase>
>>>          <goals>
>>>            <goal>copy-dependencies</goal>
>>>          </goals>
>>>          <configuration>
>>>
>>>  <outputDirectory>${project.build.directory}/lib</outputDirectory>
>>>          </configuration>
>>>        </execution>
>>>      </executions>
>>>    </plugin>
>>>
>>> Greetings
>>>
>>> Christian
>>>
>>> Steve Cohen schrieb:
>>>>
>>>> Yeah, that's where I'm at.
>>>> 1) in a BIG company with a Dilbert-style "Productivity Prevention
>>>> Department" :-)
>>>> 2) on the other hand, in a small, practically invisible backwaterish
>>>> part of the BIG company so that there is nothing like an SCM team,
>>>> application not deployed in data center, etc.
>>>> 3) Preexisting product with preexisting handbuilt war including some
>>>> VERY nonstandard proprietary jars and shared libraries that have to be
>>>> included.
>>>> 4) Deadlines
>>>>
>>>> The chances of rewriting the build process anytime soon to use Maven in
>>>> this context are next to nil, notwithstanding the value that Maven
>>>> nonetheless would undoubtedly provide.
>>>>
>>>> But, since the advantages of using CXF here are great, my temporary
>>>> solution is going to have to be
>>>>
>>>>  * build the test project my vendor has supplied me with maven,
>>>>  * transfer the jars maven downloads for me to another location
>>>>  * build the new war incorporating the old stuff and the now stuff
>>>>
>>>> It would be nice to port the whole mess to Maven but I don't have the
>>>> time for it now.
>>>
>>>
>>> --
>>>
>>> Christian Schneider
>>> ---
>>> http://www.liquid-reality.de
>>>
>>
>>
>>
>
>

Re: Grr. Maven.

[Steve Cohen <sc...@javactivity.org>]

My "problem" is more philosophical than anything, and I'm not sure it's 
really a problem.  But, consider that by adding a web service client, a 
small new piece of my application's functionality, the WAR file size has 
ballooned in size from 3MB to over 10MB.  Additionally, as I look at the 
33 or so jars it was necessary to add to the war in order to get the 
thing to run (and I manually hacked 14 out of the dependencies generated 
by Maven which I found NOT to be needed), I can't say I know what most 
of them do.  Why, for example, was it necessary to include pieces of the 
Spring framework, even though my application doesn't use that 
framework?  What, for Pete's sake, is Neethi, and why was it necessary 
to add it?  Quite a lot of stuff for the "simple" task of marshalling 
and unmarshalling data into SOAP-XML packets and sending them across the 
wire.  From their names, it looks as though some of them repeat 
functionality that is available in other jars - but who has time to 
investigate?  I also have a little nagging fear that down the road a few 
weeks, when I have to add my NEXT web service client to this app (and 
this one uses AXIS) I will end up adding another bunch of jars, some of 
which may conflict with the ones just added. 

In other words I feel that I've lost control of my application.

Prior to this, I understood my dependencies.  I understand that there's 
a tradeoff here.  In return for letting go of control of my 
dependencies, I have a potentially much simpler and more automated build 
process - and I know that's  a good thing - especially when and if I 
convert the project's entire build process to Maven.  And speaking of 
CXF in particular, I like that the client code I need to write is not 
particularly ugly, as it is with some other SOAP platforms (AXIS - grr 
grr).  But I continue to wonder whether it isn't a problem that Maven 
encourages these chains of dependencies that grow geometrically without 
appropriate consideration to developer understanding being given.  For 
the sake of developer understanding, would it perhaps be a good thing if 
pom.xml dependency elements had a required <comment> element that the 
composer of a POM would have to think about before issuing a POM to the 
world?  Or maybe a newer version of CXF will pare the dependencies down 
to what is truly needed to run client-side and server-side apps.

<end of rant>
 

Brad O'Hearne wrote:
> Steve,
>
> So that I understand the problem properly, is your problem that 
> building downloads jars from maven repositories, or that these jars 
> are getting packaged into your WAR file, and you don't want that to 
> happen, due to some proprietary approach to deploying dependencies in 
> your app server environment?
>
> Thanks,
>
> Brad
>
> On Nov 24, 2008, at 4:02 PM, Christian Schneider wrote:
>
>> In this case you can perhaps use the following maven plugin.
>> It copies all jars you depend on into a folder target/lib. This is 
>> probably what you need to build your war file the old way.
>>
>>     <plugin>
>>       <groupId>org.codehaus.mojo</groupId>
>>       <artifactId>dependency-maven-plugin</artifactId>
>>       <executions>
>>         <execution>
>>           <id>copy-dependencies</id>
>>           <phase>package</phase>
>>           <goals>
>>             <goal>copy-dependencies</goal>
>>           </goals>
>>           <configuration>
>>             
>> <outputDirectory>${project.build.directory}/lib</outputDirectory>
>>           </configuration>
>>         </execution>
>>       </executions>
>>     </plugin>
>>
>> Greetings
>>
>> Christian
>>
>> Steve Cohen schrieb:
>>> Yeah, that's where I'm at.
>>> 1) in a BIG company with a Dilbert-style "Productivity Prevention 
>>> Department" :-)
>>> 2) on the other hand, in a small, practically invisible backwaterish 
>>> part of the BIG company so that there is nothing like an SCM team, 
>>> application not deployed in data center, etc.
>>> 3) Preexisting product with preexisting handbuilt war including some 
>>> VERY nonstandard proprietary jars and shared libraries that have to 
>>> be included.
>>> 4) Deadlines
>>>
>>> The chances of rewriting the build process anytime soon to use Maven 
>>> in this context are next to nil, notwithstanding the value that 
>>> Maven nonetheless would undoubtedly provide.
>>>
>>> But, since the advantages of using CXF here are great, my temporary 
>>> solution is going to have to be
>>>
>>>   * build the test project my vendor has supplied me with maven,
>>>   * transfer the jars maven downloads for me to another location
>>>   * build the new war incorporating the old stuff and the now stuff
>>>
>>> It would be nice to port the whole mess to Maven but I don't have 
>>> the time for it now.
>>
>>
>> -- 
>>
>> Christian Schneider
>> ---
>> http://www.liquid-reality.de
>>
>
>
>

Re: Grr. Maven.

[Brad O'Hearne <br...@bighillsoftware.com>]

Steve,

So that I understand the problem properly, is your problem that  
building downloads jars from maven repositories, or that these jars  
are getting packaged into your WAR file, and you don't want that to  
happen, due to some proprietary approach to deploying dependencies in  
your app server environment?

Thanks,

Brad

On Nov 24, 2008, at 4:02 PM, Christian Schneider wrote:

> In this case you can perhaps use the following maven plugin.
> It copies all jars you depend on into a folder target/lib. This is  
> probably what you need to build your war file the old way.
>
>     <plugin>
>       <groupId>org.codehaus.mojo</groupId>
>       <artifactId>dependency-maven-plugin</artifactId>
>       <executions>
>         <execution>
>           <id>copy-dependencies</id>
>           <phase>package</phase>
>           <goals>
>             <goal>copy-dependencies</goal>
>           </goals>
>           <configuration>
>             <outputDirectory>${project.build.directory}/lib</ 
> outputDirectory>
>           </configuration>
>         </execution>
>       </executions>
>     </plugin>
>
> Greetings
>
> Christian
>
> Steve Cohen schrieb:
>> Yeah, that's where I'm at.
>> 1) in a BIG company with a Dilbert-style "Productivity Prevention  
>> Department" :-)
>> 2) on the other hand, in a small, practically invisible  
>> backwaterish part of the BIG company so that there is nothing like  
>> an SCM team, application not deployed in data center, etc.
>> 3) Preexisting product with preexisting handbuilt war including  
>> some VERY nonstandard proprietary jars and shared libraries that  
>> have to be included.
>> 4) Deadlines
>>
>> The chances of rewriting the build process anytime soon to use  
>> Maven in this context are next to nil, notwithstanding the value  
>> that Maven nonetheless would undoubtedly provide.
>>
>> But, since the advantages of using CXF here are great, my temporary  
>> solution is going to have to be
>>
>>   * build the test project my vendor has supplied me with maven,
>>   * transfer the jars maven downloads for me to another location
>>   * build the new war incorporating the old stuff and the now stuff
>>
>> It would be nice to port the whole mess to Maven but I don't have  
>> the time for it now.
>
>
> -- 
>
> Christian Schneider
> ---
> http://www.liquid-reality.de
>

Re: Grr. Maven.

[Christian Schneider <ch...@die-schneider.net>]

In this case you can perhaps use the following maven plugin.
It copies all jars you depend on into a folder target/lib. This is 
probably what you need to build your war file the old way.

      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>dependency-maven-plugin</artifactId>
        <executions>
          <execution>
            <id>copy-dependencies</id>
            <phase>package</phase>
            <goals>
              <goal>copy-dependencies</goal>
            </goals>
            <configuration>
              
<outputDirectory>${project.build.directory}/lib</outputDirectory>
            </configuration>
          </execution>
        </executions>
      </plugin>

Greetings

Christian

Steve Cohen schrieb:
> Yeah, that's where I'm at.
> 1) in a BIG company with a Dilbert-style "Productivity Prevention 
> Department" :-)
> 2) on the other hand, in a small, practically invisible backwaterish 
> part of the BIG company so that there is nothing like an SCM team, 
> application not deployed in data center, etc.
> 3) Preexisting product with preexisting handbuilt war including some 
> VERY nonstandard proprietary jars and shared libraries that have to be 
> included.
> 4) Deadlines
>
> The chances of rewriting the build process anytime soon to use Maven 
> in this context are next to nil, notwithstanding the value that Maven 
> nonetheless would undoubtedly provide.
>
> But, since the advantages of using CXF here are great, my temporary 
> solution is going to have to be
>
>    * build the test project my vendor has supplied me with maven,
>    * transfer the jars maven downloads for me to another location
>    * build the new war incorporating the old stuff and the now stuff
>
> It would be nice to port the whole mess to Maven but I don't have the 
> time for it now.


-- 

Christian Schneider
---
http://www.liquid-reality.de

Re: Grr. Maven.

[Steve Cohen <sc...@javactivity.org>]

Yeah, that's where I'm at.
1) in a BIG company with a Dilbert-style "Productivity Prevention 
Department" :-)
2) on the other hand, in a small, practically invisible backwaterish 
part of the BIG company so that there is nothing like an SCM team, 
application not deployed in data center, etc.
3) Preexisting product with preexisting handbuilt war including some 
VERY nonstandard proprietary jars and shared libraries that have to be 
included.
4) Deadlines

The chances of rewriting the build process anytime soon to use Maven in 
this context are next to nil, notwithstanding the value that Maven 
nonetheless would undoubtedly provide.

But, since the advantages of using CXF here are great, my temporary 
solution is going to have to be

    * build the test project my vendor has supplied me with maven,
    * transfer the jars maven downloads for me to another location
    * build the new war incorporating the old stuff and the now stuff

It would be nice to port the whole mess to Maven but I don't have the 
time for it now.

Christian Schneider wrote:
> Try the following in your pom:
>
>    <packaging>war</packaging>
>
> and
>    <build>
>        <finalName>${artifactId}</finalName>
>        <plugins>
>            <plugin>
>                <groupId>org.apache.maven.plugins</groupId>
>                <artifactId>maven-eclipse-plugin</artifactId>
>                <configuration>
>                    
> <projectNameTemplate>[artifactId]-[version]</projectNameTemplate>
>                    <wtpmanifest>true</wtpmanifest>
>                    <wtpapplicationxml>true</wtpapplicationxml>
>                    <wtpversion>2.0</wtpversion>
>                    
> <manifest>${basedir}/src/main/resources/META-INF/MANIFEST.MF</manifest>
>                </configuration>
>            </plugin>
>        </plugins>
>    </build>
>
> You can use maven to create your complete war file. It also works 
> together with wtp in eclipse. So you can debug your project.
> Normally you will not use maven directly in production. You create a 
> war file and deploy just like before. On the other hand some of the 
> newer app servers
> start to use maven for deployment. For example geronimo uses a maven 
> repo internally. I guess it won´t be long before you can simply deploy 
> your project and the app server
> loads the dependecies at runtime.
>
> When you want to use maven inside a big company you should use a maven 
> proxy nexus like http://nexus.sonatype.org/ .
> Setting up maven in a big company can be quite some work especially 
> with security people but when you are done the whole process of 
> building and
> deployment works quite smooth.
>
> Greetings
>
> Christian
>
> Steve Cohen schrieb:
>> To compile my client I only needed three of them.  To run my client, 
>> connect to the vendor's Web Service, I have to keep adding things to 
>> my runtime classpath.
>> I am also trying to think a couple steps ahead, when I go from my 
>> simple client test application to deploying my client inside an 
>> existing Tomcat WebApp which has a completely different mechanism for 
>> managing runtime dependencies.  This is why I like to know what I 
>> need and why I need it.  But it seems the stars are aligning against 
>> my philosophy.
>>
>> How is a Maven repository typically accessed in a runtime production 
>> environment?
>>
>> Mick Knutson wrote:
>>> To compile in Maven, you might need to reference all these jars. But 
>>> you
>>> will not need to deploy all those jars. There are many things behind 
>>> the
>>> scenes that you don't see that require many other jars than you are 
>>> used to.
>>> The more you mes with Maven, the more you will totally fall in love 
>>> with
>>> everything it is providing. Even if you don't understand it right now.
>>>
>>> Once you download those jars, they are local and you do NOT have to
>>> re-download everything each time.
>>>
>>>
>>>
>>> On Mon, Nov 24, 2008 at 2:02 PM, Steve Cohen <st...@comcast.net> 
>>> wrote:
>>>
>>>  
>>>> I am trying to build a client to a web-service using their 
>>>> vendor-supplied
>>>> WSDL.  The vendor-recommended approach is to use Maven with their 
>>>> pom.xml.
>>>>
>>>> building the source code brings in something like 50 jars.  Only three
>>>> appear to be needed for compilation, but at runtime, I am adding 
>>>> jar after
>>>> jar to get my code over each succeeding hurdle.
>>>>
>>>> Is this really the way software is developed now?  Call me old 
>>>> fashioned,
>>>> but I like to know what I'm depending on.  It shouldn't require 50 
>>>> jars to
>>>> run a simple SOAP client.  What is the thinking behind this?  Must 
>>>> I bite
>>>> the bullet, load all this crap, and stop thinking about it?
>>>>
>>>>     
>>>
>>>
>>>
>>>   
>>
>>
>
>

Re: Grr. Maven.

[Christian Schneider <ch...@die-schneider.net>]

Try the following in your pom:

    <packaging>war</packaging>

and
    <build>
        <finalName>${artifactId}</finalName>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-eclipse-plugin</artifactId>
                <configuration>
                    
<projectNameTemplate>[artifactId]-[version]</projectNameTemplate>
                    <wtpmanifest>true</wtpmanifest>
                    <wtpapplicationxml>true</wtpapplicationxml>
                    <wtpversion>2.0</wtpversion>
                    
<manifest>${basedir}/src/main/resources/META-INF/MANIFEST.MF</manifest>
                </configuration>
            </plugin>
        </plugins>
    </build>

You can use maven to create your complete war file. It also works 
together with wtp in eclipse. So you can debug your project.
Normally you will not use maven directly in production. You create a war 
file and deploy just like before. On the other hand some of the newer 
app servers
start to use maven for deployment. For example geronimo uses a maven 
repo internally. I guess it won´t be long before you can simply deploy 
your project and the app server
loads the dependecies at runtime.

When you want to use maven inside a big company you should use a maven 
proxy nexus like http://nexus.sonatype.org/ .
Setting up maven in a big company can be quite some work especially with 
security people but when you are done the whole process of building and
deployment works quite smooth.

Greetings

Christian

Steve Cohen schrieb:
> To compile my client I only needed three of them.  To run my client, 
> connect to the vendor's Web Service, I have to keep adding things to 
> my runtime classpath.
> I am also trying to think a couple steps ahead, when I go from my 
> simple client test application to deploying my client inside an 
> existing Tomcat WebApp which has a completely different mechanism for 
> managing runtime dependencies.  This is why I like to know what I need 
> and why I need it.  But it seems the stars are aligning against my 
> philosophy.
>
> How is a Maven repository typically accessed in a runtime production 
> environment?
>
> Mick Knutson wrote:
>> To compile in Maven, you might need to reference all these jars. But you
>> will not need to deploy all those jars. There are many things behind the
>> scenes that you don't see that require many other jars than you are 
>> used to.
>> The more you mes with Maven, the more you will totally fall in love with
>> everything it is providing. Even if you don't understand it right now.
>>
>> Once you download those jars, they are local and you do NOT have to
>> re-download everything each time.
>>
>>
>>
>> On Mon, Nov 24, 2008 at 2:02 PM, Steve Cohen <st...@comcast.net> 
>> wrote:
>>
>>  
>>> I am trying to build a client to a web-service using their 
>>> vendor-supplied
>>> WSDL.  The vendor-recommended approach is to use Maven with their 
>>> pom.xml.
>>>
>>> building the source code brings in something like 50 jars.  Only three
>>> appear to be needed for compilation, but at runtime, I am adding jar 
>>> after
>>> jar to get my code over each succeeding hurdle.
>>>
>>> Is this really the way software is developed now?  Call me old 
>>> fashioned,
>>> but I like to know what I'm depending on.  It shouldn't require 50 
>>> jars to
>>> run a simple SOAP client.  What is the thinking behind this?  Must I 
>>> bite
>>> the bullet, load all this crap, and stop thinking about it?
>>>
>>>     
>>
>>
>>
>>   
>
>


-- 

Christian Schneider
---
http://www.liquid-reality.de

Re: Grr. Maven.

[Benson Margulies <bi...@gmail.com>]

Or, learn to use the shade plugin to combine all your dependencies
into One Giant Jar.

On Mon, Nov 24, 2008 at 3:18 PM, Mick Knutson <mk...@baselogic.com> wrote:
> Do a search for maven-definitive-guide.pdf it is a great read to get you
> into the Maven game.
>
> On Mon, Nov 24, 2008 at 3:11 PM, Steve Cohen <sc...@javactivity.org> wrote:
>
>> Okay thanks, Mick.
>>
>> My SCM Team - that's rich.  I am my own SCM team. :-)
>>
>> Oh well, at least I know what I'm up against.
>>
>>
>>
>> Mick Knutson wrote:
>>
>>  Maven REPO is only accessed to create deployables. Your SCM team would
>>> have
>>> access to the repo to build your production releases only. Nothing else.
>>>
>>>
>>> On Mon, Nov 24, 2008 at 2:46 PM, Steve Cohen <sc...@javactivity.org>
>>> wrote:
>>>
>>>
>>>
>>>> To compile my client I only needed three of them.  To run my client,
>>>> connect to the vendor's Web Service, I have to keep adding things to my
>>>> runtime classpath.
>>>> I am also trying to think a couple steps ahead, when I go from my simple
>>>> client test application to deploying my client inside an existing Tomcat
>>>> WebApp which has a completely different mechanism for managing runtime
>>>> dependencies.  This is why I like to know what I need and why I need it.
>>>>  But it seems the stars are aligning against my philosophy.
>>>>
>>>> How is a Maven repository typically accessed in a runtime production
>>>> environment?
>>>>
>>>>
>>>> Mick Knutson wrote:
>>>>
>>>>
>>>>
>>>>> To compile in Maven, you might need to reference all these jars. But you
>>>>> will not need to deploy all those jars. There are many things behind the
>>>>> scenes that you don't see that require many other jars than you are used
>>>>> to.
>>>>> The more you mes with Maven, the more you will totally fall in love with
>>>>> everything it is providing. Even if you don't understand it right now.
>>>>>
>>>>> Once you download those jars, they are local and you do NOT have to
>>>>> re-download everything each time.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 24, 2008 at 2:02 PM, Steve Cohen <st...@comcast.net>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I am trying to build a client to a web-service using their
>>>>>> vendor-supplied
>>>>>> WSDL.  The vendor-recommended approach is to use Maven with their
>>>>>> pom.xml.
>>>>>>
>>>>>> building the source code brings in something like 50 jars.  Only three
>>>>>> appear to be needed for compilation, but at runtime, I am adding jar
>>>>>> after
>>>>>> jar to get my code over each succeeding hurdle.
>>>>>>
>>>>>> Is this really the way software is developed now?  Call me old
>>>>>> fashioned,
>>>>>> but I like to know what I'm depending on.  It shouldn't require 50 jars
>>>>>> to
>>>>>> run a simple SOAP client.  What is the thinking behind this?  Must I
>>>>>> bite
>>>>>> the bullet, load all this crap, and stop thinking about it?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
> --
> Thank You…
>
> Mick Knutson
> BASE Logic, inc.
> (415) 685-4233
>
> Website: http://baselogic.com
> Blog: http://baselogic.com/blog
> BLiNC Magazine: http://blincmagazine.com
> Linked IN: http://linkedin.com/in/mickknutson
> DJ Mick: http://djmick.com
> MySpace: http://myspace.com/mickknutson
> Vacation Rental: http://tahoe.baselogic.com
>
> coming soon: 866-BLiNC-411: (254-6241-1)
> ---
>

Re: Grr. Maven.

[Mick Knutson <mk...@baselogic.com>]

Do a search for maven-definitive-guide.pdf it is a great read to get you
into the Maven game.

On Mon, Nov 24, 2008 at 3:11 PM, Steve Cohen <sc...@javactivity.org> wrote:

> Okay thanks, Mick.
>
> My SCM Team - that's rich.  I am my own SCM team. :-)
>
> Oh well, at least I know what I'm up against.
>
>
>
> Mick Knutson wrote:
>
>  Maven REPO is only accessed to create deployables. Your SCM team would
>> have
>> access to the repo to build your production releases only. Nothing else.
>>
>>
>> On Mon, Nov 24, 2008 at 2:46 PM, Steve Cohen <sc...@javactivity.org>
>> wrote:
>>
>>
>>
>>> To compile my client I only needed three of them.  To run my client,
>>> connect to the vendor's Web Service, I have to keep adding things to my
>>> runtime classpath.
>>> I am also trying to think a couple steps ahead, when I go from my simple
>>> client test application to deploying my client inside an existing Tomcat
>>> WebApp which has a completely different mechanism for managing runtime
>>> dependencies.  This is why I like to know what I need and why I need it.
>>>  But it seems the stars are aligning against my philosophy.
>>>
>>> How is a Maven repository typically accessed in a runtime production
>>> environment?
>>>
>>>
>>> Mick Knutson wrote:
>>>
>>>
>>>
>>>> To compile in Maven, you might need to reference all these jars. But you
>>>> will not need to deploy all those jars. There are many things behind the
>>>> scenes that you don't see that require many other jars than you are used
>>>> to.
>>>> The more you mes with Maven, the more you will totally fall in love with
>>>> everything it is providing. Even if you don't understand it right now.
>>>>
>>>> Once you download those jars, they are local and you do NOT have to
>>>> re-download everything each time.
>>>>
>>>>
>>>>
>>>> On Mon, Nov 24, 2008 at 2:02 PM, Steve Cohen <st...@comcast.net>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> I am trying to build a client to a web-service using their
>>>>> vendor-supplied
>>>>> WSDL.  The vendor-recommended approach is to use Maven with their
>>>>> pom.xml.
>>>>>
>>>>> building the source code brings in something like 50 jars.  Only three
>>>>> appear to be needed for compilation, but at runtime, I am adding jar
>>>>> after
>>>>> jar to get my code over each succeeding hurdle.
>>>>>
>>>>> Is this really the way software is developed now?  Call me old
>>>>> fashioned,
>>>>> but I like to know what I'm depending on.  It shouldn't require 50 jars
>>>>> to
>>>>> run a simple SOAP client.  What is the thinking behind this?  Must I
>>>>> bite
>>>>> the bullet, load all this crap, and stop thinking about it?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>


-- 
Thank You…

Mick Knutson
BASE Logic, inc.
(415) 685-4233

Website: http://baselogic.com
Blog: http://baselogic.com/blog
BLiNC Magazine: http://blincmagazine.com
Linked IN: http://linkedin.com/in/mickknutson
DJ Mick: http://djmick.com
MySpace: http://myspace.com/mickknutson
Vacation Rental: http://tahoe.baselogic.com

coming soon: 866-BLiNC-411: (254-6241-1)
---

Re: Grr. Maven.

[Steve Cohen <sc...@javactivity.org>]

Okay thanks, Mick.

My SCM Team - that's rich.  I am my own SCM team. :-)

Oh well, at least I know what I'm up against.


Mick Knutson wrote:

> Maven REPO is only accessed to create deployables. Your SCM team would have
> access to the repo to build your production releases only. Nothing else.
>
>
> On Mon, Nov 24, 2008 at 2:46 PM, Steve Cohen <sc...@javactivity.org> wrote:
>
>   
>> To compile my client I only needed three of them.  To run my client,
>> connect to the vendor's Web Service, I have to keep adding things to my
>> runtime classpath.
>> I am also trying to think a couple steps ahead, when I go from my simple
>> client test application to deploying my client inside an existing Tomcat
>> WebApp which has a completely different mechanism for managing runtime
>> dependencies.  This is why I like to know what I need and why I need it.
>>  But it seems the stars are aligning against my philosophy.
>>
>> How is a Maven repository typically accessed in a runtime production
>> environment?
>>
>>
>> Mick Knutson wrote:
>>
>>     
>>> To compile in Maven, you might need to reference all these jars. But you
>>> will not need to deploy all those jars. There are many things behind the
>>> scenes that you don't see that require many other jars than you are used
>>> to.
>>> The more you mes with Maven, the more you will totally fall in love with
>>> everything it is providing. Even if you don't understand it right now.
>>>
>>> Once you download those jars, they are local and you do NOT have to
>>> re-download everything each time.
>>>
>>>
>>>
>>> On Mon, Nov 24, 2008 at 2:02 PM, Steve Cohen <st...@comcast.net>
>>> wrote:
>>>
>>>
>>>
>>>       
>>>> I am trying to build a client to a web-service using their
>>>> vendor-supplied
>>>> WSDL.  The vendor-recommended approach is to use Maven with their
>>>> pom.xml.
>>>>
>>>> building the source code brings in something like 50 jars.  Only three
>>>> appear to be needed for compilation, but at runtime, I am adding jar
>>>> after
>>>> jar to get my code over each succeeding hurdle.
>>>>
>>>> Is this really the way software is developed now?  Call me old fashioned,
>>>> but I like to know what I'm depending on.  It shouldn't require 50 jars
>>>> to
>>>> run a simple SOAP client.  What is the thinking behind this?  Must I bite
>>>> the bullet, load all this crap, and stop thinking about it?
>>>>
>>>>
>>>>
>>>>         
>>>
>>>
>>>
>>>       
>>     
>
>
>   

Re: Grr. Maven.

[Mick Knutson <mk...@baselogic.com>]

Maven REPO is only accessed to create deployables. Your SCM team would have
access to the repo to build your production releases only. Nothing else.


On Mon, Nov 24, 2008 at 2:46 PM, Steve Cohen <sc...@javactivity.org> wrote:

> To compile my client I only needed three of them.  To run my client,
> connect to the vendor's Web Service, I have to keep adding things to my
> runtime classpath.
> I am also trying to think a couple steps ahead, when I go from my simple
> client test application to deploying my client inside an existing Tomcat
> WebApp which has a completely different mechanism for managing runtime
> dependencies.  This is why I like to know what I need and why I need it.
>  But it seems the stars are aligning against my philosophy.
>
> How is a Maven repository typically accessed in a runtime production
> environment?
>
>
> Mick Knutson wrote:
>
>> To compile in Maven, you might need to reference all these jars. But you
>> will not need to deploy all those jars. There are many things behind the
>> scenes that you don't see that require many other jars than you are used
>> to.
>> The more you mes with Maven, the more you will totally fall in love with
>> everything it is providing. Even if you don't understand it right now.
>>
>> Once you download those jars, they are local and you do NOT have to
>> re-download everything each time.
>>
>>
>>
>> On Mon, Nov 24, 2008 at 2:02 PM, Steve Cohen <st...@comcast.net>
>> wrote:
>>
>>
>>
>>> I am trying to build a client to a web-service using their
>>> vendor-supplied
>>> WSDL.  The vendor-recommended approach is to use Maven with their
>>> pom.xml.
>>>
>>> building the source code brings in something like 50 jars.  Only three
>>> appear to be needed for compilation, but at runtime, I am adding jar
>>> after
>>> jar to get my code over each succeeding hurdle.
>>>
>>> Is this really the way software is developed now?  Call me old fashioned,
>>> but I like to know what I'm depending on.  It shouldn't require 50 jars
>>> to
>>> run a simple SOAP client.  What is the thinking behind this?  Must I bite
>>> the bullet, load all this crap, and stop thinking about it?
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>


-- 
Thank You…

Mick Knutson
BASE Logic, inc.
(415) 685-4233

Website: http://baselogic.com
Blog: http://baselogic.com/blog
BLiNC Magazine: http://blincmagazine.com
Linked IN: http://linkedin.com/in/mickknutson
DJ Mick: http://djmick.com
MySpace: http://myspace.com/mickknutson
Vacation Rental: http://tahoe.baselogic.com

coming soon: 866-BLiNC-411: (254-6241-1)
---

Re: Grr. Maven.

[Steve Cohen <sc...@javactivity.org>]

To compile my client I only needed three of them.  To run my client, 
connect to the vendor's Web Service, I have to keep adding things to my 
runtime classpath. 

I am also trying to think a couple steps ahead, when I go from my simple 
client test application to deploying my client inside an existing Tomcat 
WebApp which has a completely different mechanism for managing runtime 
dependencies.  This is why I like to know what I need and why I need 
it.  But it seems the stars are aligning against my philosophy.

How is a Maven repository typically accessed in a runtime production 
environment?

Mick Knutson wrote:
> To compile in Maven, you might need to reference all these jars. But you
> will not need to deploy all those jars. There are many things behind the
> scenes that you don't see that require many other jars than you are used to.
> The more you mes with Maven, the more you will totally fall in love with
> everything it is providing. Even if you don't understand it right now.
>
> Once you download those jars, they are local and you do NOT have to
> re-download everything each time.
>
>
>
> On Mon, Nov 24, 2008 at 2:02 PM, Steve Cohen <st...@comcast.net> wrote:
>
>   
>> I am trying to build a client to a web-service using their vendor-supplied
>> WSDL.  The vendor-recommended approach is to use Maven with their pom.xml.
>>
>> building the source code brings in something like 50 jars.  Only three
>> appear to be needed for compilation, but at runtime, I am adding jar after
>> jar to get my code over each succeeding hurdle.
>>
>> Is this really the way software is developed now?  Call me old fashioned,
>> but I like to know what I'm depending on.  It shouldn't require 50 jars to
>> run a simple SOAP client.  What is the thinking behind this?  Must I bite
>> the bullet, load all this crap, and stop thinking about it?
>>
>>     
>
>
>
>