Java/HOWTO

Материал из ALT Linux Wiki

< Java(Различия между версиями)

Текущая версия на 08:36, 29 марта 2009

Содержание

1 Предварительные сведения
2 Общие указания по сборке
- 2.1 Сборка в hasher требует /proc
- 2.2 Шаблоны spec-файлов
3 Определение типа сборочной системы
4 Сборка с помощью ant
5 Сборка с помощью ivy
6 Сборка с помощью maven1
7 Сборка с помощью maven2
- 7.1 Советы

Предварительные сведения

Прежде чем читать данный документ, необходимо ознакомиться с ALT Linux Java Policy и JPackagePolicy. Оригинал JPackagePolicy можно найти в пакете jpackage-utils (в сизифе или на www.jpackage.org). Также доступен Перевод JPackagePolicy на русский.

Общие указания по сборке

Сборка в hasher требует /proc

добавьте allowed_mountpoints=/proc в /etc/hasher-priv/system и --mountpoints=/proc в параметры hasher.

В противном случае попытка сборки в hasher приведет к ошибкам вида:

/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: 
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)

и даже вида

...
checking whether to build with Java support... yes
checking for java... /usr/bin/java
checking the installed JDK... configure: error: JDK is too old, you
need at least 1.5
...

(configure не заметил, что /usr/bin/java завершился аварийно).

Шаблоны spec-файлов

JPackage Spec Template — шаблон spec-файла для java-приложений из JPackage, адаптированный для сизифа.

javalib Spec Template — шаблон spec-файла для java-библиотеки, собираемой с помощью ant.

Определение типа сборочной системы

Тип сборочной системы можно определить по файлам в корневом каталоге проекта.

Наиболее распространённые системы сборки:

Файл	Сборочная система
build.xml	ant
maven.xml	maven1
pom.xml	maven2
ivy.xml	ivy+ant

Существуют и другие системы сборки для java, но из-за их редкости здесь они рассматриваться не будут.

Сборка с помощью ant

%prep

Обычно проекты на ant таскают с собой готовые собранные сторонние библиотеки, необходимые для сборки. Все эти библиотеки необходимо удалить

find . \( -name '*.jar' -or -name '*.zip' \) -exec rm -f {} \;

либо переместить:

find . \( -name '*.jar' -or -name '*.zip' \) -exec mv {} {}.no \;

Пакеты не должны использовать при сборке эти готовые сторонние собранные библиотеки, а должны использовать вместо них библиотеки, собранные в Сизифе. Если какой-то готовой сторонней собранной библиотеки в Сизифе нет, ее необходимо сначала туда собрать.

Пусть, например, до удаления ls ./lib показывало

ls ./lib
commons-cli.jar
xerces-j.jar

Нам нужно использовать вместо них библиотеки, собранные в Сизифе. Для этого установим в сборочную среду пакеты jakarta-commons-cli и xerces-j2. теперь добавим в проект вместо удаленных библиотек ссылки на библиотеки из Сизифа.

ln -s $(build-classpath commons-cli) ./lib/commons-cli.jar
ln -s $(build-classpath xerces-j2) ./lib/xerces-j.jar

Заметим, что в Сизифе jar называется xerces-j2.jar, но в проекте ожидается xerces-j.jar.

При создании символической ссылки мы использовали скрипт build-classpath пакета jpackage-utils. Например, $(build-classpath commons-cli) расскрывается в /usr/share/java/commons.cli.jar. Возникает вопрос, зачем использовать build-classpath, если можно просто написать

ln -s /usr/share/java/commons.cli.jar ./lib/commons-cli.jar

Ответ - /usr/share/java только одно из мест, где может лежать библиотека. build-classpath просматривает все эти места, а также учитывает различия в JVM. Например, build-classpath xml-commons-apis выдаст /usr/share/java/xml-commons-apis.jar под java-1.4.2-sun и ссылку на tools.jar (стандартную библиотеку JVM) под java-1.5.0-sun. Места, в которых ищется библиотека, детально описаны в JPackagePolicy.

%build

смотрим в build.xml, какие там есть цели. Нужная цель скорее всего будет одной из

ant all
ant jar javadoc
ant dist

Для небольших проектов можно не заниматься наполнением ./lib, а просто перечислить все необходимые библиотеки в переменной CLASSPATH:

export CLASSPATH=%(build-classpath commons-cli xerces-j2)
ant -Dbuild.sysclasspath=first dist

В build.xml должны быть заданы параметры компилятора source и target. Если они не заданы, то их лучше указать явно при вызове ant. Например,

ant -Dant.build.javac.source=1.4 -Dant.build.javac.target=1.4 <список целей>

Поскольку в сизифе минимальная версия java это 1.4.2, гнаться за значениями source и target, меньшими, чем 1.4, не имееет особого смысла. Если же исходники используют диалект java5, придется указать

ant -Dant.build.javac.source=1.5 -Dant.build.javac.target=1.5 <список целей>

Это позволит иметь код, совместимый с java5 (java4), даже если при компиляции использовался java6.

Если компиляция завершилась аварийно с сообщением вида

[javac] javac: source release 1.4 requires target release 1.4

Это означает, что в build.xml в разделе <javac> значение target уже указано, при чем отличное от 1.4. Тогда -Dant.build.javac.source=1.4 -Dant.build.javac.target=1.4 можно опустить либо согласовать с тем, которое указано в build.xml. Как правило, лучше согласовать.

Заметим, что для вызова ant есть специальный макрос

%ant

Раскрывающийся в "установить JVM и вызвать ant". В текущем Сизифе использовать этот макрос не обязательно, но "на всякий случай" рекомендуется.

%install

Внимательно перечитайте JPackage Policy.

Tips:

устанавливайте arch-и jvm -независимые публичные jar в %_javadir, arch-зависимые в %_jnidir, jvm-specific в %_javadir-ext.
не забудьте %name-%version.jar.
Создавайте симлинк %name.jar и симлинки с другими употребительными именами. Пример

pushd $RPM_BUILD_ROOT%{_javadir}
for jar in *-%{version}*; do ln -sf ${jar} `echo $jar| sed  "s|jakarta-||g"`; done
for jar in *-%{version}*; do ln -sf ${jar} `echo $jar| sed  "s|-%{version}||g"`; done
popd

Для больших проектов создавайте поддиректорию %_javadir/%name/.
Если приложению нужно приватное дерево, размещайте его в %_datadir/%name/.

Сборка с помощью ivy

Вам крупно повезло. Сочуствую.

Сборка из src.rpm не должна лазить в интернет за внешними файлами. И не факт, что это будет разрешено в сборочнице Сизифа.

Можно, конечно, пытаться обмануть ivy самодельным локальным репозиторием, но чем отучать ivy, гораздо проще глазами просмотреть ivy.xml файлы, собрать вручную нужный CLASSPATH=, выдрать с корнем упоминания ivy из build.xml файлов (см. как пример, chainedoptions-0.9.0-alt-kill-ivy.patch).

После этого сборка сводится к сборке с помощью ant. Только не забудьте ткнуть ant носом в ваш CLASSPATH, например, через

-Dbuild.sysclasspath=only

Сборка с помощью maven1

maven1 является устаревшим, и новые проекты мигрируют на maven2. Поэтому сборка с помощью maven1 рассматриваться не будет.

При необходимости рекомендуется найти в Сизифе пакеты с

BuildRequires: maven-plugins

или

BuildRequires: maven

и провести сборку, используя найденные пакеты как пример.

Сборка с помощью maven2

TODO

см. также Fedora Maven Readme

Советы

# Out of memory

# for PermGen error, running out of memory
export MAVEN_OPTS=-XX:MaxPermSize=512m

export MAVEN_OPTS="-Xmx256m"
-Dmaven.javadoc.additionalparam=-J-Xmx256m

# skip tests
-Dmaven.test.skip=true
-Dmaven.test.skip.exec=true

#List of ant patterns (spared by commas) used in test:match goal to specify the tests that shouldn't run
-Dtestnotmatchpattern='*'
-Dtestnotmatchpattern='Hey*,Joo*,??Kaa*'

-Dmaven.compile.target=1.4
-Dmaven.javadoc.source=1.4

an example how to install missing jar file manually
#--------------------------------------------------------------
# Mock objects is sort of a special case since it does not reside in 
# /usr/share/java. So we install it manually via maven.

export MAVEN_REPO_LOCAL=$(pwd)/.m2/repository
mkdir -p $MAVEN_REPO_LOCAL

mvn-jpp install:install-file \
    -Dmaven.repo.local=$MAVEN_REPO_LOCAL \
    -DgroupId=mockobjects \
    -DartifactId=mockobjects-jdk1.4-j2ee1.3 \
    -Dversion=0.09 \
    -Dpackaging=jar \
    -Dfile=$(build-classpath mockobjects-jdk1.4-j2ee1.4)

Java

Java Policy • Java/ClassPathInManifest • Java/HOWTO • Java/JPackagePolicyTranslation • Java/JPackageSpecTemplate • Java/JavaPackagingFAQ • JavaPlugin