Christof,
${project.build.directory}/${project.build.finalName} is not really 'the war
built by the war plugin'. It is a temporary directory that is very nearly
the same as what ends up in the .war file, but is not quite identical. For
example, it won't have a MANIFEST.MF.
The only way to get a true unpacked war, complete with all the eventual
behaviors of the archive plugin, to use for testing is dependency:unpack. I
ended up moving all my tests to a new project that unpacks the war build in
the initial project and then starts up the integration test circus.
There are also some issues with classpath management, at least with
jetty:run. I haven't tried tomcat:run for a while.
--benson
On Sat, Sep 4, 2010 at 11:12 AM, chris_kal <[email protected]>wrote:
>
> Hi Wayne,
>
> thanks for your quick reply. I found the answer to my problem, which is
> using the 'tomcat:run-war' instead of the 'tomcat:run' goal. But let me
> describe my original problem which might help others with similar problems:
>
> 1. In our web app we are uploading files and store them in a directory
> under
> the Tomcat docbase so that Tomcat can deliver those files (at least in the
> development environment). We use the method
> session.getServletContext().getRealPath() for that.
>
> 2. When i used the 'tomcat:run' goal those uploaded files were stored under
> /src/main/webapp and you definitely don't want to have them there. So I
> found the <webSourceDirectory> parameter and changed it to
> ${project.build.directory}/${project.build.finalName} which is the
> directory
> build by the maven-war-plugin. The Tomcat docBase was changed but now all
> the class and resources files were there twice: in the WEB-INF/classes
> directory of ${project.build.directory}/${project.build.finalName} and in
> target/classes because that directory is added to the Tomcat classpath. So
> I
> wanted to avoid that and found the <classesDir> which doesn't work.
>
> So I found the solution to use 'tomcat:run-war' with a <warDirectory> set
> to
> ${project.build.directory}/${project.build.finalName} which does exactly
> what I want.
>
> Chris
>
>
>
> Wayne Fay wrote:
> >
> >> trying to avoid that the ${project.build.outputDirectory} (which is
> >> target/classes) is added to the classloader classpath. I found the
> >> classesDir parameter in the documentation. No matter what value I give
> to
> >
> > Why do you want to do this? If this is a common need, it may be smart
> > to have a new feature added to the plugin to support this
> > functionality that you require.
> >
> > Wayne
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/Tomcat-Maven-Plugin-classesDir-tp29617622p29621720.html
> Sent from the mojo - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
