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?
--
Christian Schneider
---
http://www.liquid-reality.de
