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 wrote:
Try the following in your pom:

   <packaging>war</packaging>

and
   <build>
       <finalName>${artifactId}</finalName>
       <plugins>
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-eclipse-plugin</artifactId>
               <configuration>
<projectNameTemplate>[artifactId]-[version]</projectNameTemplate>
                   <wtpmanifest>true</wtpmanifest>
                   <wtpapplicationxml>true</wtpapplicationxml>
                   <wtpversion>2.0</wtpversion>
<manifest>${basedir}/src/main/resources/META-INF/MANIFEST.MF</manifest>
               </configuration>
           </plugin>
       </plugins>
   </build>

You can use maven to create your complete war file. It also works together with wtp in eclipse. So you can debug your project. Normally you will not use maven directly in production. You create a war file and deploy just like before. On the other hand some of the newer app servers start to use maven for deployment. For example geronimo uses a maven repo internally. I guess it won´t be long before you can simply deploy your project and the app server
loads the dependecies at runtime.

When you want to use maven inside a big company you should use a maven proxy nexus like http://nexus.sonatype.org/ . Setting up maven in a big company can be quite some work especially with security people but when you are done the whole process of building and
deployment works quite smooth.

Greetings

Christian

Steve Cohen schrieb:
To compile my client I only needed three of them. To run my client, connect to the vendor's Web Service, I have to keep adding things to my runtime classpath. I am also trying to think a couple steps ahead, when I go from my simple client test application to deploying my client inside an existing Tomcat WebApp which has a completely different mechanism for managing runtime dependencies. This is why I like to know what I need and why I need it. But it seems the stars are aligning against my philosophy.

How is a Maven repository typically accessed in a runtime production environment?

Mick Knutson wrote:
To compile in Maven, you might need to reference all these jars. But you will not need to deploy all those jars. There are many things behind the scenes that you don't see that require many other jars than you are used to. The more you mes with Maven, the more you will totally fall in love with
everything it is providing. Even if you don't understand it right now.

Once you download those jars, they are local and you do NOT have to
re-download everything each time.



On Mon, Nov 24, 2008 at 2:02 PM, Steve Cohen <[EMAIL PROTECTED]> wrote:

I am trying to build a client to a web-service using their vendor-supplied WSDL. The vendor-recommended approach is to use Maven with their pom.xml.

building the source code brings in something like 50 jars.  Only three
appear to be needed for compilation, but at runtime, I am adding jar after
jar to get my code over each succeeding hurdle.

Is this really the way software is developed now? Call me old fashioned, but I like to know what I'm depending on. It shouldn't require 50 jars to run a simple SOAP client. What is the thinking behind this? Must I bite
the bullet, load all this crap, and stop thinking about it?









Reply via email to