This is a very interesting rant, and it raises a number of interesting
questions.
It seems to me that there is a missing maven feature that would lessen
your misery. If POM's had a slot for an explanation of each
dependency, and there was a 'dependency-report' goal that produced an
annotated tree, you would at least be able to answer the question 'Why
is Neethi in here?'
Outside of Maven, I see an issue of development style. The Web Service
world grows and grows. WS-this, WS-that. These things are far more
complex than ye old original SOAP format. CXF gets bigger, and it
grows dependencies on things. Even relatively basic things are not so
simple. To get XML in and out and around at speed, we use WoodStoX.
Even more basically, we have a low activation energy for adding
dependencies. If there's something we need, and someone's got a
package out there that does it, we add a dependency. We rarely ask,
'and how many megabytes of extraneous byte code are we dragging in to
get what we want?'
After all disk space is cheap, and life is short, and some of us are
doing this more for fun than for work. (To Ars Longa, Vita Brevis, add
Discus Cheapus?)
On Sun, Nov 30, 2008 at 5:08 PM, Steve Cohen <[EMAIL PROTECTED]> 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? 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>
>
>
> 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
>>>
>>
>>
>>
>
>
