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 <[EMAIL PROTECTED]> 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 > >
