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