https://www.altlinux.org/api.php?action=feedcontributions&user=SergeyLebedev&feedformat=atomALT Linux Wiki - Вклад [ru]2024-03-28T18:40:18ZВкладMediaWiki 1.38.2https://www.altlinux.org/index.php?title=Alterator/translate&diff=16631Alterator/translate2010-10-25T10:26:34Z<p>SergeyLebedev: Новая страница: «Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1 25/10/2010 Перевод в alterator-е. Далее краткий обзор того, к...»</p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1<br />
<br />
25/10/2010 <br />
<br />
Перевод в alterator-е. Далее краткий обзор того, как организовать перевод для каждого компонента и какими средствами производить отладку.<br />
<br />
'''HTML'''<br />
<pre><br />
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><br />
<html wf="none" po-domain="MySuper-module" ><br />
<body><br />
<br />
<form method="POST"><br />
<table width="100%"><br />
<tr><br />
<td align="left"><br />
<span translate="_">New Data</span><br />
</td><br />
</tr><br />
<tr><br />
</table><br />
</form><br />
</body><br />
</html><br />
</pre><br />
<br />
В html важны 2-момента: <br />
* указание в теге <html> атрибута po-domain="MySuper-module". Часто модуль состоит из нескольких компонентов, /MySuper-module/submodule1 /MySuper-module/submodule2 и так далее. Чтобы перевод относился к одному po- и mo- (man gettext) файлу с именем MySuper-module.{po,mo} и поиск осуществлялся именно в нём, и необходим этот "загадочный" po-domain.<br />
* необходимо текст, который будет переведен, брать в тег <span translate="_"></span>, так же как это сделано с New Data в примере выше.<br />
<br />
<br />
'''AJAX'''<br />
В данном примере мы при нажатии на кнопку "Create/Add", отображается всплывающее сообщение об ошибке. Так же как и в случаи с html, мы указываем второй параметр (domain) в виде MySuper-module функции (_). <br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-datadd)<br />
(form-error (_ "This is error text" "MySuper-module"))<br />
)<br />
<br />
<br />
(define (init)<br />
(form-bind "datadd" "click" ui-datadd)<br />
)<br />
</pre><br />
<br />
'''BACKEND'''<br />
<br />
Как и в случаи с html<br />
* po-domain="MySuper-module" в начале shell-cкрипта<br />
* и более интересное с тем как передавать во write_error переведенное сообщение. Вызов subshell в переменной str необходимо делать именно таким образом. По крайней мере на RHEL gettext-0.14.6-4.el5, разобрать конструкцию вида str="$(_ "Epic Faile '%s'")" не может. <br />
<br />
<pre><br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
po-domain="MySuper-module"<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
<br />
<br />
<br />
addMyData()<br />
{<br />
local test="some value"<br />
local str="`_ "Epic Faile '%s'"`"<br />
do_some_action || write_error "`printf "$str" $test`"<br />
}<br />
<br />
<br />
on_message(){<br />
<br />
case "$in_action" in<br />
new)<br />
[ -n "$in_toBackendData" ] && addMyData "$in_toBackendData"<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
</pre><br />
<br />
После того как backend, ajax и html будут подобным образом подготовлены, необходимо в системе, где производится генерация перевода, поставить пакет alterator, положить исходник пакета alterator-l10n, зайти в директорию alterator-l10n и вызвать ./update_module c путем до исходного кода вашего модуля.<br />
<br />
как пример<br />
<pre><br />
rpm -q alterator<br />
alterator-4.17-1.el5<br />
<br />
<br />
[root@localhost git]# cd alterator-l10n/<br />
[root@localhost alterator-l10n]# ls<br />
alterator-l10n alterator-l10n.spec Makefile<br />
<br />
[root@localhost alterator-l10n]# cd alterator-l10n<br />
[root@localhost alterator-l10n]# ls<br />
alterator.pot country-po headers join_po Makefile pot update_desktop utils<br />
compendium functions help l10n po tzone-po update_module<br />
<br />
[root@localhost alterator-l10n]# ls ../../MySuper-module<br />
MySuper-module MySuper-module.spec Makefile<br />
<br />
[root@localhost alterator-l10n]# ls ../../MySuper-module/MySuper-module<br />
applications backend3 desktop-directories Makefile ui<br />
<br />
[root@localhost alterator-l10n]# ./update_module ../../MySuper-module/MySuper-module<br />
</pre><br />
<br />
Результатом этого действа будут файлы pot/MySuper-module.pot po/{ru,es,..}/MySuper-module.po<br />
<br />
Файл po/ru/MySuper-module.po правится (обязательно удаляются строки #fuzzy, иначе в конечный mo-файл они не попадут). После чего оба пакета MySuper-module и alterator-l10n собираются и устанавливаются в систему. При входе на соответствующую страницу alterator-а, получаем результат.<br />
<br />
'''Debug'''<br />
Когда что-то идет не так. <br />
* проверить po/ru/MySuper-module.po на наличие fuzzy строк<br />
* убедится что в po/ru/MySuper-module.po имеются строки из backend-а, html-а, ajax-а<br />
* проверить в новь созданном mo-файле (создается в момент сборки rpm-пакета alterator-l10n) MySuper-module.mo наличие оригинальных строк из .po файла. Я это делаю вызовом strings /usr/share/locale/ru/LC_MESSAGES/MySuper-module.mo.<br />
* еще раз проверить наличие po-domain везде, где это должно, вызов (_ "" "") с указанием вторым параметром MySuper-module в .ajax<br />
* если не из backend-а не выбираются строки, то проверить следующей командой <pre> :> temp.po ; LANG=C xgettext --join-existing --add-comments -otemp.po -L Shell --keyword=_ -- backend3/MySuper-module</pre>. Находится надо в директории MySuper-module/MySuper-module, смотри выше содержимое этой директории.<br />
* в целом, формирование конечного MySuper-module.po файла, осуществляется вызовом make-cкрипта /usr/share/alterator/build/po.mak, который для каждого компонента (ajax,html,backend и т.д.) вызывает соответствующий xgettext-cкрипт из /usr/share/alterator/build/xgettext/<br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator&diff=16630Alterator2010-10-25T09:47:04Z<p>SergeyLebedev: /* Разное */</p>
<hr />
<div>[[Category:Sisyphus]]<br />
[[en:Alterator]]<br />
'''Alterator''' — новое поколение платформ для разработки сложных систем. Используются по большей части [[Scheme]], C и старый добрый sh+awk. На данный момент используется как [[Installer|инсталлятор]] и конфигуратор системы. Копия части этой документации содержится в пакете [http://sisyphus.ru/srpm/alterator alterator]. <br />
<br />
Для обсуждения вопросов, связанных с alterator, существует список рассылки {{lists|devel-conf}}.<br />
<br />
=== Обращение к системным администраторам ===<br />
Наверняка в alterator недостаточно модулей для решения ваших задач. Каждый модуль состоит из бэкенда и интерфейса. Разработка интерфейса — это работа для программиста, но создать бэкенд вы вполне сможете. Бэкенд пишется на произвольном языке программирования по достаточно простым правилам. Имея бэкенд, при помощи интерфейса командной строки вы уже сразу же сможете использовать наработки в своих скриптах. Хороший бэкенд — это фиксация знаний и возможность повторного использования ваших наработок другими администраторами.<br />
Напишите в список рассылки — мы поможем сделать интерфейс.<br />
<br />
===Общие сведения===<br />
*[[Alterator/faq|Часто задаваемые вопросы]]<br />
*[[Alterator/debug|Отладка модулей]]<br />
*[[Alterator/todo|Книга жалоб и предложений]]<br />
*[[Alterator/releases|Выпуски]]<br />
<br />
=== Руководства ===<br />
*[[Alterator/module/first|Первый модуль]]<br />
*[[Alterator/module/structure|Структура модуля]]<br />
*[[Alterator/module/backend|Бэкенд]]<br />
*[[Alterator/module/interface|Интерфейс]]<br />
*[[Alterator/module/types|Автоматическая проверка данных]]<br />
*[[Alterator/module/debug|Отладка модулей]]<br />
*[[Alterator/module/testing|Тестирование модулей]]<br />
<br />
===Справочная информация===<br />
<br />
*[[Alterator/architecture|Архитектура]]<br />
<br />
*[[Alterator/libraries|Стандартные библиотеки scheme, предоставляемые alterator]]<br />
*[[Alterator/reserved|Зарезервированные имена]]<br />
*[[Alterator/woo|Функции для запроса бакендов]]<br />
*[[Alterator/form|Функции для работы с полями форм]]<br />
*[[Alterator/shell|Бэкенды на shell]]<br />
*[[Alterator/perl|Бэкенды на perl]]<br />
*[[Alterator/ruby|Бэкенды на ruby]]<br />
<br />
*[[Alterator/i18n|Интернационализация]]<br />
*[[Alterator/l10n|Локализация]]<br />
<br />
<br />
'''Lookout:'''<br />
*[[Alterator/evolution|Описание общей структуры документа lookout]]<br />
*[[Alterator/widgets|Краткий справочник по виджетам]]<br />
<br />
===Разное===<br />
*[[Alterator/objects|Объектная система alterator]]<br />
*[[Alterator/rfc|Протокол работы с бэкендами, черновик]]<br />
*[[Alterator/role-setup|Типичные тематические роли для альтератора]]<br />
*[http://uneex.cs.msu.su/uneex/SeminarALTerator/Conspect UNИX-конспект]<br />
*[[Alterator/html-validate|Проверка корректности html]]<br />
<br />
<br />
'''Конкретные модули'''<br />
*[[Alterator/AlteratorServices|alterator-services]]<br />
*[[Alterator/AlteratorX11|alterator-x11]]<br />
*[[Alterator/AlteratorXinetd|alterator-xinetd]]<br />
*[[Alterator/AlteratorLilo|alterator-lilo]]<br />
*[[Alterator/AlteratorNetIptables|alterator-net-iptables]]<br />
*[[:Категория:Модули_Alterator|Прочие модули Alterator]]<br />
<br />
'''Интересные проекты'''<br />
*[http://www.redhat.com/spacewalk/ SpaceWalk]<br />
*[http://www.openpegasus.org/ OpenPegasus]<br />
*[http://live.gnome.org/JsonGlib JsonGLIB]<br />
*[http://ex-parrot.com/~pdw/Mail-RFC822-Address.html регулярное выражение для валидации e-mail адреса]<br />
*[http://freesource.info/wiki/SergeyLebedev/EisSystem Проект единой информационной системы]<br />
<br />
'''Технические требования'''<br />
*[[Alterator/Выбор_DE|Выбор DE]]<br />
<br />
'''HTML, AJAX, BACKEND'''<br />
*[[Alterator/class_alterator-listbox|Таблица alterator-listbox]]<br />
*[[Alterator/class_test_and_btn|Поле ввода и кнопка "Добавить"]]<br />
*[[Alterator/catch_message|Обработка ошибок]]<br />
*[[Alterator/translate|Перевод в alterator-е]]<br />
<br />
=== См. также ===<br />
* <DPL><br />
namespace =<br />
titlematch = {{PAGENAME}}/%<br />
nottitlematch = {{PAGENAME}}/%/%<br />
mode = inline<br />
inlinetext=&nbsp;&bull;&#32;<br />
</DPL><br />
<br />
<br />
{{Category navigation|title=Alterator|category=Alterator|sortkey=*}}</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/catch_message&diff=14892Alterator/catch message2010-06-01T09:28:21Z<p>SergeyLebedev: </p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1<br />
<br />
01/06/2010 <br />
<br />
Пример обработки ошибок. Имеется простая форма: поле для ввода данных, кнопка отправить. Часто различные проверки осуществляются на стороне сервера и при возникновении ошибки необходимо оповестить пользователя.<br />
<br />
'''HTML'''<br />
<pre><br />
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><br />
<html wf="none"><br />
<body><br />
<br />
<form method="POST"><br />
<table width="100%"><br />
<tr><br />
<td align="left"><br />
<span translate="_">New Data</span><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<hr /><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<span translate="_">New Data:</span><br />
<br />
<input type="text" class="text" name="newdata"/><br />
<br />
<input type="button" name="datadd" value="Create/Add" class="btn"/><br />
</td><br />
</tr><br />
</table><br />
</form><br />
</body><br />
</html><br />
</pre><br />
<br />
'''AJAX'''<br />
При возникновении ошибки woo-error или type-error необходимо использовать функцию сatch/message как показано ниже. В данном примере мы при нажатии на кнопку "Create/Add" отправляем данные на сервер backend-у. Который осуществляет проверку и при некорректности данных генерит ошибку типа woo-error. Функция catch/message данную ошибку "ловит" и выводит error-box пользователю с сообщением, переданным backend-ом.<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-datadd)<br />
(catch/message<br />
(lambda()<br />
(woo-new "/mySuper-module" 'toBackendData (form-value "newdata"))<br />
)<br />
)<br />
<br />
<br />
(define (init)<br />
(form-bind "datadd" "click" ui-datadd)<br />
)<br />
</pre><br />
<br />
'''BACKEND'''<br />
<br />
Если пользователь введет в поле слово Test, то возникнет сообщение об ошибке.<br />
<br />
<pre><br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
addMyData()<br />
{<br />
if [ "$1" = "Test" ] ;then<br />
write_error "This is a test error"<br />
fi<br />
}<br />
<br />
<br />
on_message(){<br />
<br />
case "$in_action" in<br />
new)<br />
[ -n "$in_toBackendData" ] && addMyData "$in_toBackendData"<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
</pre><br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/class_alterator-listbox&diff=14891Alterator/class alterator-listbox2010-06-01T09:27:44Z<p>SergeyLebedev: </p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1<br />
<br />
25/05/2010<br />
<br />
'''HTML'''<br />
<br />
Пример html-кода в вашем index.html<br />
<pre><br />
<form method="POST"><br />
<table style="width:100%" name="hosts" class="alterator-listbox"><br />
<thead><br />
<tr><br />
<th><span translate="_">Host</span></th><br />
<th><span translate="_">Summary</span></th><br />
</tr><br />
</thead><br />
<tbody><br />
<tr><br />
<td nowrap="yes"><span class="alterator-label" name="name"/></td><br />
<td><span class="alterator-label" name="summary"/></td><br />
</tr><br />
</tbody><br />
</table><br />
</form><br />
</pre><br />
<br />
Т.е. мы хотим получить таблицу с двумя колонками, причем с возможностью сортировки этих колонок по алфавиту.<br />
Первая колонка у нас имя хоста, вторая информация о нем. <br />
<br />
Важно, чтобы класс у таблицы был <code>class="alterator-listbox"</code>, у таблицы так же должно быть уникальное имя, в нашем случаи это <code>name="hosts"</code><br />
<br />
Автозаполнение таблицы будет идти по тегам <code><span class="alterator-label" name="SomeName"/></code><br />
<br />
Один из span тегов должен называться name т.е. <code><span class="alterator-label" name="name"/></code>. Почему так, необходимо проверить в коде самого алтератора, без такого тега не будет корректна заполнена таблица.<br />
<br />
Итого, у нас получается html-таблица с именем hosts, классом alterator-listbox, одним и более элементами <span>, которые в свою очередь имеют уникальное имя и класс alterator-label, один из span элементов должен иметь имя name, его положение не важно.<br />
<br />
'''AJAX'''<br />
Пример scheme-кода в ajax.scm<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-init . data)<br />
(form-update-enum "hosts" (woo-list "/mySuper-module"))<br />
)<br />
<br />
(define (init)<br />
(ui-init)<br />
)<br />
</pre><br />
<br />
При обращении к странице с нашим модулем mySuper-module, будет вызвана функция init (в конце приведенного кода), которая в свою очередь вызовет ui-init.<br />
<br />
Основное действо заключено в вызове <tt>(form-update-enum "hosts" (woo-list "/mySuper-module"))</tt>, которое заключается в обновлении таблицы hosts списком, полученным вызовом backend'а командой <tt>alterator-cmdline /mySuper-module action list </tt>.<br />
<br />
Все достаточно просто. Можно использовать данный шаблон. Стоит только заменить mySuper-module на что-то более точное и при вызове woo-list использовать не прямое обращение к модулю, а дополнить его чем-нибудь типа "/mySuper-module/avail_objects", так чтобы можно было через один и тот же метод list обращаться к различным объектам avail_myobject avail_hosts и так далее. Пример можно посмотреть в alterator-sysinfo-0.8-alt3 (html,ajax).<br />
<br />
'''Backend'''<br />
<br />
Пример shell-backend'а <br />
<pre><br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
list()<br />
{<br />
echo -e "aaa\nbbb\n" | <br />
while read i ;do<br />
write_table_item \<br />
name "$i"<br />
summary "summary "$i"" \<br />
host "$i"<br />
done<br />
}<br />
<br />
on_message(){<br />
case "$in_action" in<br />
read)<br />
:<br />
;;<br />
list)<br />
list<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
<br />
</pre><br />
<br />
Для построения правильного ответа будет использована функция из alterator-sh-functions-0.13-alt2 write_table_item. Ей необходимо передавать пару имя от span элемента и значение. Одно из имен обязательно должно быть name. Пример использования выше, функция list().<br />
<br />
<br />
'''Single-select Multi-select'''<br />
Таблица всем хороша, но обычно возникает желание выбирать строки из этой таблицы и производить какие-то действия с ней. Для этого у класса alterator-listbox имеются два расширения single-select, multi-select, для выбора одной или множества строк. <br />
<br />
'''html-код'''<br />
<pre><br />
<form method="POST"><br />
<table style="width:100%" name="hosts" class="alterator-listbox multi-select"><br />
<thead><br />
<tr><br />
<th><span translate="_">Host</span></th><br />
<th><span translate="_">Summary</span></th><br />
</tr><br />
</thead><br />
<tbody><br />
<tr><br />
<td nowrap="yes"><span class="alterator-label" name="name"/></td><br />
<td><span class="alterator-label" name="summary"/></td><br />
</tr><br />
</tbody><br />
</table><br />
</form><br />
</pre><br />
<br />
Т.е. в class alterator-listbox было добавлено ключевое слово multi-select, после чего автоматически будет добавлен первый столбец в нашу таблицу с checkbox-ами для каждой строки.<br />
<br />
Для передача нескольких выбранных элементов в backend переменная in_hosts (значение name нашей таблицы) будет принимать значения равные значениям span элемента с name="name". Если выбрано более одного элемента, то в переменной они будут разделены символом ;.<br />
Т.е. если у меня в таблице два хоста host1 и host2, я выберу их и отошлю форму серверу, то в backend приедет переменная in_hosts = "host1;host2".<br />
<br />
Соответственно для single-select вместо столбца с checkbox-ами будет столбец с radiobutton-ами и переменной in_hosts будет присвоено только одно значение host1 или host2<br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/class_alterator-listbox&diff=14890Alterator/class alterator-listbox2010-06-01T09:27:26Z<p>SergeyLebedev: </p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1<br />
<br />
25/05/2010<br />
<br />
'''HTML'''<br />
<br />
Пример html-кода в вашем index.html<br />
<pre><br />
<form method="POST"><br />
<table style="width:100%" name="hosts" class="alterator-listbox"><br />
<thead><br />
<tr><br />
<th><span translate="_">Host</span></th><br />
<th><span translate="_">Summary</span></th><br />
</tr><br />
</thead><br />
<tbody><br />
<tr><br />
<td nowrap="yes"><span class="alterator-label" name="name"/></td><br />
<td><span class="alterator-label" name="summary"/></td><br />
</tr><br />
</tbody><br />
</table><br />
</form><br />
</pre><br />
<br />
Т.е. мы хотим получить таблицу с двумя колонками, причем с возможностью сортировки этих колонок по алфавиту.<br />
Первая колонка у нас имя хоста, вторая информация о нем. <br />
<br />
Важно, чтобы класс у таблицы был <code>class="alterator-listbox"</code>, у таблицы так же должно быть уникальное имя, в нашем случаи это <code>name="hosts"</code><br />
<br />
Автозаполнение таблицы будет идти по тегам <code><span class="alterator-label" name="SomeName"/></code><br />
<br />
Один из span тегов должен называться name т.е. <code><span class="alterator-label" name="name"/></code>. Почему так, необходимо проверить в коде самого алтератора, без такого тега не будет корректна заполнена таблица.<br />
<br />
Итого, у нас получается html-таблица с именем hosts, классом alterator-listbox, одним и более элементами <span>, которые в свою очередь имеют уникальное имя и класс alterator-label, один из span элементов должен иметь имя name, его положение не важно.<br />
<br />
'''AJAX'''<br />
Пример scheme-кода в ajax.scm<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-init . data)<br />
(form-update-enum "hosts" (woo-list "/mySuper-module"))<br />
)<br />
<br />
(define (init)<br />
(ui-init)<br />
)<br />
</pre><br />
<br />
При обращении к странице с нашим модулем mySuper-module, будет вызвана функция init (в конце приведенного кода), которая в свою очередь вызовет ui-init.<br />
<br />
Основное действо заключено в вызове <tt>(form-update-enum "hosts" (woo-list "/mySuper-module"))</tt>, которое заключается в обновлении таблицы hosts списком, полученным вызовом backend'а командой <tt>alterator-cmdline /mySuper-module action list </tt>.<br />
<br />
Все достаточно просто. Можно использовать данный шаблон. Стоит только заменить mySuper-module на что-то более точное и при вызове woo-list использовать не прямое обращение к модулю, а дополнить его чем-нибудь типа "/mySuper-module/avail_objects", так чтобы можно было через один и тот же метод list обращаться к различным объектам avail_myobject avail_hosts и так далее. Пример можно посмотреть в alterator-sysinfo-0.8-alt3 (html,ajax).<br />
<br />
'''Backend'''<br />
<br />
Пример shell-backend'а <br />
<pre><br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
list()<br />
{<br />
echo -e "aaa\nbbb\n" | <br />
while read i ;do<br />
write_table_item \<br />
name "$i"<br />
summary "summary "$i"" \<br />
host "$i"<br />
done<br />
}<br />
<br />
on_message(){<br />
case "$in_action" in<br />
read)<br />
:<br />
;;<br />
list)<br />
list<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
<br />
</pre><br />
<br />
Для построения правильного ответа будет использована функция из alterator-sh-functions-0.13-alt2 write_table_item. Ей необходимо передавать пару имя от span элемента и значение. Одно из имен обязательно должно быть name. Пример использования выше, функция list().<br />
<br />
<br />
'''Single-select Multi-select'''<br />
Таблица всем хороша, но обычно возникает желание выбирать строки из этой таблицы и производить какие-то действия с ней. Для этого у класса alterator-listbox имеются два расширения single-select, multi-select, для выбора одной или множества строк. <br />
<br />
'''html-код'''<br />
<pre><br />
<form method="POST"><br />
<table style="width:100%" name="hosts" class="alterator-listbox multi-select"><br />
<thead><br />
<tr><br />
<th><span translate="_">Host</span></th><br />
<th><span translate="_">Summary</span></th><br />
</tr><br />
</thead><br />
<tbody><br />
<tr><br />
<td nowrap="yes"><span class="alterator-label" name="name"/></td><br />
<td><span class="alterator-label" name="summary"/></td><br />
</tr><br />
</tbody><br />
</table><br />
</form><br />
</pre><br />
<br />
Т.е. в class alterator-listbox было добавлено ключевое слово multi-select, после чего автоматически будет добавлен первый столбец в нашу таблицу с checkbox-ами для каждой строки.<br />
<br />
Для передача нескольких выбранных элементов в backend переменная in_hosts (значение name нашей таблицы) будет принимать значения равные значениям span элемента с name="name". Если выбрано более одного элемента, то в переменной они будут разделены символом ;.<br />
Т.е. если у меня в таблице два хоста host1 и host2, я выберу их и отошлю форму серверу, то в backend приедет переменная in_hosts = "host1;host2".<br />
<br />
Соответственно для single-select вместо столбца с checkbox-ами будет столбец с radiobutton-ами и переменной in_hosts будет присвоено только одно значение host1 или host2<br />
<br />
[[Категория:Alterator|Ajax]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/catch_message&diff=14889Alterator/catch message2010-06-01T09:26:32Z<p>SergeyLebedev: </p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1<br />
<br />
01/06/2010 <br />
<br />
Пример обработки ошибок. Имеется простая форма: поле для ввода данных, кнопка отправить. Часто различные проверки осуществляются на стороне сервера и при возникновении ошибки необходимо оповестить пользователя.<br />
<br />
'''HTML'''<br />
<pre><br />
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><br />
<html wf="none"><br />
<body><br />
<br />
<form method="POST"><br />
<table width="100%"><br />
<tr><br />
<td align="left"><br />
<span translate="_">New Data</span><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<hr /><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<span translate="_">New Data:</span><br />
<br />
<input type="text" class="text" name="newdata"/><br />
<br />
<input type="button" name="datadd" value="Create/Add" class="btn"/><br />
</td><br />
</tr><br />
</table><br />
</form><br />
</body><br />
</html><br />
</pre><br />
<br />
'''AJAX'''<br />
При возникновении ошибки woo-error или type-error необходимо использовать функцию сatch/message как показано ниже. В данном примере мы при нажатии на кнопку "Create/Add" отправляем данные на сервер backend-у. Который осуществляет проверку и при некорректности данных генерит ошибку типа woo-error. Функция catch/message данную ошибку "ловит" и выводит error-box пользователю с сообщением, переданным backend-ом.<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-datadd)<br />
(catch/message<br />
(lambda()<br />
(woo-new "/mySuper-module" 'toBackendData (form-value "newdata"))<br />
)<br />
)<br />
<br />
<br />
(define (init)<br />
(form-bind "datadd" "click" ui-datadd)<br />
)<br />
</pre><br />
<br />
'''BACKEND'''<br />
<br />
Если пользователь введет в поле слово Test, то возникнет сообщение об ошибке.<br />
<br />
<pre><br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
addMyData()<br />
{<br />
if [ "$1" = "Test" ] ;then<br />
write_error "This is a test error"<br />
fi<br />
}<br />
<br />
<br />
on_message(){<br />
<br />
case "$in_action" in<br />
new)<br />
[ -n "$in_toBackendData" ] && addMyData "$in_toBackendData"<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
</pre><br />
<br />
[[Категория:Alterator/Ajax]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/catch_message&diff=14888Alterator/catch message2010-06-01T09:26:01Z<p>SergeyLebedev: </p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1<br />
<br />
01/06/2010 <br />
<br />
Пример обработки ошибок. Имеется простая форма: поле для ввода данных, кнопка отправить. Часто различные проверки осуществляются на стороне сервера и при возникновении ошибки необходимо оповестить пользователя.<br />
<br />
'''HTML'''<br />
<pre><br />
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><br />
<html wf="none"><br />
<body><br />
<br />
<form method="POST"><br />
<table width="100%"><br />
<tr><br />
<td align="left"><br />
<span translate="_">New Data</span><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<hr /><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<span translate="_">New Data:</span><br />
<br />
<input type="text" class="text" name="newdata"/><br />
<br />
<input type="button" name="datadd" value="Create/Add" class="btn"/><br />
</td><br />
</tr><br />
</table><br />
</form><br />
</body><br />
</html><br />
</pre><br />
<br />
'''AJAX'''<br />
При возникновении ошибки woo-error или type-error необходимо использовать функцию сatch/message как показано ниже. В данном примере мы при нажатии на кнопку "Create/Add" отправляем данные на сервер backend-у. Который осуществляет проверку и при некорректности данных генерит ошибку типа woo-error. Функция catch/message данную ошибку "ловит" и выводит error-box пользователю с сообщением, переданным backend-ом.<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-datadd)<br />
(catch/message<br />
(lambda()<br />
(woo-new "/mySuper-module" 'toBackendData (form-value "newdata"))<br />
)<br />
)<br />
<br />
<br />
(define (init)<br />
(form-bind "datadd" "click" ui-datadd)<br />
)<br />
</pre><br />
<br />
'''BACKEND'''<br />
<br />
Если пользователь введет в поле слово Test, то возникнет сообщение об ошибке.<br />
<br />
<pre><br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
addMyData()<br />
{<br />
if [ "$1" = "Test" ] ;then<br />
write_error "This is a test error"<br />
fi<br />
}<br />
<br />
<br />
on_message(){<br />
<br />
case "$in_action" in<br />
new)<br />
[ -n "$in_toBackendData" ] && addMyData "$in_toBackendData"<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
</pre><br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/class_test_and_btn&diff=14887Alterator/class test and btn2010-06-01T09:25:03Z<p>SergeyLebedev: </p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1 <br />
28.05.2010<br />
<br />
Очень часто необходимо получить от пользователя данные и передать их на обработку backend-у. В данном примере мы рассмотрим как это сделать при помощи поля текстового input и обычной кнопки.<br />
<br />
'''HTML'''<br />
<br />
Пример нашего html-кода<br />
<pre><br />
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><br />
<html wf="none"><br />
<body><br />
<br />
<form method="POST"><br />
<table width="100%"><br />
<tr><br />
<td align="left"><br />
<span translate="_">New Data</span><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<hr /><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<span translate="_">New Data:</span><br />
&nbsp;<br />
<input type="text" class="text" name="newdata"/><br />
&nbsp;<br />
<input type="button" name="datadd" value="Create/Add" class="btn"/><br />
</td><br />
</tr><br />
</table><br />
</form><br />
</body><br />
</html><br />
<br />
</pre><br />
<br />
В соответствии с этим кодом, имеется текстовое поле input с уникальным атрибутом name (обязательный) и значением "newdata". Так же имеется кнопка (input class=btn) с надписью "Create/Add" и уникальный атрибут name (обязательный) со значением "datadd". <br />
<br />
При нажатии на копку "Create/Add" значение в поле newdata должно быть передано нашему серверу и далее backend-у.<br />
<br />
'''AJAX'''<br />
<br />
Наш модуль имеет uri/url /mySuper-module<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-datadd)<br />
(woo-new "/mySuper-module" 'toBackendData (form-value "newdata"))<br />
)<br />
<br />
<br />
(define (init)<br />
(form-bind "datadd" "click" ui-datadd)<br />
)<br />
</pre><br />
<br />
В определении функции init мы осуществляем привязку элемента, действия и функции-обработчика <code>(form-bind "datadd" "click" ui-datadd)</code> : при нажатии ("click") на объект с именем datadd (наша кнопка) вызвать функцию-обработчик ui-datadd. <br />
<br />
<br />
В свою очередь функция ui-datadd вызывает действие new (woo-new) с параметром toBackendData и значением, полученным из поля с уникальным именем newdata (form-value "newdata"). Это аналогично обращению к backend-у через alterator-cmdline вида <code>alterator-cmdline /mySuper-module action new toBackendData "sometext"</code>. К стандартным действия list, type, write, read, new delete, которым соответствуют функции woo-list, woo-type, woo-write, woo-read, woo-new, woo-delete, можно добавить любое свое, тогда вызов несколько измениться. К примеру пусть это будет действие addData. Тогда заменим вызов woo-new на следующий <code>(woo "addData" "/mySuper-module" 'toBackendData (form-value "newdata"))</code><br />
<br />
<br />
'''BACKEND'''<br />
<pre><br />
<br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
addMyData()<br />
{<br />
echo "$1" >> /tmp/mysuperconfig.file.txt<br />
}<br />
<br />
<br />
on_message(){<br />
<br />
case "$in_action" in<br />
new)<br />
[ -n "$in_toBackendData" ] && addMyData "$in_toBackendData"<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
</pre><br />
<br />
Данный backend, при получении значения в переменной in_action (действие), проверяет соответствие слову new. Хотя это может быть любым другим действием, к примеру addData. Если соответствие найдено, то проверяется переменная in_toBackendData на наличие значения, если проверка успешная, вызывается функция addMyData с параметром in_toBackendData, которая просто записывает этот параметр в файл /tmp/mysuperconfig.file.txt<br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/catch_message&diff=14886Alterator/catch message2010-06-01T08:52:45Z<p>SergeyLebedev: f</p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1<br />
<br />
01/06/2010 <br />
<br />
Пример обработки ошибок. Имеется простая форма: поле для ввода данных, кнопка отправить. Часто различные проверки осуществляются на стороне сервера и при возникновении ошибки необходимо оповестить пользователя.<br />
<br />
'''HTML'''<br />
<pre><br />
<br />
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><br />
<html wf="none"><br />
<body><br />
<br />
<form method="POST"><br />
<table width="100%"><br />
<tr><br />
<td align="left"><br />
<span translate="_">New Data</span><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<hr /><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<span translate="_">New Data:</span><br />
<br />
<input type="text" class="text" name="newdata"/><br />
<br />
<input type="button" name="datadd" value="Create/Add" class="btn"/><br />
</td><br />
</tr><br />
</table><br />
</form><br />
</body><br />
</html><br />
<br />
</pre><br />
<br />
'''AJAX'''<br />
При возникновении ошибки woo-error или type-error необходимо использовать функцию сatch/message как показано ниже. В данном примере мы при нажатии на кнопку "Create/Add" отправляем данные на сервер backend-у. Который осуществляет проверку и при некорректности данных генерит ошибку типа woo-error. Функция catch/message данную ошибку "ловит" и выводит error-box пользователю с сообщением, переданным backend-ом.<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-datadd)<br />
(catch/message<br />
(lambda()<br />
(woo-new "/mySuper-module" 'toBackendData (form-value "newdata"))<br />
)<br />
)<br />
<br />
<br />
(define (init)<br />
(form-bind "datadd" "click" ui-datadd)<br />
)<br />
</pre><br />
<br />
'''BACKEND'''<br />
<br />
Если пользователь введет в поле слово Test, то возникнет сообщение об ошибке.<br />
<br />
<pre><br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
addMyData()<br />
{<br />
if [ "$1" = "Test" ] ;then<br />
write_error "This is a test error"<br />
fi<br />
}<br />
<br />
<br />
on_message(){<br />
<br />
case "$in_action" in<br />
new)<br />
[ -n "$in_toBackendData" ] && addMyData "$in_toBackendData"<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
</pre><br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/catch_message&diff=14885Alterator/catch message2010-06-01T08:44:22Z<p>SergeyLebedev: Новая страница: «Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1 01/06/2010 Пример обработки ошибок. Имеется простая фо...»</p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1<br />
<br />
01/06/2010 <br />
<br />
Пример обработки ошибок. Имеется простая форма: поле для ввода данных, кнопка отправить. Часто различные проверки осуществляются на стороне сервера и при возникновении ошибки необходимо оповестить пользователя.<br />
<br />
'''HTML'''<br />
<br />
'''AJAX'''<br />
<br />
<br />
'''BACKEND'''<br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator&diff=14884Alterator2010-06-01T08:41:24Z<p>SergeyLebedev: /* Разное */</p>
<hr />
<div>[[Category:Sisyphus]]<br />
[[en:Alterator]]<br />
'''Alterator''' — новое поколение платформ для разработки сложных систем. Используются по большей части [[Scheme]], C и старый добрый sh+awk. На данный момент используется как [[Installer|инсталлятор]] и конфигуратор системы. Копия части этой документации содержится в пакете [http://sisyphus.ru/srpm/alterator alterator]. <br />
<br />
Для обсуждения вопросов, связанных с alterator, существует список рассылки {{lists|devel-conf}}.<br />
<br />
=== Обращение к системным администраторам ===<br />
Наверняка в alterator недостаточно модулей для решения ваших задач. Каждый модуль состоит из бэкенда и интерфейса. Разработка интерфейса — это работа для программиста, но создать бэкенд вы вполне сможете. Бэкенд пишется на произвольном языке программирования по достаточно простым правилам. Имея бэкенд, при помощи интерфейса командной строки вы уже сразу же сможете использовать наработки в своих скриптах. Хороший бэкенд — это фиксация знаний и возможность повторного использования ваших наработок другими администраторами.<br />
Напишите в список рассылки — мы поможем сделать интерфейс.<br />
<br />
===Общие сведения===<br />
*[[Alterator/faq|Часто задаваемые вопросы]]<br />
*[[Alterator/debug|Отладка модулей]]<br />
*[[Alterator/todo|Книга жалоб и предложений]]<br />
*[[Alterator/releases|Выпуски]]<br />
<br />
=== Руководства ===<br />
*[[Alterator/module/first|Первый модуль]]<br />
*[[Alterator/module/structure|Структура модуля]]<br />
*[[Alterator/module/backend|Бэкенд]]<br />
*[[Alterator/module/interface|Интерфейс]]<br />
*[[Alterator/module/types|Автоматическая проверка данных]]<br />
*[[Alterator/module/debug|Отладка модулей]]<br />
*[[Alterator/module/testing|Тестирование модулей]]<br />
<br />
===Справочная информация===<br />
<br />
*[[Alterator/architecture|Архитектура]]<br />
<br />
*[[Alterator/libraries|Стандартные библиотеки scheme, предоставляемые alterator]]<br />
*[[Alterator/reserved|Зарезервированные имена]]<br />
*[[Alterator/woo|Функции для запроса бакендов]]<br />
*[[Alterator/form|Функции для работы с полями форм]]<br />
*[[Alterator/shell|Бэкенды на shell]]<br />
*[[Alterator/perl|Бэкенды на perl]]<br />
*[[Alterator/ruby|Бэкенды на ruby]]<br />
<br />
*[[Alterator/i18n|Интернационализация]]<br />
*[[Alterator/l10n|Локализация]]<br />
<br />
<br />
'''Lookout:'''<br />
*[[Alterator/evolution|Описание общей структуры документа lookout]]<br />
*[[Alterator/widgets|Краткий справочник по виджетам]]<br />
<br />
===Разное===<br />
*[[Alterator/objects|Объектная система alterator]]<br />
*[[Alterator/rfc|Протокол работы с бэкендами, черновик]]<br />
*[[Alterator/role-setup|Типичные тематические роли для альтератора]]<br />
*[http://uneex.cs.msu.su/uneex/SeminarALTerator/Conspect UNИX-конспект]<br />
*[[Alterator/html-validate|Проверка корректности html]]<br />
<br />
<br />
'''Конкретные модули'''<br />
*[[Alterator/AlteratorServices|alterator-services]]<br />
*[[Alterator/AlteratorX11|alterator-x11]]<br />
*[[Alterator/AlteratorXinetd|alterator-xinetd]]<br />
*[[Alterator/AlteratorLilo|alterator-lilo]]<br />
*[[Alterator/AlteratorNetIptables|alterator-net-iptables]]<br />
<br />
<br />
'''Интересные проекты'''<br />
*[http://www.redhat.com/spacewalk/ SpaceWalk]<br />
*[http://www.openpegasus.org/ OpenPegasus]<br />
*[http://live.gnome.org/JsonGlib JsonGLIB]<br />
*[http://ex-parrot.com/~pdw/Mail-RFC822-Address.html регулярное выражение для валидации e-mail адреса]<br />
*[http://freesource.info/wiki/SergeyLebedev/EisSystem Проект единой информационной системы]<br />
<br />
'''Технические требования'''<br />
*[[Alterator/Выбор_DE|Выбор DE]]<br />
<br />
'''HTML, AJAX, BACKEND'''<br />
*[[Alterator/class_alterator-listbox|Таблица alterator-listbox]]<br />
*[[Alterator/class_test_and_btn|Поле ввода и кнопка "Добавить"]]<br />
*[[Alterator/catch_message|Обработка ошибок]]<br />
<br />
=== См. также ===<br />
* <DPL><br />
namespace =<br />
titlematch = {{PAGENAME}}/%<br />
nottitlematch = {{PAGENAME}}/%/%<br />
mode = inline<br />
inlinetext=&nbsp;&bull;&#32;<br />
</DPL><br />
<br />
<br />
{{Category navigation|title=Alterator|category=Alterator|sortkey=*}}</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/class_test_and_btn&diff=14830Alterator/class test and btn2010-05-28T13:43:11Z<p>SergeyLebedev: </p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1 <br />
28.05.2010<br />
<br />
Очень часто необходимо получить от пользователя данные и передать их на обработку backend-у. В данном примере мы рассмотрим как это сделать при помощи поля текстового input и обычной кнопки.<br />
<br />
'''HTML'''<br />
<br />
Пример нашего html-кода<br />
<pre><br />
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><br />
<!-- control administration module --><br />
<html wf="none"><br />
<body><br />
<br />
<form method="POST"><br />
<table width="100%"><br />
<tr><br />
<td align="left"><br />
<span translate="_">New Data</span><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<hr /><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<span translate="_">New Data:</span><br />
&nbsp;<br />
<input type="text" class="text" name="newdata"/><br />
&nbsp;<br />
<input type="button" name="datadd" value="Create/Add" class="btn"/><br />
</td><br />
</tr><br />
</table><br />
</form><br />
</body><br />
</html><br />
<br />
</pre><br />
<br />
В соответствии с этим кодом, имеется текстовое поле input с уникальным атрибутом name (обязательный) и значением "newdata". Так же имеется кнопка (input class=btn) с надписью "Create/Add" и уникальный атрибут name (обязательный) со значением "datadd". <br />
<br />
При нажатии на копку "Create/Add" значение в поле newdata должно быть передано нашему серверу и далее backend-у.<br />
<br />
'''AJAX'''<br />
<br />
Наш модуль имеет uri/url /mySuper-module<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-datadd)<br />
(woo-new "/mySuper-module" 'toBackendData (form-value "newdata"))<br />
)<br />
<br />
<br />
(define (init)<br />
(form-bind "datadd" "click" ui-datadd)<br />
)<br />
</pre><br />
<br />
В определении функции init мы осуществляем привязку элемента, действия и функции-обработчика <code>(form-bind "datadd" "click" ui-datadd)</code> : при нажатии ("click") на объект с именем datadd (наша кнопка) вызвать функцию-обработчик ui-datadd. <br />
<br />
<br />
В свою очередь функция ui-datadd вызывает действие new (woo-new) с параметром toBackendData и значением, полученным из поля с уникальным именем newdata (form-value "newdata"). Это аналогично обращению к backend-у через alterator-cmdline вида <code>alterator-cmdline /mySuper-module action new toBackendData "sometext"</code>. К стандартным действия list, type, write, read, new delete, которым соответствуют функции woo-list, woo-type, woo-write, woo-read, woo-new, woo-delete, можно добавить любое свое, тогда вызов несколько измениться. К примеру пусть это будет действие addData. Тогда заменим вызов woo-new на следующий <code>(woo "addData" "/mySuper-module" 'toBackendData (form-value "newdata"))</code><br />
<br />
<br />
'''BACKEND'''<br />
<pre><br />
<br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
addMyData()<br />
{<br />
echo "$1" >> /tmp/mysuperconfig.file.txt<br />
}<br />
<br />
<br />
on_message(){<br />
<br />
case "$in_action" in<br />
new)<br />
[ -n "$in_toBackendData" ] && addMyData "$in_toBackendData"<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
</pre><br />
<br />
Данный backend, при получении значения в переменной in_action (действие), проверяет соответствие слову new. Хотя это может быть любым другим действием, к примеру addData. Если соответствие найдено, то проверяется переменная in_toBackendData на наличие значения, если проверка успешная, вызывается функция addMyData с параметром in_toBackendData, которая просто записывает этот параметр в файл /tmp/mysuperconfig.file.txt<br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator&diff=14829Alterator2010-05-28T13:22:35Z<p>SergeyLebedev: /* Разное */</p>
<hr />
<div>[[Category:Sisyphus]]<br />
[[en:Alterator]]<br />
'''Alterator''' — новое поколение платформ для разработки сложных систем. Используются по большей части [[Scheme]], C и старый добрый sh+awk. На данный момент используется как [[Installer|инсталлятор]] и конфигуратор системы. Копия части этой документации содержится в пакете [http://sisyphus.ru/srpm/alterator alterator]. <br />
<br />
Для обсуждения вопросов, связанных с alterator, существует список рассылки {{lists|devel-conf}}.<br />
<br />
=== Обращение к системным администраторам ===<br />
Наверняка в alterator недостаточно модулей для решения ваших задач. Каждый модуль состоит из бэкенда и интерфейса. Разработка интерфейса — это работа для программиста, но создать бэкенд вы вполне сможете. Бэкенд пишется на произвольном языке программирования по достаточно простым правилам. Имея бэкенд, при помощи интерфейса командной строки вы уже сразу же сможете использовать наработки в своих скриптах. Хороший бэкенд — это фиксация знаний и возможность повторного использования ваших наработок другими администраторами.<br />
Напишите в список рассылки — мы поможем сделать интерфейс.<br />
<br />
===Общие сведения===<br />
*[[Alterator/faq|Часто задаваемые вопросы]]<br />
*[[Alterator/debug|Отладка модулей]]<br />
*[[Alterator/todo|Книга жалоб и предложений]]<br />
*[[Alterator/releases|Выпуски]]<br />
<br />
=== Руководства ===<br />
*[[Alterator/module/first|Первый модуль]]<br />
*[[Alterator/module/structure|Структура модуля]]<br />
*[[Alterator/module/backend|Бэкенд]]<br />
*[[Alterator/module/interface|Интерфейс]]<br />
*[[Alterator/module/types|Автоматическая проверка данных]]<br />
*[[Alterator/module/debug|Отладка модулей]]<br />
*[[Alterator/module/testing|Тестирование модулей]]<br />
<br />
===Справочная информация===<br />
<br />
*[[Alterator/architecture|Архитектура]]<br />
<br />
*[[Alterator/libraries|Стандартные библиотеки scheme, предоставляемые alterator]]<br />
*[[Alterator/reserved|Зарезервированные имена]]<br />
*[[Alterator/woo|Функции для запроса бакендов]]<br />
*[[Alterator/form|Функции для работы с полями форм]]<br />
*[[Alterator/shell|Бэкенды на shell]]<br />
*[[Alterator/perl|Бэкенды на perl]]<br />
*[[Alterator/ruby|Бэкенды на ruby]]<br />
<br />
*[[Alterator/i18n|Интернационализация]]<br />
*[[Alterator/l10n|Локализация]]<br />
<br />
<br />
'''Lookout:'''<br />
*[[Alterator/evolution|Описание общей структуры документа lookout]]<br />
*[[Alterator/widgets|Краткий справочник по виджетам]]<br />
<br />
===Разное===<br />
*[[Alterator/objects|Объектная система alterator]]<br />
*[[Alterator/rfc|Протокол работы с бэкендами, черновик]]<br />
*[[Alterator/role-setup|Типичные тематические роли для альтератора]]<br />
*[http://uneex.cs.msu.su/uneex/SeminarALTerator/Conspect UNИX-конспект]<br />
*[[Alterator/html-validate|Проверка корректности html]]<br />
<br />
<br />
'''Конкретные модули'''<br />
*[[Alterator/AlteratorServices|alterator-services]]<br />
*[[Alterator/AlteratorX11|alterator-x11]]<br />
*[[Alterator/AlteratorXinetd|alterator-xinetd]]<br />
*[[Alterator/AlteratorLilo|alterator-lilo]]<br />
*[[Alterator/AlteratorNetIptables|alterator-net-iptables]]<br />
<br />
<br />
'''Интересные проекты'''<br />
*[http://www.redhat.com/spacewalk/ SpaceWalk]<br />
*[http://www.openpegasus.org/ OpenPegasus]<br />
*[http://live.gnome.org/JsonGlib JsonGLIB]<br />
*[http://ex-parrot.com/~pdw/Mail-RFC822-Address.html регулярное выражение для валидации e-mail адреса]<br />
*[http://freesource.info/wiki/SergeyLebedev/EisSystem Проект единой информационной системы]<br />
<br />
'''Технические требования'''<br />
*[[Alterator/Выбор_DE|Выбор DE]]<br />
<br />
'''HTML, AJAX, BACKEND'''<br />
*[[Alterator/class_alterator-listbox|Таблица alterator-listbox]]<br />
*[[Alterator/class_test_and_btn|Поле ввода и кнопка "Добавить"]]<br />
<br />
=== См. также ===<br />
* <DPL><br />
namespace =<br />
titlematch = {{PAGENAME}}/%<br />
nottitlematch = {{PAGENAME}}/%/%<br />
mode = inline<br />
inlinetext=&nbsp;&bull;&#32;<br />
</DPL><br />
<br />
<br />
{{Category navigation|title=Alterator|category=Alterator|sortkey=*}}</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/class_test_and_btn&diff=14828Alterator/class test and btn2010-05-28T13:20:53Z<p>SergeyLebedev: </p>
<hr />
<div>Очень часто необходимо получить от пользователя данные и передать их на обработку backend-у. В данном примере мы рассмотрим как это сделать при помощи поля текстового input и обычной кнопки.<br />
<br />
'''HTML'''<br />
<br />
Пример нашего html-кода<br />
<pre><br />
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><br />
<!-- control administration module --><br />
<html wf="none"><br />
<body><br />
<br />
<form method="POST"><br />
<table width="100%"><br />
<tr><br />
<td align="left"><br />
<span translate="_">New Data</span><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<hr /><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<span translate="_">New Data:</span><br />
&nbsp;<br />
<input type="text" class="text" name="newdata"/><br />
&nbsp;<br />
<input type="button" name="datadd" value="Create/Add" class="btn"/><br />
</td><br />
</tr><br />
</table><br />
</form><br />
</body><br />
</html><br />
<br />
</pre><br />
<br />
В соответствии с этим кодом, имеется текстовое поле input с уникальным атрибутом name (обязательный) и значением "newdata". Так же имеется кнопка (input class=btn) с надписью "Create/Add" и уникальный атрибут name (обязательный) со значением "datadd". <br />
<br />
При нажатии на копку "Create/Add" значение в поле newdata должно быть передано нашему серверу и далее backend-у.<br />
<br />
'''AJAX'''<br />
<br />
Наш модуль имеет uri/url /mySuper-module<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-datadd)<br />
(woo-new "/mySuper-module" 'toBackendData (form-value "newdata"))<br />
)<br />
<br />
<br />
(define (init)<br />
(form-bind "datadd" "click" ui-datadd)<br />
)<br />
</pre><br />
<br />
В определении функции init мы осуществляем привязку элемента, действия и функции-обработчика <code>(form-bind "datadd" "click" ui-datadd)</code> : при нажатии ("click") на объект с именем datadd (наша кнопка) вызвать функцию-обработчик ui-datadd. <br />
<br />
<br />
В свою очередь функция ui-datadd вызывает действие new (woo-new) с параметром toBackendData и значением, полученным из поля с уникальным именем newdata (form-value "newdata"). Это аналогично обращению к backend-у через alterator-cmdline вида <code>alterator-cmdline /mySuper-module action new toBackendData "sometext"</code>. К стандартным действия list, type, write, read, new delete, которым соответствуют функции woo-list, woo-type, woo-write, woo-read, woo-new, woo-delete, можно добавить любое свое, тогда вызов несколько измениться. К примеру пусть это будет действие addData. Тогда заменим вызов woo-new на следующий <code>(woo "addData" "/mySuper-module" 'toBackendData (form-value "newdata"))</code><br />
<br />
<br />
'''BACKEND'''<br />
<pre><br />
<br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
addMyData()<br />
{<br />
echo "$1" >> /tmp/mysuperconfig.file.txt<br />
}<br />
<br />
<br />
on_message(){<br />
<br />
case "$in_action" in<br />
new)<br />
[ -n "$in_toBackendData" ] && addMyData "$in_toBackendData"<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
</pre><br />
<br />
Данный backend, при получении значения в переменной in_action (действие), проверяет соответствие слову new. Хотя это может быть любым другим действием, к примеру addData. Если соответствие найдено, то проверяется переменная in_toBackendData на наличие значения, если проверка успешная, вызывается функция addMyData с параметром in_toBackendData, которая просто записывает этот параметр в файл /tmp/mysuperconfig.file.txt<br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/class_test_and_btn&diff=14827Alterator/class test and btn2010-05-28T13:10:44Z<p>SergeyLebedev: </p>
<hr />
<div>Очень часто необходимо получить от пользователя данные и передать их backend-у. В данном примере мы рассмотрим как это сделать при помощи поля input типа text и обычной кнопки.<br />
<br />
'''HTML'''<br />
<br />
Пример нашего html-кода<br />
<pre><br />
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><br />
<!-- control administration module --><br />
<html wf="none"><br />
<body><br />
<br />
<form method="POST"><br />
<table width="100%"><br />
<tr><br />
<td align="left"><br />
<span translate="_">New Data</span><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<hr /><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<span translate="_">New Data:</span><br />
&nbsp;<br />
<input type="text" class="text" name="newdata"/><br />
&nbsp;<br />
<input type="button" name="datadd" value="Create/Add" class="btn"/><br />
</td><br />
</tr><br />
</table><br />
</form><br />
</body><br />
</html><br />
<br />
</pre><br />
<br />
В соответствии с этим кодом, у нас будет поле input типа text и уникальным атрибутом name newdata (name -- обязательный атрибут). Так же имеем кнопку (input class=btn) с надписью "Create/Add" уникальный атрибут name datadd. <br />
<br />
При нажатии на копку "Create/Add" значение в поле newdata должно быть передано нашему серверу и далее до backend-а.<br />
<br />
'''AJAX'''<br />
<br />
Наш модуль имеет uri/url /mySuper-module<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-datadd)<br />
(woo-new "/mySuper-module" 'toBackendData (form-value "newdata"))<br />
)<br />
<br />
<br />
(define (init)<br />
(form-bind "datadd" "click" ui-datadd)<br />
)<br />
</pre><br />
<br />
В определении функции init мы осуществляем привязку элемента, действия и функции-обработчик <code>(form-bind "datadd" "click" ui-datadd)</code> : при нажатии ("click") на объект с именем datadd (наша кнопка) вызвать функцию-обработчик ui-datadd. <br />
<br />
<br />
В свою очередь функция ui-datadd вызывает действие new (woo-new) с параметром toBackendData и значением, полученным из поля с уникальным именем newdata (form-value "newdata"). Это аналогично обращению к backend-у через alterator-cmdline вида <code>alterator-cmdline /mySuper-module action new toBackendData "sometext". К стандартным действия list, type, write, read, new delete, которым соответствуют функции woo-list, woo-type, woo-write, woo-read, woo-new, woo-delete, можно добавить любое свое, тогда вызов несколько измениться. К примеру пусть это будет действие addData. Тогда заменим вызов woo-new на следующий <code>(woo "addData" "/mySuper-module" 'toBackendData (form-value "newdata"))</code><br />
<br />
<br />
'''BACKEND'''<br />
<pre><br />
<br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
addMyData()<br />
{<br />
echo "$1" >> /tmp/mysuperconfig.file.txt<br />
}<br />
<br />
<br />
on_message(){<br />
<br />
case "$in_action" in<br />
new)<br />
[ -n "$in_toBackendData" ] && addMyData "$in_toBackendData"<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
</pre><br />
<br />
Данный backend при получении значения в переменной in_action проверяет соответствие слову new. Хотя это может быть любым другим действием, к примеру addData. Если соответствие найдено, но проверяется переменная in_toBackendData на наличие значения, если проверка успешная, вызывается функция addMyData с параметром in_toBackendData, которая просто записывает этот параметр в файл /tmp/mysuperconfig.file.txt<br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/class_test_and_btn&diff=14826Alterator/class test and btn2010-05-28T13:00:55Z<p>SergeyLebedev: Новая страница: «Очень часто необходимо получить от пользователя данные и передать их backend-у. В данном прим...»</p>
<hr />
<div>Очень часто необходимо получить от пользователя данные и передать их backend-у. В данном примере мы рассмотрим как это сделать при помощи поля input типа text и обычной кнопки.<br />
<br />
'''HTML'''<br />
<br />
Пример нашего html-кода<br />
<pre><br />
<form method="POST"><br />
<table width="100%"><br />
<tr><br />
<td align="left"><br />
<span translate="_">New Data</span><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<hr /><br />
</td><br />
</tr><br />
<tr><br />
<td ><br />
<span translate="_">New Data:</span><br />
&nbsp;<br />
<input type="text" class="text" name="newdata"/><br />
&nbsp;<br />
<input type="button" name="datadd" value="Create/Add" class="btn"/><br />
</td><br />
</tr><br />
</table><br />
</form><br />
</pre><br />
<br />
В соответствии с этим кодом, у нас будет поле input типа text и уникальным атрибутом name newdata (name -- обязательный атрибут). Так же имеем кнопку (input class=btn) с надписью "Create/Add" уникальный атрибут name datadd. <br />
<br />
При нажатии на копку "Create/Add" значение в поле newdata должно быть передано нашему серверу и далее до backend-а.<br />
<br />
'''AJAX'''<br />
<br />
Наш модуль имеет uri/url /mySuper-module<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-datadd)<br />
(woo-new "/mySuper-module" 'toBackendData (form-value "newdata"))<br />
)<br />
<br />
<br />
(define (init)<br />
(form-bind "datadd" "click" ui-datadd)<br />
)<br />
</pre><br />
<br />
В определении функции init мы осуществляем привязку элемента, действия и функции-обработчик <code>(form-bind "datadd" "click" ui-datadd)</code>: при нажатии ("click") на объект с именем datadd (наша кнопка) вызвать функцию-обработчик ui-datadd. <br />
<br />
<br />
В свою очередь функция ui-datadd вызывает действие new (woo-new) с параметром toBackendData и значением, полученным из поля с уникальным именем newdata (form-value "newdata"). Это аналогично обращению к backend-у через alterator-cmdline вида <code>alterator-cmdline /mySuper-module action new toBackendData "sometext". К стандартным действия list, type, write, read, new delete, которым соответствуют функции woo-list, woo-type, woo-write, woo-read, woo-new, woo-delete, можно добавить любое свое, тогда вызов несколько измениться. К примеру пусть это будет действие addData. Тогда заменим вызов woo-new на следующий <code>(woo "addData" "/mySuper-module" 'toBackendData (form-value "newdata"))</code><br />
<br />
<br />
'''BACKEND'''<br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator&diff=14825Alterator2010-05-28T12:38:28Z<p>SergeyLebedev: /* Разное */</p>
<hr />
<div>[[Category:Sisyphus]]<br />
[[en:Alterator]]<br />
'''Alterator''' — новое поколение платформ для разработки сложных систем. Используются по большей части [[Scheme]], C и старый добрый sh+awk. На данный момент используется как [[Installer|инсталлятор]] и конфигуратор системы. Копия части этой документации содержится в пакете [http://sisyphus.ru/srpm/alterator alterator]. <br />
<br />
Для обсуждения вопросов, связанных с alterator, существует список рассылки {{lists|devel-conf}}.<br />
<br />
=== Обращение к системным администраторам ===<br />
Наверняка в alterator недостаточно модулей для решения ваших задач. Каждый модуль состоит из бэкенда и интерфейса. Разработка интерфейса — это работа для программиста, но создать бэкенд вы вполне сможете. Бэкенд пишется на произвольном языке программирования по достаточно простым правилам. Имея бэкенд, при помощи интерфейса командной строки вы уже сразу же сможете использовать наработки в своих скриптах. Хороший бэкенд — это фиксация знаний и возможность повторного использования ваших наработок другими администраторами.<br />
Напишите в список рассылки — мы поможем сделать интерфейс.<br />
<br />
===Общие сведения===<br />
*[[Alterator/faq|Часто задаваемые вопросы]]<br />
*[[Alterator/debug|Отладка модулей]]<br />
*[[Alterator/todo|Книга жалоб и предложений]]<br />
*[[Alterator/releases|Выпуски]]<br />
<br />
=== Руководства ===<br />
*[[Alterator/module/first|Первый модуль]]<br />
*[[Alterator/module/structure|Структура модуля]]<br />
*[[Alterator/module/backend|Бэкенд]]<br />
*[[Alterator/module/interface|Интерфейс]]<br />
*[[Alterator/module/types|Автоматическая проверка данных]]<br />
*[[Alterator/module/debug|Отладка модулей]]<br />
*[[Alterator/module/testing|Тестирование модулей]]<br />
<br />
===Справочная информация===<br />
<br />
*[[Alterator/architecture|Архитектура]]<br />
<br />
*[[Alterator/libraries|Стандартные библиотеки scheme, предоставляемые alterator]]<br />
*[[Alterator/reserved|Зарезервированные имена]]<br />
*[[Alterator/woo|Функции для запроса бакендов]]<br />
*[[Alterator/form|Функции для работы с полями форм]]<br />
*[[Alterator/shell|Бэкенды на shell]]<br />
*[[Alterator/perl|Бэкенды на perl]]<br />
*[[Alterator/ruby|Бэкенды на ruby]]<br />
<br />
*[[Alterator/i18n|Интернационализация]]<br />
*[[Alterator/l10n|Локализация]]<br />
<br />
<br />
'''Lookout:'''<br />
*[[Alterator/evolution|Описание общей структуры документа lookout]]<br />
*[[Alterator/widgets|Краткий справочник по виджетам]]<br />
<br />
===Разное===<br />
*[[Alterator/objects|Объектная система alterator]]<br />
*[[Alterator/rfc|Протокол работы с бэкендами, черновик]]<br />
*[[Alterator/role-setup|Типичные тематические роли для альтератора]]<br />
*[http://uneex.cs.msu.su/uneex/SeminarALTerator/Conspect UNИX-конспект]<br />
*[[Alterator/html-validate|Проверка корректности html]]<br />
<br />
<br />
'''Конкретные модули'''<br />
*[[Alterator/AlteratorServices|alterator-services]]<br />
*[[Alterator/AlteratorX11|alterator-x11]]<br />
*[[Alterator/AlteratorXinetd|alterator-xinetd]]<br />
*[[Alterator/AlteratorLilo|alterator-lilo]]<br />
*[[Alterator/AlteratorNetIptables|alterator-net-iptables]]<br />
<br />
<br />
'''Интересные проекты'''<br />
*[http://www.redhat.com/spacewalk/ SpaceWalk]<br />
*[http://www.openpegasus.org/ OpenPegasus]<br />
*[http://live.gnome.org/JsonGlib JsonGLIB]<br />
*[http://ex-parrot.com/~pdw/Mail-RFC822-Address.html регулярное выражение для валидации e-mail адреса]<br />
*[http://freesource.info/wiki/SergeyLebedev/EisSystem Проект единой информационной системы]<br />
<br />
'''Технические требования'''<br />
*[[Alterator/Выбор_DE|Выбор DE]]<br />
<br />
'''HTML, AJAX, BACKEND'''<br />
*[[Alterator/class_alterator-listbox|alterator-listbox]]<br />
*[[Alterator/class_test_and_btn|text and button]]<br />
<br />
=== См. также ===<br />
* <DPL><br />
namespace =<br />
titlematch = {{PAGENAME}}/%<br />
nottitlematch = {{PAGENAME}}/%/%<br />
mode = inline<br />
inlinetext=&nbsp;&bull;&#32;<br />
</DPL><br />
<br />
<br />
{{Category navigation|title=Alterator|category=Alterator|sortkey=*}}</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/html-validate&diff=14793Alterator/html-validate2010-05-25T10:38:15Z<p>SergeyLebedev: Новая страница: «Пакет expat команда xmlwf index.html Категория:Alterator»</p>
<hr />
<div>Пакет expat команда xmlwf index.html<br />
<br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator&diff=14792Alterator2010-05-25T10:37:01Z<p>SergeyLebedev: /* Разное */</p>
<hr />
<div>[[Category:Sisyphus]]<br />
[[en:Alterator]]<br />
'''Alterator''' — новое поколение платформ для разработки сложных систем. Используются по большей части [[Scheme]], C и старый добрый sh+awk. На данный момент используется как [[Installer|инсталлятор]] и конфигуратор системы. Копия части этой документации содержится в пакете [http://sisyphus.ru/srpm/alterator alterator]. <br />
<br />
Для обсуждения вопросов, связанных с alterator, существует список рассылки {{lists|devel-conf}}.<br />
<br />
=== Обращение к системным администраторам ===<br />
Наверняка в alterator недостаточно модулей для решения ваших задач. Каждый модуль состоит из бэкенда и интерфейса. Разработка интерфейса — это работа для программиста, но создать бэкенд вы вполне сможете. Бэкенд пишется на произвольном языке программирования по достаточно простым правилам. Имея бэкенд, при помощи интерфейса командной строки вы уже сразу же сможете использовать наработки в своих скриптах. Хороший бэкенд — это фиксация знаний и возможность повторного использования ваших наработок другими администраторами.<br />
Напишите в список рассылки — мы поможем сделать интерфейс.<br />
<br />
===Общие сведения===<br />
*[[Alterator/faq|Часто задаваемые вопросы]]<br />
*[[Alterator/debug|Отладка модулей]]<br />
*[[Alterator/todo|Книга жалоб и предложений]]<br />
*[[Alterator/releases|Выпуски]]<br />
<br />
=== Руководства ===<br />
*[[Alterator/module/first|Первый модуль]]<br />
*[[Alterator/module/structure|Структура модуля]]<br />
*[[Alterator/module/backend|Бэкенд]]<br />
*[[Alterator/module/interface|Интерфейс]]<br />
*[[Alterator/module/types|Автоматическая проверка данных]]<br />
*[[Alterator/module/debug|Отладка модулей]]<br />
*[[Alterator/module/testing|Тестирование модулей]]<br />
<br />
===Справочная информация===<br />
<br />
*[[Alterator/architecture|Архитектура]]<br />
<br />
*[[Alterator/libraries|Стандартные библиотеки scheme, предоставляемые alterator]]<br />
*[[Alterator/reserved|Зарезервированные имена]]<br />
*[[Alterator/woo|Функции для запроса бакендов]]<br />
*[[Alterator/form|Функции для работы с полями форм]]<br />
*[[Alterator/shell|Бэкенды на shell]]<br />
*[[Alterator/perl|Бэкенды на perl]]<br />
*[[Alterator/ruby|Бэкенды на ruby]]<br />
<br />
*[[Alterator/i18n|Интернационализация]]<br />
*[[Alterator/l10n|Локализация]]<br />
<br />
<br />
'''Lookout:'''<br />
*[[Alterator/evolution|Описание общей структуры документа lookout]]<br />
*[[Alterator/widgets|Краткий справочник по виджетам]]<br />
<br />
===Разное===<br />
*[[Alterator/objects|Объектная система alterator]]<br />
*[[Alterator/rfc|Протокол работы с бэкендами, черновик]]<br />
*[[Alterator/role-setup|Типичные тематические роли для альтератора]]<br />
*[http://uneex.cs.msu.su/uneex/SeminarALTerator/Conspect UNИX-конспект]<br />
*[[Alterator/html-validate|Проверка корректности html]]<br />
<br />
<br />
'''Конкретные модули'''<br />
*[[Alterator/AlteratorServices|alterator-services]]<br />
*[[Alterator/AlteratorX11|alterator-x11]]<br />
*[[Alterator/AlteratorXinetd|alterator-xinetd]]<br />
*[[Alterator/AlteratorLilo|alterator-lilo]]<br />
*[[Alterator/AlteratorNetIptables|alterator-net-iptables]]<br />
<br />
<br />
'''Интересные проекты'''<br />
*[http://www.redhat.com/spacewalk/ SpaceWalk]<br />
*[http://www.openpegasus.org/ OpenPegasus]<br />
*[http://live.gnome.org/JsonGlib JsonGLIB]<br />
*[http://ex-parrot.com/~pdw/Mail-RFC822-Address.html регулярное выражение для валидации e-mail адреса]<br />
*[http://freesource.info/wiki/SergeyLebedev/EisSystem Проект единой информационной системы]<br />
<br />
'''Технические требования'''<br />
*[[Alterator/Выбор_DE|Выбор DE]]<br />
<br />
'''HTML, AJAX, BACKEND'''<br />
*[[Alterator/class_alterator-listbox|alterator-listbox]]<br />
<br />
=== См. также ===<br />
* <DPL><br />
namespace =<br />
titlematch = {{PAGENAME}}/%<br />
nottitlematch = {{PAGENAME}}/%/%<br />
mode = inline<br />
inlinetext=&nbsp;&bull;&#32;<br />
</DPL><br />
<br />
<br />
{{Category navigation|title=Alterator|category=Alterator|sortkey=*}}</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/class_alterator-listbox&diff=14791Alterator/class alterator-listbox2010-05-25T09:57:23Z<p>SergeyLebedev: </p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1<br />
<br />
25/05/2010<br />
<br />
'''HTML'''<br />
<br />
Пример html-кода в вашем index.html<br />
<pre><br />
<form method="POST"><br />
<table style="width:100%" name="hosts" class="alterator-listbox"><br />
<thead><br />
<tr><br />
<th><span translate="_">Host</span></th><br />
<th><span translate="_">Summary</span></th><br />
</tr><br />
</thead><br />
<tbody><br />
<tr><br />
<td nowrap="yes"><span class="alterator-label" name="name"/></td><br />
<td><span class="alterator-label" name="summary"/>&nbsp;</td><br />
</tr><br />
</tbody><br />
</table><br />
</form><br />
</pre><br />
<br />
Т.е. мы хотим получить таблицу с двумя колонками, причем с возможностью сортировки этих колонок по алфавиту.<br />
Первая колонка у нас имя хоста, вторая информация о нем. <br />
<br />
Важно, чтобы класс у таблицы был <code>class="alterator-listbox"</code>, у таблицы так же должно быть уникальное имя, в нашем случаи это <code>name="hosts"</code><br />
<br />
Автозаполнение таблицы будет идти по тегам <code><span class="alterator-label" name="SomeName"/></code><br />
<br />
Один из span тегов должен называться name т.е. <code><span class="alterator-label" name="name"/></code>. Почему так, необходимо проверить в коде самого алтератора, без такого тега не будет корректна заполнена таблица.<br />
<br />
Итого, у нас получается html-таблица с именем hosts, классом alterator-listbox, одним и более элементами <span>, которые в свою очередь имеют уникальное имя и класс alterator-label, один из span элементов должен иметь имя name, его положение не важно.<br />
<br />
'''AJAX'''<br />
Пример scheme-кода в ajax.scm<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-init . data)<br />
(form-update-enum "hosts" (woo-list "/mySuper-module"))<br />
)<br />
<br />
(define (init)<br />
(ui-init)<br />
)<br />
</pre><br />
<br />
При обращении к странице с нашим модулем mySuper-module, будет вызвана функция init (в конце приведенного кода), которая в свою очередь вызовет ui-init.<br />
<br />
Основное действо заключено в вызове <tt>(form-update-enum "hosts" (woo-list "/mySuper-module"))</tt>, которое заключается в обновлении таблицы hosts списком, полученным вызовом backend'а командой <tt>alterator-cmdline /mySuper-module action list </tt>.<br />
<br />
Все достаточно просто. Можно использовать данный шаблон. Стоит только заменить mySuper-module на что-то более точное и при вызове woo-list использовать не прямое обращение к модулю, а дополнить его чем-нибудь типа "/mySuper-module/avail_objects", так чтобы можно было через один и тот же метод list обращаться к различным объектам avail_myobject avail_hosts и так далее. Пример можно посмотреть в alterator-sysinfo-0.8-alt3 (html,ajax).<br />
<br />
'''Backend'''<br />
<br />
Пример shell-backend'а <br />
<pre><br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
list()<br />
{<br />
echo -e "aaa\nbbb\n" | <br />
while read i ;do<br />
write_table_item \<br />
name "$i"<br />
summary "summary "$i"" \<br />
host "$i"<br />
done<br />
}<br />
<br />
on_message(){<br />
case "$in_action" in<br />
read)<br />
:<br />
;;<br />
list)<br />
list<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
<br />
</pre><br />
<br />
Для построения правильного ответа будет использована функция из alterator-sh-functions-0.13-alt2 write_table_item. Ей необходимо передавать пару имя от span элемента и значение. Одно из имен обязательно должно быть name.<br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/class_alterator-listbox&diff=14790Alterator/class alterator-listbox2010-05-25T09:52:54Z<p>SergeyLebedev: </p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1<br />
<br />
'''HTML'''<br />
<br />
Пример html-кода в вашем index.html<br />
<pre><br />
<form method="POST"><br />
<table style="width:100%" name="hosts" class="alterator-listbox"><br />
<thead><br />
<tr><br />
<th><span translate="_">Host</span></th><br />
<th><span translate="_">Summary</span></th><br />
</tr><br />
</thead><br />
<tbody><br />
<tr><br />
<td nowrap="yes"><span class="alterator-label" name="name"/></td><br />
<td><span class="alterator-label" name="summary"/>&nbsp;</td><br />
</tr><br />
</tbody><br />
</table><br />
</form><br />
</pre><br />
<br />
Т.е. мы хотим получить таблицу с двумя колонками, причем с возможностью сортировки этих колонок по алфавиту.<br />
Первая колонка у нас имя хоста, вторая информация о нем. <br />
<br />
Важно, чтобы класс у таблицы был <code>class="alterator-listbox"</code>, у таблицы так же должно быть уникальное имя, в нашем случаи это <code>name="hosts"</code><br />
<br />
Автозаполнение таблицы будет идти по тегам <code><span class="alterator-label" name="SomeName"/></code><br />
<br />
Один из span тегов должен называться name т.е. <code><span class="alterator-label" name="name"/></code>. Почему так, необходимо проверить в коде самого алтератора, без такого тега не будет корректна заполнена таблица.<br />
<br />
Итого, у нас получается html-таблица с именем hosts, классом alterator-listbox, одним и более элементами <span>, которые в свою очередь имеют уникальное имя и класс alterator-label, один из span элементов должен иметь имя name, его положение не важно.<br />
<br />
'''AJAX'''<br />
Пример scheme-кода в ajax.scm<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-init . data)<br />
(form-update-enum "hosts" (woo-list "/mySuper-module"))<br />
)<br />
<br />
(define (init)<br />
(ui-init)<br />
)<br />
</pre><br />
<br />
При обращении к странице с нашим модулем mySuper-module, будет вызвана функция init (в конце приведенного кода), которая в свою очередь вызовет ui-init.<br />
<br />
Основное действо заключено в вызове <tt>(form-update-enum "hosts" (woo-list "/mySuper-module"))</tt>, которое заключается в обновлении таблицы hosts списком, полученным вызовом backend'а командой <tt>alterator-cmdline /mySuper-module action list </tt>.<br />
<br />
Все достаточно просто. Можно использовать данный шаблон. Стоит только заменить mySuper-module на что-то более точное и при вызове woo-list использовать не прямое обращение к модулю, а дополнить его чем-нибудь типа "/mySuper-module/avail_objects", так чтобы можно было через один и тот же метод list обращаться к различным объектам avail_myobject avail_hosts и так далее. Пример можно посмотреть в alterator-sysinfo-0.8-alt3 (html,ajax).<br />
<br />
'''Backend'''<br />
<br />
Пример shell-backend'а <br />
<pre><br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
list()<br />
{<br />
echo -e "aaa\nbbb\n" | <br />
while read i ;do<br />
write_table_item \<br />
name "$i"<br />
summary "summary "$i"" \<br />
host "$i"<br />
done<br />
}<br />
<br />
on_message(){<br />
case "$in_action" in<br />
read)<br />
:<br />
;;<br />
list)<br />
list<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
<br />
</pre><br />
<br />
Для построения правильного ответа будет использована функция из alterator-sh-functions-0.13-alt2 write_table_item. Ей необходимо передавать пару имя от span элемента и значение. Одно из имен обязательно должно быть name.<br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/class_alterator-listbox&diff=14789Alterator/class alterator-listbox2010-05-25T09:51:49Z<p>SergeyLebedev: </p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1<br />
<br />
'''HTML'''<br />
<br />
Пример html-кода в вашем index.html<br />
<pre><br />
<form method="POST"><br />
<table style="width:100%" name="hosts" class="alterator-listbox"><br />
<thead><br />
<tr><br />
<th><span translate="_">Host</span></th><br />
<th><span translate="_">Summary</span></th><br />
</tr><br />
</thead><br />
<tbody><br />
<tr><br />
<td nowrap="yes"><span class="alterator-label" name="name"/></td><br />
<td><span class="alterator-label" name="summary"/>&nbsp;</td><br />
</tr><br />
</tbody><br />
</table><br />
</form><br />
</pre><br />
<br />
Т.е. мы хотим получить таблицу с двумя колонками, причем с возможностью сортировки этих колонок по алфавиту.<br />
Первая колонка у нас имя хоста, вторая информация о нем. <br />
<br />
Важно, чтобы класс у таблицы был <code>class="alterator-listbox"</code>, у таблицы так же должно быть уникальное имя, в нашем случаи это <code>name="hosts"</code><br />
<br />
Автозаполнение таблицы будет идти по тегам <code><span class="alterator-label" name="SomeName"/></code><br />
<br />
Один из span тегов должен называться name т.е. <code><span class="alterator-label" name="name"/></code>. Почему так необходимо проверить в коде самого алтератора, без такого тега, не будет заполнена корректно таблица.<br />
<br />
Итого, у нас получается html-таблица с именем hosts, классом alterator-listbox, одним и более элементами <span>, которые в свою очередь имеют уникальное имя и класс alterator-label, один из span элементов должен иметь имя name, его положение не важно.<br />
<br />
'''AJAX'''<br />
Пример scheme-кода в ajax.scm<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-init . data)<br />
(form-update-enum "hosts" (woo-list "/mySuper-module"))<br />
)<br />
<br />
(define (init)<br />
(ui-init)<br />
)<br />
</pre><br />
<br />
При обращении к странице с нашим модулем mySuper-module, будет вызвана функция init (в конце приведенного кода), которая в свою очередь вызовет ui-init.<br />
<br />
Основное действо заключено в вызове <tt>(form-update-enum "hosts" (woo-list "/mySuper-module"))</tt>, которое заключается в обновлении таблицы hosts списком, полученным вызовом backend'а командой <tt>alterator-cmdline /mySuper-module action list </tt>.<br />
<br />
Все достаточно просто. Можно использовать данный шаблон. Стоит только заменить mySuper-module на что-то более точное и при вызове woo-list использовать не прямое обращение к модулю, а дополнить его чем-нибудь типа "/mySuper-module/avail_objects", так чтобы можно было через один и тот же метод list обращаться к различным объектам avail_myobject avail_hosts и так далее. Пример можно посмотреть в alterator-sysinfo-0.8-alt3 (html,ajax).<br />
<br />
'''Backend'''<br />
<br />
Пример shell-backend'а <br />
<pre><br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
list()<br />
{<br />
echo -e "aaa\nbbb\n" | <br />
while read i ;do<br />
write_table_item \<br />
name "$i"<br />
summary "summary "$i"" \<br />
host "$i"<br />
done<br />
}<br />
<br />
on_message(){<br />
case "$in_action" in<br />
read)<br />
:<br />
;;<br />
list)<br />
list<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
<br />
</pre><br />
<br />
Для построения правильного ответа будет использована функция из alterator-sh-functions-0.13-alt2 write_table_item. Ей необходимо передавать пару имя от span элемента и значение. Одно из имен обязательно должно быть name.<br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/class_alterator-listbox&diff=14788Alterator/class alterator-listbox2010-05-25T09:50:59Z<p>SergeyLebedev: </p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1<br />
<br />
'''HTML'''<br />
<br />
Пример html-кода в вашем index.html<br />
<pre><br />
<form method="POST"><br />
<table style="width:100%" name="hosts" class="alterator-listbox"><br />
<thead><br />
<tr><br />
<th><span translate="_">Host</span></th><br />
<th><span translate="_">Summary</span></th><br />
</tr><br />
</thead><br />
<tbody><br />
<tr><br />
<td nowrap="yes"><span class="alterator-label" name="name"/></td><br />
<td><span class="alterator-label" name="summary"/>&nbsp;</td><br />
</tr><br />
</tbody><br />
</table><br />
</form><br />
</pre><br />
<br />
Т.е. мы хотим получить таблицу с двумя колонками, причем с возможностью сортировки этих колонок по алфавиту.<br />
Первая колонка у нас имя хоста, вторая информация о нем. <br />
<br />
Важно, чтобы класс у таблицы был <code>class="alterator-listbox"</code>, у таблицы так же должно быть уникальное имя, в нашем случаи это <code>name="hosts"</code><br />
<br />
Автозаполнение таблицы будет идти по тегам <code><span class="alterator-label" name="SomeName"/></code><br />
<br />
Один из span тегов должен называться name т.е. <code><span class="alterator-label" name="name"/></code>. Почему так необходимо проверить в коде самого алтератора, без такого тега, не будет заполнена корректно таблица.<br />
<br />
Итого, у нас получается html-таблица с именем hosts, классом alterator-listbox, одним и более элементами <span>, которые в свою очередь имеют уникальное имя и класс alterator-label, один из span элементов должен иметь имя name, его положение не важно.<br />
<br />
'''AJAX'''<br />
Пример scheme-кода в ajax.scm<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-init . data)<br />
(form-update-enum "hosts" (woo-list "/mySuper-module"))<br />
)<br />
<br />
(define (init)<br />
(ui-init)<br />
)<br />
</pre><br />
<br />
При обращении к странице с нашим модулем mySuper-module, будет вызвана функция init (в конце приведенного кода), которая в свою очередь вызовет ui-init.<br />
<br />
Основное действо заключено в вызове <tt>(form-update-enum "hosts" (woo-list "/mySuper-module"))</tt>, которое заключается в обновлении таблицы hosts списком, полученным вызовом backend'а командой <tt>alterator-cmdline /mySuper-module action list </tt>.<br />
<br />
Все достаточно просто. Можно использовать данный шаблон. Стоит только заменить mySuper-module на что-то более точное и при вызове woo-list использовать не прямое обращение к модулю, а дополнить его чем-нибудь типа "/mySuper-module/avail_objects", так чтобы можно было через один и тот же метод list обращаться к различным объектам avail_myobject avail_hosts и так далее. Пример можно посмотреть в alterator-sysinfo-0.8-alt3 (html,ajax).<br />
<br />
'''Backend'''<br />
<br />
Пример shell-backend'а <br />
<pre><br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
list()<br />
{<br />
echo -e "aaa\nbbb\n" | <br />
while read i ;do<br />
write_table_item \<br />
name "$i"<br />
summary "summary "$i"" \<br />
host "$i"<br />
done<br />
}<br />
<br />
on_message(){<br />
case "$in_action" in<br />
read)<br />
:<br />
;;<br />
list)<br />
cluster-config list | list<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
<br />
</pre><br />
<br />
Для построения правильного ответа будет использована функция из alterator-sh-functions-0.13-alt2 write_table_item. Ей необходимо передавать пару имя от span элемента и значение. Одно из имен обязательно должно быть name.<br />
<br />
[[Категория:Alterator]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator/class_alterator-listbox&diff=14787Alterator/class alterator-listbox2010-05-25T09:18:26Z<p>SergeyLebedev: Новая страница: «Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1 '''HTML''' Пример html-кода в вашем index.html <pre> <form method="POST"> <...»</p>
<hr />
<div>Актуально для alterator-4.17-alt3 alterator-fbi-5.26-alt1<br />
<br />
'''HTML'''<br />
<br />
Пример html-кода в вашем index.html<br />
<pre><br />
<form method="POST"><br />
<table style="width:100%" name="hosts" class="alterator-listbox"><br />
<thead><br />
<tr><br />
<th><span translate="_">Host</span></th><br />
<th><span translate="_">Summary</span></th><br />
</tr><br />
</thead><br />
<tbody><br />
<tr><br />
<td nowrap="yes"><span class="alterator-label" name="name"/></td><br />
<td><span class="alterator-label" name="summary"/>&nbsp;</td><br />
</tr><br />
</tbody><br />
</table><br />
</form><br />
</pre><br />
<br />
Т.е. мы хотим получить таблицу с двумя колонками, причем с возможностью сортировки этих колонок по алфавиту.<br />
Первая колонка у нас имя хоста, вторая информация о нем. <br />
<br />
Важно, чтобы класс у таблицы был <code>class="alterator-listbox"</code>, у таблицы так же должно быть уникальное имя, в нашем случаи это <code>name="hosts"</code><br />
<br />
Автозаполнение таблицы будет идти по тегам <code><span class="alterator-label" name="SomeName"/></code><br />
<br />
Один из span тегов должен называться name т.е. <code><span class="alterator-label" name="name"/></code>. Почему так необходимо проверить в коде самого алтератора, без такого тега, не будет заполнена корректно таблица.<br />
<br />
Итого, у нас получается html-таблица с именем hosts, классом alterator-listbox, одним и более элементами <code><span></code>, которые в свою очередь имеют уникальное имя и класс alterator-label, один из <code><span></code> элементов должен иметь имя name, его положение не важно.<br />
<br />
'''AJAX'''<br />
Пример scheme-кода в ajax.scm<br />
<br />
<pre><br />
(define-module (ui mySuper-module ajax)<br />
:use-module (alterator woo)<br />
:use-module (alterator ajax)<br />
:export (init))<br />
<br />
(define (ui-init . data)<br />
(form-update-enum "hosts" (woo-list "/mySuper-module"))<br />
)<br />
<br />
(define (init)<br />
(ui-init)<br />
)<br />
</pre><br />
<br />
При обращении к странице с нашим модулем mySuper-module, будет вызвана функция init (в конце приведенного кода), которая в свою очередь вызовет ui-init.<br />
<br />
Основное действо заключено в вызове <code>(form-update-enum "hosts" (woo-list "/mySuper-module"))</code>, которое заключается в обновлении таблицы hosts списком, полученным вызовом backend'а командой <code>alterator-cmdline /mySuper-module action list</code>.<br />
<br />
Все достаточно просто. Можно использовать данный шаблон. Стоит только заменить mySuper-module на что-то более точное и при вызове woo-list использовать не прямое обращение к модулю, а дополнить его чем-нибудь типа "/mySuper-module/avail_objects", так чтобы можно было через один и тот же метод list обращаться к различным объектам avail_myobject avail_hosts и так далее. Пример можно посмотреть в alterator-sysinfo-0.8-alt3 (html,ajax).<br />
<br />
'''Backend'''<br />
<br />
Пример shell-backend'а <br />
<pre><br />
Останавливается alteratord: [ OK ]<br />
#!/bin/sh <br />
<br />
#turn of auto expansion<br />
set -f<br />
<br />
alterator_api_version=1<br />
. alterator-sh-functions<br />
. shell-config<br />
<br />
<br />
list()<br />
{<br />
echo -e "aaa\nbbb\n" | <br />
while read i ;do<br />
write_table_item \<br />
name "$i"<br />
summary "summary "$i"" \<br />
host "$i"<br />
done<br />
}<br />
<br />
on_message(){<br />
case "$in_action" in<br />
read)<br />
:<br />
;;<br />
list)<br />
cluster-config list | list<br />
;;<br />
esac<br />
}<br />
<br />
message_loop<br />
<br />
</pre><br />
<br />
Для построения правильного ответа будет использована функция из alterator-sh-functions-0.13-alt2 write_table_item.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Alterator&diff=14786Alterator2010-05-25T08:45:04Z<p>SergeyLebedev: /* Разное */</p>
<hr />
<div>[[Category:Sisyphus]]<br />
[[en:Alterator]]<br />
'''Alterator''' — новое поколение платформ для разработки сложных систем. Используются по большей части [[Scheme]], C и старый добрый sh+awk. На данный момент используется как [[Installer|инсталлятор]] и конфигуратор системы. Копия части этой документации содержится в пакете [http://sisyphus.ru/srpm/alterator alterator]. <br />
<br />
Для обсуждения вопросов, связанных с alterator, существует список рассылки {{lists|devel-conf}}.<br />
<br />
=== Обращение к системным администраторам ===<br />
Наверняка в alterator недостаточно модулей для решения ваших задач. Каждый модуль состоит из бэкенда и интерфейса. Разработка интерфейса — это работа для программиста, но создать бэкенд вы вполне сможете. Бэкенд пишется на произвольном языке программирования по достаточно простым правилам. Имея бэкенд, при помощи интерфейса командной строки вы уже сразу же сможете использовать наработки в своих скриптах. Хороший бэкенд — это фиксация знаний и возможность повторного использования ваших наработок другими администраторами.<br />
Напишите в список рассылки — мы поможем сделать интерфейс.<br />
<br />
===Общие сведения===<br />
*[[Alterator/faq|Часто задаваемые вопросы]]<br />
*[[Alterator/debug|Отладка модулей]]<br />
*[[Alterator/todo|Книга жалоб и предложений]]<br />
*[[Alterator/releases|Выпуски]]<br />
<br />
=== Руководства ===<br />
*[[Alterator/module/first|Первый модуль]]<br />
*[[Alterator/module/structure|Структура модуля]]<br />
*[[Alterator/module/backend|Бэкенд]]<br />
*[[Alterator/module/interface|Интерфейс]]<br />
*[[Alterator/module/types|Автоматическая проверка данных]]<br />
*[[Alterator/module/debug|Отладка модулей]]<br />
*[[Alterator/module/testing|Тестирование модулей]]<br />
<br />
===Справочная информация===<br />
<br />
*[[Alterator/architecture|Архитектура]]<br />
<br />
*[[Alterator/libraries|Стандартные библиотеки scheme, предоставляемые alterator]]<br />
*[[Alterator/reserved|Зарезервированные имена]]<br />
*[[Alterator/woo|Функции для запроса бакендов]]<br />
*[[Alterator/form|Функции для работы с полями форм]]<br />
*[[Alterator/shell|Бэкенды на shell]]<br />
*[[Alterator/perl|Бэкенды на perl]]<br />
*[[Alterator/ruby|Бэкенды на ruby]]<br />
<br />
*[[Alterator/i18n|Интернационализация]]<br />
*[[Alterator/l10n|Локализация]]<br />
<br />
<br />
'''Lookout:'''<br />
*[[Alterator/evolution|Описание общей структуры документа lookout]]<br />
*[[Alterator/widgets|Краткий справочник по виджетам]]<br />
<br />
===Разное===<br />
*[[Alterator/objects|Объектная система alterator]]<br />
*[[Alterator/rfc|Протокол работы с бэкендами, черновик]]<br />
*[[Alterator/role-setup|Типичные тематические роли для альтератора]]<br />
*[http://uneex.cs.msu.su/uneex/SeminarALTerator/Conspect UNИX-конспект]<br />
<br />
'''Конкретные модули'''<br />
*[[Alterator/AlteratorServices|alterator-services]]<br />
*[[Alterator/AlteratorX11|alterator-x11]]<br />
*[[Alterator/AlteratorXinetd|alterator-xinetd]]<br />
*[[Alterator/AlteratorLilo|alterator-lilo]]<br />
*[[Alterator/AlteratorNetIptables|alterator-net-iptables]]<br />
<br />
<br />
'''Интересные проекты'''<br />
*[http://www.redhat.com/spacewalk/ SpaceWalk]<br />
*[http://www.openpegasus.org/ OpenPegasus]<br />
*[http://live.gnome.org/JsonGlib JsonGLIB]<br />
*[http://ex-parrot.com/~pdw/Mail-RFC822-Address.html регулярное выражение для валидации e-mail адреса]<br />
*[http://freesource.info/wiki/SergeyLebedev/EisSystem Проект единой информационной системы]<br />
<br />
'''Технические требования'''<br />
*[[Alterator/Выбор_DE|Выбор DE]]<br />
<br />
'''HTML, AJAX, BACKEND'''<br />
*[[Alterator/class_alterator-listbox|alterator-listbox]]<br />
<br />
=== См. также ===<br />
* <DPL><br />
namespace =<br />
titlematch = {{PAGENAME}}/%<br />
nottitlematch = {{PAGENAME}}/%/%<br />
mode = inline<br />
inlinetext=&nbsp;&bull;&#32;<br />
</DPL><br />
<br />
<br />
{{Category navigation|title=Alterator|category=Alterator|sortkey=*}}</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Puppet&diff=3419Puppet2008-09-05T13:59:00Z<p>SergeyLebedev: /* puppetd */</p>
<hr />
<div>==== Черновик ====<br />
<br />
===== puppetd =====<br />
<br />
'''TODO'''<br />
* В соответсвии с http://reductivelabs.com/trac/puppet/wiki/CertificatesAndSecurity при первом запуске puppetd клиента, необходимо обратиться к серверу с запросом подписания сертификата. Для этого puppetd должен быть запущен с ключом <tt>--waitforcert</tt>. Предлагаю исправить /etc/init.d/puppetd -- добавить режим sign, при котором puppetd стартует с этой опцией. <br />
* Необходимо добавить в /etc/init.d/puppetd проверку на задание переменной PUPPET_SERVER, чтобы при старте происходило подключение к последнему. А то висит процесс, вроде всё работает, но на самом деле клиент ничего не делает -- не знает ip-сервера.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Puppet&diff=3418Puppet2008-09-05T13:57:55Z<p>SergeyLebedev: /* puppetd */</p>
<hr />
<div>==== Черновик ====<br />
<br />
===== puppetd =====<br />
<br />
'''TODO'''<br />
* В соответсвии с [http://reductivelabs.com/trac/puppet/wiki/CertificatesAndSecurity] при первом запуске puppetd клиента, необходимо обратиться к серверу с запросом подписания сертификата. Для этого puppetd должен быть запущен с ключом <tt>--waitforcert</tt>. Предлагаю исправить /etc/init.d/puppetd -- добавить режим sign, при котором puppetd стартует с этой опцией. <br />
* Необходимо добавить в /etc/init.d/puppetd проверку на задание переменной PUPPET_SERVER, чтобы при старте происходило подключение к последнему. А то висит процесс, вроде всё работает, но на самом деле клиент ничего не делает -- не знает ip-сервера.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Puppet&diff=3417Puppet2008-09-05T13:57:18Z<p>SergeyLebedev: Новая: ==== Черновик ==== ===== puppetd ===== '''TODO''' * В соответсвии с [http://reductivelabs.com/trac/puppet/wiki/CertificatesAndSecurity] при первом зап...</p>
<hr />
<div>==== Черновик ====<br />
<br />
===== puppetd =====<br />
<br />
'''TODO'''<br />
* В соответсвии с [http://reductivelabs.com/trac/puppet/wiki/CertificatesAndSecurity] при первом запуске puppetd клиента, <br />
необходимо обратиться к серверу с запросом подписания сертификата. Для этого puppetd должен быть запущен с ключом <br />
<tt>--waitforcert</tt>. Предлагаю исправить /etc/init.d/puppetd -- добавить режим sign, при котором puppetd стартует с <br />
этой опцией. <br />
* Необходимо добавить в /etc/init.d/puppetd проверку на задание переменной PUPPET_SERVER, чтобы при старте происходило<br />
подключение к последнему. А то висит процесс, вроде всё работает, но на самом деле клиент ничего не делает -- не знает<br />
ip-сервера.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Sysadmin&diff=3416Sysadmin2008-09-05T13:50:17Z<p>SergeyLebedev: /* Конфигурация = */</p>
<hr />
<div>[[Категория:Admin]]<br />
{{stub}}<br />
<br />
== Портал системного администратора ==<br />
<br />
<br />
=== Установка ===<br />
* [[InstallFlash | Как сделать установочную флешку]]<br />
* [[NetInstall | Установка полностью по сети]] (требуется поддержка [[ruwp:PXE|PXE]])<br />
<br />
=== Сеть ===<br />
* [[Etcnet | Система конфигурирования сетевых интерфейсов etcnet]]<br />
* [[Etcnet Firewall | Настройка файрволлов с помощью etcnet]]<br />
* [[Etcnet QoS | Настройка QoS с помощью etcnet]]<br />
<br />
=== Система ===<br />
<br />
===== Дисковая подсистема =====<br />
* [[РазбиениеДиска | Разбиение диска для увеличения производительности]]<br />
* [[CreateMdRAID1onLiveSystem | Миграция установленной системы на md-raid1]]<br />
<br />
===== Виртуализация =====<br />
* [[OpenVZ | OpenVZ в ALT Linux]]<br />
* [[ALTLinuxXen | Xen в ALT Linux]]<br />
<br />
=== Софт ===<br />
<br />
===== DNS =====<br />
* [[BIND | Несколько заметок по Bind]]<br />
* [[DDNS | DHCP + динамическое обновление зон (DDNS) ]]<br />
<br />
===== WEB =====<br />
* [[Mailman_and_lighttpd | Как поднять веб-интерфейс mailman под lighttpd]]<br />
<br />
===== Enterprise =====<br />
* [[1C | Установка сервера 1С Предприятие 8.1 на ALT Linux]]<br />
* [[OracleALS40 | Установка Oracle DBMS на ALT Linux Server 4.0]]<br />
<br />
===== Конфигурация =====<br />
* [[puppet | Он и в Африке Puppet]]<br />
<br />
=== Прочее ===<br />
* [[Mirror | Как поднять зеркало альтовских репозиториев]]<br />
* [[ТестированиеКомпьютера | Описание программ для тестирования компьютера]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Sysadmin&diff=3415Sysadmin2008-09-05T13:50:02Z<p>SergeyLebedev: /* Enterprise */</p>
<hr />
<div>[[Категория:Admin]]<br />
{{stub}}<br />
<br />
== Портал системного администратора ==<br />
<br />
<br />
=== Установка ===<br />
* [[InstallFlash | Как сделать установочную флешку]]<br />
* [[NetInstall | Установка полностью по сети]] (требуется поддержка [[ruwp:PXE|PXE]])<br />
<br />
=== Сеть ===<br />
* [[Etcnet | Система конфигурирования сетевых интерфейсов etcnet]]<br />
* [[Etcnet Firewall | Настройка файрволлов с помощью etcnet]]<br />
* [[Etcnet QoS | Настройка QoS с помощью etcnet]]<br />
<br />
=== Система ===<br />
<br />
===== Дисковая подсистема =====<br />
* [[РазбиениеДиска | Разбиение диска для увеличения производительности]]<br />
* [[CreateMdRAID1onLiveSystem | Миграция установленной системы на md-raid1]]<br />
<br />
===== Виртуализация =====<br />
* [[OpenVZ | OpenVZ в ALT Linux]]<br />
* [[ALTLinuxXen | Xen в ALT Linux]]<br />
<br />
=== Софт ===<br />
<br />
===== DNS =====<br />
* [[BIND | Несколько заметок по Bind]]<br />
* [[DDNS | DHCP + динамическое обновление зон (DDNS) ]]<br />
<br />
===== WEB =====<br />
* [[Mailman_and_lighttpd | Как поднять веб-интерфейс mailman под lighttpd]]<br />
<br />
===== Enterprise =====<br />
* [[1C | Установка сервера 1С Предприятие 8.1 на ALT Linux]]<br />
* [[OracleALS40 | Установка Oracle DBMS на ALT Linux Server 4.0]]<br />
<br />
===== Конфигурация ======<br />
* [[puppet | Он и в Африке Puppet]]<br />
<br />
=== Прочее ===<br />
* [[Mirror | Как поднять зеркало альтовских репозиториев]]<br />
* [[ТестированиеКомпьютера | Описание программ для тестирования компьютера]]</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=3029Java/JavaPackagingFAQ2008-08-25T22:39:44Z<p>SergeyLebedev: /* Советы по замене устаревших макросов set/add_classpath */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
=====Обсуждение с Виталием=====<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
=====Обсуждение с Денисом=====<br />
;viy ><br />
:хотел бы попросить рассказать что неудобно<br />
;Mithraen > <br />
:Отсутствие префиксов типа java- или аналогичных<br />
;viy > <br />
:я уже говорил с lav@ <br />
:уже де-факто есть суффикс.<br />
;Mithraen > <br />
:Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
:Какой суффикс?<br />
;viy > <br />
:можно это выписать в полиси и к пакетам добавлять<br />
:jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
:jpackage repository P.Q/<br />
:jvm4.2==jpp1.7<br />
:jvm5.0==jpp5.0<br />
;Mithraen > <br />
:Гм.<br />
:Не уверен что такая подробность (версия в имени) нужна<br />
:А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
;viy > <br />
:можно будет написать робот такого типа:<br />
:vpupkin@ собрал пакет с суффиксом jvm4.2<br />
:но он собран 1.6.0 без -target 1.4<br />
:соответственно в 1.4\1.5 работать не будет.<br />
;Mithraen > <br />
:К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
:А с provides/requires при этом что делать?<br />
:Они-ж еще и по файлам пересекаться небось будут :(<br />
:Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
;viy > <br />
:нет. пакет должен быть собран для наименьшей возможной java.<br />
:т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
:пример junit (jvm4.2) и junit4 (jvm5.0)<br />
;Mithraen > <br />
:А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
;viy > <br />
:да.<br />
;Mithraen > <br />
:Их придется дублировать<br />
;viy > <br />
:лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
:а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
:автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
:в ней любой пакет можно будет по отдельности пересобрать. <br />
:Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
;Mithraen > <br />
:Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
:Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
;viy > <br />
:можно... <br />
:но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
:Не нравилось мне работать в <чужом дистрибутиве>.<br />
:Соответственно совместимость это полезная вещь, она денег стоит.<br />
:Смысла ее ломать из-за эстетических соображений я не вижу.<br />
:Это удар по разработчикам.<br />
;Mithraen > <br />
:Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
;viy > <br />
:бесполезная работа отнимает кучу время/денег тоже.<br />
;Mithraen > <br />
:А соображения эти не эстетического характера, а следствия элементарного удобства<br />
;Mithraen > <br />
:<tt>apt-cache search log | grep java</tt> -- это удобно<br />
;viy > <br />
:я же предложил суффикс :)<br />
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt><br />
;Mithraen > <br />
:Суффикс это точно такое же переименование<br />
:От необходимости делать provides на jpackage name не спасет<br />
;viy > <br />
:нет. он же в Release. на зависимости не влияет.<br />
;Mithraen ><br />
:А.. в release...<br />
:Ужас :)<br />
<br />
----<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
<pre><br />
Nov 14, 2007 <br />
Slava Dubrovskiy wrote: <br />
QA Team Download Robot пишет: <br />
> List of files which have been downloaded from the "devel" <br />
> incoming: maven2-2.0.4-alt1_10jpp1.7.src.rpm <br />
Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1) /usr/bin/mvn -- это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с -Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars<br />
<br />
2) для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3) Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
</pre><br />
----<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
<pre><br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
Nov 26, 2007 Slava Dubrovskiy wrote:<br />
> На выходных сделал подход к снаряду. <br />
> На текущей пакетной базе это <br />
> сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для<br />
> сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
<br />
Это достаточно скоро будет.<br />
> Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) <br />
> стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
> Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в <br />
> репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br />
наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
</pre><br />
----<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
<br />
<pre><br />
Jan 29, 2008 <br />
Alexey I. Froloff wrote: <br />
> $ sudo apt-get install jakarta-commons-cli log4j<br />
> The following NEW packages will be installed:<br />
> jpackage-utils log4j rpm-build-java<br />
</pre><br />
<br />
;raorn ><br />
:.o0( ох проклянут меня за азуреусовские зависимости... )<br />
;viy ><br />
:скорее за их отсутствие :)<br />
:если не будет зависимостей, средняя софтина на java <br />
:будет тянуть 40-200 Mb. 1 софтина как весь <br />
:дистрибутив. а так они разделяют зависимости...<br />
:не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
:[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
:Особенно смущают jpackage-utils и rpm-build-java.<br />
:jpackage-utils здесь потому, что в log4j есть приложения.<br />
:для их запуска рекомендуется строить classspath с помощью<br />
:скрипта build-classpath<br />
:а не указывать библиотеки явно.<br />
<br />
:Например<br />
:<tt>java -cp \<br />
:$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
:<class></tt><br />
<br />
:Кстати, это советую сделать для azaureus.<br />
<br />
:с rpm-build-java, боюсь, findreq наshellил.<br />
:в свободное время посмотрю.<br />
<br />
;raorn > <br />
:а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
;viy > <br />
:надо, но руки не доходят... увы, не многорукое Шиво...<br />
:там java-common Миши Забалуева был по сути попыткой написать <br />
:jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
;raorn > <br />
:ага, я видел. вкусные функции там<br />
:а дока есть? или экспортируемые переменные большой секрет?<br />
;viy > <br />
:дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
:документация разная есть, в процессе написания, сейчас брошу ссылки<br />
:[http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
:1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
:2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
----<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
;raorn ><br />
:а ещё build-classpath не умеет абсолютные пути к жарам<br />
;viy > <br />
:в смысле? нельзя ж абсолютные пути.<br />
;raorn > <br />
:у меня софтина в /usr/share/azureus/Azureus2.jar<br />
:или в %_javadir положить?<br />
:я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
:он находит Azureus2.jar<br />
<br />
;viy > <br />
:по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
:библиотека ищется в нескольких местах<br />
;raorn > <br />
:это я уже подсмотрел<br />
<br />
;viy > <br />
:проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
:у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
:что касается /usr/share/azureus/Azureus2.jar --<br />
:если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
:и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
:если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
;raorn > <br />
:это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
;viy > <br />
:юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
;raorn > <br />
:а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
:это в корне неверно?<br />
;viy > <br />
:да, неверно. граблей слишком много,<br />
;raorn > <br />
:я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
:но если говоришь надо - переделаю ;-)<br />
:мне ещё наверно зымбру собирать...<br />
;viy > <br />
:_javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
:('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
:а от явного указания и в /opt не скроешься.<br />
;raorn > <br />
:ну тогда ладно<br />
<br />
----<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
<pre><br />
%set_classpath %_javadir/junit.jar<br />
export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
%ant_build \<br />
%ant \<br />
</pre><br />
<br />
<pre><br />
Jul 23, 2008 <br />
Kirill Maslinsky wrote: <br />
> > export CLASSPATH=$(build-classpath junit) <br />
> Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.<br />
</pre><br />
<br />
----</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=3028Java/JavaPackagingFAQ2008-08-25T22:37:18Z<p>SergeyLebedev: /* использование build-classpath из jpackage-utils */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
=====Обсуждение с Виталием=====<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
=====Обсуждение с Денисом=====<br />
;viy ><br />
:хотел бы попросить рассказать что неудобно<br />
;Mithraen > <br />
:Отсутствие префиксов типа java- или аналогичных<br />
;viy > <br />
:я уже говорил с lav@ <br />
:уже де-факто есть суффикс.<br />
;Mithraen > <br />
:Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
:Какой суффикс?<br />
;viy > <br />
:можно это выписать в полиси и к пакетам добавлять<br />
:jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
:jpackage repository P.Q/<br />
:jvm4.2==jpp1.7<br />
:jvm5.0==jpp5.0<br />
;Mithraen > <br />
:Гм.<br />
:Не уверен что такая подробность (версия в имени) нужна<br />
:А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
;viy > <br />
:можно будет написать робот такого типа:<br />
:vpupkin@ собрал пакет с суффиксом jvm4.2<br />
:но он собран 1.6.0 без -target 1.4<br />
:соответственно в 1.4\1.5 работать не будет.<br />
;Mithraen > <br />
:К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
:А с provides/requires при этом что делать?<br />
:Они-ж еще и по файлам пересекаться небось будут :(<br />
:Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
;viy > <br />
:нет. пакет должен быть собран для наименьшей возможной java.<br />
:т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
:пример junit (jvm4.2) и junit4 (jvm5.0)<br />
;Mithraen > <br />
:А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
;viy > <br />
:да.<br />
;Mithraen > <br />
:Их придется дублировать<br />
;viy > <br />
:лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
:а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
:автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
:в ней любой пакет можно будет по отдельности пересобрать. <br />
:Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
;Mithraen > <br />
:Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
:Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
;viy > <br />
:можно... <br />
:но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
:Не нравилось мне работать в <чужом дистрибутиве>.<br />
:Соответственно совместимость это полезная вещь, она денег стоит.<br />
:Смысла ее ломать из-за эстетических соображений я не вижу.<br />
:Это удар по разработчикам.<br />
;Mithraen > <br />
:Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
;viy > <br />
:бесполезная работа отнимает кучу время/денег тоже.<br />
;Mithraen > <br />
:А соображения эти не эстетического характера, а следствия элементарного удобства<br />
;Mithraen > <br />
:<tt>apt-cache search log | grep java</tt> -- это удобно<br />
;viy > <br />
:я же предложил суффикс :)<br />
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt><br />
;Mithraen > <br />
:Суффикс это точно такое же переименование<br />
:От необходимости делать provides на jpackage name не спасет<br />
;viy > <br />
:нет. он же в Release. на зависимости не влияет.<br />
;Mithraen ><br />
:А.. в release...<br />
:Ужас :)<br />
<br />
----<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
<pre><br />
Nov 14, 2007 <br />
Slava Dubrovskiy wrote: <br />
QA Team Download Robot пишет: <br />
> List of files which have been downloaded from the "devel" <br />
> incoming: maven2-2.0.4-alt1_10jpp1.7.src.rpm <br />
Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1) /usr/bin/mvn -- это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с -Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars<br />
<br />
2) для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3) Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
</pre><br />
----<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
<pre><br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
Nov 26, 2007 Slava Dubrovskiy wrote:<br />
> На выходных сделал подход к снаряду. <br />
> На текущей пакетной базе это <br />
> сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для<br />
> сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
<br />
Это достаточно скоро будет.<br />
> Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) <br />
> стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
> Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в <br />
> репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br />
наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
</pre><br />
----<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
<br />
<pre><br />
Jan 29, 2008 <br />
Alexey I. Froloff wrote: <br />
> $ sudo apt-get install jakarta-commons-cli log4j<br />
> The following NEW packages will be installed:<br />
> jpackage-utils log4j rpm-build-java<br />
</pre><br />
<br />
;raorn ><br />
:.o0( ох проклянут меня за азуреусовские зависимости... )<br />
;viy ><br />
:скорее за их отсутствие :)<br />
:если не будет зависимостей, средняя софтина на java <br />
:будет тянуть 40-200 Mb. 1 софтина как весь <br />
:дистрибутив. а так они разделяют зависимости...<br />
:не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
:[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
:Особенно смущают jpackage-utils и rpm-build-java.<br />
:jpackage-utils здесь потому, что в log4j есть приложения.<br />
:для их запуска рекомендуется строить classspath с помощью<br />
:скрипта build-classpath<br />
:а не указывать библиотеки явно.<br />
<br />
:Например<br />
:<tt>java -cp \<br />
:$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
:<class></tt><br />
<br />
:Кстати, это советую сделать для azaureus.<br />
<br />
:с rpm-build-java, боюсь, findreq наshellил.<br />
:в свободное время посмотрю.<br />
<br />
;raorn > <br />
:а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
;viy > <br />
:надо, но руки не доходят... увы, не многорукое Шиво...<br />
:там java-common Миши Забалуева был по сути попыткой написать <br />
:jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
;raorn > <br />
:ага, я видел. вкусные функции там<br />
:а дока есть? или экспортируемые переменные большой секрет?<br />
;viy > <br />
:дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
:документация разная есть, в процессе написания, сейчас брошу ссылки<br />
:[http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
:1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
:2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
----<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
;raorn ><br />
:а ещё build-classpath не умеет абсолютные пути к жарам<br />
;viy > <br />
:в смысле? нельзя ж абсолютные пути.<br />
;raorn > <br />
:у меня софтина в /usr/share/azureus/Azureus2.jar<br />
:или в %_javadir положить?<br />
:я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
:он находит Azureus2.jar<br />
<br />
;viy > <br />
:по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
:библиотека ищется в нескольких местах<br />
;raorn > <br />
:это я уже подсмотрел<br />
<br />
;viy > <br />
:проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
:у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
:что касается /usr/share/azureus/Azureus2.jar --<br />
:если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
:и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
:если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
;raorn > <br />
:это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
;viy > <br />
:юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
;raorn > <br />
:а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
:это в корне неверно?<br />
;viy > <br />
:да, неверно. граблей слишком много,<br />
;raorn > <br />
:я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
:но если говоришь надо - переделаю ;-)<br />
:мне ещё наверно зымбру собирать...<br />
;viy > <br />
:_javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
:('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
:а от явного указания и в /opt не скроешься.<br />
;raorn > <br />
:ну тогда ладно<br />
<br />
----<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=3027Java/JavaPackagingFAQ2008-08-25T22:36:46Z<p>SergeyLebedev: /* приложения с разделяемыми библиотеками */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
=====Обсуждение с Виталием=====<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
=====Обсуждение с Денисом=====<br />
;viy ><br />
:хотел бы попросить рассказать что неудобно<br />
;Mithraen > <br />
:Отсутствие префиксов типа java- или аналогичных<br />
;viy > <br />
:я уже говорил с lav@ <br />
:уже де-факто есть суффикс.<br />
;Mithraen > <br />
:Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
:Какой суффикс?<br />
;viy > <br />
:можно это выписать в полиси и к пакетам добавлять<br />
:jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
:jpackage repository P.Q/<br />
:jvm4.2==jpp1.7<br />
:jvm5.0==jpp5.0<br />
;Mithraen > <br />
:Гм.<br />
:Не уверен что такая подробность (версия в имени) нужна<br />
:А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
;viy > <br />
:можно будет написать робот такого типа:<br />
:vpupkin@ собрал пакет с суффиксом jvm4.2<br />
:но он собран 1.6.0 без -target 1.4<br />
:соответственно в 1.4\1.5 работать не будет.<br />
;Mithraen > <br />
:К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
:А с provides/requires при этом что делать?<br />
:Они-ж еще и по файлам пересекаться небось будут :(<br />
:Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
;viy > <br />
:нет. пакет должен быть собран для наименьшей возможной java.<br />
:т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
:пример junit (jvm4.2) и junit4 (jvm5.0)<br />
;Mithraen > <br />
:А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
;viy > <br />
:да.<br />
;Mithraen > <br />
:Их придется дублировать<br />
;viy > <br />
:лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
:а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
:автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
:в ней любой пакет можно будет по отдельности пересобрать. <br />
:Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
;Mithraen > <br />
:Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
:Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
;viy > <br />
:можно... <br />
:но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
:Не нравилось мне работать в <чужом дистрибутиве>.<br />
:Соответственно совместимость это полезная вещь, она денег стоит.<br />
:Смысла ее ломать из-за эстетических соображений я не вижу.<br />
:Это удар по разработчикам.<br />
;Mithraen > <br />
:Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
;viy > <br />
:бесполезная работа отнимает кучу время/денег тоже.<br />
;Mithraen > <br />
:А соображения эти не эстетического характера, а следствия элементарного удобства<br />
;Mithraen > <br />
:<tt>apt-cache search log | grep java</tt> -- это удобно<br />
;viy > <br />
:я же предложил суффикс :)<br />
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt><br />
;Mithraen > <br />
:Суффикс это точно такое же переименование<br />
:От необходимости делать provides на jpackage name не спасет<br />
;viy > <br />
:нет. он же в Release. на зависимости не влияет.<br />
;Mithraen ><br />
:А.. в release...<br />
:Ужас :)<br />
<br />
----<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
<pre><br />
Nov 14, 2007 <br />
Slava Dubrovskiy wrote: <br />
QA Team Download Robot пишет: <br />
> List of files which have been downloaded from the "devel" <br />
> incoming: maven2-2.0.4-alt1_10jpp1.7.src.rpm <br />
Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1) /usr/bin/mvn -- это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с -Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars<br />
<br />
2) для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3) Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
</pre><br />
----<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
<pre><br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
Nov 26, 2007 Slava Dubrovskiy wrote:<br />
> На выходных сделал подход к снаряду. <br />
> На текущей пакетной базе это <br />
> сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для<br />
> сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
<br />
Это достаточно скоро будет.<br />
> Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) <br />
> стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
> Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в <br />
> репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br />
наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
</pre><br />
----<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
<br />
<pre><br />
Jan 29, 2008 <br />
Alexey I. Froloff wrote: <br />
> $ sudo apt-get install jakarta-commons-cli log4j<br />
> The following NEW packages will be installed:<br />
> jpackage-utils log4j rpm-build-java<br />
</pre><br />
<br />
;raorn ><br />
:.o0( ох проклянут меня за азуреусовские зависимости... )<br />
;viy ><br />
:скорее за их отсутствие :)<br />
:если не будет зависимостей, средняя софтина на java <br />
:будет тянуть 40-200 Mb. 1 софтина как весь <br />
:дистрибутив. а так они разделяют зависимости...<br />
:не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
:[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
:Особенно смущают jpackage-utils и rpm-build-java.<br />
:jpackage-utils здесь потому, что в log4j есть приложения.<br />
:для их запуска рекомендуется строить classspath с помощью<br />
:скрипта build-classpath<br />
:а не указывать библиотеки явно.<br />
<br />
:Например<br />
:<tt>java -cp \<br />
:$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
:<class></tt><br />
<br />
:Кстати, это советую сделать для azaureus.<br />
<br />
:с rpm-build-java, боюсь, findreq наshellил.<br />
:в свободное время посмотрю.<br />
<br />
;raorn > <br />
:а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
;viy > <br />
:надо, но руки не доходят... увы, не многорукое Шиво...<br />
:там java-common Миши Забалуева был по сути попыткой написать <br />
:jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
;raorn > <br />
:ага, я видел. вкусные функции там<br />
:а дока есть? или экспортируемые переменные большой секрет?<br />
;viy > <br />
:дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
:документация разная есть, в процессе написания, сейчас брошу ссылки<br />
:[http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
:1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
:2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
;raorn ><br />
:а ещё build-classpath не умеет абсолютные пути к жарам<br />
;viy > <br />
:в смысле? нельзя ж абсолютные пути.<br />
;raorn > <br />
:у меня софтина в /usr/share/azureus/Azureus2.jar<br />
:или в %_javadir положить?<br />
:я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
:он находит Azureus2.jar<br />
<br />
;viy > <br />
:по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
:библиотека ищется в нескольких местах<br />
;raorn > <br />
:это я уже подсмотрел<br />
<br />
;viy > <br />
:проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
:у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
:что касается /usr/share/azureus/Azureus2.jar --<br />
:если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
:и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
:если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
;raorn > <br />
:это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
;viy > <br />
:юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
;raorn > <br />
:а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
:это в корне неверно?<br />
;viy > <br />
:да, неверно. граблей слишком много,<br />
;raorn > <br />
:я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
:но если говоришь надо - переделаю ;-)<br />
:мне ещё наверно зымбру собирать...<br />
;viy > <br />
:_javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
:('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
:а от явного указания и в /opt не скроешься.<br />
;raorn > <br />
:ну тогда ладно<br />
<br />
----<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=3026Java/JavaPackagingFAQ2008-08-25T22:33:02Z<p>SergeyLebedev: /* использование build-classpath из jpackage-utils */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
=====Обсуждение с Виталием=====<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
=====Обсуждение с Денисом=====<br />
;viy ><br />
:хотел бы попросить рассказать что неудобно<br />
;Mithraen > <br />
:Отсутствие префиксов типа java- или аналогичных<br />
;viy > <br />
:я уже говорил с lav@ <br />
:уже де-факто есть суффикс.<br />
;Mithraen > <br />
:Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
:Какой суффикс?<br />
;viy > <br />
:можно это выписать в полиси и к пакетам добавлять<br />
:jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
:jpackage repository P.Q/<br />
:jvm4.2==jpp1.7<br />
:jvm5.0==jpp5.0<br />
;Mithraen > <br />
:Гм.<br />
:Не уверен что такая подробность (версия в имени) нужна<br />
:А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
;viy > <br />
:можно будет написать робот такого типа:<br />
:vpupkin@ собрал пакет с суффиксом jvm4.2<br />
:но он собран 1.6.0 без -target 1.4<br />
:соответственно в 1.4\1.5 работать не будет.<br />
;Mithraen > <br />
:К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
:А с provides/requires при этом что делать?<br />
:Они-ж еще и по файлам пересекаться небось будут :(<br />
:Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
;viy > <br />
:нет. пакет должен быть собран для наименьшей возможной java.<br />
:т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
:пример junit (jvm4.2) и junit4 (jvm5.0)<br />
;Mithraen > <br />
:А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
;viy > <br />
:да.<br />
;Mithraen > <br />
:Их придется дублировать<br />
;viy > <br />
:лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
:а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
:автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
:в ней любой пакет можно будет по отдельности пересобрать. <br />
:Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
;Mithraen > <br />
:Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
:Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
;viy > <br />
:можно... <br />
:но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
:Не нравилось мне работать в <чужом дистрибутиве>.<br />
:Соответственно совместимость это полезная вещь, она денег стоит.<br />
:Смысла ее ломать из-за эстетических соображений я не вижу.<br />
:Это удар по разработчикам.<br />
;Mithraen > <br />
:Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
;viy > <br />
:бесполезная работа отнимает кучу время/денег тоже.<br />
;Mithraen > <br />
:А соображения эти не эстетического характера, а следствия элементарного удобства<br />
;Mithraen > <br />
:<tt>apt-cache search log | grep java</tt> -- это удобно<br />
;viy > <br />
:я же предложил суффикс :)<br />
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt><br />
;Mithraen > <br />
:Суффикс это точно такое же переименование<br />
:От необходимости делать provides на jpackage name не спасет<br />
;viy > <br />
:нет. он же в Release. на зависимости не влияет.<br />
;Mithraen ><br />
:А.. в release...<br />
:Ужас :)<br />
<br />
----<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
<pre><br />
Nov 14, 2007 <br />
Slava Dubrovskiy wrote: <br />
QA Team Download Robot пишет: <br />
> List of files which have been downloaded from the "devel" <br />
> incoming: maven2-2.0.4-alt1_10jpp1.7.src.rpm <br />
Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1) /usr/bin/mvn -- это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с -Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars<br />
<br />
2) для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3) Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
</pre><br />
----<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
<pre><br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
Nov 26, 2007 Slava Dubrovskiy wrote:<br />
> На выходных сделал подход к снаряду. <br />
> На текущей пакетной базе это <br />
> сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для<br />
> сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
<br />
Это достаточно скоро будет.<br />
> Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) <br />
> стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
> Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в <br />
> репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br />
наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
</pre><br />
----<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
<br />
<pre><br />
Jan 29, 2008 <br />
Alexey I. Froloff wrote: <br />
> $ sudo apt-get install jakarta-commons-cli log4j<br />
> The following NEW packages will be installed:<br />
> jpackage-utils log4j rpm-build-java<br />
</pre><br />
<br />
;raorn ><br />
:.o0( ох проклянут меня за азуреусовские зависимости... )<br />
;viy ><br />
:скорее за их отсутствие :)<br />
:если не будет зависимостей, средняя софтина на java <br />
:будет тянуть 40-200 Mb. 1 софтина как весь <br />
:дистрибутив. а так они разделяют зависимости...<br />
:не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
:[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
:Особенно смущают jpackage-utils и rpm-build-java.<br />
:jpackage-utils здесь потому, что в log4j есть приложения.<br />
:для их запуска рекомендуется строить classspath с помощью<br />
:скрипта build-classpath<br />
:а не указывать библиотеки явно.<br />
<br />
:Например<br />
:<tt>java -cp \<br />
:$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
:<class></tt><br />
<br />
:Кстати, это советую сделать для azaureus.<br />
<br />
:с rpm-build-java, боюсь, findreq наshellил.<br />
:в свободное время посмотрю.<br />
<br />
;raorn > <br />
:а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
;viy > <br />
:надо, но руки не доходят... увы, не многорукое Шиво...<br />
:там java-common Миши Забалуева был по сути попыткой написать <br />
:jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
;raorn > <br />
:ага, я видел. вкусные функции там<br />
:а дока есть? или экспортируемые переменные большой секрет?<br />
;viy > <br />
:дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
:документация разная есть, в процессе написания, сейчас брошу ссылки<br />
:[http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
:1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
:2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2982Java/JavaPackagingFAQ2008-08-24T20:34:22Z<p>SergeyLebedev: /* Советы по сборке пакетов с помощью maven2 */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
=====Обсуждение с Виталием=====<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
=====Обсуждение с Денисом=====<br />
;viy ><br />
:хотел бы попросить рассказать что неудобно<br />
;Mithraen > <br />
:Отсутствие префиксов типа java- или аналогичных<br />
;viy > <br />
:я уже говорил с lav@ <br />
:уже де-факто есть суффикс.<br />
;Mithraen > <br />
:Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
:Какой суффикс?<br />
;viy > <br />
:можно это выписать в полиси и к пакетам добавлять<br />
:jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
:jpackage repository P.Q/<br />
:jvm4.2==jpp1.7<br />
:jvm5.0==jpp5.0<br />
;Mithraen > <br />
:Гм.<br />
:Не уверен что такая подробность (версия в имени) нужна<br />
:А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
;viy > <br />
:можно будет написать робот такого типа:<br />
:vpupkin@ собрал пакет с суффиксом jvm4.2<br />
:но он собран 1.6.0 без -target 1.4<br />
:соответственно в 1.4\1.5 работать не будет.<br />
;Mithraen > <br />
:К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
:А с provides/requires при этом что делать?<br />
:Они-ж еще и по файлам пересекаться небось будут :(<br />
:Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
;viy > <br />
:нет. пакет должен быть собран для наименьшей возможной java.<br />
:т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
:пример junit (jvm4.2) и junit4 (jvm5.0)<br />
;Mithraen > <br />
:А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
;viy > <br />
:да.<br />
;Mithraen > <br />
:Их придется дублировать<br />
;viy > <br />
:лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
:а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
:автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
:в ней любой пакет можно будет по отдельности пересобрать. <br />
:Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
;Mithraen > <br />
:Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
:Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
;viy > <br />
:можно... <br />
:но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
:Не нравилось мне работать в <чужом дистрибутиве>.<br />
:Соответственно совместимость это полезная вещь, она денег стоит.<br />
:Смысла ее ломать из-за эстетических соображений я не вижу.<br />
:Это удар по разработчикам.<br />
;Mithraen > <br />
:Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
;viy > <br />
:бесполезная работа отнимает кучу время/денег тоже.<br />
;Mithraen > <br />
:А соображения эти не эстетического характера, а следствия элементарного удобства<br />
;Mithraen > <br />
:<tt>apt-cache search log | grep java</tt> -- это удобно<br />
;viy > <br />
:я же предложил суффикс :)<br />
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt><br />
;Mithraen > <br />
:Суффикс это точно такое же переименование<br />
:От необходимости делать provides на jpackage name не спасет<br />
;viy > <br />
:нет. он же в Release. на зависимости не влияет.<br />
;Mithraen ><br />
:А.. в release...<br />
:Ужас :)<br />
<br />
----<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
<pre><br />
Nov 14, 2007 <br />
Slava Dubrovskiy wrote: <br />
QA Team Download Robot пишет: <br />
> List of files which have been downloaded from the "devel" <br />
> incoming: maven2-2.0.4-alt1_10jpp1.7.src.rpm <br />
Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1) /usr/bin/mvn -- это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с -Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars<br />
<br />
2) для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3) Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
</pre><br />
----<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
<pre><br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
Nov 26, 2007 Slava Dubrovskiy wrote:<br />
> На выходных сделал подход к снаряду. <br />
> На текущей пакетной базе это <br />
> сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для<br />
> сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
<br />
Это достаточно скоро будет.<br />
> Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) <br />
> стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
> Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в <br />
> репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br />
наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
</pre><br />
----<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2981Java/JavaPackagingFAQ2008-08-24T20:31:55Z<p>SergeyLebedev: /* Советы по сборке пакетов с помощью maven2 */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
=====Обсуждение с Виталием=====<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
=====Обсуждение с Денисом=====<br />
;viy ><br />
:хотел бы попросить рассказать что неудобно<br />
;Mithraen > <br />
:Отсутствие префиксов типа java- или аналогичных<br />
;viy > <br />
:я уже говорил с lav@ <br />
:уже де-факто есть суффикс.<br />
;Mithraen > <br />
:Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
:Какой суффикс?<br />
;viy > <br />
:можно это выписать в полиси и к пакетам добавлять<br />
:jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
:jpackage repository P.Q/<br />
:jvm4.2==jpp1.7<br />
:jvm5.0==jpp5.0<br />
;Mithraen > <br />
:Гм.<br />
:Не уверен что такая подробность (версия в имени) нужна<br />
:А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
;viy > <br />
:можно будет написать робот такого типа:<br />
:vpupkin@ собрал пакет с суффиксом jvm4.2<br />
:но он собран 1.6.0 без -target 1.4<br />
:соответственно в 1.4\1.5 работать не будет.<br />
;Mithraen > <br />
:К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
:А с provides/requires при этом что делать?<br />
:Они-ж еще и по файлам пересекаться небось будут :(<br />
:Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
;viy > <br />
:нет. пакет должен быть собран для наименьшей возможной java.<br />
:т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
:пример junit (jvm4.2) и junit4 (jvm5.0)<br />
;Mithraen > <br />
:А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
;viy > <br />
:да.<br />
;Mithraen > <br />
:Их придется дублировать<br />
;viy > <br />
:лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
:а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
:автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
:в ней любой пакет можно будет по отдельности пересобрать. <br />
:Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
;Mithraen > <br />
:Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
:Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
;viy > <br />
:можно... <br />
:но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
:Не нравилось мне работать в <чужом дистрибутиве>.<br />
:Соответственно совместимость это полезная вещь, она денег стоит.<br />
:Смысла ее ломать из-за эстетических соображений я не вижу.<br />
:Это удар по разработчикам.<br />
;Mithraen > <br />
:Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
;viy > <br />
:бесполезная работа отнимает кучу время/денег тоже.<br />
;Mithraen > <br />
:А соображения эти не эстетического характера, а следствия элементарного удобства<br />
;Mithraen > <br />
:<tt>apt-cache search log | grep java</tt> -- это удобно<br />
;viy > <br />
:я же предложил суффикс :)<br />
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt><br />
;Mithraen > <br />
:Суффикс это точно такое же переименование<br />
:От необходимости делать provides на jpackage name не спасет<br />
;viy > <br />
:нет. он же в Release. на зависимости не влияет.<br />
;Mithraen ><br />
:А.. в release...<br />
:Ужас :)<br />
<br />
----<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
<pre><br />
Nov 14, 2007 <br />
Slava Dubrovskiy wrote: <br />
QA Team Download Robot пишет: <br />
> List of files which have been downloaded from the "devel" <br />
> incoming: maven2-2.0.4-alt1_10jpp1.7.src.rpm <br />
Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1) /usr/bin/mvn -- это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с -[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
2) для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3) Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
</pre><br />
----<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
<pre><br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
Nov 26, 2007 Slava Dubrovskiy wrote:<br />
> На выходных сделал подход к снаряду. <br />
> На текущей пакетной базе это <br />
> сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для<br />
> сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
<br />
Это достаточно скоро будет.<br />
> Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) <br />
> стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
> Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в <br />
> репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br />
наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
</pre><br />
----<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2980Java/JavaPackagingFAQ2008-08-24T20:25:28Z<p>SergeyLebedev: /* Советы по сборке пакетов с помощью maven2 */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
=====Обсуждение с Виталием=====<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
=====Обсуждение с Денисом=====<br />
;viy ><br />
:хотел бы попросить рассказать что неудобно<br />
;Mithraen > <br />
:Отсутствие префиксов типа java- или аналогичных<br />
;viy > <br />
:я уже говорил с lav@ <br />
:уже де-факто есть суффикс.<br />
;Mithraen > <br />
:Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
:Какой суффикс?<br />
;viy > <br />
:можно это выписать в полиси и к пакетам добавлять<br />
:jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
:jpackage repository P.Q/<br />
:jvm4.2==jpp1.7<br />
:jvm5.0==jpp5.0<br />
;Mithraen > <br />
:Гм.<br />
:Не уверен что такая подробность (версия в имени) нужна<br />
:А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
;viy > <br />
:можно будет написать робот такого типа:<br />
:vpupkin@ собрал пакет с суффиксом jvm4.2<br />
:но он собран 1.6.0 без -target 1.4<br />
:соответственно в 1.4\1.5 работать не будет.<br />
;Mithraen > <br />
:К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
:А с provides/requires при этом что делать?<br />
:Они-ж еще и по файлам пересекаться небось будут :(<br />
:Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
;viy > <br />
:нет. пакет должен быть собран для наименьшей возможной java.<br />
:т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
:пример junit (jvm4.2) и junit4 (jvm5.0)<br />
;Mithraen > <br />
:А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
;viy > <br />
:да.<br />
;Mithraen > <br />
:Их придется дублировать<br />
;viy > <br />
:лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
:а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
:автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
:в ней любой пакет можно будет по отдельности пересобрать. <br />
:Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
;Mithraen > <br />
:Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
:Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
;viy > <br />
:можно... <br />
:но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
:Не нравилось мне работать в <чужом дистрибутиве>.<br />
:Соответственно совместимость это полезная вещь, она денег стоит.<br />
:Смысла ее ломать из-за эстетических соображений я не вижу.<br />
:Это удар по разработчикам.<br />
;Mithraen > <br />
:Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
;viy > <br />
:бесполезная работа отнимает кучу время/денег тоже.<br />
;Mithraen > <br />
:А соображения эти не эстетического характера, а следствия элементарного удобства<br />
;Mithraen > <br />
:<tt>apt-cache search log | grep java</tt> -- это удобно<br />
;viy > <br />
:я же предложил суффикс :)<br />
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt><br />
;Mithraen > <br />
:Суффикс это точно такое же переименование<br />
:От необходимости делать provides на jpackage name не спасет<br />
;viy > <br />
:нет. он же в Release. на зависимости не влияет.<br />
;Mithraen ><br />
:А.. в release...<br />
:Ужас :)<br />
<br />
----<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
<pre><br />
Nov 14, 2007 <br />
Slava Dubrovskiy wrote: <br />
QA Team Download Robot пишет: <br />
> List of files which have been downloaded from the "devel" <br />
> incoming: maven2-2.0.4-alt1_10jpp1.7.src.rpm <br />
Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1) <tt>/usr/bin/mvn</tt> -- это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать <tt>/usr/bin/mvn-jpp</tt>,<br />
который вызывает mvn с -[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
2) для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3) Свежие примеры сборки с помощью maven2<br />
<tt>plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm</tt><br />
<tt>plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm</tt><br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль <tt>maven2-plugins-2.0.4-alt1</tt><br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
</pre><br />
----<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
Это достаточно скоро будет.<br />
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
&gt; Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в &gt; репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2979Java/JavaPackagingFAQ2008-08-24T20:24:53Z<p>SergeyLebedev: /* Советы по сборке пакетов с помощью maven2 */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
=====Обсуждение с Виталием=====<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
=====Обсуждение с Денисом=====<br />
;viy ><br />
:хотел бы попросить рассказать что неудобно<br />
;Mithraen > <br />
:Отсутствие префиксов типа java- или аналогичных<br />
;viy > <br />
:я уже говорил с lav@ <br />
:уже де-факто есть суффикс.<br />
;Mithraen > <br />
:Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
:Какой суффикс?<br />
;viy > <br />
:можно это выписать в полиси и к пакетам добавлять<br />
:jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
:jpackage repository P.Q/<br />
:jvm4.2==jpp1.7<br />
:jvm5.0==jpp5.0<br />
;Mithraen > <br />
:Гм.<br />
:Не уверен что такая подробность (версия в имени) нужна<br />
:А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
;viy > <br />
:можно будет написать робот такого типа:<br />
:vpupkin@ собрал пакет с суффиксом jvm4.2<br />
:но он собран 1.6.0 без -target 1.4<br />
:соответственно в 1.4\1.5 работать не будет.<br />
;Mithraen > <br />
:К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
:А с provides/requires при этом что делать?<br />
:Они-ж еще и по файлам пересекаться небось будут :(<br />
:Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
;viy > <br />
:нет. пакет должен быть собран для наименьшей возможной java.<br />
:т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
:пример junit (jvm4.2) и junit4 (jvm5.0)<br />
;Mithraen > <br />
:А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
;viy > <br />
:да.<br />
;Mithraen > <br />
:Их придется дублировать<br />
;viy > <br />
:лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
:а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
:автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
:в ней любой пакет можно будет по отдельности пересобрать. <br />
:Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
;Mithraen > <br />
:Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
:Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
;viy > <br />
:можно... <br />
:но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
:Не нравилось мне работать в <чужом дистрибутиве>.<br />
:Соответственно совместимость это полезная вещь, она денег стоит.<br />
:Смысла ее ломать из-за эстетических соображений я не вижу.<br />
:Это удар по разработчикам.<br />
;Mithraen > <br />
:Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
;viy > <br />
:бесполезная работа отнимает кучу время/денег тоже.<br />
;Mithraen > <br />
:А соображения эти не эстетического характера, а следствия элементарного удобства<br />
;Mithraen > <br />
:<tt>apt-cache search log | grep java</tt> -- это удобно<br />
;viy > <br />
:я же предложил суффикс :)<br />
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt><br />
;Mithraen > <br />
:Суффикс это точно такое же переименование<br />
:От необходимости делать provides на jpackage name не спасет<br />
;viy > <br />
:нет. он же в Release. на зависимости не влияет.<br />
;Mithraen ><br />
:А.. в release...<br />
:Ужас :)<br />
<br />
----<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
<pre><br />
Nov 14, 2007 <br />
Slava Dubrovskiy wrote: <br />
QA Team Download Robot пишет: <br />
> List of files which have been downloaded from the "devel" <br />
> incoming: maven2-2.0.4-alt1_10jpp1.7.src.rpm <br />
Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1) <tt>/usr/bin/mvn</tt> -- это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать <tt>/usr/bin/mvn-jpp</tt>,<br />
который вызывает mvn с -[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
2) для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3) Свежие примеры сборки с помощью maven2<br />
<tt>plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm</tt><br />
<tt>plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm</tt><br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
</pre><br />
:4) костыль <tt>maven2-plugins-2.0.4-alt1</tt><br />
:вытягивает maven2 вместе со всеми plugins.<br />
:Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
<br />
----<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
Это достаточно скоро будет.<br />
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
&gt; Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в &gt; репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2621Java/JavaPackagingFAQ2008-08-19T14:05:52Z<p>SergeyLebedev: /* Советы по сборке пакетов с помощью maven2 */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
=====Обсуждение с Виталием=====<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
=====Обсуждение с Денисом=====<br />
;viy ><br />
:хотел бы попросить рассказать что неудобно<br />
;Mithraen > <br />
:Отсутствие префиксов типа java- или аналогичных<br />
;viy > <br />
:я уже говорил с lav@ <br />
:уже де-факто есть суффикс.<br />
;Mithraen > <br />
:Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
:Какой суффикс?<br />
;viy > <br />
:можно это выписать в полиси и к пакетам добавлять<br />
:jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
:jpackage repository P.Q/<br />
:jvm4.2==jpp1.7<br />
:jvm5.0==jpp5.0<br />
;Mithraen > <br />
:Гм.<br />
:Не уверен что такая подробность (версия в имени) нужна<br />
:А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
;viy > <br />
:можно будет написать робот такого типа:<br />
:vpupkin@ собрал пакет с суффиксом jvm4.2<br />
:но он собран 1.6.0 без -target 1.4<br />
:соответственно в 1.4\1.5 работать не будет.<br />
;Mithraen > <br />
:К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
:А с provides/requires при этом что делать?<br />
:Они-ж еще и по файлам пересекаться небось будут :(<br />
:Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
;viy > <br />
:нет. пакет должен быть собран для наименьшей возможной java.<br />
:т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
:пример junit (jvm4.2) и junit4 (jvm5.0)<br />
;Mithraen > <br />
:А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
;viy > <br />
:да.<br />
;Mithraen > <br />
:Их придется дублировать<br />
;viy > <br />
:лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
:а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
:автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
:в ней любой пакет можно будет по отдельности пересобрать. <br />
:Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
;Mithraen > <br />
:Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
:Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
;viy > <br />
:можно... <br />
:но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
:Не нравилось мне работать в <чужом дистрибутиве>.<br />
:Соответственно совместимость это полезная вещь, она денег стоит.<br />
:Смысла ее ломать из-за эстетических соображений я не вижу.<br />
:Это удар по разработчикам.<br />
;Mithraen > <br />
:Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
;viy > <br />
:бесполезная работа отнимает кучу время/денег тоже.<br />
;Mithraen > <br />
:А соображения эти не эстетического характера, а следствия элементарного удобства<br />
;Mithraen > <br />
:<tt>apt-cache search log | grep java</tt> -- это удобно<br />
;viy > <br />
:я же предложил суффикс :)<br />
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt><br />
;Mithraen > <br />
:Суффикс это точно такое же переименование<br />
:От необходимости делать provides на jpackage name не спасет<br />
;viy > <br />
:нет. он же в Release. на зависимости не влияет.<br />
;Mithraen ><br />
:А.. в release...<br />
:Ужас :)<br />
<br />
----<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
Nov 14, 2007 <br />
; Slava Dubrovskiy wrote: <br />
:QA Team Download Robot пишет: <br />
:> List of files which have been downloaded from the "devel" <br />
:> incoming: maven2-2.0.4-alt1_10jpp1.7.src.rpm <br />
:Ура! Заждались уже.<br />
<br />
:В связи с этим несколько hints.<br />
:1) <tt>/usr/bin/mvn</tt> -- это обычный "онлайновый" maven2.<br />
:Для сборки rpm пакетов надо использовать <tt>/usr/bin/mvn-jpp</tt>,<br />
:который вызывает mvn с -[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
:2) для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
:В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
:"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
:но я надеюсь быстро пересобрать такие пакеты, так что<br />
:относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
:репозиторий pom'ов будет.<br />
<br />
:3) Свежие примеры сборки с помощью maven2<br />
:<tt>plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm</tt><br />
:<tt>plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm</tt><br />
:уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
:будет опубликован maven2.<br />
<br />
:4) костыль <tt>maven2-plugins-2.0.4-alt1</tt><br />
:вытягивает maven2 вместе со всеми plugins.<br />
:Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
<br />
----<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
Это достаточно скоро будет.<br />
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
&gt; Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в &gt; репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2620Java/JavaPackagingFAQ2008-08-19T14:05:14Z<p>SergeyLebedev: /* Советы по сборке пакетов с помощью maven2 */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
=====Обсуждение с Виталием=====<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
=====Обсуждение с Денисом=====<br />
;viy ><br />
:хотел бы попросить рассказать что неудобно<br />
;Mithraen > <br />
:Отсутствие префиксов типа java- или аналогичных<br />
;viy > <br />
:я уже говорил с lav@ <br />
:уже де-факто есть суффикс.<br />
;Mithraen > <br />
:Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
:Какой суффикс?<br />
;viy > <br />
:можно это выписать в полиси и к пакетам добавлять<br />
:jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
:jpackage repository P.Q/<br />
:jvm4.2==jpp1.7<br />
:jvm5.0==jpp5.0<br />
;Mithraen > <br />
:Гм.<br />
:Не уверен что такая подробность (версия в имени) нужна<br />
:А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
;viy > <br />
:можно будет написать робот такого типа:<br />
:vpupkin@ собрал пакет с суффиксом jvm4.2<br />
:но он собран 1.6.0 без -target 1.4<br />
:соответственно в 1.4\1.5 работать не будет.<br />
;Mithraen > <br />
:К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
:А с provides/requires при этом что делать?<br />
:Они-ж еще и по файлам пересекаться небось будут :(<br />
:Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
;viy > <br />
:нет. пакет должен быть собран для наименьшей возможной java.<br />
:т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
:пример junit (jvm4.2) и junit4 (jvm5.0)<br />
;Mithraen > <br />
:А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
;viy > <br />
:да.<br />
;Mithraen > <br />
:Их придется дублировать<br />
;viy > <br />
:лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
:а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
:автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
:в ней любой пакет можно будет по отдельности пересобрать. <br />
:Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
;Mithraen > <br />
:Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
:Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
;viy > <br />
:можно... <br />
:но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
:Не нравилось мне работать в <чужом дистрибутиве>.<br />
:Соответственно совместимость это полезная вещь, она денег стоит.<br />
:Смысла ее ломать из-за эстетических соображений я не вижу.<br />
:Это удар по разработчикам.<br />
;Mithraen > <br />
:Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
;viy > <br />
:бесполезная работа отнимает кучу время/денег тоже.<br />
;Mithraen > <br />
:А соображения эти не эстетического характера, а следствия элементарного удобства<br />
;Mithraen > <br />
:<tt>apt-cache search log | grep java</tt> -- это удобно<br />
;viy > <br />
:я же предложил суффикс :)<br />
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt><br />
;Mithraen > <br />
:Суффикс это точно такое же переименование<br />
:От необходимости делать provides на jpackage name не спасет<br />
;viy > <br />
:нет. он же в Release. на зависимости не влияет.<br />
;Mithraen ><br />
:А.. в release...<br />
:Ужас :)<br />
<br />
----<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
Nov 14, 2007 <br />
; Slava Dubrovskiy wrote: <br />
:QA Team Download Robot пишет: <br />
:> List of files which have been downloaded from the "devel" <br />
:> incoming: maven2-2.0.4-alt1_10jpp1.7.src.rpm <br />
:Ура! Заждались уже.<br />
<br />
:В связи с этим несколько hints.<br />
:1)<br />
:<tt>/usr/bin/mvn</tt> -- это обычный "онлайновый" maven2.<br />
:Для сборки rpm пакетов надо использовать <tt>/usr/bin/mvn-jpp</tt>,<br />
:который вызывает mvn с -[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
:2)<br />
:для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
:В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
:"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
:но я надеюсь быстро пересобрать такие пакеты, так что<br />
:относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
:репозиторий pom'ов будет.<br />
<br />
:3)<br />
:Свежие примеры сборки с помощью maven2<br />
:<tt>plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm</tt><br />
:<tt>plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm</tt><br />
:уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
:будет опубликован maven2.<br />
<br />
:4) костыль<br />
:<tt>maven2-plugins-2.0.4-alt1</tt><br />
:вытягивает maven2 вместе со всеми plugins.<br />
:Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
<br />
----<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
Это достаточно скоро будет.<br />
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
&gt; Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в &gt; репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2619Java/JavaPackagingFAQ2008-08-19T13:43:31Z<p>SergeyLebedev: /* Советы по сборке пакетов с помощью maven2 */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
=====Обсуждение с Виталием=====<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
=====Обсуждение с Денисом=====<br />
;viy ><br />
:хотел бы попросить рассказать что неудобно<br />
;Mithraen > <br />
:Отсутствие префиксов типа java- или аналогичных<br />
;viy > <br />
:я уже говорил с lav@ <br />
:уже де-факто есть суффикс.<br />
;Mithraen > <br />
:Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
:Какой суффикс?<br />
;viy > <br />
:можно это выписать в полиси и к пакетам добавлять<br />
:jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
:jpackage repository P.Q/<br />
:jvm4.2==jpp1.7<br />
:jvm5.0==jpp5.0<br />
;Mithraen > <br />
:Гм.<br />
:Не уверен что такая подробность (версия в имени) нужна<br />
:А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
;viy > <br />
:можно будет написать робот такого типа:<br />
:vpupkin@ собрал пакет с суффиксом jvm4.2<br />
:но он собран 1.6.0 без -target 1.4<br />
:соответственно в 1.4\1.5 работать не будет.<br />
;Mithraen > <br />
:К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
:А с provides/requires при этом что делать?<br />
:Они-ж еще и по файлам пересекаться небось будут :(<br />
:Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
;viy > <br />
:нет. пакет должен быть собран для наименьшей возможной java.<br />
:т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
:пример junit (jvm4.2) и junit4 (jvm5.0)<br />
;Mithraen > <br />
:А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
;viy > <br />
:да.<br />
;Mithraen > <br />
:Их придется дублировать<br />
;viy > <br />
:лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
:а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
:автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
:в ней любой пакет можно будет по отдельности пересобрать. <br />
:Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
;Mithraen > <br />
:Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
:Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
;viy > <br />
:можно... <br />
:но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
:Не нравилось мне работать в <чужом дистрибутиве>.<br />
:Соответственно совместимость это полезная вещь, она денег стоит.<br />
:Смысла ее ломать из-за эстетических соображений я не вижу.<br />
:Это удар по разработчикам.<br />
;Mithraen > <br />
:Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
;viy > <br />
:бесполезная работа отнимает кучу время/денег тоже.<br />
;Mithraen > <br />
:А соображения эти не эстетического характера, а следствия элементарного удобства<br />
;Mithraen > <br />
:<tt>apt-cache search log | grep java</tt> -- это удобно<br />
;viy > <br />
:я же предложил суффикс :)<br />
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt><br />
;Mithraen > <br />
:Суффикс это точно такое же переименование<br />
:От необходимости делать provides на jpackage name не спасет<br />
;viy > <br />
:нет. он же в Release. на зависимости не влияет.<br />
;Mithraen ><br />
:А.. в release...<br />
:Ужас :)<br />
<br />
----<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
On Wed, Nov 14, 2007 at 08:57:29AM +0200, Slava Dubrovskiy wrote: &gt; QA Team Download Robot пишет: &gt; > List of files which have been downloaded from the "devel" incoming: &gt; > maven2-2.0.4-alt1_10jpp1.7.src.rpm &gt; Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1)<br />
/usr/bin/mvn <br/>это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с<br />
-[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
2)<br />
для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3)<br />
Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль<br />
maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
<br />
----<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
Это достаточно скоро будет.<br />
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
&gt; Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в &gt; репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2618Java/JavaPackagingFAQ2008-08-19T13:42:41Z<p>SergeyLebedev: /* Обсуждение с Денисом */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
=====Обсуждение с Виталием=====<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
=====Обсуждение с Денисом=====<br />
;viy ><br />
:хотел бы попросить рассказать что неудобно<br />
;Mithraen > <br />
:Отсутствие префиксов типа java- или аналогичных<br />
;viy > <br />
:я уже говорил с lav@ <br />
:уже де-факто есть суффикс.<br />
;Mithraen > <br />
:Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
:Какой суффикс?<br />
;viy > <br />
:можно это выписать в полиси и к пакетам добавлять<br />
:jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
:jpackage repository P.Q/<br />
:jvm4.2==jpp1.7<br />
:jvm5.0==jpp5.0<br />
;Mithraen > <br />
:Гм.<br />
:Не уверен что такая подробность (версия в имени) нужна<br />
:А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
;viy > <br />
:можно будет написать робот такого типа:<br />
:vpupkin@ собрал пакет с суффиксом jvm4.2<br />
:но он собран 1.6.0 без -target 1.4<br />
:соответственно в 1.4\1.5 работать не будет.<br />
;Mithraen > <br />
:К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
:А с provides/requires при этом что делать?<br />
:Они-ж еще и по файлам пересекаться небось будут :(<br />
:Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
;viy > <br />
:нет. пакет должен быть собран для наименьшей возможной java.<br />
:т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
:пример junit (jvm4.2) и junit4 (jvm5.0)<br />
;Mithraen > <br />
:А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
;viy > <br />
:да.<br />
;Mithraen > <br />
:Их придется дублировать<br />
;viy > <br />
:лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
:а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
:автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
:в ней любой пакет можно будет по отдельности пересобрать. <br />
:Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
;Mithraen > <br />
:Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
:Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
;viy > <br />
:можно... <br />
:но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
:Не нравилось мне работать в <чужом дистрибутиве>.<br />
:Соответственно совместимость это полезная вещь, она денег стоит.<br />
:Смысла ее ломать из-за эстетических соображений я не вижу.<br />
:Это удар по разработчикам.<br />
;Mithraen > <br />
:Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
;viy > <br />
:бесполезная работа отнимает кучу время/денег тоже.<br />
;Mithraen > <br />
:А соображения эти не эстетического характера, а следствия элементарного удобства<br />
;Mithraen > <br />
:<tt>apt-cache search log | grep java</tt> -- это удобно<br />
;viy > <br />
:я же предложил суффикс :)<br />
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt><br />
;Mithraen > <br />
:Суффикс это точно такое же переименование<br />
:От необходимости делать provides на jpackage name не спасет<br />
;viy > <br />
:нет. он же в Release. на зависимости не влияет.<br />
;Mithraen ><br />
:А.. в release...<br />
:Ужас :)<br />
<br />
----<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
On Wed, Nov 14, 2007 at 08:57:29AM +0200, Slava Dubrovskiy wrote: &gt; QA Team Download Robot пишет: &gt; > List of files which have been downloaded from the "devel" incoming: &gt; > maven2-2.0.4-alt1_10jpp1.7.src.rpm &gt; Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1)<br />
/usr/bin/mvn <br/>это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с<br />
-[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
2)<br />
для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3)<br />
Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль<br />
maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
Это достаточно скоро будет.<br />
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
&gt; Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в &gt; репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2617Java/JavaPackagingFAQ2008-08-19T13:42:08Z<p>SergeyLebedev: /* Переименовывать ли пакеты Java? */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
=====Обсуждение с Виталием=====<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
=====Обсуждение с Денисом=====<br />
;viy ><br />
:хотел бы попросить рассказать что неудобно<br />
;Mithraen > <br />
:Отсутствие префиксов типа java- или аналогичных<br />
;viy > <br />
:я уже говорил с lav@ <br />
:уже де-факто есть суффикс.<br />
;Mithraen > <br />
:Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
:Какой суффикс?<br />
;viy > <br />
:можно это выписать в полиси и к пакетам добавлять<br />
:jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
:jpackage repository P.Q/<br />
:jvm4.2==jpp1.7<br />
:jvm5.0==jpp5.0<br />
;Mithraen > <br />
:Гм.<br />
:Не уверен что такая подробность (версия в имени) нужна<br />
:А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
;viy > <br />
:можно будет написать робот такого типа:<br />
:vpupkin@ собрал пакет с суффиксом jvm4.2<br />
:но он собран 1.6.0 без -target 1.4<br />
:соответственно в 1.4\1.5 работать не будет.<br />
;Mithraen > <br />
:К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
:А с provides/requires при этом что делать?<br />
:Они-ж еще и по файлам пересекаться небось будут :(<br />
:Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
;viy > <br />
:нет. пакет должен быть собран для наименьшей возможной java.<br />
:т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
:пример junit (jvm4.2) и junit4 (jvm5.0)<br />
;Mithraen > <br />
:А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
;viy > <br />
:да.<br />
;Mithraen > <br />
:Их придется дублировать<br />
;viy > <br />
:лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
:а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
:автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
:в ней любой пакет можно будет по отдельности пересобрать. <br />
:Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
;Mithraen > <br />
:Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
:Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
;viy > <br />
:можно... <br />
:но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
:Не нравилось мне работать в <чужом дистрибутиве>.<br />
:Соответственно совместимость это полезная вещь, она денег стоит.<br />
:Смысла ее ломать из-за эстетических соображений я не вижу.<br />
:Это удар по разработчикам.<br />
;Mithraen > <br />
:Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
;viy > <br />
:бесполезная работа отнимает кучу время/денег тоже.<br />
;Mithraen > <br />
:А соображения эти не эстетического характера, а следствия элементарного удобства<br />
;Mithraen > <br />
:<tt>apt-cache search log | grep java</tt> -- это удобно<br />
;viy > <br />
:я же предложил суффикс :)<br />
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt><br />
;Mithraen > <br />
:Суффикс это точно такое же переименование<br />
:От необходимости делать provides на jpackage name не спасет<br />
;viy > <br />
:нет. он же в Release. на зависимости не влияет.<br />
;Mithraen ><br />
:А.. в release...<br />
:Ужас :)<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
On Wed, Nov 14, 2007 at 08:57:29AM +0200, Slava Dubrovskiy wrote: &gt; QA Team Download Robot пишет: &gt; > List of files which have been downloaded from the "devel" incoming: &gt; > maven2-2.0.4-alt1_10jpp1.7.src.rpm &gt; Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1)<br />
/usr/bin/mvn <br/>это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с<br />
-[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
2)<br />
для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3)<br />
Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль<br />
maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
Это достаточно скоро будет.<br />
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
&gt; Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в &gt; репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2615Java/JavaPackagingFAQ2008-08-19T13:34:56Z<p>SergeyLebedev: /* Переименовывать ли пакеты Java? */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
'''Обсуждение с Виталием'''<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
;viy > <br />
:я хочу создать полную среду разработки.<br />
:в которой нет необходимости ставить сторонние пакеты.<br />
;Lav ><br />
:То есть в FC и в Novell вот так же накиданы пакеты?<br />
;viy > <br />
:да.<br />
;Lav > <br />
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt><br />
:или<br />
:<tt>Requires: isorelax</tt><br />
:Это же просто вопрос принятого соглашения.<br />
;viy > <br />
:оно не бесплатно.<br />
;Lav > <br />
:Дело в том, что после создания полной среды разработки пакетов будет столько, <br />
:что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
;viy > <br />
:нет. я же руками ничего не делаю.<br />
:отшлифовываю робота для проведения массовых операций.<br />
:с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
:у меня спеки правит робот.<br />
;Lav > <br />
:Таким образом, есть надежда, что со временем робота можно переучить?<br />
;viy > <br />
:мне важно 2) -- чтобы всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
;Lav > <br />
:Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
;viy > <br />
:робот работает согласно jpackage.org policy.<br />
:раньше у нас не было совместимости с jpackage.<br />
;Lav > <br />
:В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
;viy > <br />
:ok.<br />
:для java библиотек вменяемые спеки и не нужны.<br />
:не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
:Эта ситуация когда отсутствует сборочная среда.<br />
:когда она уже есть, тогда можно уже собирать приложения.<br />
:они и требуют ручной работы.<br />
:от библиотек требуется. чтобы они были.<br />
;Lav > <br />
:По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
;viy ><br />
:1) несовместимостей много<br />
:2) нельзя будет проверки зависимостей внедрить и т. д.<br />
:у меня спеки заменяет набор хуков для робота.<br />
:в простых случаях их нет. в запущенных имеем<br />
:... <br />
:<tt>: $jpp->disable_package('plugin-jalopy');</tt><br />
:<tt>< и другие примеры команд роботу></tt><br />
:...<br />
<br />
----<br />
<br />
'''Обсуждение с Денисом'''<br />
10:55:12] <viy> хотел бы попросить рассказать что неудобно<br />
[10:55:28] <Mithraen> Отсутствие префиксов типа java- или аналогичных<br />
[10:56:07] <viy> я уже говорил с lav@ <br />
уже де-факто есть суффикс.<br />
[10:56:10] <Mithraen> Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
[10:56:22] <Mithraen> Какой суффикс?<br />
[10:58:07] <viy> можно это выписать в полиси и к пакетам добавлять<br />
jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
jpackage repository P.Q/<br />
jvm4.2==jpp1.7<br />
jvm5.0==jpp5.0<br />
[10:59:16] <Mithraen> Гм.<br />
[10:59:28] <Mithraen> Не уверен что такая подробность (версия в имени) нужна<br />
[10:59:46] <Mithraen> А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
[11:01:23] <viy> можно будет написать робот такого типа:<br />
vpupkin@ собрал пакет с суффиксом jvm4.2<br />
но он собран 1.6.0 без -target 1.4<br />
соответственно в 1.4\1.5 работать не будет.<br />
[11:01:28] <Mithraen> К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
[11:01:50] <Mithraen> А с provides/requires при этом что делать?<br />
[11:02:00] <Mithraen> Они-ж еще и по файлам пересекаться небось будут :(<br />
[11:02:27] <Mithraen> Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
[11:02:36] <viy> нет. пакет должен быть собран для наименьшей возможной java.<br />
[11:03:16] <viy> т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
[11:03:50] <viy> пример junit (jvm4.2) и junit4 (jvm5.0)<br />
[11:03:57] <Mithraen> А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
[11:04:08] <viy> да.<br />
[11:04:30] <Mithraen> Их придется дублировать<br />
[11:05:07] <viy> лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
[11:05:52] <viy> а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
[11:09:42] <viy> автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
в ней любой пакет можно будет по отдельности пересобрать. Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
[11:22:38] <Mithraen> Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
[11:22:54] <Mithraen> Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
[11:26:22] <viy> можно... <br />
но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
Не нравилось мне работать в <чужом дистрибутиве>.<br />
Соответственно совместимость это полезная вещь, она денег стоит.<br />
Смысла ее ломать из-за эстетических соображений я не вижу.<br />
Это удар по разработчикам.<br />
[11:27:01] <Mithraen> Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
[11:27:36] <viy> бесполезная работа отнимает кучу время/денег тоже.<br />
[11:27:39] <Mithraen> А соображения эти не эстетического характера, а следствия элементарного удобства<br />
[11:28:13] <Mithraen> apt-cache search log | grep java -- это удобно<br />
[11:28:22] <viy> я же предложил суффикс :)<br />
pcregrep '(jvm|jpp)\d\.\d$'<br />
[11:28:34] <Mithraen> Суффикс это точно такое же переименование<br />
[11:29:02] <Mithraen> От необходимости делать provides на jpackage name не спасет<br />
[11:29:04] <viy> нет. он же в Release. на зависимости не влияет.<br />
[11:29:21] <Mithraen> А.. в release...<br />
[11:29:23] <Mithraen> Ужас :)<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
On Wed, Nov 14, 2007 at 08:57:29AM +0200, Slava Dubrovskiy wrote: &gt; QA Team Download Robot пишет: &gt; > List of files which have been downloaded from the "devel" incoming: &gt; > maven2-2.0.4-alt1_10jpp1.7.src.rpm &gt; Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1)<br />
/usr/bin/mvn <br/>это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с<br />
-[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
2)<br />
для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3)<br />
Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль<br />
maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
Это достаточно скоро будет.<br />
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
&gt; Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в &gt; репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2305Java/JavaPackagingFAQ2008-08-15T18:40:09Z<p>SergeyLebedev: /* Переименовывать ли пакеты Java? */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
'''Обсуждение с Виталием'''<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
:от fedora до novell)<br />
:это мне важно.<br />
:3) очень многих пакетов в Сизифе еще нет.<br />
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt><br />
;Lav > <br />
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)<br />
;viy > <br />
:но заботятся о названии pc - файла.<br />
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?<br />
;Lav > <br />
:До окончания каких работ?<br />
[00:25:46] <viy> я хочу создать полную среду разработки.<br />
в которой нет необходимости ставить сторонние пакеты.<br />
[00:25:48] <Lav>То есть в FC и в Novell вот так же накиданы пакеты?<br />
[00:27:22] <viy> да.<br />
[00:27:48] <Lav> И я всё же не понимаю, какая разница - указывать в спеке Requires: java-isorelax<br />
или<br />
Requires: isorelax<br />
Это же просто вопрос принятого соглашения.<br />
[00:28:06] <viy> оно не бесплатно.<br />
[00:28:10] <Lav> Дело в том, что после создания полной среды разработки пакетов будет столько, что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
[00:29:31] <viy> нет. я же руками ничего не делаю.<br />
отшлифовываю робота для проведения массовых операций.<br />
с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
у меня спеки правит робот.<br />
[00:30:09] <Lav> Таким образом, есть надежда, что со временем робота можно переучить?<br />
[00:30:39] <viy> мне важно 2) -- чтобы всегда оставалась возможность<br />
иметь совместимость по srpm<br />
(т. е. чтобы я мог разрабатывать в ALT <br />
java пакеты, которые после нативной пересборки работают <br />
от fedora до novell)<br />
[00:30:28] <Lav> Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
[00:30:58] <viy> робот работает согласно jpackage.org policy.<br />
[00:31:38] <viy> раньше у нас не было совместимости с jpackage.<br />
[00:33:05] <Lav> В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
[00:35:42] <viy> ok.<br />
для java библиотек вменяемые спеки и не нужны.<br />
не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
Эта ситуация когда отсутствует сборочная среда.<br />
когда она уже есть, тогда можно уже собирать приложения.<br />
они и требуют ручной работы.<br />
от библиотек требуется. чтобы они были.<br />
[00:36:09] <Lav> По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
[00:37:01] <viy> 1) несовместимостей много<br />
2) нельзя будет проверки зависимостей внедрить и т. д.<br />
у меня спеки заменяет набор хуков для робота.<br />
в простых случаях их нет. в запущенных имеем<br />
... <br />
: $jpp->disable_package('plugin-jalopy');<br />
< и другие примеры команд роботу><br />
...<br />
===== Обсуждение с Денисом =====<br />
10:55:12] <viy> хотел бы попросить рассказать что неудобно<br />
[10:55:28] <Mithraen> Отсутствие префиксов типа java- или аналогичных<br />
[10:56:07] <viy> я уже говорил с lav@ <br />
уже де-факто есть суффикс.<br />
[10:56:10] <Mithraen> Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
[10:56:22] <Mithraen> Какой суффикс?<br />
[10:58:07] <viy> можно это выписать в полиси и к пакетам добавлять<br />
jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
jpackage repository P.Q/<br />
jvm4.2==jpp1.7<br />
jvm5.0==jpp5.0<br />
[10:59:16] <Mithraen> Гм.<br />
[10:59:28] <Mithraen> Не уверен что такая подробность (версия в имени) нужна<br />
[10:59:46] <Mithraen> А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
[11:01:23] <viy> можно будет написать робот такого типа:<br />
vpupkin@ собрал пакет с суффиксом jvm4.2<br />
но он собран 1.6.0 без -target 1.4<br />
соответственно в 1.4\1.5 работать не будет.<br />
[11:01:28] <Mithraen> К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
[11:01:50] <Mithraen> А с provides/requires при этом что делать?<br />
[11:02:00] <Mithraen> Они-ж еще и по файлам пересекаться небось будут :(<br />
[11:02:27] <Mithraen> Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
[11:02:36] <viy> нет. пакет должен быть собран для наименьшей возможной java.<br />
[11:03:16] <viy> т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
[11:03:50] <viy> пример junit (jvm4.2) и junit4 (jvm5.0)<br />
[11:03:57] <Mithraen> А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
[11:04:08] <viy> да.<br />
[11:04:30] <Mithraen> Их придется дублировать<br />
[11:05:07] <viy> лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
[11:05:52] <viy> а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
[11:09:42] <viy> автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
в ней любой пакет можно будет по отдельности пересобрать. Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
[11:22:38] <Mithraen> Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
[11:22:54] <Mithraen> Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
[11:26:22] <viy> можно... <br />
но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
Не нравилось мне работать в <чужом дистрибутиве>.<br />
Соответственно совместимость это полезная вещь, она денег стоит.<br />
Смысла ее ломать из-за эстетических соображений я не вижу.<br />
Это удар по разработчикам.<br />
[11:27:01] <Mithraen> Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
[11:27:36] <viy> бесполезная работа отнимает кучу время/денег тоже.<br />
[11:27:39] <Mithraen> А соображения эти не эстетического характера, а следствия элементарного удобства<br />
[11:28:13] <Mithraen> apt-cache search log | grep java -- это удобно<br />
[11:28:22] <viy> я же предложил суффикс :)<br />
pcregrep '(jvm|jpp)\d\.\d$'<br />
[11:28:34] <Mithraen> Суффикс это точно такое же переименование<br />
[11:29:02] <Mithraen> От необходимости делать provides на jpackage name не спасет<br />
[11:29:04] <viy> нет. он же в Release. на зависимости не влияет.<br />
[11:29:21] <Mithraen> А.. в release...<br />
[11:29:23] <Mithraen> Ужас :)<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
On Wed, Nov 14, 2007 at 08:57:29AM +0200, Slava Dubrovskiy wrote: &gt; QA Team Download Robot пишет: &gt; > List of files which have been downloaded from the "devel" incoming: &gt; > maven2-2.0.4-alt1_10jpp1.7.src.rpm &gt; Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1)<br />
/usr/bin/mvn <br/>это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с<br />
-[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
2)<br />
для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3)<br />
Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль<br />
maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
Это достаточно скоро будет.<br />
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
&gt; Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в &gt; репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2304Java/JavaPackagingFAQ2008-08-15T18:37:12Z<p>SergeyLebedev: /* Переименовывать ли пакеты Java? */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
'''Обсуждение с Виталием'''<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt><br />
<br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
<br />
;viy > <br />
:причина - совместимость.<br />
:например, <tt>libz.so</tt> можно было бы назвать<br />
:<tt>libz-pureС-altcore.so</tt><br />
:и патчить все <tt>configure.am</tt>, чтобы линковаться<br />
:<tt>-lz-pureС-altcore</tt><br />
:Но так не делают.<br />
<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
<br />
;viy > <br />
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt><br />
<br />
;Lav > <br />
:Я, если честно, в java мало понимаю.<br />
:Это пример запуска программы?<br />
<br />
;viy ><br />
:для библиотек есть 1) фиксированный путь<br />
:<tt>/lib + /usr/lib </tt><br />
:2) канонические имена (libz.so.*)<br />
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
<br />
;Lav ><br />
:А для java какую роль пакет играет?<br />
<br />
;viy > <br />
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и <br />
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt><br />
:с java это не пройдет они просто не найдут друг друга <br />
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt><br />
<br />
;Lav > <br />
:Нет, я никак не пойму связи названия пакета и classpath<br />
<br />
;viy ><br />
:Это другая тема.<br />
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
:я хочу, чтобы до окончания работ <br />
:1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
:2) всегда оставалась возможность<br />
:иметь совместимость по srpm<br />
:(т. е. чтобы я мог разрабатывать в ALT <br />
:java пакеты, которые после нативной пересборки работают <br />
от fedora до novell)<br />
это мне важно.<br />
3) очень многих пакетов в Сизифе еще нет.<br />
добавление их в несовместимую среду потребует кучу пустой работы наподобие -lz-pureС-altcore.<br />
[00:16:24] <Lav> все нормальные программы используют pkgconfig и не заботятся о названии библиотек :)<br />
[00:25:46] <viy> но заботятся о названии pc - файла.<br />
что будет, если программа надеется на libpcre.pc, а в Сизифе лежит пакет с libpcre-pureC.pc ?<br />
[00:24:48] <Lav> До окончания каких работ?<br />
[00:25:46] <viy> я хочу создать полную среду разработки.<br />
в которой нет необходимости ставить сторонние пакеты.<br />
[00:25:48] <Lav>То есть в FC и в Novell вот так же накиданы пакеты?<br />
[00:27:22] <viy> да.<br />
[00:27:48] <Lav> И я всё же не понимаю, какая разница - указывать в спеке Requires: java-isorelax<br />
или<br />
Requires: isorelax<br />
Это же просто вопрос принятого соглашения.<br />
[00:28:06] <viy> оно не бесплатно.<br />
[00:28:10] <Lav> Дело в том, что после создания полной среды разработки пакетов будет столько, что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
[00:29:31] <viy> нет. я же руками ничего не делаю.<br />
отшлифовываю робота для проведения массовых операций.<br />
с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
у меня спеки правит робот.<br />
[00:30:09] <Lav> Таким образом, есть надежда, что со временем робота можно переучить?<br />
[00:30:39] <viy> мне важно 2) -- чтобы всегда оставалась возможность<br />
иметь совместимость по srpm<br />
(т. е. чтобы я мог разрабатывать в ALT <br />
java пакеты, которые после нативной пересборки работают <br />
от fedora до novell)<br />
[00:30:28] <Lav> Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
[00:30:58] <viy> робот работает согласно jpackage.org policy.<br />
[00:31:38] <viy> раньше у нас не было совместимости с jpackage.<br />
[00:33:05] <Lav> В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
[00:35:42] <viy> ok.<br />
для java библиотек вменяемые спеки и не нужны.<br />
не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
Эта ситуация когда отсутствует сборочная среда.<br />
когда она уже есть, тогда можно уже собирать приложения.<br />
они и требуют ручной работы.<br />
от библиотек требуется. чтобы они были.<br />
[00:36:09] <Lav> По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
[00:37:01] <viy> 1) несовместимостей много<br />
2) нельзя будет проверки зависимостей внедрить и т. д.<br />
у меня спеки заменяет набор хуков для робота.<br />
в простых случаях их нет. в запущенных имеем<br />
... <br />
: $jpp->disable_package('plugin-jalopy');<br />
< и другие примеры команд роботу><br />
...<br />
===== Обсуждение с Денисом =====<br />
10:55:12] <viy> хотел бы попросить рассказать что неудобно<br />
[10:55:28] <Mithraen> Отсутствие префиксов типа java- или аналогичных<br />
[10:56:07] <viy> я уже говорил с lav@ <br />
уже де-факто есть суффикс.<br />
[10:56:10] <Mithraen> Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
[10:56:22] <Mithraen> Какой суффикс?<br />
[10:58:07] <viy> можно это выписать в полиси и к пакетам добавлять<br />
jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
jpackage repository P.Q/<br />
jvm4.2==jpp1.7<br />
jvm5.0==jpp5.0<br />
[10:59:16] <Mithraen> Гм.<br />
[10:59:28] <Mithraen> Не уверен что такая подробность (версия в имени) нужна<br />
[10:59:46] <Mithraen> А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
[11:01:23] <viy> можно будет написать робот такого типа:<br />
vpupkin@ собрал пакет с суффиксом jvm4.2<br />
но он собран 1.6.0 без -target 1.4<br />
соответственно в 1.4\1.5 работать не будет.<br />
[11:01:28] <Mithraen> К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
[11:01:50] <Mithraen> А с provides/requires при этом что делать?<br />
[11:02:00] <Mithraen> Они-ж еще и по файлам пересекаться небось будут :(<br />
[11:02:27] <Mithraen> Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
[11:02:36] <viy> нет. пакет должен быть собран для наименьшей возможной java.<br />
[11:03:16] <viy> т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
[11:03:50] <viy> пример junit (jvm4.2) и junit4 (jvm5.0)<br />
[11:03:57] <Mithraen> А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
[11:04:08] <viy> да.<br />
[11:04:30] <Mithraen> Их придется дублировать<br />
[11:05:07] <viy> лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
[11:05:52] <viy> а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
[11:09:42] <viy> автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
в ней любой пакет можно будет по отдельности пересобрать. Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
[11:22:38] <Mithraen> Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
[11:22:54] <Mithraen> Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
[11:26:22] <viy> можно... <br />
но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
Не нравилось мне работать в <чужом дистрибутиве>.<br />
Соответственно совместимость это полезная вещь, она денег стоит.<br />
Смысла ее ломать из-за эстетических соображений я не вижу.<br />
Это удар по разработчикам.<br />
[11:27:01] <Mithraen> Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
[11:27:36] <viy> бесполезная работа отнимает кучу время/денег тоже.<br />
[11:27:39] <Mithraen> А соображения эти не эстетического характера, а следствия элементарного удобства<br />
[11:28:13] <Mithraen> apt-cache search log | grep java -- это удобно<br />
[11:28:22] <viy> я же предложил суффикс :)<br />
pcregrep '(jvm|jpp)\d\.\d$'<br />
[11:28:34] <Mithraen> Суффикс это точно такое же переименование<br />
[11:29:02] <Mithraen> От необходимости делать provides на jpackage name не спасет<br />
[11:29:04] <viy> нет. он же в Release. на зависимости не влияет.<br />
[11:29:21] <Mithraen> А.. в release...<br />
[11:29:23] <Mithraen> Ужас :)<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
On Wed, Nov 14, 2007 at 08:57:29AM +0200, Slava Dubrovskiy wrote: &gt; QA Team Download Robot пишет: &gt; > List of files which have been downloaded from the "devel" incoming: &gt; > maven2-2.0.4-alt1_10jpp1.7.src.rpm &gt; Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1)<br />
/usr/bin/mvn <br/>это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с<br />
-[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
2)<br />
для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3)<br />
Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль<br />
maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
Это достаточно скоро будет.<br />
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
&gt; Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в &gt; репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2303Java/JavaPackagingFAQ2008-08-15T18:30:45Z<p>SergeyLebedev: /* Переименовывать ли пакеты Java? */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
'''Обсуждение с Виталием'''<br />
<br />
;viy > <br />
:есть серьезные причины не трогать имена,<br />
:как такой вариант -- суффикс?<br />
:почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
:можно дополнить для остальных суффикс jvmX.X<br />
:например maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm<br />
<br />
;Lav > <br />
:Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
<br />
;viy > <br />
:причина - совместимость.<br />
:например, libz.so можно было бы назвать<br />
:libz-pureС-altcore.so<br />
:и патчить все configure.am, чтобы линковаться<br />
:-lz-pureС-altcore<br />
:Но так не делают.<br />
<br />
;Lav > <br />
:Какое отношение название пакета имеет к линковке?<br />
:И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
<br />
;viy > <br />
:аналог линковки -- создание classpath:<br />
:java -cp a:b:c:d run<br />
[00:07:07] <Lav> Я, если честно, в java мало понимаю.<br />
Это пример запуска программы?<br />
[00:07:11] <viy> для библиотек есть 1) фиксированный путь<br />
/lib + /usr/lib <br />
2) канонические имена (libz.so.*)<br />
поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
<br />
[00:07:17] <viy> да<br />
[00:07:28] <Lav> А для java какую роль пакет играет?<br />
[00:10:27] <viy> проприетарщина для C может указывать зависимости вида libXft.so(64bit) и они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
Открытые программы тоже могут сказать хотим -lXft<br />
с java это не пройдет они просто не найдут друг друга <br />
[00:11:40] <viy> Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
иначе куча работы как в примере выше с libz-pureС-altcore.so<br />
[00:15:39] <Lav> Нет, я никак не пойму связи названия пакета и classpath<br />
[00:23:31] <viy> Это другая тема.<br />
поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
я хочу, чтобы до окончания работ <br />
1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
2) всегда оставалась возможность<br />
иметь совместимость по srpm<br />
(т. е. чтобы я мог разрабатывать в ALT <br />
java пакеты, которые после нативной пересборки работают <br />
от fedora до novell)<br />
это мне важно.<br />
3) очень многих пакетов в Сизифе еще нет.<br />
добавление их в несовместимую среду потребует кучу пустой работы наподобие -lz-pureС-altcore.<br />
[00:16:24] <Lav> все нормальные программы используют pkgconfig и не заботятся о названии библиотек :)<br />
[00:25:46] <viy> но заботятся о названии pc - файла.<br />
что будет, если программа надеется на libpcre.pc, а в Сизифе лежит пакет с libpcre-pureC.pc ?<br />
[00:24:48] <Lav> До окончания каких работ?<br />
[00:25:46] <viy> я хочу создать полную среду разработки.<br />
в которой нет необходимости ставить сторонние пакеты.<br />
[00:25:48] <Lav>То есть в FC и в Novell вот так же накиданы пакеты?<br />
[00:27:22] <viy> да.<br />
[00:27:48] <Lav> И я всё же не понимаю, какая разница - указывать в спеке Requires: java-isorelax<br />
или<br />
Requires: isorelax<br />
Это же просто вопрос принятого соглашения.<br />
[00:28:06] <viy> оно не бесплатно.<br />
[00:28:10] <Lav> Дело в том, что после создания полной среды разработки пакетов будет столько, что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
[00:29:31] <viy> нет. я же руками ничего не делаю.<br />
отшлифовываю робота для проведения массовых операций.<br />
с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
у меня спеки правит робот.<br />
[00:30:09] <Lav> Таким образом, есть надежда, что со временем робота можно переучить?<br />
[00:30:39] <viy> мне важно 2) -- чтобы всегда оставалась возможность<br />
иметь совместимость по srpm<br />
(т. е. чтобы я мог разрабатывать в ALT <br />
java пакеты, которые после нативной пересборки работают <br />
от fedora до novell)<br />
[00:30:28] <Lav> Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
[00:30:58] <viy> робот работает согласно jpackage.org policy.<br />
[00:31:38] <viy> раньше у нас не было совместимости с jpackage.<br />
[00:33:05] <Lav> В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
[00:35:42] <viy> ok.<br />
для java библиотек вменяемые спеки и не нужны.<br />
не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
Эта ситуация когда отсутствует сборочная среда.<br />
когда она уже есть, тогда можно уже собирать приложения.<br />
они и требуют ручной работы.<br />
от библиотек требуется. чтобы они были.<br />
[00:36:09] <Lav> По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
[00:37:01] <viy> 1) несовместимостей много<br />
2) нельзя будет проверки зависимостей внедрить и т. д.<br />
у меня спеки заменяет набор хуков для робота.<br />
в простых случаях их нет. в запущенных имеем<br />
... <br />
: $jpp->disable_package('plugin-jalopy');<br />
< и другие примеры команд роботу><br />
...<br />
===== Обсуждение с Денисом =====<br />
10:55:12] <viy> хотел бы попросить рассказать что неудобно<br />
[10:55:28] <Mithraen> Отсутствие префиксов типа java- или аналогичных<br />
[10:56:07] <viy> я уже говорил с lav@ <br />
уже де-факто есть суффикс.<br />
[10:56:10] <Mithraen> Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
[10:56:22] <Mithraen> Какой суффикс?<br />
[10:58:07] <viy> можно это выписать в полиси и к пакетам добавлять<br />
jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
jpackage repository P.Q/<br />
jvm4.2==jpp1.7<br />
jvm5.0==jpp5.0<br />
[10:59:16] <Mithraen> Гм.<br />
[10:59:28] <Mithraen> Не уверен что такая подробность (версия в имени) нужна<br />
[10:59:46] <Mithraen> А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
[11:01:23] <viy> можно будет написать робот такого типа:<br />
vpupkin@ собрал пакет с суффиксом jvm4.2<br />
но он собран 1.6.0 без -target 1.4<br />
соответственно в 1.4\1.5 работать не будет.<br />
[11:01:28] <Mithraen> К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
[11:01:50] <Mithraen> А с provides/requires при этом что делать?<br />
[11:02:00] <Mithraen> Они-ж еще и по файлам пересекаться небось будут :(<br />
[11:02:27] <Mithraen> Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
[11:02:36] <viy> нет. пакет должен быть собран для наименьшей возможной java.<br />
[11:03:16] <viy> т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
[11:03:50] <viy> пример junit (jvm4.2) и junit4 (jvm5.0)<br />
[11:03:57] <Mithraen> А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
[11:04:08] <viy> да.<br />
[11:04:30] <Mithraen> Их придется дублировать<br />
[11:05:07] <viy> лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
[11:05:52] <viy> а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
[11:09:42] <viy> автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
в ней любой пакет можно будет по отдельности пересобрать. Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
[11:22:38] <Mithraen> Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
[11:22:54] <Mithraen> Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
[11:26:22] <viy> можно... <br />
но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
Не нравилось мне работать в <чужом дистрибутиве>.<br />
Соответственно совместимость это полезная вещь, она денег стоит.<br />
Смысла ее ломать из-за эстетических соображений я не вижу.<br />
Это удар по разработчикам.<br />
[11:27:01] <Mithraen> Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
[11:27:36] <viy> бесполезная работа отнимает кучу время/денег тоже.<br />
[11:27:39] <Mithraen> А соображения эти не эстетического характера, а следствия элементарного удобства<br />
[11:28:13] <Mithraen> apt-cache search log | grep java -- это удобно<br />
[11:28:22] <viy> я же предложил суффикс :)<br />
pcregrep '(jvm|jpp)\d\.\d$'<br />
[11:28:34] <Mithraen> Суффикс это точно такое же переименование<br />
[11:29:02] <Mithraen> От необходимости делать provides на jpackage name не спасет<br />
[11:29:04] <viy> нет. он же в Release. на зависимости не влияет.<br />
[11:29:21] <Mithraen> А.. в release...<br />
[11:29:23] <Mithraen> Ужас :)<br />
<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
On Wed, Nov 14, 2007 at 08:57:29AM +0200, Slava Dubrovskiy wrote: &gt; QA Team Download Robot пишет: &gt; > List of files which have been downloaded from the "devel" incoming: &gt; > maven2-2.0.4-alt1_10jpp1.7.src.rpm &gt; Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1)<br />
/usr/bin/mvn <br/>это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с<br />
-[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
2)<br />
для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3)<br />
Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль<br />
maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
Это достаточно скоро будет.<br />
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
&gt; Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в &gt; репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2302Java/JavaPackagingFAQ2008-08-15T18:28:40Z<p>SergeyLebedev: /* Правила для Java */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
----<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
===== Обсуждение с Виталием =====<br />
[23:59:11] <viy> есть серьезные причины не трогать имена,<br />
как такой вариант -- суффикс?<br />
почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
можно дополнить для остальных суффикс jvmX.X<br />
например maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm<br />
<br />
[00:00:37] <Lav> Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
[00:03:27] <viy> причина - совместимость.<br />
например, libz.so можно было бы назвать<br />
libz-pureС-altcore.so<br />
и патчить все configure.am, чтобы линковаться<br />
-lz-pureС-altcore<br />
Но так не делают.<br />
[00:03:49] <Lav> Какое отношение название пакета имеет к линковке?<br />
[00:04:23] <Lav> И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
[00:05:30] <viy> аналог линковки -- создание classpath:<br />
java -cp a:b:c:d run<br />
[00:07:07] <Lav> Я, если честно, в java мало понимаю.<br />
Это пример запуска программы?<br />
[00:07:11] <viy> для библиотек есть 1) фиксированный путь<br />
/lib + /usr/lib <br />
2) канонические имена (libz.so.*)<br />
поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
<br />
[00:07:17] <viy> да<br />
[00:07:28] <Lav> А для java какую роль пакет играет?<br />
[00:10:27] <viy> проприетарщина для C может указывать зависимости вида libXft.so(64bit) и они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
Открытые программы тоже могут сказать хотим -lXft<br />
с java это не пройдет они просто не найдут друг друга <br />
[00:11:40] <viy> Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
иначе куча работы как в примере выше с libz-pureС-altcore.so<br />
[00:15:39] <Lav> Нет, я никак не пойму связи названия пакета и classpath<br />
[00:23:31] <viy> Это другая тема.<br />
поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
я хочу, чтобы до окончания работ <br />
1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
2) всегда оставалась возможность<br />
иметь совместимость по srpm<br />
(т. е. чтобы я мог разрабатывать в ALT <br />
java пакеты, которые после нативной пересборки работают <br />
от fedora до novell)<br />
это мне важно.<br />
3) очень многих пакетов в Сизифе еще нет.<br />
добавление их в несовместимую среду потребует кучу пустой работы наподобие -lz-pureС-altcore.<br />
[00:16:24] <Lav> все нормальные программы используют pkgconfig и не заботятся о названии библиотек :)<br />
[00:25:46] <viy> но заботятся о названии pc - файла.<br />
что будет, если программа надеется на libpcre.pc, а в Сизифе лежит пакет с libpcre-pureC.pc ?<br />
[00:24:48] <Lav> До окончания каких работ?<br />
[00:25:46] <viy> я хочу создать полную среду разработки.<br />
в которой нет необходимости ставить сторонние пакеты.<br />
[00:25:48] <Lav>То есть в FC и в Novell вот так же накиданы пакеты?<br />
[00:27:22] <viy> да.<br />
[00:27:48] <Lav> И я всё же не понимаю, какая разница - указывать в спеке Requires: java-isorelax<br />
или<br />
Requires: isorelax<br />
Это же просто вопрос принятого соглашения.<br />
[00:28:06] <viy> оно не бесплатно.<br />
[00:28:10] <Lav> Дело в том, что после создания полной среды разработки пакетов будет столько, что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
[00:29:31] <viy> нет. я же руками ничего не делаю.<br />
отшлифовываю робота для проведения массовых операций.<br />
с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
у меня спеки правит робот.<br />
[00:30:09] <Lav> Таким образом, есть надежда, что со временем робота можно переучить?<br />
[00:30:39] <viy> мне важно 2) -- чтобы всегда оставалась возможность<br />
иметь совместимость по srpm<br />
(т. е. чтобы я мог разрабатывать в ALT <br />
java пакеты, которые после нативной пересборки работают <br />
от fedora до novell)<br />
[00:30:28] <Lav> Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
[00:30:58] <viy> робот работает согласно jpackage.org policy.<br />
[00:31:38] <viy> раньше у нас не было совместимости с jpackage.<br />
[00:33:05] <Lav> В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
[00:35:42] <viy> ok.<br />
для java библиотек вменяемые спеки и не нужны.<br />
не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
Эта ситуация когда отсутствует сборочная среда.<br />
когда она уже есть, тогда можно уже собирать приложения.<br />
они и требуют ручной работы.<br />
от библиотек требуется. чтобы они были.<br />
[00:36:09] <Lav> По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
[00:37:01] <viy> 1) несовместимостей много<br />
2) нельзя будет проверки зависимостей внедрить и т. д.<br />
у меня спеки заменяет набор хуков для робота.<br />
в простых случаях их нет. в запущенных имеем<br />
... <br />
: $jpp->disable_package('plugin-jalopy');<br />
< и другие примеры команд роботу><br />
...<br />
===== Обсуждение с Денисом =====<br />
10:55:12] <viy> хотел бы попросить рассказать что неудобно<br />
[10:55:28] <Mithraen> Отсутствие префиксов типа java- или аналогичных<br />
[10:56:07] <viy> я уже говорил с lav@ <br />
уже де-факто есть суффикс.<br />
[10:56:10] <Mithraen> Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
[10:56:22] <Mithraen> Какой суффикс?<br />
[10:58:07] <viy> можно это выписать в полиси и к пакетам добавлять<br />
jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
jpackage repository P.Q/<br />
jvm4.2==jpp1.7<br />
jvm5.0==jpp5.0<br />
[10:59:16] <Mithraen> Гм.<br />
[10:59:28] <Mithraen> Не уверен что такая подробность (версия в имени) нужна<br />
[10:59:46] <Mithraen> А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
[11:01:23] <viy> можно будет написать робот такого типа:<br />
vpupkin@ собрал пакет с суффиксом jvm4.2<br />
но он собран 1.6.0 без -target 1.4<br />
соответственно в 1.4\1.5 работать не будет.<br />
[11:01:28] <Mithraen> К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
[11:01:50] <Mithraen> А с provides/requires при этом что делать?<br />
[11:02:00] <Mithraen> Они-ж еще и по файлам пересекаться небось будут :(<br />
[11:02:27] <Mithraen> Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
[11:02:36] <viy> нет. пакет должен быть собран для наименьшей возможной java.<br />
[11:03:16] <viy> т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
[11:03:50] <viy> пример junit (jvm4.2) и junit4 (jvm5.0)<br />
[11:03:57] <Mithraen> А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
[11:04:08] <viy> да.<br />
[11:04:30] <Mithraen> Их придется дублировать<br />
[11:05:07] <viy> лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
[11:05:52] <viy> а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
[11:09:42] <viy> автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
в ней любой пакет можно будет по отдельности пересобрать. Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
[11:22:38] <Mithraen> Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
[11:22:54] <Mithraen> Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
[11:26:22] <viy> можно... <br />
но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
Не нравилось мне работать в <чужом дистрибутиве>.<br />
Соответственно совместимость это полезная вещь, она денег стоит.<br />
Смысла ее ломать из-за эстетических соображений я не вижу.<br />
Это удар по разработчикам.<br />
[11:27:01] <Mithraen> Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
[11:27:36] <viy> бесполезная работа отнимает кучу время/денег тоже.<br />
[11:27:39] <Mithraen> А соображения эти не эстетического характера, а следствия элементарного удобства<br />
[11:28:13] <Mithraen> apt-cache search log | grep java -- это удобно<br />
[11:28:22] <viy> я же предложил суффикс :)<br />
pcregrep '(jvm|jpp)\d\.\d$'<br />
[11:28:34] <Mithraen> Суффикс это точно такое же переименование<br />
[11:29:02] <Mithraen> От необходимости делать provides на jpackage name не спасет<br />
[11:29:04] <viy> нет. он же в Release. на зависимости не влияет.<br />
[11:29:21] <Mithraen> А.. в release...<br />
[11:29:23] <Mithraen> Ужас :)<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
On Wed, Nov 14, 2007 at 08:57:29AM +0200, Slava Dubrovskiy wrote: &gt; QA Team Download Robot пишет: &gt; > List of files which have been downloaded from the "devel" incoming: &gt; > maven2-2.0.4-alt1_10jpp1.7.src.rpm &gt; Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1)<br />
/usr/bin/mvn <br/>это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с<br />
-[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
2)<br />
для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3)<br />
Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль<br />
maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
Это достаточно скоро будет.<br />
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
&gt; Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в &gt; репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2301Java/JavaPackagingFAQ2008-08-15T18:28:11Z<p>SergeyLebedev: /* Правила для Java */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
<pre><br />
From: Michael Pozhidaev<br />
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
From: Igor Vlasenko<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
<br />
From: Michael Pozhidaev<br />
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. <br />
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки <br />
или можно упаковать самому, соблюдая какие-нибудь правила?<br />
<br />
From: Igor Vlasenko<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]<br />
</pre><br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
===== Обсуждение с Виталием =====<br />
[23:59:11] <viy> есть серьезные причины не трогать имена,<br />
как такой вариант -- суффикс?<br />
почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
можно дополнить для остальных суффикс jvmX.X<br />
например maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm<br />
<br />
[00:00:37] <Lav> Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
[00:03:27] <viy> причина - совместимость.<br />
например, libz.so можно было бы назвать<br />
libz-pureС-altcore.so<br />
и патчить все configure.am, чтобы линковаться<br />
-lz-pureС-altcore<br />
Но так не делают.<br />
[00:03:49] <Lav> Какое отношение название пакета имеет к линковке?<br />
[00:04:23] <Lav> И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
[00:05:30] <viy> аналог линковки -- создание classpath:<br />
java -cp a:b:c:d run<br />
[00:07:07] <Lav> Я, если честно, в java мало понимаю.<br />
Это пример запуска программы?<br />
[00:07:11] <viy> для библиотек есть 1) фиксированный путь<br />
/lib + /usr/lib <br />
2) канонические имена (libz.so.*)<br />
поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
<br />
[00:07:17] <viy> да<br />
[00:07:28] <Lav> А для java какую роль пакет играет?<br />
[00:10:27] <viy> проприетарщина для C может указывать зависимости вида libXft.so(64bit) и они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
Открытые программы тоже могут сказать хотим -lXft<br />
с java это не пройдет они просто не найдут друг друга <br />
[00:11:40] <viy> Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
иначе куча работы как в примере выше с libz-pureС-altcore.so<br />
[00:15:39] <Lav> Нет, я никак не пойму связи названия пакета и classpath<br />
[00:23:31] <viy> Это другая тема.<br />
поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
я хочу, чтобы до окончания работ <br />
1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
2) всегда оставалась возможность<br />
иметь совместимость по srpm<br />
(т. е. чтобы я мог разрабатывать в ALT <br />
java пакеты, которые после нативной пересборки работают <br />
от fedora до novell)<br />
это мне важно.<br />
3) очень многих пакетов в Сизифе еще нет.<br />
добавление их в несовместимую среду потребует кучу пустой работы наподобие -lz-pureС-altcore.<br />
[00:16:24] <Lav> все нормальные программы используют pkgconfig и не заботятся о названии библиотек :)<br />
[00:25:46] <viy> но заботятся о названии pc - файла.<br />
что будет, если программа надеется на libpcre.pc, а в Сизифе лежит пакет с libpcre-pureC.pc ?<br />
[00:24:48] <Lav> До окончания каких работ?<br />
[00:25:46] <viy> я хочу создать полную среду разработки.<br />
в которой нет необходимости ставить сторонние пакеты.<br />
[00:25:48] <Lav>То есть в FC и в Novell вот так же накиданы пакеты?<br />
[00:27:22] <viy> да.<br />
[00:27:48] <Lav> И я всё же не понимаю, какая разница - указывать в спеке Requires: java-isorelax<br />
или<br />
Requires: isorelax<br />
Это же просто вопрос принятого соглашения.<br />
[00:28:06] <viy> оно не бесплатно.<br />
[00:28:10] <Lav> Дело в том, что после создания полной среды разработки пакетов будет столько, что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
[00:29:31] <viy> нет. я же руками ничего не делаю.<br />
отшлифовываю робота для проведения массовых операций.<br />
с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
у меня спеки правит робот.<br />
[00:30:09] <Lav> Таким образом, есть надежда, что со временем робота можно переучить?<br />
[00:30:39] <viy> мне важно 2) -- чтобы всегда оставалась возможность<br />
иметь совместимость по srpm<br />
(т. е. чтобы я мог разрабатывать в ALT <br />
java пакеты, которые после нативной пересборки работают <br />
от fedora до novell)<br />
[00:30:28] <Lav> Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
[00:30:58] <viy> робот работает согласно jpackage.org policy.<br />
[00:31:38] <viy> раньше у нас не было совместимости с jpackage.<br />
[00:33:05] <Lav> В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
[00:35:42] <viy> ok.<br />
для java библиотек вменяемые спеки и не нужны.<br />
не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
Эта ситуация когда отсутствует сборочная среда.<br />
когда она уже есть, тогда можно уже собирать приложения.<br />
они и требуют ручной работы.<br />
от библиотек требуется. чтобы они были.<br />
[00:36:09] <Lav> По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
[00:37:01] <viy> 1) несовместимостей много<br />
2) нельзя будет проверки зависимостей внедрить и т. д.<br />
у меня спеки заменяет набор хуков для робота.<br />
в простых случаях их нет. в запущенных имеем<br />
... <br />
: $jpp->disable_package('plugin-jalopy');<br />
< и другие примеры команд роботу><br />
...<br />
===== Обсуждение с Денисом =====<br />
10:55:12] <viy> хотел бы попросить рассказать что неудобно<br />
[10:55:28] <Mithraen> Отсутствие префиксов типа java- или аналогичных<br />
[10:56:07] <viy> я уже говорил с lav@ <br />
уже де-факто есть суффикс.<br />
[10:56:10] <Mithraen> Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
[10:56:22] <Mithraen> Какой суффикс?<br />
[10:58:07] <viy> можно это выписать в полиси и к пакетам добавлять<br />
jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
jpackage repository P.Q/<br />
jvm4.2==jpp1.7<br />
jvm5.0==jpp5.0<br />
[10:59:16] <Mithraen> Гм.<br />
[10:59:28] <Mithraen> Не уверен что такая подробность (версия в имени) нужна<br />
[10:59:46] <Mithraen> А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
[11:01:23] <viy> можно будет написать робот такого типа:<br />
vpupkin@ собрал пакет с суффиксом jvm4.2<br />
но он собран 1.6.0 без -target 1.4<br />
соответственно в 1.4\1.5 работать не будет.<br />
[11:01:28] <Mithraen> К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
[11:01:50] <Mithraen> А с provides/requires при этом что делать?<br />
[11:02:00] <Mithraen> Они-ж еще и по файлам пересекаться небось будут :(<br />
[11:02:27] <Mithraen> Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
[11:02:36] <viy> нет. пакет должен быть собран для наименьшей возможной java.<br />
[11:03:16] <viy> т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
[11:03:50] <viy> пример junit (jvm4.2) и junit4 (jvm5.0)<br />
[11:03:57] <Mithraen> А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
[11:04:08] <viy> да.<br />
[11:04:30] <Mithraen> Их придется дублировать<br />
[11:05:07] <viy> лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
[11:05:52] <viy> а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
[11:09:42] <viy> автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
в ней любой пакет можно будет по отдельности пересобрать. Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
[11:22:38] <Mithraen> Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
[11:22:54] <Mithraen> Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
[11:26:22] <viy> можно... <br />
но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
Не нравилось мне работать в <чужом дистрибутиве>.<br />
Соответственно совместимость это полезная вещь, она денег стоит.<br />
Смысла ее ломать из-за эстетических соображений я не вижу.<br />
Это удар по разработчикам.<br />
[11:27:01] <Mithraen> Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
[11:27:36] <viy> бесполезная работа отнимает кучу время/денег тоже.<br />
[11:27:39] <Mithraen> А соображения эти не эстетического характера, а следствия элементарного удобства<br />
[11:28:13] <Mithraen> apt-cache search log | grep java -- это удобно<br />
[11:28:22] <viy> я же предложил суффикс :)<br />
pcregrep '(jvm|jpp)\d\.\d$'<br />
[11:28:34] <Mithraen> Суффикс это точно такое же переименование<br />
[11:29:02] <Mithraen> От необходимости делать provides на jpackage name не спасет<br />
[11:29:04] <viy> нет. он же в Release. на зависимости не влияет.<br />
[11:29:21] <Mithraen> А.. в release...<br />
[11:29:23] <Mithraen> Ужас :)<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
On Wed, Nov 14, 2007 at 08:57:29AM +0200, Slava Dubrovskiy wrote: &gt; QA Team Download Robot пишет: &gt; > List of files which have been downloaded from the "devel" incoming: &gt; > maven2-2.0.4-alt1_10jpp1.7.src.rpm &gt; Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1)<br />
/usr/bin/mvn <br/>это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с<br />
-[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
2)<br />
для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3)<br />
Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль<br />
maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
Это достаточно скоро будет.<br />
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
&gt; Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в &gt; репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedevhttps://www.altlinux.org/index.php?title=Java/JavaPackagingFAQ&diff=2300Java/JavaPackagingFAQ2008-08-15T18:25:39Z<p>SergeyLebedev: /* Общая концепция импорта java-пакетов в Сизифе */</p>
<hr />
<div>[[Category:Policy]]<br />
{{Викифицировать}}<br />
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}<br />
<br />
__TOC__<br />
<br />
----<br />
=== Общая концепция импорта java-пакетов в Сизифе ===<br />
;viy > <br />
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.<br />
----<br />
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====<br />
<br />
;lsv > <br />
:одни и те же пакеты с разными именами<br />
:хотя бы в имени релиза<br />
;viy > <br />
:есть, но тут все просто.<br />
:1) есть пакеты с разными <tt>ABI/API</tt><br />
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt><br />
:2) есть пакеты с одним и тем же содержимым.<br />
:это мусор, я стараюсь чистить.<br />
: примеров мало.<br />
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.<br />
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..<br />
----<br />
<br />
==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====<br />
какие-то отметки хранятся в <br />
[http://git.altlinux.org/people/viy/packages/?p=jppimport.git;a=blob_plain;f=deps.notes;hb=master deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes]<br />
==== Что такое jppimport и как использовать ====<br />
<br />
;viy > <br />
:вы <tt>srpm</tt> руками пишете или через <tt>jppimport</tt> ?<br />
;lsv > <br />
:<tt>jppimport</tt>, потом смотрю что на выходе, spec этого пакета<br />
;viy > <br />
:эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.<br />
;lsv > <br />
:хорошая задумка<br />
;viy > <br />
:иначе вырастает трудоемкость<br />
:при выходе новой версии надо разбираться, что и где правилось.<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup</tt><br />
:это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.<br />
:потом я <br />
:<tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.<br />
;lsv > <br />
:отлично<br />
;viy > <br />
:еще пример ?<br />
:<tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.<br />
:я после того, как руками подаботаю, запускал <tt>/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`</tt><br />
:и <tt>for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log</tt><br />
:сразу давал улов.<br />
:запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.<br />
:отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.<br />
----<br />
==== jpackage-xx-compat ====<br />
<br />
;lsv > <br />
:что такое <tt>jpackage-1.4-compat</tt><br />
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?<br />
<br />
:ага, типа у нас пакет называется одним боком, а у них другим<br />
:а он прослойка для rpm'а<br />
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.<br />
;viy > <br />
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(<br />
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.<br />
:идея <tt>jpackage-xx-compat</tt><br />
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду<br />
:<tt>(unzip, ant-junit, ...)</tt><br />
:это <tt>jpackage-generic-compat</tt>.<br />
:кроме того, есть еще 2 пакета для ленивых<br />
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt><br />
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt><br />
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4<br />
----<br />
<br />
==== jboss и все, все все ====<br />
<br />
;viy > <br />
:<tt>jboss</tt> альтовский. собран <tt>java 1.5</tt> и его нельзя использовать при сборке с <tt>java 1.4</tt><br />
:а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.<br />
;lsv > <br />
:в <tt>jpackage</tt> идет разделение по веткам.<br />
;viy > <br />
:в jpackage целых 3 jboss<br />
:2 в 1.7 и 1 в 5.0.<br />
:наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.<br />
:на примере jboss это легко решается.<br />
:переименовать его в <tt>jboss42-j2se15</tt> и собрать рядом из <tt>jpackage</tt>. я давно бы так сделал, будь это ничей пакет.<br />
----<br />
<br />
==== java-софт в сизифе, что где когда ====<br />
<br />
;lsv > <br />
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все<br />
;viy > <br />
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:<br />
;viy > <br />
:<tt>wc java-alt-packages.owners</tt><br />
:<tt>361 java-alt-packages.owners</tt><br />
<br />
<pre>viy > $ grep nobody java-alt-packages.owners <br />
--je @nobody--<br />
trang @nobody</pre><br />
<br />
;viy > <br />
:как видим, не так уж много пакетов.<br />
----<br />
<br />
==== Пакеты с лицензией Sun Binary Code License. ====<br />
;viy > <br />
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.<br />
:сантехника = <tt>Sun Binary Code License.</tt><br />
----<br />
<br />
==== Про поддержку пакетов в jpackage ====<br />
<br />
;lsv > <br />
:мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.<br />
;viy > <br />
:да. конечно. но проблема в следующем. утрируя, можно сказать<br />
:кому они нужны?<br />
:типичный всюду плотный пакет из <tt>jpackage</tt> сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,<br />
:звено пищевой цепочки зависимостей. как в природе<br />
:для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.<br />
:пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же <tt>jpackage</tt> до 20. может, до 10 на самом деле.<br />
:более того, в <tt>jpackage</tt> особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде <tt>java basesystem</tt>.<br />
;lsv > <br />
:это хорошо<br />
;viy > <br />
:с такого рода софтом другая крайность<br />
:в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.<br />
:там дискуссия есть, как это правильно будет. например maven использует подход<br />
:публичный url.<br />
----<br />
<br />
==== Что сейчас возможно сделать, для пересборки jpackage-хозяйства. ====<br />
<br />
;viy > <br />
:поэтому реальная ценность <tt>jpackage</tt><br />
:в том, что он задает стандарты именования. Потому и топы <tt>(RH/FC Md Su SE? etc)</tt> сидят на нем.<br />
;lsv > <br />
:ну это на поверхности. Достаточно глянуть на <tt>jpackage.org</tt> и все понятно становится<br />
;viy ><br />
:теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, <br />
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.<br />
;lsv > <br />
:да<br />
:это пожалуй центральный момент<br />
;viy > <br />
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг <br />
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. <br />
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. <br />
----<br />
<br />
==== Epoch в jpackage пакетах ====<br />
;Damir ><br />
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.<br />
:То есть для apt или rpm между двумя строчками:<br />
:<tt>Conflicts: foo < version-release</tt><br />
:и<br />
:<tt>Conflicts: foo < 0:version-release</tt><br />
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.<br />
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.<br />
<br />
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в<br />
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.<br />
----<br />
<br />
==== Все ли java пакеты требуют jpackage полиси? ====<br />
<br />
;lsv > :<br />
при каком случаи пакет может не требовать полиси?<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?<br />
:обоснование.<br />
:1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._<br />
:в смысле куда что ложить.<br />
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?<br />
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.<br />
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать<br />
:тогда да. имеет.<br />
;lsv > <br />
:в jpackage -- основной момент имя пакета<br />
;viy > <br />
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, <br />
:только интегрировать ее с jpackage-utils. проще и доступнее.<br />
;lsv > <br />
:и имя jar-файла<br />
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить<br />
;viy > <br />
:3) в в jpackage -- основной момент имя пакета и имя jar-файла.<br />
:если даного пакета в jpackage нет, то как узнать его имя?<br />
;lsv > <br />
:нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage<br />
;viy > <br />
:здесь могут быть только рекомендации. 100% угадать нельзя.<br />
;lsv > <br />
:понятно что нет<br />
;viy > <br />
:в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?<br />
;lsv > <br />
:а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета<br />
;viy ><br />
:например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим<br />
:симлинками и Provides.<br />
;lsv > <br />
:на мой взгляд лучше переписать <tt>jpackage policy</tt> оствавив только FHS и общие рекомендации по имени <br />
:пакета, добавив <tt>alt-specific</tt>, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage<br />
;viy > <br />
:не точно.<br />
:если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.<br />
:с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? <br />
:имитатор просто разрушит систему сборки импортированных пакетов.<br />
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:<br />
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические <br />
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если <br />
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка<br />
:50% вероятности, что сборка сломается.<br />
;viy > <br />
:это не версионированные jar чаще ломают, чем версионированные jar, <br />
:но отсутствие версионированных jar тоже может сломать (и ломает)<br />
----<br />
<br />
==== Автоопределение зависимостей для java ====<br />
<br />
;lsv > <br />
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? <br />
:Для полноты счастья и мира во всем мире.<br />
;Алексей Турбин > <br />
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. <br />
:Типа вот [http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary]<br />
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.<br />
----<br />
<br />
==== /usr/share/java не соответствует /usr/lib ====<br />
;viy ><br />
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt><br />
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что<br />
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt><br />
----<br />
<br />
==== Почему все пакеты собираем jav'ой 1.4.2? ====<br />
<br />
;viy ><br />
:цитирую наше полиси:<br />
:Необходимо обеспечивать максимальную запускаемость на разных JVM <br />
<br />
<pre>11.03.2006<br />
mhz@ сообщает: <br />
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые<br />
теперь выбираются по умолчанию в сборочной среде, появилась новая<br />
особенность при сборке пакетов на Java. Компилятор JDK 1.5 по умолчанию<br />
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому<br />
необходимо следить, чтобы в сборочных скриптах для ant или make<br />
компилятор вызывался с параметрами source и target в значении 1.3 или<br />
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует<br />
иного. Если в коде используется ключевое слово assert, нужно ставить как<br />
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus<br />
пока не отмечено.<br />
<br />
viy: <br />
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.<br />
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.<br />
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 <br />
(Не злоупотреблять. только если код написан под Java 5).<br />
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.<br />
</pre><br />
<br />
;viy ><br />
:править <tt>build.xml</tt> крайне ресурсоемко,<br />
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt><br />
:в jpackage люди сами выбирают чем собирать<br />
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или<br />
:меньше ленятся прописывать :(<br />
:<tt>openjdk</tt><br />
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для <br />
:него костыль, иначе он всегда поставит 1.7<br />
----<br />
<br />
==== Hasher ====<br />
<pre>2007/10/26, <br />
Yury A.Romanov > <br />
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом. При попытке сборки в hasher - выдает следующую ошибку: <br />
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: <br />
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)<br />
<br />
"Damir Shayhutdinov" ><br />
добавьте<br />
allowed_mountpoints=/proc в /etc/hasher-priv/system<br />
--mountpoints=/proc в параметры hasher.<br />
<br />
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(<br />
</pre><br />
----<br />
<br />
==== java-select ====<br />
<br />
<div style="display: inline; color: red;">deprecated</div> <br />
;lsv > <br />
:существует переключалка между jvm'ами? аналог select-gcc ?<br />
;viy > <br />
:нет.<br />
;lsv > <br />
:вот жшь<br />
;viy > <br />
:там 5-7 альтернатив сразу переключить надо :( <br />
:совместимость называется ;(<br />
;lsv > <br />
:ну да<br />
:уродство<br />
;viy > <br />
:не знаю как побороть лучше.<br />
:наверно проще будет одномоментно обновить все jvm.<br />
----<br />
<br />
==== Правила для Java ====<br />
From: Michael Pozhidaev <msp@altlinux.ru><br />
&gt; Здравствуйте! &gt; Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? <br />
<br />
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].<br />
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] <br />
&gt;У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. &gt;Если пакета нет на JPackage , то какая политика предполагается: &gt;лучше вообще воздержаться от упаковки &gt;или можно упаковать самому, соблюдая какие-нибудь правила?<br />
скорее наоборот:<br />
Если пакет есть на JPackage, незачем делать дурную работу за робота.<br />
Если его там нет, то придется паковать. И тут в помощь <br />
[[Java|ALT Linux Java Policy]]<br />
<br />
==== Переименовывать ли пакеты Java? ====<br />
===== Обсуждение с Виталием =====<br />
[23:59:11] <viy> есть серьезные причины не трогать имена,<br />
как такой вариант -- суффикс?<br />
почти все пакеты имеют в релизе пакета суффикс jppX.X<br />
можно дополнить для остальных суффикс jvmX.X<br />
например maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm<br />
<br />
[00:00:37] <Lav> Я собственно хотел бы, чтобы причины сформулированы в полиси<br />
[00:03:27] <viy> причина - совместимость.<br />
например, libz.so можно было бы назвать<br />
libz-pureС-altcore.so<br />
и патчить все configure.am, чтобы линковаться<br />
-lz-pureС-altcore<br />
Но так не делают.<br />
[00:03:49] <Lav> Какое отношение название пакета имеет к линковке?<br />
[00:04:23] <Lav> И почему-то вся значимая информация в сиюминутном поле релиза :)<br />
[00:05:30] <viy> аналог линковки -- создание classpath:<br />
java -cp a:b:c:d run<br />
[00:07:07] <Lav> Я, если честно, в java мало понимаю.<br />
Это пример запуска программы?<br />
[00:07:11] <viy> для библиотек есть 1) фиксированный путь<br />
/lib + /usr/lib <br />
2) канонические имена (libz.so.*)<br />
поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...<br />
<br />
[00:07:17] <viy> да<br />
[00:07:28] <Lav> А для java какую роль пакет играет?<br />
[00:10:27] <viy> проприетарщина для C может указывать зависимости вида libXft.so(64bit) и они будут дистрибутивно не зависимы, имя пакета особой роли не играет.<br />
Открытые программы тоже могут сказать хотим -lXft<br />
с java это не пройдет они просто не найдут друг друга <br />
[00:11:40] <viy> Поэтому есть стандарт и все rpm дистрибутивы ему следуют.<br />
иначе куча работы как в примере выше с libz-pureС-altcore.so<br />
[00:15:39] <Lav> Нет, я никак не пойму связи названия пакета и classpath<br />
[00:23:31] <viy> Это другая тема.<br />
поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.<br />
я хочу, чтобы до окончания работ <br />
1) оставалась возможность установить сторонние пакеты (мне не важно)<br />
2) всегда оставалась возможность<br />
иметь совместимость по srpm<br />
(т. е. чтобы я мог разрабатывать в ALT <br />
java пакеты, которые после нативной пересборки работают <br />
от fedora до novell)<br />
это мне важно.<br />
3) очень многих пакетов в Сизифе еще нет.<br />
добавление их в несовместимую среду потребует кучу пустой работы наподобие -lz-pureС-altcore.<br />
[00:16:24] <Lav> все нормальные программы используют pkgconfig и не заботятся о названии библиотек :)<br />
[00:25:46] <viy> но заботятся о названии pc - файла.<br />
что будет, если программа надеется на libpcre.pc, а в Сизифе лежит пакет с libpcre-pureC.pc ?<br />
[00:24:48] <Lav> До окончания каких работ?<br />
[00:25:46] <viy> я хочу создать полную среду разработки.<br />
в которой нет необходимости ставить сторонние пакеты.<br />
[00:25:48] <Lav>То есть в FC и в Novell вот так же накиданы пакеты?<br />
[00:27:22] <viy> да.<br />
[00:27:48] <Lav> И я всё же не понимаю, какая разница - указывать в спеке Requires: java-isorelax<br />
или<br />
Requires: isorelax<br />
Это же просто вопрос принятого соглашения.<br />
[00:28:06] <viy> оно не бесплатно.<br />
[00:28:10] <Lav> Дело в том, что после создания полной среды разработки пакетов будет столько, что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.<br />
[00:29:31] <viy> нет. я же руками ничего не делаю.<br />
отшлифовываю робота для проведения массовых операций.<br />
с ним мне не принципиально, пересобрать 2 пакета или 2000.<br />
у меня спеки правит робот.<br />
[00:30:09] <Lav> Таким образом, есть надежда, что со временем робота можно переучить?<br />
[00:30:39] <viy> мне важно 2) -- чтобы всегда оставалась возможность<br />
иметь совместимость по srpm<br />
(т. е. чтобы я мог разрабатывать в ALT <br />
java пакеты, которые после нативной пересборки работают <br />
от fedora до novell)<br />
[00:30:28] <Lav> Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)<br />
[00:30:58] <viy> робот работает согласно jpackage.org policy.<br />
[00:31:38] <viy> раньше у нас не было совместимости с jpackage.<br />
[00:33:05] <Lav> В общем ситуацию я примерно понял... Спасибо за объяснение...<br />
[00:35:42] <viy> ok.<br />
для java библиотек вменяемые спеки и не нужны.<br />
не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.<br />
Эта ситуация когда отсутствует сборочная среда.<br />
когда она уже есть, тогда можно уже собирать приложения.<br />
они и требуют ручной работы.<br />
от библиотек требуется. чтобы они были.<br />
[00:36:09] <Lav> По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage<br />
[00:37:01] <viy> 1) несовместимостей много<br />
2) нельзя будет проверки зависимостей внедрить и т. д.<br />
у меня спеки заменяет набор хуков для робота.<br />
в простых случаях их нет. в запущенных имеем<br />
... <br />
: $jpp->disable_package('plugin-jalopy');<br />
< и другие примеры команд роботу><br />
...<br />
===== Обсуждение с Денисом =====<br />
10:55:12] <viy> хотел бы попросить рассказать что неудобно<br />
[10:55:28] <Mithraen> Отсутствие префиксов типа java- или аналогичных<br />
[10:56:07] <viy> я уже говорил с lav@ <br />
уже де-факто есть суффикс.<br />
[10:56:10] <Mithraen> Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)<br />
[10:56:22] <Mithraen> Какой суффикс?<br />
[10:58:07] <viy> можно это выписать в полиси и к пакетам добавлять<br />
jvmX.Y (работает с java X.Y и выше) либо jppP.Q<br />
jpackage repository P.Q/<br />
jvm4.2==jpp1.7<br />
jvm5.0==jpp5.0<br />
[10:59:16] <Mithraen> Гм.<br />
[10:59:28] <Mithraen> Не уверен что такая подробность (версия в имени) нужна<br />
[10:59:46] <Mithraen> А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен<br />
[11:01:23] <viy> можно будет написать робот такого типа:<br />
vpupkin@ собрал пакет с суффиксом jvm4.2<br />
но он собран 1.6.0 без -target 1.4<br />
соответственно в 1.4\1.5 работать не будет.<br />
[11:01:28] <Mithraen> К примеру log4j -- без поллитры не поймешь что это жаба :)<br />
[11:01:50] <Mithraen> А с provides/requires при этом что делать?<br />
[11:02:00] <Mithraen> Они-ж еще и по файлам пересекаться небось будут :(<br />
[11:02:27] <Mithraen> Или делать abc-jvm4.2 conflicts abc-jvm5.0?<br />
[11:02:36] <viy> нет. пакет должен быть собран для наименьшей возможной java.<br />
[11:03:16] <viy> т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.<br />
[11:03:50] <viy> пример junit (jvm4.2) и junit4 (jvm5.0)<br />
[11:03:57] <Mithraen> А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?<br />
[11:04:08] <viy> да.<br />
[11:04:30] <Mithraen> Их придется дублировать<br />
[11:05:07] <viy> лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.<br />
[11:05:52] <viy> а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.<br />
[11:09:42] <viy> автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.<br />
в ней любой пакет можно будет по отдельности пересобрать. Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.<br />
[11:22:38] <Mithraen> Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей<br />
[11:22:54] <Mithraen> Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни<br />
[11:26:22] <viy> можно... <br />
но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте. <br />
Не нравилось мне работать в <чужом дистрибутиве>.<br />
Соответственно совместимость это полезная вещь, она денег стоит.<br />
Смысла ее ломать из-за эстетических соображений я не вижу.<br />
Это удар по разработчикам.<br />
[11:27:01] <Mithraen> Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя<br />
[11:27:36] <viy> бесполезная работа отнимает кучу время/денег тоже.<br />
[11:27:39] <Mithraen> А соображения эти не эстетического характера, а следствия элементарного удобства<br />
[11:28:13] <Mithraen> apt-cache search log | grep java -- это удобно<br />
[11:28:22] <viy> я же предложил суффикс :)<br />
pcregrep '(jvm|jpp)\d\.\d$'<br />
[11:28:34] <Mithraen> Суффикс это точно такое же переименование<br />
[11:29:02] <Mithraen> От необходимости делать provides на jpackage name не спасет<br />
[11:29:04] <viy> нет. он же в Release. на зависимости не влияет.<br />
[11:29:21] <Mithraen> А.. в release...<br />
[11:29:23] <Mithraen> Ужас :)<br />
==== Советы по сборке пакетов с помощью maven2 ====<br />
On Wed, Nov 14, 2007 at 08:57:29AM +0200, Slava Dubrovskiy wrote: &gt; QA Team Download Robot пишет: &gt; > List of files which have been downloaded from the "devel" incoming: &gt; > maven2-2.0.4-alt1_10jpp1.7.src.rpm &gt; Ура! Заждались уже.<br />
<br />
В связи с этим несколько hints.<br />
1)<br />
/usr/bin/mvn <br/>это обычный "онлайновый" maven2.<br />
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,<br />
который вызывает mvn с<br />
-[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]<br />
<br />
2)<br />
для сборки, кроме mvn, нужен еще репозиторий pom'ов.<br />
В отсутствие maven2 в сизифе, часть пакетов была собрана<br />
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)<br />
но я надеюсь быстро пересобрать такие пакеты, так что<br />
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)<br />
репозиторий pom'ов будет.<br />
<br />
3)<br />
Свежие примеры сборки с помощью maven2<br />
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm<br />
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm<br />
уже лежат в инкоминге. Они попадут в Сизиф, как только там<br />
будет опубликован maven2.<br />
<br />
4) костыль<br />
maven2-plugins-2.0.4-alt1<br />
вытягивает maven2 вместе со всеми plugins.<br />
Удобен, когда заранее неизвестно, какие плагины понадобятся.<br />
<br />
===== разбор полетов с maven2 =====<br />
<br />
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)<br />
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).<br />
<br />
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня<br />
экзотики там мало, почти все зависимости уже собраны.<br />
<br />
Там проблема, решаемая, скорее не в отсутствии<br />
зависимостей, а в неинформированности maven2.<br />
Я ее опишу далее.<br />
С плагинами несколько по другому, там<br />
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,<br />
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,<br />
там целый букет плагинов<br />
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,<br />
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,<br />
...-exec,<br />
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,<br />
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,<br />
...-xdoclet, ...-xmlbeans, ...-xslt<br />
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные<br />
плагины.<br />
Это достаточно скоро будет.<br />
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.<br />
<br />
кстати, листинг find .m2 -type f вышлите, пожалуйста.<br />
очень был бы удобен чтобы одним взглядом увидеть все зависимости.<br />
&gt; Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в &gt; репозитариях интернета? Как можно помочь ускорить этот процесс?<br />
<br />
Как я говорил, большинство зависимостей уже есть.<br />
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)<br />
создать в RPM/BUILD/name папку .m2 и набросать туда,<br />
копируя структуру /.m2, симлинки вида<br />
groupid/artifactid-version.jar -> /usr/share/java/real.jar<br />
<br />
Проблема была в том, что структура /usr/share/java/<br />
не совпадает со структурой maven-репозитория.<br />
<br />
Чтобы преодолеть эту трудность, используется описанный в<br />
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html<br />
следующий прием.<br />
В файле /etc/maven/maven2-depmap.xml<br />
каждому pom сопоставляется real.jar в /usr/share/java/.<br />
Этот файл собирается из кусочков в /etc/maven/fragments/*<br />
при %post/%postun java пакетов.<br />
<br />
Другие приемы считаются устаревшими, я о них говорить не буду.<br />
<br />
Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,<br />
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске<br />
зависимостей.<br />
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,<br />
но maven2 его не видит.<br />
<br />
И затруднение в том, что еще не так много пакетов это делает<br />
(носит для своих jar'ов pom'ы и depmap fragments).<br />
<br />
Однако и решение достаточно просто. можно сделать пакет для сборочной<br />
среды, который будет устанавливать для maven2 нужные pom и fragments.<br />
<br />
Потом можно будет разложить эти pom и fragments по соответствующим<br />
пакетам, и нужда в костыле отпадет.<br />
<br />
=== вопросы по упаковке пользовательских приложений на java ===<br />
<br />
==== использование build-classpath из jpackage-utils ====<br />
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]<br />
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j<br />
... &gt; The following NEW packages will be installed:<br />
... jpackage-utils log4j rpm-build-java<br />
<br />
*raorn .o0( ох проклянут меня за азуреусовские зависимости... )<br />
<viy> скорее за их отсутствие :)<br />
если не будет зависимостей, средняя софтина на java <br />
будет тянуть 40-200 Mb. 1 софтина как весь <br />
дистрибутив. а так они разделяют зависимости...<br />
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.<br />
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.<br />
&gt; Особенно смущают jpackage-utils и rpm-build-java.<br />
jpackage-utils здесь потому, что в log4j есть приложения.<br />
для их запуска рекомендуется строить classspath с помощью<br />
скрипта build-classpath<br />
а не указывать библиотеки явно.<br />
Например<br />
java -cp \<br />
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \<br />
<class><br />
Кстати, это советую сделать для azaureus.<br />
<br />
с rpm-build-java, боюсь, findreq наshellил.<br />
в свободное время посмотрю.<br />
<br />
<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?<br />
<viy> надо, но руки не доходят... увы, не многорукое Шиво...<br />
<viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.<br />
<br />
<raorn> ага, я видел. вкусные функции там<br />
<raorn> а дока есть? или экспортируемые переменные большой секрет?<br />
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.<br />
документация разная есть, в процессе написания, сейчас брошу ссылки<br />
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]<br />
1) перевод полиси [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
2) текущие заготовки [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java]<br />
<br />
==== приложения с разделяемыми библиотеками ====<br />
<raorn> а ещё build-classpath не умеет абсолютные пути к жарам<br />
<viy> в смысле? нельзя ж абсолютные пути.<br />
<raorn> у меня софтина в /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]]<br />
<raorn> или в %_javadir положить?<br />
<raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus<br />
[12:24:08] <raorn> он находит [[Java/Azureus2.jar|Azureus2.jar]]<br />
<br />
<viy> по стандарту<br />
[http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java]<br />
библиотека ищется в нескольких местах<br />
<raorn> это я уже подсмотрел<br />
<br />
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,<br />
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.<br />
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] -- <br />
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, <br />
и ее нужно паковать в %_javadir и вообще соблюдать policy. <br />
если же это глубоко личная библиотека приложения, то хоть в /opt :)<br />
<br />
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются<br />
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.<br />
<br />
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?<br />
<raorn> это в корне неверно?<br />
<viy> да, неверно. граблей слишком много,<br />
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...<br />
<raorn> но если говоришь надо - переделаю ;-)<br />
<raorn> мне ещё наверно зымбру собирать...<br />
<viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется<br />
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )<br />
а от явного указания и в /opt не скроешься.<br />
<raorn> ну тогда ладно<br />
<br />
==== Советы по замене устаревших макросов set/add_classpath ====<br />
<br />
здесь пример избавления от макросов.<br />
<br />
54c54<br />
< %set_classpath %_javadir/junit.jar<br />
<br/>> export CLASSPATH=$(build-classpath junit)<br />
<br />
Замечание. build-classpath junit<br />
в отличие от %set_classpath %_javadir/junit.jar<br />
ищет junit.jar в нескольких местах,<br />
кроме того, выругается, если его не найдет.<br />
<br />
ну и<br />
56c56<br />
< %ant_build \<br />
<br/>> %ant \<br />
<br />
On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?<br />
<br />
Это дословная конструкция, а не самая удачная.<br />
Как если бы перевести "I have a friend" через<br />
"Я имею друга".<br />
<br />
Расскажу на абстрактном примере сборки пакета malvina.<br />
Пусть в build.xml этого пакета добавлена проверка на<br />
наличие в classpath класса boy.class, при наличии<br />
которого malvina.jar собирается с новыми возможностями.<br />
<br />
Пусть ранее boy.class предоставлялся pierre.jar.<br />
В результате изменений pierre.jar исчез, а<br />
появился buratino.jar, который и предоставляет boy.class.<br />
<br />
Теперь рассмотрим, что произойдет при использовании<br />
в спек-файле различных конструкций.<br />
<br />
1) %add_classpath /usr/share/java/pierre.jar<br />
В этом случае пакет молча пересоберется без замечаний,<br />
но malvina.jar потеряет существенную часть функциональности.<br />
<br />
2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)<br />
В этом случае пакет пересоберется,<br />
malvina.jar потеряет существенную часть функциональности,<br />
но в процессе сборки будет ругань, которую внимательный<br />
майнтайнер может заметить и исправить пакет,<br />
заменив pierre на buratino.<br />
<br />
3) обычно при сборке через ant подключаемые библиотеки<br />
ищутся в ./lib. В таком случае можно написать<br />
ln -s $(build-classpath pierre) ./lib<br />
Этот вариант превосходен тем, что malvina не захочет собирться<br />
до тех пор, пока ее майнтайнер не сменит pierre на buratino.</div>SergeyLebedev