I have a large project that I am working on. I recently checked out our evolution branch, did a git pull and tried to deploy the app locally. It doesn't seem to recognize some libraries or jars in one Java class, so subsequently errors halt me from running. Basically, the import statements go unrecognized in the class.
Turns out I forgot to rebuild maven. When I ran mvn clean install from the command prompt, the build fails (even when I do mvn clean install -fn) as there are tests that fail. I don't often work with maven, or the command line, but here is my full stack trace when I run mvn clean install -e:
I'm running my project in the IntelliJ environment.
When I ran mvn clean install -fn, 'talent-app' was successful, but talent-core still failed and I still got
[INFO] BUILD FAILURE
Please let me know if you have any input, I appreciate it!
I'm not sure I understand your question correctly.
Basically, regarding your first paragraph, you said you had library issues but that after a clean rebuild - of your project, I suppose not of Maven itself - everything is fine?
Regarding the rest of your post, your build is failing because of a failing test case. This is shown by the line:
talent-core ............................... FAILURE
and by the output:
Failed to execute goal [...]. There are test failures.
If you go into the target/surefire-reports folder, you will find some files containing the output and error traces of each test, including the one that failed.
By scrolling up in your terminal, you should also be able to see which test was failing for talent-core.
From then on, by order of preference:
either look at the test reports as mentioned in the output, and attempt to figure our why the test is failing, and either fix the test or the code;
or skip the tests, you can add -DskipTests to the command-line. But you shouldn't skip your tests, really.
Related
I've been trying for the last few weeks at this point to get Maven to compile my project and I am so desperate
I am running the following maven command on the root directory:
mvn clean verify -fae -X
And I am getting the following output: log on Pastebin
This clearly means that it cannot find the module that it has already identified, during compile (meaning any goal that includes compile will throw the same error). IntelliJ could even find the source of the module (with find usages) in the MAVEN LOCAL REPO as a compiled JAR, which baffles me because maven doesn't seem to want to figure that one out and now after renaming it can find the sources in this project too, so I don't know where it could be going wrong at all.
I can't provide any relevant code, because I have no clue where the issue might lie. All of my code can be found on my GitHub here, in the IerisLib repository on the experimental branch.
I am extremely frustrated with this issue and at this point I don't know what to do. I have attempted:
Deleting all and cloning again, changing the module's names twice, rewriting the module-info.java files and just playing around with Maven command parameters(that's how I came up with -fae -X instead of just mvn clean verify).
I'm running Maven 3.8.5
Please, any help is appreciated
I try to build a site for my minecraft plugin but it fails during javadoc generation. I have my pom.xml and the log in this gist.
When I run mvn clean site it fails while generating javadoc because it does not find the dependencies used in my program. The problem is, that these dependencies are usually provided by the server, which tries to run the plugin so it does not make any sense to compile these dependencies. For some dependencies it is even forbidden to compile them. For example the spigot-api, which is part of the io.papermc.paper:paper-api-dependency.
And the weird thing is, it works just fine in IntelliJ. When I run the mvn clean site-command in IntelliJ using a run configuration it works just fine.
I already tried the additionalDependencies option but it did not improve the result.
I could stop it from failing the build by setting failOnError and failOnWarning to false but I still don't want these errors in my log.
Any ideas how to fix it?
Sincerely yours,
Trqhxrd
I imported a maven project to intellij with two modules under a parent project.
The test I want to run is made with TestNg and when I run it I just get a single line of:
java.lang.NullPointerException
No stacktrace, nothing.
If I run it from the command line it works, but only if I cd into the directory of one of the modules.
So basically thats the command that actually works:
cd server
mvn -Dtest=ConversionServiceT2 test
I'm pretty sure I didn't configure IntelliJ in the right way, but I have no idea where to start.
Here a few infos that might help:
I use the openJDK 11
I tried to set the working directory of the test config in IntelliJ to the server directory, which results in the same error
So how can I get this test (or tests in general) to run?
When I use mvn clean install after adding the dependency in the 'pom.xml', I get the following output, instead of the expected Downloading: https://repo.maven.apache.org/maven2/mysql/mysql-connector-java/6.0.5/mysql-connector-java-6.0.5.pom-type of message.
You've only posted the end of the Maven output -- are you sure the new dependency wasn't downloaded before the tests were run? It finishes with BUILD SUCCESS... how do you know something's not working?
What changes did you make to the pom.xml file? If I could see those, I could offer some thoughts about whether they look correct or not.
In case there's any confusion on this point -- you indicate that you ran mvn clean install. These are lifecycle goals of the project itself. Some of what you posted makes me wonder if you really intended to run (thought you were running) the maven-install-plugin. That would look more like $mvn install:install ....
official documentation http://docs.sonarqube.org/display/SONAR/Analyzing+with+Maven says that the proper way of invoking sonar is:
mvn clean install -DskipTests=true
mvn sonar:sonar
but doesn't say why. how does sonar work? does it need compiled classes? so why not just mvn clean compile? or does it need a jar file? so why not just mvn clean package? what exactly does sonar plugin?
Explanation from a SonarSource team member:
In a multi-module build an aggregator plugin can't resolve dependencies from target folder. So you have two options:
mvn clean install && mvn sonar:sonar as two separate processes
mvn clean package sonar:sonar as a single reactor
I was surprised too, so I made a tweet an received the following answer from the official Maven account:
If the plugin is not designed to use the target/classes folder as a substitute, then yes you would need to have installed to get the jar when running *in a different session*. Complain to the plugin author if they force you to use install without foo reason [ed - #connolly_s]
The SonarQube analyzer indeed needs compiled classes (e.g for Findbugs rules, coverage). And since by default it executes tests itself, the compile phase can skip tests.
You can run SonarQube as part of a single Maven command if you meet some requirements:
As Mithfindel mentions, some SonarQube plugins need to analyze .class files. And if you run unit tests outside of SonarQube, then of course the testing plugins must read output from the test phase.
Got integration tests? Then you need to run after the integration-test phase.
If you want to run SonarQube as a true quality gate then you absolutely must run it before the deploy phase.
One solution is to just attach SonarQube to run after the package phase. Then you can get a full build with a simple clean install or clean deploy. Most people do not do this because SonarQube is time-consuming, but the incremental mode added in 4.0 and greatly improved in the upcoming 4.2 solves this.
As far as the official documentation goes, it's a lot easier to say "build and then run sonar:sonar" then it is to say, "open your POM, add a build element for the sonar-maven-plugin, attach it to verify, etc".
One caveat. SonarQube requires Java 6, so if you're building against JDK 1.5 (still common in large organizations), the analysis will have to happen in a separate Maven invocation with a newer JDK selected. We solved this issue with custom Maven build wrapper.