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 > > >
