cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies" <bimargul...@gmail.com>
Subject Re: Grr. Maven.
Date Mon, 01 Dec 2008 14:08:52 GMT
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 <scohen@javactivity.org> 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
>> <sergey.beryozkin@progress.com> 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
>>>> <bimargulies@gmail.com>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
>>>>> <chris@die-schneider.net> 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
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>
>>
>>
>
>

Mime
View raw message