Common Errors
This section contains explanations and solutions/workarounds for common errors which can be encountered during packaging.
Missing dependency
[ERROR] Failed to execute goal on project simplemaven: Could not resolve dependencies for project com.example:simplemaven:jar:1.0: The following artifacts could not be resolved: commons-io:commons-io:jar:2.4, junit:junit:jar:4.11: Cannot access central (http://repo.maven.apache.org/maven2) in offline mode and the artifact commons-io:commons-io:jar:2.4 has not been downloaded from it before. -> [Help 1]
Maven wasn’t able to build project com.example:simplemaven
because it couldn’t find some dependencies (in this case commons-io:commons-io:jar:2.4
and junit:junit:jar:4.11
)
You have multiple options here:
-
If you suspect that a dependency is not necessary, you can remove it from
pom.xml
file and Maven will stop complaining about it. You can use wide variety of macros for modifying POM files. The one for removing dependencies is called%pom_remove_dep
. -
There is a mock plugin that can automate installation of missing dependencies. When you’re using mock, pass additional
--enable-plugin pm_request
argument and the build process would be able to install missing dependencies by itself. You still need to add theBuildRequires
later, because you need to build the package in Koji, where the plugin is not allowed. You should do so usingxmvn-builddep build.log
, wherebuild.log
is the path to mock’s build log. It will print a list ofBuildRequires
lines, which you can directly paste into the specfile. To verify that theBuildRequires
you just added are correct, you can rebuild the package once more without the plugin enabled. -
Add the artifacts to
BuildRequires
manually. Maven packages have virtual provides in a formatmvn(artifact coordinates)
, where artifact coordinates are in the format which Maven used in the error message, but without version for non-compat packages (most of the packages you encounter). Virtual provides can be used directly inBuildRequires
, so in this case it would be:
BuildRequires: mvn(commons-io:commons-io) BuildRequires: mvn(junit:junit)
Compilation failure
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project simplemaven: Compilation failure: Compilation failure: [ERROR] /builddir/build/BUILD/simplemaven-1.0/src/main/java/com/example/Main.java:[3,29] package org.apache.commons.io does not exist [ERROR] /builddir/build/BUILD/simplemaven-1.0/src/main/java/com/example/Main.java:[8,9] cannot find symbol [ERROR] symbol: class FileUtils [ERROR] location: class com.example.Main [ERROR] -> [Help 1]
Java compiler couldn’t find given class on classpath or incompatible version was present. This could be caused by following reasons:
-
pom.xml
requires different version of the Maven artifact than the local repository provides -
pom.xml
is missing a necessary dependency
Different versions of same library may provide slightly different API. This means that project doesn’t have to be buildable if different version is provided. If the library in local repository is older than the one required by project, then the library could be updated. If the project requires older version, then the project should be ported to latest stable version of the library (this may require cooperation with project’s upstream). If none of these is possible from some reason, it is still possible to introduce new compat
package. See compat packages section for more information on this topic.
Sometimes pom.xml
doesn’t list all the necessary dependencies, even if it should. Dependencies can also depend on some other and typically all these will be available to the project which is being built. The problem is that local repository may contain different versions of these dependencies. And even if these versions are fully compatible with the project, they may require slightly different set of dependencies. This could lead to build failure if pom.xml
doesn’t specify all necessary dependencies and relies on transitive dependencies. Such a missing dependency may be considered a bug in the project. The solution is to explicitly add missing dependency to the pom.xml
. This may be easily done by using %pom_add_dep
macro. See the section about macros for POM modification for more information.
Requires cannot be generated
Following dependencies were not resolved and requires cannot be generated. Either remove the dependency from pom.xml or add proper packages to BuildRequires: org.apache.maven.doxia:doxia-core::tests:UNKNOWN
Most often this error happens when one part of the package depends on an attached artifact which is not being installed. Automatic RPM requires generator then tries to generate requires on artifact which is not being installed. This would most likely result in a broken RPM package so generator halts the build.
There are usually two possible solutions for this problem:
-
Install attached artifact in question. For the above error following macro would install artifacts with
tests
classifiers intotests
subpackage.
%mvn_package :::tests: %{name}-tests
-
Remove dependency on problematic artifact. This can involve
pom.xml
modifications, disabling tests or even code changes so it is usually easier to install the dependency.
Dependencies with scope system
[ERROR] Failed to execute goal org.fedoraproject.xmvn:xmvn-mojo:1.2.0:install (default-cli) on project pom: Some reactor artifacts have dependencies with scope "system". Such dependencies are not supported by XMvn installer. You should either remove any dependencies with scope "system" before the build or not run XMvn instaler. -> [Help 1]
Some Maven artifacts try to depend on exact system paths. Most usually this dependency is either on com.sun:tools
or sun.jdk:jconsole
. Dependencies with system scope cause issues with our tooling and requires generators so they are not supported.
Easiest way to solve this for above two dependencies is by removing and adding back the dependency without <scope>
or <systemPath>
nodes:
%pom_remove_dep com.sun:tools %pom_add_dep com.sun:tools
Want to help? Learn how to contribute to Fedora Docs ›