Parsing POMs
Discovered a new module be.howest:someproject someproject
It seems to find a new module on the first time I make a hudson job. Well, nothing really to worry, but it seems to execute everything twice, and I don't really know why. Another thing is: it gives this odd error (at least to me):
[WARNING] Removing: cobertura from forked lifecycle, to prevent recursive invocation.
[WARNING] Removing: findbugs from forked lifecycle, to prevent recursive invocation.
To me this looks like it tried to execute twice, but why is escaping me.
Also, it has a module under the build, which is something i'm not very familiar with, but I wouldn't bother too much (and consider it normal) if it didn't do my tests twice.
right now it is running two phases: clean and test. I changed it to clean package, because I included javadoc in the package lifecycle, but nothing has changed.
Hudson console log: http://pastebin.com/2GRmc2yP
Pom.xml: http://pastebin.com/HL9Qd821
Maven will execute tests first without any instrumentation, then it will execute cobertura plugin that will instrument the classes and re-run all the tests. Thus, the tests will be executed twice.
It is cobertura which makes the tests run the second time.
Related
What are the possible causes of a "java.lang.Error: Unresolved compilation problem"?
Additional information:
I have seen this after copying a set of updated JAR files from a build on top of the existing JARs and restarting the application. The JARs are built using a Maven build process.
I would expect to see LinkageErrors or ClassNotFound errors if interfaces changed. The above error hints at some lower level problem.
A clean rebuild and redeployment fixed the problem. Could this error indicate a corrupted JAR?
(rewritten 2015-07-28)
Summary: Eclipse had compiled some or all of the classes, and its compiler is more tolerant of errors.
Long explanation:
The default behavior of Eclipse when compiling code with errors in it, is to generate byte code throwing the exception you see, allowing the program to be run. This is possible as Eclipse uses its own built-in compiler, instead of javac from the JDK which Apache Maven uses, and which fails the compilation completely for errors. If you use Eclipse on a Maven project which you are also working with using the command line mvn command, this may happen.
The cure is to fix the errors and recompile, before running again.
The setting is marked with a red box in this screendump:
try to clean the eclipse project
you just try to clean maven by command
mvn clean
and after that following command
mvn eclipse:clean eclipse:eclipse
and rebuild your project....
Your compiled classes may need to be recompiled from the source with the new jars.
Try running "mvn clean" and then rebuild
The major part is correctly answered by Thorbjørn Ravn Andersen.
This answer tries to shed light on the remaining question: how could the class file with errors end up in the jar?
Each build (Maven & javac or Eclipse) signals in its specific way when it hits a compile error, and will refuse to create a Jar file from it (or at least prominently alert you). The most likely cause for silently getting class files with errors into a jar is by concurrent operation of Maven and Eclipse.
If you have Eclipse open while running a mvn build, you should disable Project > Build Automatically until mvn completes.
EDIT:
Let's try to split the riddle into three parts:
(1) What is the meaning of "java.lang.Error: Unresolved compilation
problem"
This has been explained by Thorbjørn Ravn Andersen. There is no doubt that Eclipse found an error at compile time.
(2) How can an eclipse-compiled class file end up in jar file created
by maven (assuming maven is not configured to used ecj for
compilation)?
This could happen either by invoking Maven with no or incomplete cleaning. Or, an automatic Eclipse build could react to changes in the filesystem (done by Maven) and re-compile a class, before Maven proceeds to collect class files into the jar (this is what I meant by "concurrent operation" in my original answer).
(3) How come there is a compile error, but mvn clean succeeds?
Again several possibilities: (a) compilers don't agree whether or not the source code is legal, or (b) Eclipse compiles with broken settings like incomplete classpath, wrong Java compliance etc. Either way a sequence of refresh and clean build in Eclipse should surface the problem.
I had this error when I used a launch configuration that had an invalid classpath. In my case, I had a project that initially used Maven and thus a launch configuration had a Maven classpath element in it. I had later changed the project to use Gradle and removed the Maven classpath from the project's classpath, but the launch configuration still used it. I got this error trying to run it. Cleaning and rebuilding the project did not resolve this error. Instead, edit the launch configuration, remove the project classpath element, then add the project back to the User Entries in the classpath.
I got this error multiple times and struggled to work out. Finally, I removed the run configuration and re-added the default entries. It worked beautifully.
Just try to include package name in eclipse in case if you forgot it
Import all packages before using it, EX: import java.util.Scanner before using Scanner class.
These improvements might work and it will not give Java: Unresolved compilation problem anymore.
Also make sure to check compiler compliance level and selected jdk version is same
As a weird case, I encountered such an exception where the exception message (unresolved compilation bla bla) was hardcoded inside of generated class' itself. Decompiling the class revealed this.
I had the same issue using the visual studio Code. The root cause was backup java file was left in the same directory.
Removed the backup java file
When the build failed, selected the Fix it, it cleaned up the cache and restarted the workSpace.
I'm new to SBT and I would like to know if it is possible to run tests without compiling. I mean to use a set of classes that have been already compiled.
Is this possible and what should I do to get this done?
sbt detects the available tests during compilation for efficiency. To run already compiled tests that are on the classpath and not in source files, it would be necessary to explicitly list them in the definedTests task. This isn't too straightforward, though.
I have a default maven project:
/src/main/java
/src/test/java (include *Test.java).
When I exeucte "mvn compile", maven also tries to compile the testClasses under /src/test/java. This fails, as of some dependencies such as JUnit are under "test"-scope. Changing the scope of e.g. JUnit to "provided" everything works fine.
How can I avoid maven to compile testClasses when compiling? In my understanding, I expect to maven to compile this files only when executing "testcompile".
I am using maven 2.2.1
I believe it is nothing to do with the scope of JUnit. Normally we set JUnit's scope to test (instead of provided) and everything is just fine.
src/test/java is compiled by Maven Compiler Plugin's testCompile goal. However, you don't need to explicitly run that goal. Please have a look in topics about Maven's Lifecycle. For example, if you run maven install, it is implicitly going through many phases (e.g. compile, compile test, generate resources etc), and many of them is bounded to a default plugin goal.
If you want to avoid test source from building, from Maven Compiler Plugin's usage page, compiler:testCompile will be skipped if you turn off testing by setting maven.test.skip=true
So, if your unit tests are not yet ready, just build with Maven, with -Dmaven.test.skip=true parameter.
Just to add, this is absolutely not a good practice to assume "unit test failing" being normal during development.
Just use the skip parameter for the maven-surefire-plugin which skip tests as well as compiling the test.
The pom.xml had defined "sourceDirectory" incorrectly. Removing it fixed the issue
Instead of command "maven clean compile" , use "mvn -B -Dmaven.test.skip=true clean compile". This parameter skips test.
I have a maven execution that runs a javascript compressor as a command line program, however, this tool also does some jslint checks as well.
If these jslint checks fail so should my build.
These errors are output as a parseable string to stdout.
If this maven plugin cannot solve this problem, I'm happy to use any other suggested.
Thanks.
To my knowledge, exec:exec will fail the build if the return code of the executed command is not 0 (or one of the configured successCodes). Maybe you can build something around this.
As an alternative, have a look at these plugins, they both can fail a build on problems:
the Jslint Maven Plugin
the YUI Compressor Maven Mojo
Depending on what you need exactly, there is also the Maven Javascript Plugin.
And also have a look at this Maven plugins for javascript question.
In our project, we run both junits and cobertura using maven. The problem I am facing is that,
junit test cases are running twice, once before the jar creation process and then once again for generating cobertura coverage reports. When running cobertura and junits with ant, we run junits only once since, cobertura runs along with junits. Is there a way to configure the above case with maven. I know we can use "maven.test.skip" property to skip junits. But when I do this, I am not able to see junit xml & html file reports.
Also, in maven how to configure junits to run in batch or parallel ?
thank you!
While I cannot find the exact page anymore, I recently read a discussion of why running the tests twice is considered a good idea. The key issues cited were around the effects of the Cobertura byte code alteration on the accuracy of your tests. In certain cases the timing of your code execution might be important, the byte code alteration can cause tests that fail in JUnit to pass when run only in Cobertura and vice versa. For this reason, it was recommended that the tests be allowed to execute twice. Most of the examples cited were around multi-threaded behaviors, but I imagine that there could be other cases were the byte code alteration can cause issues in your tests. Having the tests execute both ways provides you with baseline results and also reduces the chances of sending you on a wild goose chase if Cobertura is in fact altering test success.
Try adding cobertura as a compile scope reference. And post the relevant parts of your pom.
This happens because the reporting execution requires the test execution so it can create the reports. If there were a "site-only" goal on the site plugin that didn't have the #requiresDependencyResolution test annotation, it could be bound to the project's prepare-package phase and your reports would be generated without the tests running twice.
Unfortunately there seems to currently be no such goal (see my question on the subject).
See my answer to the question for details of a workaround.