Hi Benson
Eoghan and myself introduced this seperate bundle as part of DOSGi work - just to minimize the overall DOSGi RI size. Arguably the
difference in sizes between all-inclusive and cxf-minimal bundles is negligible on 2.0.x line, but it's becoming a bit more
noticeable on 2.1.x and and indeed on 2.2.
have a look here please
http://svn.apache.org/repos/asf/cxf/trunk/distribution/bundle
Eoghan reported some issues with a cxf-minimal bundle but these issues are OSGI-related, that is some unexpected Import-Package
instructions are present in the bundle manifest - so it should not prevent users from using it in a non-OSGI environment. That said,
perhaps we need to sort out an OSGi issue first before starting to document about this bundle (see, I found an excuse why this
bundle has not been mentioned yet on the wiki :-))
Cheers, Sergey
----- Original Message -----
From: "Benson Margulies" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, December 01, 2008 1:33 PM
Subject: Re: Grr. Maven.
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
>
>
