Interesting discussion. Let me jump in here.....
In the "lib" directory of our distribution, there is a "WHICH_JARS" file which
lists which jars are required for various bits of functionality:
http://svn.apache.org/repos/asf/cxf/trunk/distribution/src/main/release/lib/WHICH_JARS
That MAY help a bit. However, it probably would be good to document what
each jar really provides and why it's needed.
On Sunday 30 November 2008 5:08:06 pm Steve Cohen wrote:
> 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?
Cause CXF does use it? Most of the wiring of CXF itself is done with Spring.
CXF can provide limited functionality without spring, but if you want to do
any advanced configuration, you're most likely going to need Spring.
Also, the JMS transport now uses Spring JMS. Thus, if you need soap/jms,
you need spring.
> What, for Pete's sake, is Neethi, and why was it necessary
> to add it?
Neethi is the WS-Policy implementation. That said, if you aren't using any
policy assertions we probably could somehow make this optional. That's
definitely something we could look into. For basic soap/http, this could be
removable. However, once we start getting the WS-SecurityPolicy stuff
flushed, it would DEFINITELY be required for that.
This is actually a "problem" with our "common" and "api" modules. They pull
in a bunch of deps that may not be needed if nothing uses those parts of the
apis. Some of these could be marked "provided" in the api module and then
make them runtime/compile scope in the modules that really need them. (in
this case, the ws-policy module)
> 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.
In all honesty, the difference between server and client side deps is almost
nill. In fact, I cannot think of anything other than the tooling stuff.
You MAY think that Jetty is not client side, but if you use WS-RM or
WS-Addressing, it IS required on the client side.
One thing that I ran into last week that could be a big help is to flush out a
useful set of Maven archetypes that would be good "getting started" points
for various things. The poms they produce could be "minimal deps" type
things. While working on a Maven presentation last week, I discovered our
single "hello world, java first" archetype actually didn't work. I've fixed
that on trunk, but it definitely shows there isn't much work done in that
area. We really should have a several archetypes to use as getting started
things. A "jax-rs" archetype. A "wsdl first client" archetype, a "wsdl
first war" archetype, security, etc....
Another thing I started but haven't completed was to get things to work with
the versions of various things built into Java 6. Specifically JAXB.
Right now, if using Java6, you can remove SOME of the jars, but JAXB isn't
one of them. On trunk, the RUNTIME will work with the in-jdk jaxb, but none
of the tooling will.
Dan
>
> <end of rant>
>
> Brad O'Hearne wrote:
> > Steve,
> >
> > So that I understand the problem properly, is your problem that
> > building downloads jars from maven repositories, or that these jars
> > are getting packaged into your WAR file, and you don't want that to
> > happen, due to some proprietary approach to deploying dependencies in
> > your app server environment?
> >
> > Thanks,
> >
> > Brad
> >
> > On Nov 24, 2008, at 4:02 PM, Christian Schneider wrote:
> >> In this case you can perhaps use the following maven plugin.
> >> It copies all jars you depend on into a folder target/lib. This is
> >> probably what you need to build your war file the old way.
> >>
> >> <plugin>
> >> <groupId>org.codehaus.mojo</groupId>
> >> <artifactId>dependency-maven-plugin</artifactId>
> >> <executions>
> >> <execution>
> >> <id>copy-dependencies</id>
> >> <phase>package</phase>
> >> <goals>
> >> <goal>copy-dependencies</goal>
> >> </goals>
> >> <configuration>
> >>
> >> <outputDirectory>${project.build.directory}/lib</outputDirectory>
> >> </configuration>
> >> </execution>
> >> </executions>
> >> </plugin>
> >>
> >> Greetings
> >>
> >> Christian
> >>
> >> Steve Cohen schrieb:
> >>> Yeah, that's where I'm at.
> >>> 1) in a BIG company with a Dilbert-style "Productivity Prevention
> >>> Department" :-)
> >>> 2) on the other hand, in a small, practically invisible backwaterish
> >>> part of the BIG company so that there is nothing like an SCM team,
> >>> application not deployed in data center, etc.
> >>> 3) Preexisting product with preexisting handbuilt war including some
> >>> VERY nonstandard proprietary jars and shared libraries that have to
> >>> be included.
> >>> 4) Deadlines
> >>>
> >>> The chances of rewriting the build process anytime soon to use Maven
> >>> in this context are next to nil, notwithstanding the value that
> >>> Maven nonetheless would undoubtedly provide.
> >>>
> >>> But, since the advantages of using CXF here are great, my temporary
> >>> solution is going to have to be
> >>>
> >>> * build the test project my vendor has supplied me with maven,
> >>> * transfer the jars maven downloads for me to another location
> >>> * build the new war incorporating the old stuff and the now stuff
> >>>
> >>> It would be nice to port the whole mess to Maven but I don't have
> >>> the time for it now.
> >>
> >> --
> >>
> >> Christian Schneider
> >> ---
> >> http://www.liquid-reality.de
--
Daniel Kulp
[EMAIL PROTECTED]
http://dankulp.com/blog
