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