forked from fedora-java/howto
-
Notifications
You must be signed in to change notification settings - Fork 0
/
common_errors.txt
148 lines (121 loc) · 6.44 KB
/
common_errors.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
== Common Errors
This section contains explanations and solutions/workarounds for common
errors which can be encountered during packaging.
[[error_missing_dependency]]
=== 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
<<helper_macros, macros>> for modifying POM files. The one
for removing dependencies is called
<<pom_remove_dep, %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 the `BuildRequires` later, because you need to build
the package in Koji, where the plugin is not allowed. You should do so using
`xmvn-builddep build.log`, where `build.log` is the path to mock's build log.
It will print a list of `BuildRequires` lines, which you can directly paste
into the specfile. To verify that the `BuildRequires` 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 format `mvn(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 in `BuildRequires`, so in this case, it would be:
------
BuildRequires: mvn(commons-io:commons-io)
BuildRequires: mvn(junit:junit)
------
[[error_compilation_failure]]
=== 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 Maven artifact than local
repository provides
- `pom.xml` is missing 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, 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 section about
<<helper_macros, macros for POM modification>> for more information.
[[error_requires_unknown]]
=== 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 into `tests` 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.
[[error_scope_system]]
=== 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