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