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
