I have a question in regards to running a single test class through maven. More specifically, I have a project structure which looks like this:
And I would like to run the integration test inside the StatusSocketIT class through a maven command. I tried therefore the following maven command:
mvn test -Dtest=todolist.websocket.src.it.java.org.smart.todolist.websocket.StatusSocketIT
but it fails with the following error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) on project backend: No tests were executed! (Set -DfailIfNoTests=false to ignore this error.) -> [Help 1]
which tells that the tests cant be executed. I have also tried other path names like for instance org.smart.todolist.websocket.StatusSocketIT but this also throws the same error. Would anyone maybe know what the issue is? Thanks in advance
Change the command to:
mvn test -Dtest=org.smart.todolist.websocket.StatusSocketIT
Only the "path" inside src/it/java is part of the class name (its package).
In addition, make sure you have the src/it/java directory configured as a test directory in your pom file:
<build>
<testSourceDirectory>src/it/java</testSourceDirectory>
</build>
Trying to compile a Maven project using JDK 9.0.1 I'm facing this stacktrace without much of an explanation:
Exception in thread "main" java.lang.AssertionError
at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:250)
at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:821)
at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ImplicitCompleter.complete(JavacProcessingEnvironment.java:1510)
at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633)
at jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1314)
at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.complete(Type.java:1139)
at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.getTypeArguments(Type.java:1065)
at jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:237)
at jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:52)
at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:992)
at jdk.compiler/com.sun.tools.javac.code.Printer.visit(Printer.java:136)
at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:197)
at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165)
at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:183)
at jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165)
at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
at jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
at jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.getMessage(JCDiagnostic.java:771)
at jdk.compiler/com.sun.tools.javac.api.ClientCodeWrapper$DiagnosticSourceUnwrapper.getMessage(ClientCodeWrapper.java:799)
at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:131)
at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174)
at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1075)
at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:168)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Not really sure what's causing this, is this a bug in the JDK?
Additional details:
Maven 3.5.0 with maven-compiler-plugin 3.7.0
I'm just executing mvn clean install
The source code is not open source unfortunately, so I'm not at liberty to share it
There are no module-info.java files yet, I'm just trying to compile a project using Java 9
Strangely enough if I leave the source level on 1.8, the code compiles, but it fails with the above exception if I specify it as 9
Just add this
<forceJavacCompilerUse>true</forceJavacCompilerUse>
to your maven compiler build plugin in your POM and you'll see all the javac errors! Source with more details
Debugging
Step one should be to add the maven-compiler-plugin and enable
<forceJavacCompilerUse>true</forceJavacCompilerUse> as the top answer suggests.
<project>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<forceJavacCompilerUse>true</forceJavacCompilerUse>
</configuration>
</plugin>
...
This will point out the actual compilation error.
[main] INFO org.apache.maven.plugin.compiler.CompilerMojo - -------------------------------------------------------------
[main] ERROR org.apache.maven.plugin.compiler.CompilerMojo - COMPILATION ERROR :
[main] INFO org.apache.maven.plugin.compiler.CompilerMojo - -------------------------------------------------------------
[main] ERROR org.apache.maven.plugin.compiler.CompilerMojo - last round: true
/home/vsts/work/1/s/src/main/java/com/company/services/TemplateService.java:[3,61] error: cannot find symbol
symbol: class VariableNotFoundException
Root Cause
For me the root cause was that I made a commit and pushed it to the server which triggered CI, but did not include one class in the commit that was being used somewhere. Hence the compiler was not able to find it in the CI environment.
throws VariableNotFoundException {
The solution is to make sure you don't have any Git staged files that you forgot to include as part of your commit.
UPDATE
Most of the time this error seems to occur, when the compiler is trying to report a compilation error, but it blows up in the process. So far mainly two approach helped to resolve these issues:
Disable annotation processing by using -proc:none compiler argument (it seems like that annotation processing can upset the compiler, so if you are not meant to use any, this is a free win).
Debug the compiler using a conditional breakpoint and walk the stack until a compiler error message can be found, and then fix that error...
ORGINAL SOLUTION
After lots of trial and error I was able to work around/fix this problem locally, my approach in the end was the following:
I had an assumption that maybe the dependencies are somehow interfering with the build result, so I started to comment out Maven <dependency> entries in the failing module's POM.
the build then started to fail, but it did so with the expected cannot find symbol and similar compilation errors instead of the unhelpful AssertionError failure
it turned out that there was one particular dependency that triggered this AssertionError.
After code analysis, I couldn't determine any good reason why that dependency would cause problems, so I started to look at the transitive dependencies
I then used the same approach as before, but instead of uncommenting the faulty dependency, I've inserted all of its transitive dependencies into the POM
the build again failed, and after lots and lots of testing it turned out that I could trigger the AssertionError when both io.vavr:vavr:0.9.0:compile and javax.servlet:servlet-api:3.0.1:test were included in the dependency graph
It is still beyond me how a test scoped dependency could have any effect on the project's compilation... It also turned out that javax.servlet:servlet-api:3.0.1:provided was already amongst the dependencies of the failing module, and the test scoped dependency wasn't actually used for anything.
In the end I just removed the incorrectly defined test scoped servlet-api dependency from the bug triggering module and suddenly Maven was able to compile the previously failing module.
I'm fairly sure that this is a very obscure answer to a very obscure question in the first place, but hopefully my approach will be of use for someone else.
I got the same error on java 11. Adding jaxb api dependency to the pom solved my issue.
I had a similar stacktrace (abbreviated):
Exception in thread "main" java.lang.AssertionError at
jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
...
...javac.main.JavaCompiler.readSourceFile(....
Since this occurred after a recent change to a library I had made, I traced the issue to a case change in a class name in one of my dependencies.
My dependency had changed from having a class with, for example, BlahMDCCustomizer to having a class with the same name but camelcase for 'Mdc' - BlahMdcCustomizer.
The source code I was trying to compile that used this library, had not yet been updated to the new name and still referenced the non-existent BlahMDCCustomizer.
No amount of mvn cleaning, invalidating caches or restarts would resolve the issue.
Once I updated my bad reference to BlahMDCCustomizer to the new name BlahMdcCustomizer, then mvn compile succeeded.
So it would seem that the compiler code has some case-sensitive assertions inside a case-insensitive process. Posting this in case it sheds light on the issue for someone more familiar with the source!
This was using JDK11 & maven 3.5.2, on Windows.
The part of the stack trace
at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:821)
relates to the line of code
throw new CompletionFailure(c, diags.fragment("cant.resolve.modules"));
This would possibly happen when you're trying to build a maven module which is not based on Java9 and/or does not have(correct) module declaration module-info.java with a release version specified as 9 where it won't be able to resolve modules with/without the declaration.
In my case (IntelliJ), it happened due to the caches. So I had to remove .idea (rm -rf **/.idea) and .iml(rm -f **/*.iml) directories/files and re-import the project, Rebuild the project.
Previously, the project was in JDK8 and upgraded in the maven and IntelliJ settings but still some of the configurations remained the same. Hence removing those files reimporting, and rebuilding the project resolved the issue.
I encouter the same crash with the same stack trace.
For me it was due to a spring-boot-maven-plugin in two maven modules (our app's module and an app's library of us). That was pointed to in the existing spring boot multi module spring-boot-maven-plugin compilation failure.
In my case it happened because I before applied
dependency:purge-local-repository
and I had missing dependencies without compile.
So I compiled my missing dependencies and retry
and all went well.
Need to execute mvn clean. It helped me.
I'm trying to do a clean install on this project
https://github.com/jberet/jberet-wildfly-samples
I'm stucked with this error:
Could not resolve dependencies for project
org.jberet.samples:clusterInfinispan:war:1.4.0.Alpha-SNAPSHOT: Failed
to collect dependencies at
org.jberet:jberet-wildfly-cluster-infinispan:jar:1.3.0.Final: Failed
to read artifact descriptor for
org.jberet:jberet-wildfly-cluster-infinispan:jar:1.3.0.Final: Failure
to find org.jberet:jberet-wildfly:pom:1.4.0.Alpha-SNAPSHOT
It appears that artifactory is ONLY available on search.maven.org
I tried to do either a force update -U and to manually clean the local repo directory, but nothing changes.
I wonder if I have to manually add the above repo or should automatically seek there
Any hints?
I think he didn't publish 1.4.0.Alpha in maven center.
You can try to change 1.4.0.Alpha to 1.3.0.Final in pom.xml like this
<parent>
<groupId>org.jberet</groupId>
<artifactId>jberet-parent</artifactId>
<version>1.3.0.Final</version>
</parent>
<groupId>org.jberet.samples</groupId>
<artifactId>wildfly-jberet-samples</artifactId>
<version>1.3.0.Final</version>
And use mvn clean install -Pwildfly
Wow, you are right: https://search.maven.org/artifact/org.jberet/jberet-wildfly-cluster-infinispan/1.3.0.Final/jar
I'm not sure if anybody here on Stackoverflow will be able to help you.
Continue your issue with jberet's community: https://github.com/jberet/jberet-wildfly-samples/issues/2 you have to solve it with them.
EDIT:
Now that I think more about it, it's also possible to add their SNAPSHOT repository to your settings.xml file: https://maven.apache.org/settings.html#Repositories but I didn't find link to their repository.
Anyway: witnessing this I would stay away from jberet project, because this is a big failure on their part.
Read the maven error: "failure to find org.jberet:jberet-wildfly:pom:1.4.0.Alpha-SNAPSHOT" means there is a a dependency referencing org.jberet:jberet-wildfly:pom 1.4.0.Alpha-SNAPSHOT.
Either the repository forbids deploying SNAPSHOT (and it make sense for central)
either your configuration forbids downloading SNAPSHOT (see http://maven.apache.org/settings.html#Repositories).
You should check local pom.xml referencing 1.4.0.Alpha-SNAPSHOT and replace it with a non SNAPSHOT (1.4.0.Alpha for beginners).
I'm trying to setup sonar to analyze both java and javascript sources.
I have a standard structure maven project.
Following THIS example I've added the line
<properties>
<sonar.sources>src</sonar.sources>
</properties>
But when I run
mvn clean install sonar:sonar
I get the following error
[ERROR] Failed to execute goal
org.codehaus.mojo:sonar-maven-plugin:2.5:sonar (default-cli) on
project myproject: File [moduleKey=myproject:myproject,
relative=src/test/java/com/myproject/api/v1/ControllerTest.java,
basedir=C:\sources\project] can't be indexed twice. Please check that
inclusion/exclusion patterns produce disjoint sets for main and test
files -> [Help 1]
"ControllerTest.java" is the first file in the /src/test/java/../.. folder
project structure:
Any hints? Thanks in advance for any help!
UPDATE
1#
Tried Akash Rajbanshi suggestion: error disappeared but js code is not analyzed and also sonar doesn't analyze the test folder
2# tried to put <sonar.language>js</sonar.language> and the js code is actually analyzed but java code is not (that was just a test)
I'm kind of stuck
In order to make SonarQube analyse your tests as well, you should also set the "sonar.tests" property:
<properties>
<sonar.sources>src/main</sonar.sources>
<sonar.tests>src/test</sonar.tests>
</properties>
You can use this instead:
<properties>
<sonar.sources>src/main</sonar.sources>
</properties>
I have a mojo annotated with #requiresDependencyResolution test.
It works for multi-module projects with a single layer of nesting, but a user has reported an issue with a structure such as below.
-- my_project
|
-- pom.xml
-- submodule1
|
-- pom.xml
-- submodule2
|
-- pom.xml
-- submodule21
|
-- pom.xml
-- submodule22
|
-- pom.xml
If submodule21 depends on submodule1 maven reports
Failed to execute goal on project submodule21: Could not resolve
dependencies for project org.my:submodule21:jar:1.0-SNAPSHOT: Could
not find artifact org.my:submodule1:jar:1.0-SNAPSHOT
Removing the requiresDependencyResolution=test annotation prevents this problem but then I do not have access to the information I require for the mojo to run.
From brief scan of the surefire code on github, it looks to also use requiresDependencyResolution=test but is able to run against this project without issue.
https://github.com/apache/maven-surefire/blob/master/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
The only obvious difference from my own code is that it uses java annotations rather than old style javadoc ones.
How is the surefire mojo achieving this?
My code is
http://code.google.com/p/pitestrunner/source/browse/pitest-maven/src/main/java/org/pitest/maven/PitMojo.java
Example project displaying issue
http://code.google.com/p/pitestrunner/issues/detail?id=71
For the benefit of anyone else having this issue - I eventually solved this problem. There was no issue with the plugin.
The difference between surefire and my own plugin was simply the way in which they were being run. Surefire was bound to the test phase, my own plugin was being run by calling a goal directly. When I bind my plugin to the verify phase, everything resolves without issue.