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
>
>
