The war itself deploys to a Tomcat instance on a testing machine just fine - that Tomcat includes the javamail and activation in it's installation hence they are declared as "provided" in our project's POM.
This boils down to not knowing if the extra dependencies within the maven plugin are actually deployed and deployed prior to booting the war archive. On 2 December 2014 at 19:11, Chris Gamache <cgama...@gmail.com> wrote: > 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 > > > > > > > > > >
