Unless you're doing something unconventional, it shouldn't be painful. We may getting off-topic, but if you would like to post your project pom and any parents, I'll take a peek and see if there's anything that leaps out at me.
My gut says your build is omitting dependencies that Maven expects to be in the classpath but they aren't in your Tomcat environment. When you unpack your war, do you see all the jarfiles you expect in WEB-INF/libs? Look for missing jars or multiple versions of the same dependencies (that's a dog that has bitten me many times). If the jars aren't there they would have to be in the Java runtime classpath or in Tomcat's global classpath, yes? You mentioned integration testing... Your war works with other servlet containers? Perhaps there is a dependency that the other containers provide as a standard that tomcat does not. On Tue, Dec 2, 2014 at 4:52 AM, James Green <james.mk.gr...@gmail.com> wrote: > What you wrote as a set of suggestions was my original attempt. Then I read > (possibly spuriously) that Tomcat ignored either mailx or activation when > shipped inside a WAR, and that if both Tomcat (via it's lib/) and the WAR > contained either of those then the duplicate JAR would result in an error. > > So as a result I spotted someone on SO suggesting the above for the > maven-war-plugin. > However that does not work either. > > I am aware of the transitive dependencies thing, I was minded anyway to > mark those two as "provided" and ship them to Tomcat via Puppet. > > I am however still unable to integration test against Tomcat as it cannot > find the class. This appears to be far more painful than expected :( > > James > > > On 1 December 2014 at 18:05, Chris Gamache <cgama...@gmail.com> wrote: > > > A few things you might take a look at. I don't think the Tomcat plugin > > requires javax.mail or activation by itself. That part of the plugin > > definition probably isn't doing what you intended it to do. I think you > > might want to remove the <extraDependencies> section. > > > > By including > > <project> > > ... > > <dependencies> > > .... > > <dependency> > > <groupId>org.apache.commons</groupId> > > <artifactId>commons-email</artifactId> > > <version>your_version_here</version> > > </dependency> > > </dependencies> > > </project> > > > > > > You'll get javax.mail as a transitive dependency. The Maven WAR plugin is > > smart enough to include your dependencies and their transitive > dependencies > > in your war file. > > > > Even though you're looking up the mail Session using JNDI, I still think > > you'll be needing the commons email as a "compiled" dependency unless > > you've put it in the classpath yourself. > > > > If you have put it in the classpath, using "provided" scope will not > > include transitive dependencies, of which there are several for > > commons-email. If that's the route you want to go, you'll need to > download > > and put commons-email's dependencies in the classpath along with > > commons-email. > > > > IMO and FWIW, self-managing dependencies like this complicates your > project > > deployment scheme. The size overhead of including your project's > > dependencies in the each war is so worth it when Maven can handle making > > sure the dependency artifacts are where they need to be. > > > > On Mon, Dec 1, 2014 at 8:17 AM, James Green <james.mk.gr...@gmail.com> > > wrote: > > > > > Is there a way of getting this to work? > > > > > > We have a Maven project that depends on Apache's commons-email. We use > > JNDI > > > to look up a mail Session. We use the following in our POM: > > > > > > <plugin> > > > <groupId>org.apache.maven.plugins</groupId> > > > <artifactId>maven-war-plugin</artifactId> > > > <configuration> > > > <failOnMissingWebXml>false</failOnMissingWebXml> > > > </configuration> > > > </plugin> > > > <plugin> > > > <groupId>org.apache.tomcat.maven</groupId> > > > <artifactId>tomcat7-maven-plugin</artifactId> > > > <version>2.2</version> > > > <configuration> > > > <contextFile>tomcat/context.xml</contextFile> > > > <port>9000</port> > > > <path>/foo</path> > > > <fork>true</fork> > > > <extraDependencies> > > > <extraDependency> > > > <groupId>javax.mail</groupId> > > > <artifactId>mail</artifactId> > > > <version>1.4</version> > > > </extraDependency> > > > <extraDependency> > > > <groupId>javax.activation</groupId> > > > <artifactId>activation</artifactId> > > > <version>1.1.1</version> > > > </extraDependency> > > > </extraDependencies> > > > </configuration> > > > <executions> > > > <execution> > > > <id>start</id> > > > <goals> > > > <goal>run-war-only</goal> > > > </goals> > > > <phase>pre-integration-test</phase> > > > </execution> > > > <execution> > > > <id>shutdown</id> > > > <goals> > > > <goal>shutdown</goal> > > > </goals> > > > <phase>post-integration-test</phase> > > > </execution> > > > </executions> > > > </plugin> > > > > > > Deployment fails with the following: > > > > > > java.lang.ClassNotFoundException: javax.mail.Session > > > > > > I have both mail and activation listed in the POM's dependencies with a > > > scope of provided. > > > > > > Is further magic required? > > > > > > Thanks, > > > > > > James > > > > > >
