Java/HOWTO: различия между версиями

Материал из ALT Linux Wiki
Нет описания правки
 
(не показана 31 промежуточная версия 5 участников)
Строка 1: Строка 1:
[[Category:Policy]]
== Предварительные сведения ==
{{Викифицировать}}
 
Прежде чем читать данный документ, необходимо ознакомиться с [[JavaPolicy| ALT Linux Java Policy]] и JPackagePolicy.
Оригинал JPackagePolicy можно найти в пакете jpackage-utils (в сизифе или на [http://www.jpackage.org/ www.jpackage.org]).
Также доступен [[Java/JPackagePolicyTranslation|Перевод JPackagePolicy на русский.]]


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


----
=== Сборка в 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-файлов ===
[[Java/JPackageSpecTemplate|JPackage Spec Template]] — шаблон spec-файла для java-приложений из JPackage, адаптированный для сизифа.


Прежде чем читать данный документ, необходимо ознакомиться с [[JavaPolicy| ALTLinux Java Policy]] и JPackagePolicy.
[[SampleSpecs/javalib| javalib Spec Template]] — шаблон spec-файла для java-библиотеки, собираемой с помощью ant.
Оригинал JPackagePolicy можно найти в пакете jpackage-utils (в сизифе или на [http://www.jpackage.org/ www.jpackage.org]).
Также доступен [[Java/JPackagePolicyTranslation|Перевод JPackagePolicy на русский.]]


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


Наиболее распространенные системы сборки:
Наиболее распространённые системы сборки:
{| class="standard"
{| class="standard"
  |файл
  !Файл
  |сборочная система  
  !Сборочная система  
  |-
  |-
  |build.xml
  |build.xml
Строка 28: Строка 49:
  |pom.xml
  |pom.xml
  |maven2
  |maven2
|-
|ivy.xml
|ivy+ant
  |}
  |}


Строка 38: Строка 62:
Обычно проекты на ant таскают с собой готовые собранные сторонние библиотеки,
Обычно проекты на ant таскают с собой готовые собранные сторонние библиотеки,
необходимые для сборки. Все эти библиотеки необходимо удалить
необходимые для сборки. Все эти библиотеки необходимо удалить
find . \( -name '*.jar' -or -name '*.zip' \) -exec rm -f {} \;
find . \( -name '*.jar' -or -name '*.zip' \) -exec rm -f {} \;
либо переместить:
либо переместить:
find . \( -name '*.jar' -or -name '*.zip' \) -exec mv {} {}.no \;
find . \( -name '*.jar' -or -name '*.zip' \) -exec mv {} {}.no \;


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


Заметим, что в Сизифе jar называется xerces-j2.jar, но в проекте ожидается 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 ===
Строка 71: Строка 108:
  export CLASSPATH=%(build-classpath commons-cli xerces-j2)
  export CLASSPATH=%(build-classpath commons-cli xerces-j2)
  ant -Dbuild.sysclasspath=first dist
  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 ===
=== %install ===
Строка 77: Строка 138:
Tips:
Tips:


* устанавливайте arch-и jvm -независимые jar в %_javadir, arch-зависимые в %_jnidir, jvm-specific в %_javadir-ext.
* устанавливайте arch-и jvm -независимые публичные jar в %_javadir, arch-зависимые в %_jnidir, jvm-specific в %_javadir-ext.
* не забудьте %name-%version.jar.
* не забудьте %name-%version.jar.
* симлинк %name.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/.
* Для больших проектов создавайте поддиректорию %_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 ==
Строка 88: Строка 170:


При необходимости рекомендуется найти в Сизифе пакеты с  
При необходимости рекомендуется найти в Сизифе пакеты с  
:BuildRequires: maven-plugins  
BuildRequires: maven-plugins  
или BuildRequires: maven
или
BuildRequires: maven
и провести сборку, используя найденные пакеты как пример.
и провести сборку, используя найденные пакеты как пример.


== Сборка с помощью maven2 ==
== Сборка с помощью maven2 ==
TODO
см. также [http://fedoraproject.org/wiki/Java/JPPMavenReadme Fedora Maven Readme]
=== Советы ===
<pre>
# 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)
</pre>
{{Category navigation|title=Java|category=Java|sortkey={{SUBPAGENAME}}}}

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

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

Прежде чем читать данный документ, необходимо ознакомиться с 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)