I am trying to install a maven project at work and getting the following error. A bit of googling shows other people with the mojo problem, but none with the specific maven-war-plug and MavenFilteringException.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project genericIntegrationServer: Executio
n default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Unable to load the mojo 'war' in the plugin 'org.apache.maven.plugin
s:maven-war-plugin:2.1.1'. A required class is missing: org/apache/maven/shared/filtering/MavenFilteringException
Apache Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+0000)
Maven home: C:\dev\apache-maven-3.0.3\bin..
Java version: 1.6.0_19, vendor: Sun Microsystems Inc.
Java home: c:\dev\jdk\1.6\1.6.0_19\jre
Default locale: en_GB, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
I had same issue. However, after running {Maven->Update Project} resolved the issue.
When I had this problem, it seemed to be a problem with my Maven install.
Uninstalling the M2Eclipse plugin and deleting the .m2 folder on my drive, then reinstalling M2Eclipse seemed to fix it.
I just ran into this problem or something very similar:
Unable to load the mojo 'resources'
I had just renamed some view files and had two path related errors in STS / Eclipse which I fixed but after fixing them a red X appeared next to the war line in the POM file.
"Project -> Clean" didn't help.
"Maven -> Update Project" did the trick though and cleared the error message.
I fixed this problem by doing a maven update and force Update of Snapshots/Releases
maven > update Maven Project > force Update of Snapshots/Releases
Yes, force update of Snapshots/Releases works for me. And I think it's an easy way to fix this problem.
I had the same issue and was able to resolve this error in Eclipse by doing an Maven->Update Project and checking the 'Force Update of Snapshots/Releases' check box. Without checking 'Force Update of Snapshots/Releases' though I continued to get the same errors.
The problem is solved by adding a plugin
<build>
<finalName>some_name</finalName>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.2</version>
</plugin>
</plugins>
</pluginManagement>
I experienced a related problem (and ended up at this question after googling).
When building from Eclipse using the Maven plugin (Run As... -> Maven install), it was failing with the following error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:2.4.1:resources (default-resources) on project [project-name]: Execution default-resources of goal org.apache.maven.plugins:maven-resources-plugin:2.4.1:resources failed: Unable to load the mojo 'resources' in the plugin 'org.apache.maven.plugins:maven-resources-plugin:2.4.1'. A required class is missing: org/apache/maven/shared/filtering/MavenFilteringException
(also seen in this coderanch post)
Building from the command line worked fine, and I noticed that in that case it was using maven-resources-plugin version 2.4.3 and not 2.4.1.
In the end I fixed this by uninstalling and then reinstalling the M2Eclipse plugin (ver. 0.12.1) like Kevin suggested. (It seemed to work without deleting the .m2 folder)
I'm thinking the corruption might have happened when I exited Eclipse while it was in the middle of "Updating Indexes...".
I had a similar problem so I deleted only the folder maven folder at ~/.m2/repository/org/apache/maven and worked for me.
All maven libraries was downloaded and the error with MavenFilteringException stopped happened.
Just close and reopen the project
for me it solved the problem adding
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.3.2</version>
</plugin>
as I use
<packaging>war</packaging>
I resolved this issue running clean install.
Navigate to the project root directory in terminal and run mvn clean install.
Then refresh the eclipse project. That's it.
I simply resolved this issue by deleting the repository folder in .m2, then running mvn clean install. In my case, the downloading of dependencies was aborted due to my machine shutting down, so I think one of the plugins were corrupted. Hope this helps someone.
For me, my maven was outdated in the bundle. I was using netbeans. So I first found where my maven was installed by using mvn -version and then copying the location. Then, on MACOS, I went to Netbeans --> Preferences --> Java and then Maven to finally set the maven Home to where maven is installed!
My issue got resolved by doing
Project (right click) -> Maven -> Update Project..
Related
I'm trying to build dbeaver and get the following error when running mvn package:
[ERROR] Cannot resolve project dependencies:
[ERROR] Software being installed: org.jkiss.dbeaver.slf4j 1.0.0.qualifier
[ERROR] Missing requirement: org.jkiss.dbeaver.slf4j 1.0.0.qualifier requires 'bundle org.slf4j.api 0.0.0' but it could not be found
I'm running on Windows 10 and using apache-maven-3.6.1. The strange thing is that when I try the same steps on Linux it builds without problem.
Update
Possible cause is maven 3.6.1 https://www.eclipse.org/lists/tycho-user/msg08177.html
Original post
The problem here, I presume, is that https://dbeaver.io/eclipse-repo/ p2 site is missing slf4j bundle and Tycho (?) cannot resolve the requirement. I still do not know how to make standalone maven build work, but here is an ugly workaround on how to build Windows binary with Eclipse (and embedded maven).
You can use p2-maven-plugin to build that missing bundle yourself. Instead of setting up a brand new project, you can temporarily modify product\localRepository\pom.xml to have a single artifact like
...
<artifacts>
<artifact><id>org.slf4j:slf4j-api:1.7.26</id></artifact>
</artifacts>
...
Now build that (product\localRepository\) project and start jetty
mvn p2:site
start mvn jetty:start
Now you can add this interim update site (http://localhost:8080/site/) to your Eclipse installation (Help -> Install New Software) and install slf4j. You should already be able to run DBeaver from within Eclipse.
To build a binary, add this interim repo into main pom.xml file, e.g. right after local-contrib one.
<repository>
<id>more</id>
<url>http://localhost:8080/site/</url>
<layout>p2</layout>
</repository>
Then go to Run Configurations -> Maven Build -> dbeaver, enter package goal and tick Skip Tests, click Run and go have some coffee.
As you can see Eclipse uses some sort of embedded maven runtime, so I guess it resolves things differently.
Note that if you are updating your local git repo, you might need to update your Eclipse project big time. I was unable to do it with right clicking on the project -> Configure -> Configure and Detect Nested Projects :( But deleting Eclipse project and nested projects (without deleting underlying files) and re-importing Maven project did the trick for me.
There is also an open issue for this https://github.com/dbeaver/dbeaver/issues/6115 .
Dear Stackoverflow Community, I have the following problem with my spring boot starter application. I imported the starter project as a new maven project into IntelliJ. But IntelliJ does not find the dependencies I specified in the pom.
Image of my Application Class:
If I try to run the project I get the following error message.
Image of the Error Message:
I already tried everything from re-installing IntelliJ to re-importing the project or redownloading the dependencies. I simply dont know why IntelliJ doesn´t find the dependencies.
My pom.xml looks as following
Image of my pom.xml:
The first time I tried to edit the pom.xml it said to me "this file does not belong to the project". Maybe this might be one reason.
Running the whole thing with 'mvn install' or 'mvn clean verify' works.
Try this and then build: mvn -U idea:idea
Had the same problem. I have tried everything: invalidating cache, deleting the whole .m2 folder, changing settings, reloding the project, nothing helped.
The solution for me was to delete the .iml files which are IntelliJ module files used for keeping module configuration. After reopening the project it worked.
The idea was not mine, I found the hint here: https://intellij-support.jetbrains.com/hc/en-us/community/posts/203365204--package-does-not-exist-error-despite-autocomplete-being-aware-of-them
Sometimes your workspace could get corrupted.
In my case, I tried to Reload the project and it worked
in my case changed JDK version in Maven importer from JDK 11 to my local JDK version 1.8
Here is how my IntelliJ settings for spring boot application looks like
Click open -> browse your workspace -> and select POM.xml file
Check this in your intelliJ settings
Do this too [Settings --> Maven --> Importing]
I just had the same issue. My solution was to remove all dependencies from the pom, reload via maven -> Reload All Maven Projects. Run mvn compile. Add dependencies back to the pom, maven -> Reload All Maven Projects. Run mvn compile.
Now the Intellij build works.
You need to change Maven's JDK for importing option from Project JDK to the Path variable for Java on your machine.
You can get to this by going to Settings -> Build, Execution, Deployment -> Build Tools -> Maven -> Importing. Scroll down to the bottom and look for JDK for importing:. Select from the list the path variable for JAVA.
For Windows users, JAVA_HOME should be an option in the drop-down list.
Follow these steps, your problem should be solved. You just need to add Spring-framework-starter-web and Spring-framework-starter-tester from your pom.xml file.
Got to generate(ALT+Insert)
Add dependencies
Search "springframwork"
Add...
Here is the link
In my case, adding the project as maven project helped .
I'm using SonarQube for code quality control and suddenly builds that would otherwise pass can't be analyzed and fails.
[INFO] [00:00:03.630] Analysing /mySuperProject/target/jacoco.exec ->
java.io.IOException: Incompatible version 1007
When I invoke maven build with debug switch, this cause is revealed
Caused by: java.io.IOException: Incompatible version 1007.
at org.jacoco.core.data.ExecutionDataReader.readHeader(ExecutionDataReader.java:127)
at org.jacoco.core.data.ExecutionDataReader.readBlock(ExecutionDataReader.java:107)
at org.jacoco.core.data.ExecutionDataReader.read(ExecutionDataReader.java:87)
at org.sonar.plugins.jacoco.AbstractAnalyzer.readExecutionData(AbstractAnalyzer.java:134)
at org.sonar.plugins.jacoco.AbstractAnalyzer.analyse(AbstractAnalyzer.java:107)
While inspecting jacoco ExecutionDataReader, I found that exception is thrown from
if (version != ExecutionDataWriter.FORMAT_VERSION) {
throw new IOException(format("Incompatible version %x.",Integer.valueOf(version)));
}
and from ExecutionDataWriter I've found out
/** File format version, will be incremented for each incompatible change. */
public static final char FORMAT_VERSION = 0x1007;
What is this incompatible change and why does it happen?
Any ideas how to fix this challenge?
As already mentioned, this is due to a break in JaCoCo maven plugin code.
You can (temporarily) specify the version in your jenkins maven command like:
clean org.jacoco:jacoco-maven-plugin:<version>:prepare-agent install
e.g.
clean org.jacoco:jacoco-maven-plugin:0.7.4.201502262128:prepare-agent install
This was the workaround that helped us. But like most people, I'm still waiting for the fix to come.
What I did was to specify the jacoco version in my maven project.
<jacoco-maven-plugin.version>0.7.4.201502262128</jacoco-maven-plugin.version>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco-maven-plugin.version}</version>
</plugin>
That fix my issue!
Most likely that's caused by latest jacoco-maven-plugin update. Everything was working on 0.7.4.201502262128 but today we switched to 0.7.5.201505241946 which resulted in this error.
Run:
mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent install
mvn org.jacoco:jacoco-maven-plugin:prepare-agent clean install -Pcoverage-per-test
mvn sonar:sonar
This will re-generate .exec files created by older versions of jacoco.
Try to update the Java plugin in SonarQube Update Center, this works for me. I updated the Java plugin from version 2.4 to latest 3.13.1.
SonarQube Update Center -> Plugin Updates -> Java
As kdowbecki mentionned it, this error is most likely due to an update of jacoco-maven-plugin.
Your SonarQube is most likely now using the new version of Jacoco Maven Plugin (probably the new 0.7.5.201505241946) but is actually trying to read an old version of a jacoco.exec (in your case it might be reading a jacoco.exec generated by jacoco maven plugin version 0.7.4.201502262128) which results in an incompatibility thrown by JaCoCo.
To fix this problem, you should make sure all your SonarQube/Jenkins jobs generate a JaCoCo report each time and do not rely on an older version of jacoco.exec that might have been generated by a previous job.
For me this, when doing a mvn install
Error while creating report: Cannot read execution data version 0x1006. This version of JaCoCo uses execution data version 0x1007
meant I had done an archetype generate but the archetype accidentally included the target directory with old jacoco files in it (or it had been checked into git on accident). Doing a mvn clean first (and checking that in) cleared up the issue. Guess jacoco is reluctant to overwrite the jacoco.exec file with a new one when there are no unit tests to run or something like that, so the old file gets preserved and attempted to used for the jacoco report. FWIW...
In general it means a version mismatch of generator vs. reporter.
I changed pom.xml like
groupId=org.jacoco
artifactId=jacoco-maven-plugin
version=0.8.4-SNAPSHOT
it worked for me
I occasionally receive this error when I build my project with
>mvn --version
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 15:51:28+0200)
Maven home: ...\apache-maven-3.0.5
Java version: 1.6.0_45, vendor: Sun Microsystems Inc.
Java home: ...
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
and the error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:2.5:resources
(default-resources) on project project-name: Cannot create resource output directory:
path\to\project\code\project-name\target\classes -> [Help 1]
Note: this happens sometimes, and it is not related to the code. It can happen in one of two consecutive builds - one after the other, against exactly the same source code.
Does anyone have any idea how to avoid it completely? It tends to interrupt quite a time-consuming build :-/
On Windows, there reasons for being unable to create a folder are:
Some other process is deleting this folder at the same time
You don't have permissions to access this folder
The folder is on a network share
Network shares are notoriously unreliable on Windows. Don't use them for any automated tasks. Always build projects with all files residing on a local hard disk.
If you use Maven and Eclipse to build at the same time, you should configure them to use different target folders. See https://stackoverflow.com/a/54366009/34088
Your POM should look like this:
<project>
...
<build>
<outputDirectory>${basedir}/${target.dir}/classes</outputDirectory>
<testOutputDirectory>${basedir}/${target.dir}/test-classes</testOutputDirectory>
</build>
<properties>
<target.dir>target</target.dir>
</properties>
<profiles>
<profile>
<id>eclipse-folders</id>
<properties>
<target.dir>target-eclipse</target.dir>
</properties>
</profile>
</profiles>
...
All that's left is to enable the profile eclipse-folders in the IDE.
Disable the automatic build of your IDE (Eclipse or IntellJ IDEA or whatever). It will conflict with the Maven build.
I experience this issue every time I run the command while I have the output folder or the parent folder opened in Windows Explorer.
If I move one level above the parent, the build ends successfully.
For me the reason for this was only being in said folder with my git bash while building. Ensure that you don't happen to have the said folder open in any other program.
I had the exact same issue when trying to run the First Cup tutorial.
I fixed it by simply closing NetBeans and running it as administrator (via right click).
In my case the parent directory inside which maven was trying to create a directory was root, so I did a sudo chown -R : /path/to/directory to change permissions before rerunning the mvn command.
In my case, I opened the jar in 7zip and I opened the target folder. I run my application and received this error. After closing 7zip, the application run fine and build successfully.
You can use the following in pom.xml
<build>
<directory>${project.basedir}/target1</directory>
</build>
My issue was resolved when I gave mvn clean command from windows coammandprompt
Please note :- My mvn clean install goes successful
but when i do mvn sonar:sonar it throws me
[ERROR] Squid Error occurs when analysing :/junk/test/src/main/java/API/com/API/HelloAPI.java
org.sonar.squid.api.AnalysisException: The source directory does not correspond to the package declaration com.API
at org.sonar.java.ast.visitor.PackageVisitor.checkPhysicalDirectory(PackageVisitor.java:93) [sonar-squid-java-plugin-2.8.jar:na]
at org.sonar.java.ast.visitor.PackageVisitor.createSourcePackage(PackageVisitor.java:75) [sonar-squid-java-plugin-2.8.jar:na]
http://sonar-dev.787459.n3.nabble.com/file/n3324837/squid-test.zip
The message is quite clear: the package declaration is wrong. It should be API.com.API if the source directory is /junk/test/src/main/java (that is the default value in Maven). An alternative is to change the source dir to src/main/java/API.
Could it be that your POM contains this line:
<sourceDirectory>.</sourceDirectory>
If so, changing it to this might help:
<sourceDirectory>src/main/java</sourceDirectory>
Maven doesn't care, but sonar does.
I had the same problem with sonar and a maven project generated by eclipse.
(Found the solution at http://www.digipedia.pl/usenet/thread/13899/13064/ )
I got the same error message after upgrading to a more recent sonar plugin (sonar-maven3-plugin:3.7.1/3.7.3/4.0 running against SonarQube Server 3.5.1) for a source file which worked with 3.6-RC3/3.6.3/3.7.0. Apparently 3.7.1 introduced the issue :-/