We Keep Coding

Difference between "mvn dependency:tree" and http://repo.maven.org dependency details

In my project there is a Java Class which does:
import javax.activation.DataHandler;
My POM only has this dependency:
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>1.5.0-b01</version>
</dependency>
Build (mvn clean install) is working, because:
mvn dependency:tree
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli)
[INFO] \- javax.mail:mail:jar:1.5.0-b01:compile
[INFO] \- javax.activation:activation:jar:1.1:compile
But why does
https://mvnrepository.com/artifact/javax.mail/mail/1.5.0-b01
and also
https://repo1.maven.org/maven2/javax/mail/mail/1.5.0-b01/mail-1.5.0-b01.pom
say there are no dependencies ???
Another question:
Why does javax.mail:mail:jar:1.5.0-b01 (from 2013) not depend on the latest javax.activation:activation:jar:1.1.1 (from 2009)?

Because mvnrepository has it wrong, "javax.mail:mail:jar:1.5.0-b01" version does have dependency to "javax.activation:activation:jar:1.1", it's in it's parent:
https://repo1.maven.org/maven2/com/sun/mail/all/1.5.0-b01/all-1.5.0-b01.pom
Don't depend on mvnrepository very much, the truth is always in pom files. Btw. javalibs shows you the dependency:
https://javalibs.com/artifact/javax.mail/javax.mail-api
Why the newest javax.mail version doesn't contain dependency to activation-api is probably due to transition to jakarta artifacts ... old javax dependencies cannot depend on new jakarta dependencies because Oracle said so ... :-( Newest javax.mail and activation artifacts are these:
https://javalibs.com/artifact/javax.mail/javax.mail-api
https://javalibs.com/artifact/jakarta.mail/jakarta.mail-api

error 404 for rest service in netbeans, using tomcat7 and java JDK 8 [duplicate]

I am running a Maven project which is also a dynamic web project. I have used all Spring libraries in Maven. I created web.xml, but when I start my Tomcat 7 server I am getting the following message:
INFO: validateJarFile(C:\Users\mibvzd0\workspace\.metadata\.plugins\
org.eclipse.wst.server.core\tmp2\wtpwebapps\hapi_hl7\WEB-INF\lib\
servlet-api-2.4.jar) - jar not loaded.
See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class
I tried deleting the servlet from webapp/lib, but it didn't work. Let me know what should be done in my case.

The servlet API .jar file must not be embedded inside the webapp since, obviously, the container already has these classes in its classpath: it implements the interfaces contained in this jar.
The dependency should be in the provided scope, rather than the default compile scope, in your Maven pom:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>

You get this warning message when the servlet api jar file has already been loaded in the container and you try to load it once again from lib directory.
The Servlet specs say you are not allowed to have servlet.jar in
your webapps lib directory.
Get rid of the warning message by simply removing servlet.jar from your lib directory.
If you don't find the jar in the lib directory scan for your build path and remove the jar.
C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\project\WEB-INF\lib
If you are running a maven project, change the javax.servlet-api dependency to scope provided in you pom.xml since the container already provided the servlet jar in itself.

To fix it, set the scope to provided. This tells Maven use code servlet-api.jar for compiling and testing only, but NOT include it in the WAR file. The deployed container will “provide” the servlet-api.jar at runtime.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>

You may find the following windows command line useful in tracking down the offending jar file. it creates an index of all the class files in all the jars in the folder. Execute from within the lib folder of your deployed app, then search the index.txt file for the offending class.
for /r %X in (*.jar) do (echo %X & jar -tf %X) >> index.txt

Maven Dependency Scope
provided : This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example,
when building a web application for the Java Enterprise Edition, you
would set the dependency on the Servlet API and related Java EE APIs
to scope provided because the web container provides those classes.
This scope is only available on the compilation and test classpath,
and is not transitive.

I've been struggling with this issue and I've tried numerous "solutions".
However, in the end, the only one that worked and it actually took a few seconds to do it was to: delete and add back new server instance!
Basically, I right clicked on my Tomcat server in Eclipse under Servers and deleted it. Next, I've added a new Tomcat server. Cleaned and redeployed the application and I got rid of this error.

Check Inside the Following Directory for the jar file el-api.jar :C:\apache-tomcat-7.0.39\lib\el-api.jar if it exists then in this directory of your web application WEB-INF\lib\el-api.jar the jar should be removed

when your URL pattern is wrong, this error may be occurred.
eg. If you wrote #WebServlet("login"), this error will be shown. The correct one is #WebServlet("/login").

Exclusions and provided dependencies will not work in child projects.
If you are using inheritance in Maven projects you must include this configuration on the parent pom.xml file. You will have a <parent>...</parent> section in your pom.xml if you are using inheritance. So you will have something like this in your parent pom.xml:
<groupId>some.groupId</groupId>
<version>1.0</version>
<artifactId>someArtifactId</artifactId>
<packaging>pom</packaging>
<modules>
<module>child-module-1</module>
<module>child-module-2</module>
</modules>
<dependencies>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
</dependencies>

The JAX-WS dependency library “jaxws-rt.jar” is missing.
Go here http://jax-ws.java.net/.
Download JAX-WS RI distribution.
Unzip it and copy “jaxws-rt.jar” to Tomcat library folder “{$TOMCAT}/lib“.
Restart Tomcat.

Typically when you see this message, it is benign.
If it says
INFO: validateJarFile(/<webapp>/WEB-INF/lib/servlet-api-2.5.jar) - jar not loaded.
See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class
It means it is ignoring your servlet-api-2.5.jar because tomcat already has a built-in version of that jar, so it isn't going to be using yours. Typically this doesn't cause an issue.
If however it says WEB-INF/lib/my_jar.jar - jar not loaded...Offending class: javax/servlet/Servlet.class
then what you can do (in my instance, it's a shaded jar) is run
$ mvn dependency:tree
and discover that you have a transitive dependency on "something" that depends on a jar that is either servlet-api or something like it (ex: tomcat-servlet-api-9.0.0). So add an exclusion to that to your pom, ex: (in my case, tomcat, in your case, probably the ones mentioned in the other answers):
<dependency>
...
<exclusions>
<exclusion>
<groupId>org.apache.tomcat</groupId>
<artifactId>tomcat-servlet</artifactId>
</exclusion>
</exclusions>
</dependency>

from https://stackoverflow.com/a/9941668/778517
I did mvn dependency:tree and result was
(...)
[INFO] +- org.zkoss.zk:zkspring-core:jar:3.2.0:compile
[INFO] | +- org.springframework:spring-beans:jar:3.0.7.RELEASE:compile
[INFO] | +- org.springframework:spring-context:jar:3.0.7.RELEASE:compile
[INFO] | | \- org.springframework:spring-asm:jar:3.0.7.RELEASE:compile
[INFO] | +- org.springframework:spring-web:jar:3.0.7.RELEASE:compile
[INFO] | \- org.reflections:reflections:jar:0.9.5-RC2:compile
[INFO] | +- com.google.collections:google-collections:jar:1.0:compile
[INFO] | +- ch.qos.logback:logback-classic:jar:0.9.9:runtime
[INFO] | | \- ch.qos.logback:logback-core:jar:0.9.9:runtime
[INFO] | +- com.google.code.gson:gson:jar:1.4:compile
[INFO] | \- javax.servlet:servlet-api:jar:2.5:compile
(...)
so in pom.xml, zkspring-core I added the exclusions tag
(...)
<groupId>org.zkoss.zk</groupId>
<artifactId>zkspring-core</artifactId>
<version>3.2.0</version>
+ <exclusions>
+ <exclusion>
+ <groupId>javax.servlet</groupId>
+ <artifactId>servlet-api</artifactId>
+ </exclusion>
+ </exclusions>
</dependency>
(...)
after I ran mvn dependency:tree and javax.servlet:servlet-api:jar:2.5:compile is clean
(...)
[INFO] +- org.zkoss.zk:zkspring-core:jar:3.2.0:compile
[INFO] | +- org.springframework:spring-beans:jar:3.0.7.RELEASE:compile
[INFO] | +- org.springframework:spring-context:jar:3.0.7.RELEASE:compile
[INFO] | | \- org.springframework:spring-asm:jar:3.0.7.RELEASE:compile
[INFO] | +- org.springframework:spring-web:jar:3.0.7.RELEASE:compile
[INFO] | \- org.reflections:reflections:jar:0.9.5-RC2:compile
[INFO] | +- com.google.collections:google-collections:jar:1.0:compile
[INFO] | +- ch.qos.logback:logback-classic:jar:0.9.9:runtime
[INFO] | | \- ch.qos.logback:logback-core:jar:0.9.9:runtime
[INFO] | \- com.google.code.gson:gson:jar:1.4:compile
(...)

Remove servlet.jar from source web-inf/lib folder as it is available in tomcat lib folder then it works fine

The method getDispatcherType() is undefined for the type HttpServletRequest

When I run my applicaiton from Eclipse it runs without any errors for servlet api 3.1.0 and 3.0.1.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
I use tomcat 8.0.21 for eclipse. I have set up tomcat8 on ubuntu machine which runs on tomcat 8.0.14 stable version.
Unfortunately, I get the following error message if I use servlet api 3.1.0. But it works for the older version 3.0.1.
root cause
org.apache.jasper.JasperException: Unable to compile class for JSP:
An error occurred at line: [50] in the generated java file: [/var/lib/tomcat8/work/Catalina/localhost/ROOT/org/apache/jsp/WEB_002dINF/view/templates/login_002dtemplate_jsp.java]
The method getDispatcherType() is undefined for the type HttpServletRequest
Stacktrace:
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:103)
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:199)
org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:450)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:361)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:336)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:323)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:564)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:396)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:340)
javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
Why do I get this error? How to fix this?

You're not supposed to provide Servlet API along with the web application archive if the target runtime already provides the API out the box. Tomcat as being a JSP/Servletcontainer already provides JSP, Servlet and EL APIs out the box. When you provide them along with your webapp anyway, then you may run into classloading conflicts caused by duplicate different versioned classes in the runtime classpath coming from both the webapp and the server.
Add <scope>provided</scope> to those dependencies already provided by the target runtime.
See also:
How do I import the javax.servlet API in my Eclipse project?

For Maven users there are several good answers here that you might want to check out.
I'm still in the dark ages, and am not using a dependency manager for my Tomcat project. If you're like me and have this issue, here's how I solved it: It seems tomcat provides the javax.servlet classes, so these don't need to be in your project's lib file. (I originally had the servlet-api-2.5.jar in my /WEB-INF/lib directory.) However you'll probably still need it to compile (I did), so you should move it to a location included in your java classpath. You may also need to tell your IDE where to look.
Hope that helps.

Method ServletRequest#getDispatcherType() was introduced to the Servlet Spec since version 3.0. The following error means that you are using an older version (e.g., 2.5) of javax.servlet-api in your application.
The method getDispatcherType() is undefined for the type HttpServletRequest
To solve this issue, you could follow the following two steps:
First of all, add <scope>provided</scope> to dependency javax.servlet-api
You should add <scope>provided</scope> to the dependency, because your Tomcat container will provide the dependency at runtime. And at the same time, ensure that you are using Tomcat 7 or higher, which supports Servlet Spec 3.0 or higher.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>
Second of all, exclude any older version of javax.servlet-api
You need to ensure that any older version (e.g., 2.5) of javax.servlet-api is not included transitively. You can use mvn dependency:tree to find out. See below an example:
$ mvn dependency:tree
...
[INFO] +- com.google.oauth-client:google-oauth-client-servlet:jar:1.20.0:compile
[INFO] | +- com.google.oauth-client:google-oauth-client:jar:1.20.0:compile
[INFO] | +- com.google.http-client:google-http-client-jdo:jar:1.20.0:compile
[INFO] | +- javax.servlet:servlet-api:jar:2.5:compile
[INFO] | \- javax.jdo:jdo2-api:jar:2.3-eb:compile
[INFO] | \- javax.transaction:transaction-api:jar:1.1:compile
...
In this case, javax.servlet-api version 2.5 is included transitively by a dependency called google-oauth-client-servlet. We need to exclude it in pom.xml, like below:
<dependency>
<groupId>com.google.oauth-client</groupId>
<artifactId>google-oauth-client-servlet</artifactId>
<version>1.20.0</version>
<exclusions>
<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
</exclusion>
</exclusions>
</dependency>
That's it.

Build Failure in Jenkins, Found duplicate resources

I recently added this dependency to pom.xml
<dependency>
<groupId>com.jayway.restassured</groupId>
<artifactId>rest-assured</artifactId>
<version>2.4.0</version>
</dependency>
My builds are failing in jenkins with the following error message:
[WARNING] Found duplicate resources in [org.codehaus.groovy:groovy:2.3.7,org.codehaus.groovy:groovy-json:2.3.7,org.codehaus.groovy:groovy-xml:2.3.7] :
[WARNING] META-INF/groovy-release-info.properties
[JENKINS] Archiving disabled
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5:37.485s
[INFO] Finished at: Mon Mar 09 10:10:49 PDT 2015
[INFO] Final Memory: 46M/381M
[INFO] ------------------------------------------------------------------------
[JENKINS] Archiving disabled
Waiting for Jenkins to finish collecting data
[ERROR] Failed to execute goal com.ning.maven.plugins:maven-duplicate-finder-plugin:1.0.4:check (default) on project LightmileTest: Found duplicate classes/resources -> [Help 1]

Background/Details
I had a similar issue and this threw me for a loop for a while and I started to question my maven knowledge and did some digging. If you want to learn more about duplicate finder, you can read the readme on their github: https://github.com/ning/maven-duplicate-finder-plugin
For the project I was on, I determined I could do excludes in the dependencies or add exceptions to the duplicate finder. I saw both in my project and wondered when it was appropriate to do which.
The message from the plugin helps identify where duplication resides. You'll normally see this when you try to add new dependencies. When you see that, there are two options, either exclude things from the dependencies, or create exceptions in your com.ning.maven.plugins:duplicate-finder-maven-plugin configuration.
Summary / Conclusion
Adding an exception, just ignores the problem. So the cleaner way is add the excludes in the dependencies. This way you get exactly what you expect/desire. Furthermore, going down the exception route would just add a ton of extra work that isn't really useful. So the intent of the plugin is to help you identify duplications, then try to handle them via excludes in the dependencies.
Example of How to Do Exclude
In your example/case, one of the following should work for you:
<dependency>
<groupId>com.jayway.restassured</groupId>
<artifactId>rest-assured</artifactId>
<version>2.4.0</version>
<exclusions>
<exclusion>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-json</artifactId>
</exclusion>
</exclusions>
</dependency>
or
<dependency>
<groupId>com.jayway.restassured</groupId>
<artifactId>rest-assured</artifactId>
<version>2.4.0</version>
<exclusions>
<exclusion>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy</artifactId>
</exclusion>
</exclusions>
</dependency>

It is likely that your new dependency is failing on this test your are doing via Maven (duplicate-finder-plugin). Run the manual check from command line (on the level of the POM file) to find out what are the offending classes:
mvn com.ning.maven.plugins:duplicate-finder-maven-plugin:1.0.4:check
Then you can either remove the dependency or configure the Maven plugin to ignore these. (config here)

dependency:analyze-duplicate Analyzes the and tags in the pom.xml and determines the duplicate declared dependencies.
mvn dependency:analyze-duplicate

What you can do is to follow the rule of scope, meaning that, separate dependencies according to their scopes, such as in your case, rest assured used for testing, why not to put it under the scope of a test:
<scope>test</scope>
Secondary, what I usually do is executing exactly same commands from Jenkins on my local machine and usually it does help, from you error log I think it is not rest assured related, so please try to run MVN goal which is on Jenkins side locally and make sure you have the same error. If not, it can be a different configuration of maven for example via settings.xml in Jenkins machine.

Use to avoid the duplicate finder.

Maven, Vert.x and JodaTime library - NoSuchMethodError

I have a maven project that uses Vert.x library - http://vertx.io/ (but I doubt this has any meaning).
When I try run my app by using vert.x command:
vertx runzip target/service-1.0.0-mod.zip -conf config.json
I'm getting following stacktrace:
Exception in Java verticle
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at com.mycompany.myproject.vertx.Verticle.createConfig(Verticle.java:116)
...
Caused by: java.lang.NoSuchMethodError: org.joda.time.format.DateTimeFormatter.withZoneUTC()Lorg/joda/time/format/DateTimeFormatter;
at com.mycompany.myproject.mypackage.dao.MyDAO.<clinit>(MyDAO.java:30)
...
JodaTime part of pom.xml:
<dependencies>
<dependency>
<groupId>joda-time</groupId>
<artifactId>joda-time</artifactId>
<version>2.3</version>
<scope>compile</scope>
</dependency>
</dependencies>
I tried running:
mvn dependency:tree -Dverbose -Dincludes=joda-time
to see if an old version of JodaTime library is loaded as a dependency but all looks OK:
[INFO] --- maven-dependency-plugin:2.7:tree (default-cli) # matching-service ---
[INFO] com.mycompany.myproject:service:jar:1.0.0
[INFO] \- joda-time:joda-time:jar:2.3:compile

It looks like you compiled your MyDAO against a different version of JodaTime than you use when running it.
I.e. there must be two different joda-time jars in your workspace and a static block in MyDAO calling withZoneUTC - unless you only posted half the stack trace and the problem is in a compiled class from the vertx project. In that case you need to get the joda version that vertx was compiled for.