openSUSE:打包 Java
(Build)Requires
Java(指的是通常的运行时、编译器等捆绑包)被拆分为 JRE — Java 运行时环境和 JDK — Java 开发工具包。前者包含 java 命令,用于运行 Java 应用程序。由于 SUSE 遵循 jpackage.org 兼容的命名方案,运行时由 java 符号表示。SDK 使用 java-devel。两者都有版本号,因此您可以请求要使用的 Java 的最低版本。显然,您必须区分 GNU Java 和其他 Java,因此在最常见的情况下,您将请求 Java 版本高于 1.6.0(不包括选择 gcj)。
BuildRequires: java >= 1.6.0 Requires: java >= 1.6.0
这将在每个产品上扩展为默认实现。使用完整的软件包名称是禁止的,因为它会破坏 SUSE 中每次 Java 更新的依赖关系。
启动程序
通常,Java 应用程序不提供启动脚本来从命令行启动程序或与桌面条目/图标一起使用。在这种情况下,在您的 spec 文件中的 %install 部分使用以下代码片段
# startscript
cat > %{name} << 'EOF'
#!/bin/sh
#
# <Program Name> startscript
#
echo Starting %{name} version %{version} ...
echo with options : \${@}
java -jar %{_datadir}/%{name}/%{name}.jar \${@}
EOF
然后使用以下两行将脚本安装到 /usr/bin
install -d -m 755 %{buildroot}%{_bindir}
install -m 755 %{name} %{buildroot}%{_bindir}/
现在您应该能够从命令行启动程序,并通过仅给出名称在桌面文件中引用它。
Java 版本
Sun Java
Sun Java 在 openSUSE 中不再可用。我们可以分发的最后一个过时且不安全的版本在 Java:sun:Factory 中。更新的版本具有禁止我们分发的许可证。
Java 仓库
- Java:packages - 一个用于所有 Java 包的开发项目,您可以在这里找到 Factory 的最新版本
- Java:openjdk6:Factory - 用于 openjdk 的开发项目
示例
一个独立应用程序
例如,我们将使用 "columba",一个完全用 Java 编写的电子邮件客户端。下面可以查看一个示例 spec 文件。
columba.spec
Name: columba
Summary: eMail client written in Java
Version: 1.4
Release: 1
License: GNU General Public License (GPL)
Group: Productivity/Networking/Email/Clients
Source: http://prdownloads.sourceforge.net/columba/columba-%version-src.zip
URL: http://www.columbamail.org
BuildRoot: %{_tmppath}/%{name}-%{version}-build
BuildRequires:unzip
BuildRequires:update-alternatives java-1_5_0-sun-devel
BuildRequires:ant
Requires: java >= 1.5.0
BuildArchitectures: noarch
%description
Columba is an Email Client written in Java, featuring a user-friendly
graphical interface with wizards and internationalization support. Its
a powerful email management tool with features to enhance your
productivity and communication.
So, take control of your email before it takes control of you!
Feature Highlights
* Clean and Response User Interface
* Cross Platform
* Internationalization
* Unlimited Functionality using Plugins
* Safe and Secure
* Glueing together Third-Party Tools
* Multiple Accounts and Profiles
%prep
%setup -qn columba-%version-src
# remove the third party jars
find . -type f -iname "*.jar" -delete
%build
%ant jar
%install
# jars
install -dm 0755 "%buildroot/%_datadir/%name"
install -m 0644 columba.jar "%buildroot/%_datadir/%name/"
# lib
#install -dm 0755 "%buildroot/%_datadir/%name/lib/jpa"
#install -m 0755 lib/jpa/* "%buildroot/%_datadir/%name/lib/"
cp -rp lib "%buildroot/%_datadir/%name/"
install -dm 0755 "%buildroot/%_datadir/%name/native"
cp -rp native/linux "%buildroot/%_datadir/%name/native/"
install -dm 0755 "%buildroot/%_datadir/%name/plugins"
cp -rp plugins/* "%buildroot/%_datadir/%name/plugins/"
# startscript
install -dm 0755 "%buildroot/%_bindir"
cat >"%buildroot/%_bindir/%name" << EOF
#!/bin/sh
exec java -jar "%_datadir/%name/%name.jar"
EOF
chmod 0755 "%buildroot/%_bindir/%name"
%files
%doc AUTHORS CHANGES LICENSE README
%_bindir/%name
%_datadir/%name
%changelog
一个 Java 库
columba 是一个独立应用程序。对于库的打包,有一些差异。以下 Java 库的骨架源自 jpackage.org spec 文件。有一些特殊的宏,例如 %{_javadir} - 有关详细信息,请参阅 openSUSE:Java_RPM_Macros。用于构建(和运行)的 jpackage-utils 中的便捷脚本在 openSUSE:Java jpackage-utils 上进行了描述。
### the skeleton for packaging of the java libraries
### many of these techniques are based on approach of jpackage.org spec files
Name:
Version:
Release:
Summary:
Group: Development/Libraries/Java
License:
URL:
Source:
BuildRoot: %{_tmppath}/%{name}-%{version}-build
BuildArchitectures: noarch
BuildRequires: java-devel
BuildRequires: ant
BuildRequires: javapackages-tools
%description
### Many of Java packages contains a javadoc and this is universal notation
### usefull for majority of Java packages
%package javadoc
Summary: Javadoc for %name
Group: Development/Libraries/Javam
%description javadoc
This package contains a javadoc.
%prep
%setup -q
# remove all third party jars
find . -type f -iname "*.jar" -delete
### Many of Java software comes from Windows, so this sed edit the files with
### Windows encoding - the shell scripts probably not works with the Windows end of lines!
#perl -i -pe 's{\r\n$}{\n}gs'
%build
### Sometimes is necessary to set the CLASSPATH before build
### build-classpath is a standard tool from jpackage-utils
#export CLASSPATH=$(build-classpath foo)
%ant
%install
### create of the directory for installing the jars
install -dm 755 "%buildroot/%_javadir"
# jars
### make name of jars version agnostics
(cd "%buildroot/%_javadir/%name" && for jar in *-%{version}*; do ln -sf "$jar" "${jar/-%version/}"; done)
# javadoc
install -dm 755 "%buildroot/%_javadocdir/%name-%version"
cp -pr api/* "%buildroot/%_javadocdir/%name-%version/"
%files
%_javadir/%{name}*.jar
%files javadoc
%_javadocdir/%name-%version
%changelog
第三方 jar 文件
Java 上游将库作为 jar 文件包含在源代码存档中。这种方法对于开发人员来说很有用,他们倾向于无需下载/或编译所有依赖文件即可快速构建项目。由于平台无关性,使用二进制 jar 文件没有问题。但这对于软件包维护者来说不是很有用,在 Linux 发行版中,使用系统范围内的 jar 文件(位于 /usr/share/java)进行构建和运行时是一种便捷的方法。有一些特殊情况(例如,已签名的 jar 文件),对于这些情况,无法构建自己的 jar 文件,但在常见情况下,没有理由使用第三方二进制文件。
包含外部二进制文件是恶意的,因为
- 它们对只信任自己构建的软件的人来说毫无用处。
- 它们对已经拥有这些二进制文件的人来说毫无用处。
- 它使跟踪依赖关系变得很困难。
- 它使存档更大。
(来自 [jpackage.org:Request to Java developers]
故障排除
bytecode 版本错误
警告:此错误仅存在于 SLE11 目标中,更新的 openSUSE 发行版不会限制 bytecode 版本。
如果收到错误
ERROR: the files above contain java bytecode for something later than java 1.5, ERROR: please set the javac target to 1.5 or lower
您可以将目标设置为 1.5
-Dant.build.javac.source=1.5 -Dant.build.javac.target=1.5
对于 maven
mvn-jpp -Dmaven.compile.target=1.5 -Dmaven.javadoc.source=1.5 ...
或通过以下方式抑制此测试
export NO_BRP_CHECK_BYTECODE_VERSION=true
在 %install 部分。