|Deletions are marked like this.||Additions are marked like this.|
|Line 29:||Line 29:|
|3. Check if the Maven coordinates in upstream's pom.xml file match with Debian's system libraries. If they don't, then you must overwrite groupId/artifactId/version in debian/maven.rules, so that the build system can find them in Debian's local /usr/share/maven-repo directory.||3. Check if the Maven coordinates in upstream's pom.xml file match with Debian's system libraries. If they don't, then you have to override groupId/artifactId/version in debian/maven.rules, so that the build system can find them in Debian's local /usr/share/maven-repo directory.|
How can I use a specific version of OpenJDK to build a package?
Instead of a build-dependency on default-jdk, you can build-depend on openjdk-8-jdk or openjdk-11-jdk. Then you have to make sure JAVA_HOME points to your specific version and not to the default one. You can achieve that by adding
to debian/rules in case you are building the package on amd64.
This is useful for debugging build failures with a non-default JDK. Not build-depending on default-jdk should be avoided though unless there is a very good reason. Otherwise it would make transitions to newer JDK versions more difficult.
[MAVEN] Failed to execute goal [...] dependencies could not be resolved
Failed to execute goal [...] one of its dependencies could not be resolved [...] and the artifact XYZ has not been downloaded from it
This is a very common error message when you try to package Maven projects. There are multiple possible reasons for this error.
The build-dependency was not added to debian/control. How can you find out wheter a certain jar file is already packaged for Debian? Use codesearch.debian.net or search for packages on https://www.debian.org/distrib/packages. If in doubt ask for help on the debian-java mailing list.
- Make sure that all submodules of a Maven project are added to your debian/*.poms file. If the artifact has not been packaged for Debian yet, it is often possible to just ignore a certain submodule.
- Check if the Maven coordinates in upstream's pom.xml file match with Debian's system libraries. If they don't, then you have to override groupId/artifactId/version in debian/maven.rules, so that the build system can find them in Debian's local /usr/share/maven-repo directory.
Error: package XYZ does not exist, cannot find symbol
This is also a very common Java error message. The build system tries to compile a *.java file into a *.class file but fails to find a referenced class or method.
- Make sure that the class/method which is missing, is imported correctly. The import statement might be outdated or missing completely.
- Ensure that the package which contains the missing class/method is referenced in debian/control as a build-dependency.
- If this error message occurs after you have successfully packaged your project, it might have been caused by changes to one of your build-dependencies. A newer version might have removed or renamed the class/method. In this case you could either patch the file or maybe a newer upstream version will resolve this issue for you.
- Make sure that maven.rules correctly points to the jar file in /usr/share/maven-repo or that the jar file is really on your CLASSPATH (Ant, no-build system)
Unmappable character for encoding US-ASCII
Unfortunately all build systems default to US-ASCII as the default encoding. Some packages contain umlauts or chinese characters that cannot be displayed with the default encoding and thus will cause build failures. You can fix this by
- [MAVEN] Adding project.build.sourceEncoding=UTF-8 (or some ISO encoding) to debian/maven.properties.
- [ANT] export JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8 in debian/rules
- [jh_build] Pass --javacopts='-encoding UTF-8' or --javadoc-opts='-encoding UTF-8' to jh_build
- Patch build.xml, pom.xml or build.gradle