While running tests with Maven I have encountered a NoClassDefFoundError, caused by ClassNotFoundException. The class which was not found definitely exists in my local repository.
The problematic dependency looks like this: a default scoped dependency depends on a jar which scope is a marked as provided, and the file which was not found by the classloader is located inside that jar. It compiles ok, by the file cannot be found while runnig the app.
I have fixed the error by adding that “provided jar” explicitely to my pom as a runtime-scoped dependency, but I want to understand whats going on.
1) What is the meaning of dependency scope = provided if I am running some tests? I understand that a servlet container can have some provided jars, such as servlet-api.jar, but what about tests? This looks like an error in our pom, isn’t it?
Is there any other case except from servlet-api.jar (and similair web-server jars) when we should use the “provided” scope?
2) I tried to use a maven command-line parameter -U while looking for the solution of this problem. As far as I understand, it forces Maven to check the remote repository and take most fresh the dependencies from there if necessary.
A question is: whats going on if I am not specifying this command? It will always get the outdated dependencies from local repository? If not, then why I need this command?
3) For solving issues like this it is good to know which jars are really on classpath when compiling the code, and which are there when running the code. Is it possible with Maven?
1) provided always means, that the dependencies shouldn’t be copied to the built artifact. tests with some dependencies declared as provided won’t run as these dependencies are needed at runtime. you can solve this problem by creating an own profile “Test” for example. So in your “Test” profile you declare your dependencies as default scope, this will override the provided scope. After that you can run your tests with following command:
See Introduction on profiles for for information.
2)as far as i know, the command-line parameter -U will cause to fetch the dependencies freshly, as your repository may be broken (for example, if you changed or deleted files in there).
3)
mvn dependency:tree