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