I have project A which a pom.xml dependency of:
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-email</artifactId>
<version>1.2</version>
</dependency>
commons-email depends on javax.mail-1.4.1
I ran mvn install to install projectA.jar into the local maven repo.
In project B, i depend projectA.jar.
When I run project B, it fails due to a missing class file in javax:
DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc]
java.lang.ClassNotFoundException: com.sun.mail.smtp.SMTPTransport
How can i run project B successfully without explicitly putting a maven entry for the javax.mail jar?
EDIT:
I think I found the problem.
I was using maven-shade-plugin with true and it was removing the org.apache.commons:commons-email:jar dependencies in installed(.m2) project A pom file.
Commenting out the maven-shade-plugin for project A fixed the dependency problem.
How can i run project B successfully without explicitly putting a maven entry for the javax.mail jar?
Well, that's weird. c.s.m.s.SMTPTransport is supposed to be provided by mail-1.4.1.jar which is a dependency of commons-email. Project B should get it transitively.
Could you run the following on project B and post the output
mvn dependency:tree
Update: There is definitely something weird with your dependencies and I can't reproduce the problem.
I quickly created a first project with the following pom:
<project>
...
<groupId>com.stackoverflow</groupId>
<artifactId>Q3875317-A</artifactId>
<dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-email</artifactId>
<version>1.2</version>
</dependency>
</dependencies>
</project>
And another one depending on the first artifact:
<project>
...
<groupId>com.stackoverflow</groupId>
<artifactId>Q3875317-B</artifactId>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>Q3875317-A</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
</project>
And here is the dependency tree I get for the second project:
$ mvn dependency:tree
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Q3875317-B
[INFO] task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree {execution: default-cli}]
[INFO] com.stackoverflow:Q3875317-B:jar:1.0-SNAPSHOT
[INFO] +- com.stackoverflow:Q3875317-A:jar:1.0-SNAPSHOT:compile
[INFO] | \- org.apache.commons:commons-email:jar:1.2:compile
[INFO] | +- javax.mail:mail:jar:1.4.1:compile
[INFO] | \- javax.activation:activation:jar:1.1:compile
[INFO] \- junit:junit:jar:3.8.1:test
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
...
Everything is there, as expected.
If you get a different result and if there is anything noticeable about your POMs, please show them.
PS: I removed one of the command I initially suggested as it didn't allow to see transitive dependencies.
Related
I started learning cucumber. When I created my runner class, I am not able to import Cucumber and CucumberOptions. Can anyone guide me where I am wrong?
Below are the JAR files i have added :
My Runner Class :
I am manually adding the jars. not using maven or gradle(i dont know them much)
If you follow the 10 minute tutorial you'll get an introduction that uses Maven dependency management.
In addition to this tutorial I would strongly urge you to invest time in learning either Maven or Gradle along with Cucumber. Amongst other things these tools will automate your dependency management and this can make your life much easier.
For example:
If you want to use Cucumber with JUnit 4 and annotation based step definitions you would declare this minimal set of dependencies in a Maven pom.xml file.
<properties>
<cucumber.version>5.2.0</cucumber.version>
</properties>
<dependencies>
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-java</artifactId>
<version>${cucumber.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-junit</artifactId>
<version>${cucumber.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
By telling Maven what your dependencies are Maven can calculate your transitive dependencies i.e: the dependencies of your dependencies.
This has many advantages. One example would be using the mvn dependency:tree command to list all dependencies. This is much faster and much less error prone then downloading jar files by hand and hoping that you have the right ones.
$ mvn dependency:tree
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------< cucumber:cucumber-java-skeleton >-------------------
[INFO] Building Cucumber-Java Skeleton 0.0.1
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) # cucumber-java-skeleton ---
[INFO] cucumber:cucumber-java-skeleton:jar:0.0.1
[INFO] +- io.cucumber:cucumber-java:jar:5.2.0:test
[INFO] | +- io.cucumber:cucumber-core:jar:5.2.0:test
[INFO] | | +- io.cucumber:cucumber-gherkin:jar:5.2.0:test
[INFO] | | +- io.cucumber:cucumber-gherkin-vintage:jar:5.2.0:test
[INFO] | | +- io.cucumber:tag-expressions:jar:2.0.4:test
[INFO] | | +- io.cucumber:cucumber-expressions:jar:8.3.1:test
[INFO] | | +- io.cucumber:datatable:jar:3.3.0:test
[INFO] | | +- io.cucumber:cucumber-plugin:jar:5.2.0:test
[INFO] | | \- io.cucumber:docstring:jar:5.2.0:test
[INFO] | \- org.apiguardian:apiguardian-api:jar:1.1.0:test
[INFO] +- io.cucumber:cucumber-junit:jar:5.2.0:test
[INFO] \- junit:junit:jar:4.13:test
[INFO] \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.781 s
[INFO] Finished at: 2020-02-10T23:00:14+01:00
[INFO] ------------------------------------------------------------------------
I have a third party jar which is necessary for our project. It is not available on the central maven repository, so I used the maven-install-plugin to install the jar locally during a build. I tied the "install-file" goal to the "validate" phase, and this mostly works. The pom.xml file excerpt is below:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<id>install-myartifact</id>
<phase>validate</phase>
<goals>
<goal>install-file</goal>
</goals>
<configuration>
<file>${basedir}/lib/myartifact-1.2.3.jar</file>
<groupId>com.example</groupId>
<artifactId>myartifact</artifactId>
<version>1.2.3</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>myartifact</artifactId>
<version>1.2.3</version>
</dependency>
</dependencies>
However, there's a catch. Most of our developers and our Jenkins installation run "mvn clean install." The "validate" phase is not part of the "clean" lifecycle, and clean inexplicably requires all the dependencies be present to run. So the first time someone runs this build, it does not work.
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building MyModule
[INFO] task-segment: [clean, install]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] Deleting directory C:\svn\trunk\mymodule\target
Downloading: http://nexusserver.local:8080/nexus/content/groups/public/com/example/myartifact-1.2.3.pom
[INFO] Unable to find resource 'com.example:myartifact:pom:1.2.3' in repository central (http://central)
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
Missing:
----------
1) com.example:myartifact:jar:1.2.3
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.example -DartifactId=myartifact -Dversion=1.2.3 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=com.example -DartifactId=myartifact -Dversion=1.2.3 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) com.example:mymodule:war:0.0.1-SNAPSHOT
2) com.example:myartifact:jar:1.2.3
----------
1 required artifact is missing.
for artifact:
com.example:mymodule:war:0.0.1-SNAPSHOT
from the specified remote repositories:
nexus (http://nexusserver.local:8080/nexus/content/groups/public)
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Thu Jun 09 11:01:24 EDT 2011
[INFO] Final Memory: 17M/247M
[INFO] ------------------------------------------------------------------------
If I were to run simply "mvn install", the jar is installed during "validate," and I can run "mvn clean install" in subsequent builds. However, our build server does not have that flexibility. I've considered the following:
Moving the phase to "pre-clean," but that assumes everyone always uses clean the first time. It wouldn't help if someone ran simply "mvn install."
Copying the execution, with one occurring during "pre-clean" and one occurring during "validate." This covers all the bases, but the copied code leaves a bad taste.
Ideally, I'd love some other option. Is it possible to run clean without dependencies? Or to run a plugin twice without having to fully copy the execution? Thanks!
I ran into a related issue, and I found this question when googling for a solution, so I'll note it here:
mvn clean fails in a multi-module project when there are missing dependencies within the same project, if plugins are invoked during clean.
We invoke the antrun-plugin during the clean phase in some modules, and because of that all dependencies need to be present in the maven repository, including the other modules in the same reactor, which in some cases have not been built yet (say you just bumped the project version, or you're starting off a new project).
This is a maven-antrun bug reported in https://issues.apache.org/jira/browse/MANTRUN-78 - which again leads back to a bug in maven core: https://issues.apache.org/jira/browse/MNG-3283.
My workaround was to provide the developers (and Jenkins) with an alternative way of doing clean (shell/bat script, ant script or some git/hg clean operation), and have them invoke this instead.
I would suggest a similar workaround for your team (or just set up up a shared maven repository internally in your team, use one of the developer machines if necessary).
It looks like you're using nexus. It might be easier to deploy the artifact to the nexus repo as opposed to having to maintain it with this project.
This is untested, but can you not ignore the error from the clean plugin's configuration? As in:
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<failOnError>false</failOnError>
</configuration>
</plugin>
(This is from Maven Clean Plugin : Ignoring Clean Errors)
Here is one more possibility.
Configure maven to skip clean phase and run clean during initialize. Have not tried this though.
The drawback of this is maven will always clean the output folders.
I need to start jetty before module tests. Example:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>jetty-test</groupId>
<artifactId>jetty-test</artifactId>
<version>1.0</version>
<packaging>war</packaging>
<build>
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ssh</artifactId>
<version>1.0-beta-6</version>
</extension>
</extensions>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<id>test-compile</id>
<phase>test-compile</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<echo>Hello world!</echo>
</target>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<version>6.1.26</version>
<executions>
<execution>
<id>start-webapp-for-module-tests</id>
<phase>test</phase>
<goals>
<goal>run</goal>
</goals>
</execution>
<execution>
<id>stop-webapp-for-module-tests</id>
<phase>prepare-package</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
<configuration>
<daemon>true</daemon>
<stopPort>8181</stopPort>
<stopKey>stop-webapp</stopKey>
</configuration>
</plugin>
</plugins>
</build>
</project>
Everything works, but maven-antrun-plugin (or any other plugin before test-compile phase) begins to run two times. I tried to use run-war, run-exploaded or deploy-war goals. Result is the same.
Maven output:
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Unnamed - jetty-test:jetty-test:war:1.0
[INFO] task-segment: [deploy]
[INFO] ------------------------------------------------------------------------
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /home/chardex/projects/untitled/jetty-test/src/main/resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources {execution: default-testResources}]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /home/chardex/projects/untitled/jetty-test/src/test/resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [antrun:run {execution: test-compile}]
[INFO] Executing tasks
main:
**[echo] Hello world!**
[INFO] Executed tasks
[INFO] [surefire:test {execution: default-test}]
[INFO] No tests to run.
[INFO] Preparing jetty:run
[WARNING] Removing: run from forked lifecycle, to prevent recursive invocation.
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /home/chardex/projects/untitled/jetty-test/src/main/resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources {execution: default-testResources}]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /home/chardex/projects/untitled/jetty-test/src/test/resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [antrun:run {execution: test-compile}]
[INFO] Executing tasks
main:
**[echo] Hello world!**
[INFO] Executed tasks
[INFO] [jetty:run {execution: start-webapp-for-module-tests}]
[INFO] Configuring Jetty for project: Unnamed - jetty-test:jetty-test:war:1.0
[INFO] Webapp source directory = /home/chardex/projects/untitled/jetty-test/src/main/webapp
[INFO] Reload Mechanic: automatic
[INFO] Classes directory /home/chardex/projects/untitled/jetty-test/target/classes does not exist
2010-12-24 16:50:17.254:INFO::Logging to STDERR via org.mortbay.log.StdErrLog
[INFO] Context path = /jetty-test
[INFO] Tmp directory = determined at runtime
[INFO] Web defaults = org/mortbay/jetty/webapp/webdefault.xml
[INFO] Web overrides = none
[INFO] web.xml file = /home/chardex/projects/untitled/jetty-test/src/main/webapp/WEB-INF/web.xml
[INFO] Webapp directory = /home/chardex/projects/untitled/jetty-test/src/main/webapp
[INFO] Starting jetty 6.1.26 ...
2010-12-24 16:50:17.316:INFO::jetty-6.1.26
2010-12-24 16:50:17.416:INFO::No Transaction manager found - if your webapp requires one, please configure one.
[INFO] Started Jetty Server
[INFO] [jetty:stop {execution: stop-webapp-for-module-tests}]
2010-12-24 16:50:17.603:INFO::Started SelectChannelConnector#0.0.0.0:8080
[INFO] Stopping server 0
2010-12-24 16:50:17.637:INFO::Stopped SelectChannelConnector#0.0.0.0:8080
[INFO] [war:war {execution: default-war}]
[INFO] Packaging webapp
[INFO] Assembling webapp[jetty-test] in [/home/chardex/projects/untitled/jetty-test/target/jetty-test-1.0]
[INFO] Processing war project
[INFO] Copying webapp resources[/home/chardex/projects/untitled/jetty-test/src/main/webapp]
[INFO] Webapp assembled in[25 msecs]
[INFO] Building war: /home/chardex/projects/untitled/jetty-test/target/jetty-test-1.0.war
[INFO] [install:install {execution: default-install}]
...
Where I'm wrong?
Thanks.
According to the documentation, for mvn jetty:run,
This goal is used in-situ on a Maven
project without first requiring that
the project is assembled into a war,
saving time during the development
cycle. The plugin forks a parallel
lifecycle to ensure that the "compile"
phase has been completed before
invoking Jetty. This means that you do
not need to explicity execute a "mvn
compile" first. It also means that a
"mvn clean jetty:run" will ensure that
a full fresh compile is done before
invoking Jetty.
This explains the behavior.
There should be a separate goal which does the same thing but does not fork the lifecycle. It's impossible not to execute the compile phase and all other phases when the plugin is run as a step in the build lifecycle, so everything is run twice. Bug created: http://jira.codehaus.org/browse/JETTY-1365. Bug moved as a duplicate to https://jira.codehaus.org/browse/JETTY-1405. They said they couldn't reproduce the problem and need a specific test case. Not sure when I can get to this, but if someone has a simple war project using the maven-jetty-plugin which demonstrates the issue, can they please upload it to the JIRA ticket.
I make use of dependency POMs which I will then go and include into another projects as as dependency. The problem I am having is while it aggregates the POM with those dependencies, it appears when I declare dependencies of scope, provided, those aren't included.
Is it possible to include provided dependencies in dependency POMs with a scope of provided? I often declare what APIs I need and then include the implementation as a runtime dependency.
If a dependency is provided why can't that dependency be inherited with the same scope so I don't have to declare it?
It is inherited with the same scope. Given the following parent pom.xml:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.stackoverflow.Q3597684</groupId>
<artifactId>root</artifactId>
<version>1.0-SNAPSHOT</version>
<name>Q3597684 - Root</name>
<packaging>pom</packaging>
<dependencies>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
And the following pom.xml that inherits from the root artifact:
<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>root</artifactId>
<groupId>com.stackoverflow.Q3597684</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<artifactId>child</artifactId>
<packaging>war</packaging>
<name>Q3597684 - Child</name>
<dependencies/>
</project>
Running mvn dependency:tree from the child gives the following output:
$ mvn dependency:tree[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Q3597684 - Child
[INFO] task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree {execution: default-cli}]
[INFO] com.stackoverflow.Q3597684:child:war:1.0-SNAPSHOT
[INFO] +- javax.servlet:servlet-api:jar:2.5:provided
[INFO] \- junit:junit:jar:3.8.1:test
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
The provided servlet-api is there, as expected.
Are you maybe (mis)using the dependencyManagement section?
When using Apache Commons EmailValidator through Maven, I have the following problem that doesn't deploy my app:
Exception sending context initialized event to listener instance of class org.jboss.seam.servlet.SeamListener
java.lang.LinkageError: loader constraints violated when linking org/xml/sax/EntityResolver class
I've used the following code at my pom.xml:
<dependency>
<groupId>commons-validator</groupId>
<artifactId>commons-validator</artifactId>
<version>1.3.1</version>
</dependency>
One help?
The commons-validator-1.3.1.jar artifact pulls xml-apis-1.0.b2.jar as shown below:
$ mvn dependency:tree
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Q2714398
[INFO] task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree {execution: default-cli}]
[INFO] com.stackoverflow:Q2714398:jar:1.0-SNAPSHOT
[INFO] +- commons-validator:commons-validator:jar:1.3.1:compile
[INFO] | +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
[INFO] | +- commons-digester:commons-digester:jar:1.6:compile
[INFO] | | +- commons-collections:commons-collections:jar:2.1:compile
[INFO] | | \- xml-apis:xml-apis:jar:1.0.b2:compile
[INFO] | \- commons-logging:commons-logging:jar:1.0.4:compile
[INFO] \- junit:junit:jar:3.8.1:test
[INFO] ------------------------------------------------------------------------
The LinkageError suggests that you have duplicate versions of xml-apis-1.0.b2.jar, which is an obvious suspect here, on the classpath when deploying on JBoss.
Maybe simply try to exclude it from the deployed application (can't give a more precise answer with the current level of details).
<dependency>
<groupId>commons-validator</groupId>
<artifactId>commons-validator</artifactId>
<version>1.3.1</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>