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

Материал из ALT Linux Wiki
м (→‎Правила для Java: стилизировал заодно)
 
(не показаны 32 промежуточные версии 8 участников)
Строка 1: Строка 1:
[[Category:Policy]]
{{Викифицировать}}
{{Викифицировать}}
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/JavaPackagingFAQ}}


__TOC__
__TOC__


----
=== Общая концепция импорта java-пакетов в Сизифе ===
;viy >
:для меня цель достигнута если мы импортируем все [http://jpackage.org jpackage] в сизиф.
----
----
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====
==== Одни и те же пакеты с разными именами в jpackage и в Сизифе ====
Строка 14: Строка 8:
;lsv >  
;lsv >  
:одни и те же пакеты с разными именами
:одни и те же пакеты с разными именами
:хотя бы в имени релиза
;viy >  
;viy >  
:есть, но тут все просто.
:есть, но тут все просто.
:1) есть пакеты с разными <tt>ABI/API</tt>
:1) есть compat-пакеты одной и той же библиотеки разных версий с разными <tt>ABI/API</tt>
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt>
:напр. тот же <tt>jcommon0</tt> и <tt>jcommon</tt>.
:2) есть пакеты с одним и тем же содержимым.
:2) есть переименованные пакеты и пакеты со старым именем с совместимым содержимым.
:это мусор, я стараюсь чистить.
:Например xmlgraphics-batik и batik.
: примеров мало.
:последние уходят в Obsolete после окончания переезда на новое имя.
:по памяти помню вроде <tt>bsf vs. jakarta-bsf</tt>.
:они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..
----
----


==== Текущий список задач и статус пересборки пакетов из jpackage в Сизиф. ====
==== Что означает jpp5 в релизе? ====
какие-то отметки хранятся в  
 
[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]
Пакеты, импортированные роботом из JPackage и Fedora, имеют релиз вида
alt<M>_<N>jpp<K>, где M - релиз в альт, N - релиз в JPackage или Fedora,
K - версия JVM, для которой собран данный пакет.
Текущие значения:
* 1.7 (от JPackage 1.7) java 1.4 и выше
* 5 (от JPackage 5 и Java 5) java 1.5 и выше
* 6 (от JPackage 6 и Java 6) java 1.6 и выше
 
Пакеты, собранные человеком, для которых нет аналога в Fedora/JPackage, имеют релиз вида
alt<M>_jvm<K>, где M - релиз в альт,
K - версия JVM, для которой собран данный пакет.
Текущие значения:
* 5 (от Java 5) java 1.5 и выше
* 6 (от Java 6) java 1.6 и выше
 
Это удобно: не заглядывая в пакет, можно сказать, под какими JVM он будет запускаться,
а под какими нет.
 
==== Нужен ли Epoch: в java пакетах? ====
 
Не нужен, если это оригинальный пакет для ALT Linux.
 
Однако, в импортированных пакетах, а их большинство из имеющихся, стоит Epoch:0 и выше.
Это нужно для совместимости с JPackage.  
Epoch:0 разные версии rpm обрабатывают по-разному, поэтому, чтобы не зависеть от rpm.
JPackage пакеты всегда имеют Epoch: и часто ссылаются на другие пакеты с явным указанием
Epoch:, например, Requires: jakarta-commons-cli >= 0:1.1
 
Поэтому для частичной сборочной и установочной совместимости все пакеты, которые
соответствуют пакетам из JPackage, должны иметь Epoch: не меньше того, который в JPackage.
 
Для оригинальных пакетов ALT Linux, аналог которых в JPackage отсутствует,
Epoch: указывать не нужно.
 
==== Epoch в jpackage пакетах ====
;Damir >
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.
:То есть для apt или rpm между двумя строчками:
:<tt>Conflicts: foo < version-release</tt>
:<tt>Conflicts: foo < 0:version-release</tt>
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.
 
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.
 
==== Что такое jppimport и как использовать ====
==== Что такое jppimport и как использовать ====


Строка 65: Строка 102:
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?


:ага, типа у нас пакет называется одним боком, а у них другим
:а он прослойка для rpm'а
:нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.
;viy >  
;viy >  
:напимер надо было <tt>xerces-j</tt> фиксить. Я Женю 3 недели упрашивал. :(
:или месяц, уже не помню... а пока ждал, то совал сюда <tt>provides, symlinks, requires</tt> место которых ? в соотв. пакетах.
:идея <tt>jpackage-xx-compat</tt>
:идея <tt>jpackage-xx-compat</tt>
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду
Строка 98: Строка 130:
==== java-софт в сизифе, что где когда ====
==== java-софт в сизифе, что где когда ====


;lsv >
:не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все
;viy >  
;viy >  
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>:
;viy >
:он генерирует списки всех java пакетов в Сизифе с владельцами согласно acl.
:<tt>wc java-alt-packages.owners</tt>
:<tt>361 java-alt-packages.owners</tt>
 
<pre>viy > $ grep nobody java-alt-packages.owners
--je      @nobody--
trang  @nobody</pre>
 
;viy >
:как видим, не так уж много пакетов.
----
----


Строка 152: Строка 173:
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.
:что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.
;lsv >  
;lsv >  
:да
:да, это пожалуй центральный момент
:это пожалуй центральный момент
;viy >  
;viy >  
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг  
:а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг  
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage.  
:1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage.  
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные.  
:несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные.  
----
==== Epoch в jpackage пакетах ====
;Damir >
:apt или rpm по-разному воспронимают сравнение V-R и S:V-R.
:То есть для apt или rpm между двумя строчками:
:<tt>Conflicts: foo < version-release</tt>
:<tt>Conflicts: foo < 0:version-release</tt>
:есть большая разница. В первом случае <tt>Serial</tt> не сравниваются, а во втором - сравниваются.
:Это принуждает например <tt>jpackage</tt> использовать явно указанный <tt>Epoch:0</tt> во всех спеках.
:Что, кстати, совсем не понимают наши роботы, которые выводят разницу в
:<tt>changelog-ах</tt> для обновившихся пакетов. Это давно мозолит глаз.
----
----


Строка 184: Строка 190:
:в смысле куда что ложить.
:в смысле куда что ложить.
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?
:2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?
:ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.
:ответ -- если человек пишет спек с нуля (в jpackage нет) не обязательно, но желательно.
:если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать
:тогда да. имеет.
;lsv >  
;lsv >  
:в jpackage -- основной момент имя пакета
:в jpackage -- основной момент имя пакета
;viy >
:а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева,
:только интегрировать ее с jpackage-utils. проще и доступнее.
;lsv >
:и имя jar-файла
:и имя jar-файла
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить
:утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить
Строка 220: Строка 220:
:имитатор просто разрушит систему сборки импортированных пакетов.
:имитатор просто разрушит систему сборки импортированных пакетов.
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:
:ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:
:jpackage является 'почти' (95% случаев) правильным репозитарием. java зависимости не автоматические  
:jpackage является 'почти' (95% случаев) правильным репозиторием. java зависимости не автоматические  
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если  
:но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если  
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка
:у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка
Строка 239: Строка 239:
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.
----
----
 
==== Обсуждение определителя зависимостей и загрузчика классов ====
==== /usr/share/java не соответствует /usr/lib ====
[http://lists.altlinux.org/pipermail/devel/2008-January/subject.html [devel]] Java: no magic wand / [devel] Java: no magic wand, no magic hammer
;viy >
начиная с [http://lists.altlinux.org/pipermail/devel/2008-January/068361.html http://lists.altlinux.org/pipermail/devel/2008-January/068361.html].
:<tt>/usr/share/java</tt> никак не соответствует <tt>/usr/lib</tt>. это скорее <tt>/opt.</tt>
:<tt>PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin</tt> то же что
:<tt>CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar</tt>
----


==== Почему все пакеты собираем jav'ой 1.4.2? ====
==== Почему все пакеты собираем jav'ой 1.4.2? ====
Строка 284: Строка 280:
:него костыль, иначе он всегда поставит 1.7
:него костыль, иначе он всегда поставит 1.7
----
----
==== Почему у java-пакета дикие зависимости? ====
ОТВЕТ: эти библиотеки, вообще говоря, друг другу по зависимостям нужны, так как в каких-то случаях используются.
Это то же самое, если gnomer/gtkшник поставил
себе какой-нибудь kfurrent, а тот ему пол kde в систему втянул.
Никто же по этому поводу не ругается и не предлагает
линковать kfurrent с qt4 и kde libs статически.
Да, первый kde пакет затянет в систему пол kde, зато потом
второй kde пакет и последующие ничего в систему тянуть не будут.
Почему же такое возмущение по поводу java?
Там то же самое:
первый java пакет затянет в систему пол java, зато потом
второй java пакет и последующие ничего в систему тянуть не будут.
Кто хочет без зависимостей, ставьте себе в хомяк.
см. тж. обсуждение
https://bugzilla.altlinux.org/show_bug.cgi?id=18456


==== Hasher ====
==== Hasher ====
<pre>2007/10/26,
Yury A.Romanov >
пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом.  При попытке сборки в hasher - выдает следующую ошибку:
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file:
No such file or directory error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)
"Damir Shayhutdinov" >
добавьте
allowed_mountpoints=/proc в /etc/hasher-priv/system
--mountpoints=/proc в параметры hasher.


и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(
;damned >
: при сборке в hasher получаю:<br><tt>/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory</tt>
;lost >
: добавьте <tt>allowed_mountpoints=/proc</tt> в {{path|/etc/hasher-priv/system}} и <tt>--mountpoints=/proc</tt> в параметры {{cmd|hsh}}; также {{cmd|man hasher-priv.conf}}
</pre>
</pre>
----
----
Строка 322: Строка 333:


==== Правила для Java ====
==== Правила для Java ====
<pre>
From: Michael Pozhidaev
Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage?


From: Igor Vlasenko
;msp >
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].
: Игорь, я так понял, что Вы jasperReports просто переложили из JPackage?
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings]  
 
;viy >
: сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git]<!--, см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] -- 404 по состоянию на 20180411 -->


From: Michael Pozhidaev
;msp >
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java.
: У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки или можно упаковать самому, соблюдая какие-нибудь правила?
Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки  
или можно упаковать самому, соблюдая какие-нибудь правила?


From: Igor Vlasenko
;viy >
скорее наоборот:
: скорее наоборот:<br>Если пакет есть на JPackage, незачем делать дурную работу за робота.<br>Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Java Policy]]
Если пакет есть на JPackage, незачем делать дурную работу за робота.
Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]]
</pre>
----


==== Переименовывать ли пакеты Java? ====
==== Переименовывать ли пакеты Java? ====
Строка 582: Строка 586:
> На выходных сделал подход к снаряду.  
> На выходных сделал подход к снаряду.  
> На текущей пакетной базе это  
> На текущей пакетной базе это  
> сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для
> сделать нельзя, т.к. в репозитории нет плагинов и pom которые нужны для
> сборки (не хватает очень много, мне кажется %80).
> сборки (не хватает очень много, мне кажется %80).


Строка 606: Строка 610:


Это достаточно скоро будет.
Это достаточно скоро будет.
> Собрал с закачкой из инета после чего локальный репозитарий (папка .m2)  
> Собрал с закачкой из инета после чего локальный репозиторий (папка .m2)  
> стал размером в 250MB.
> стал размером в 250MB.


Строка 612: Строка 616:
очень был бы удобен чтобы одним взглядом увидеть все зависимости.
очень был бы удобен чтобы одним взглядом увидеть все зависимости.
> Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в  
> Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в  
> репозитариях интернета? Как можно помочь ускорить этот процесс?
> репозиториях интернета? Как можно помочь ускорить этот процесс?


Как я говорил, большинство зависимостей уже есть.
Как я говорил, большинство зависимостей уже есть.
Строка 706: Строка 710:
: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]
: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]
: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]
: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]
----


==== приложения с разделяемыми библиотеками ====
==== приложения с разделяемыми библиотеками ====
Строка 760: Строка 765:
здесь пример избавления от макросов.
здесь пример избавления от макросов.


54c54
<pre>
< %set_classpath %_javadir/junit.jar
%set_classpath %_javadir/junit.jar
<br/>> export CLASSPATH=$(build-classpath junit)
export CLASSPATH=$(build-classpath junit)


Замечание. build-classpath junit
Замечание. build-classpath junit
Строка 770: Строка 775:


ну и
ну и
56c56
%ant_build \
< %ant_build \
%ant \
<br/>> %ant \
</pre>


On Wed, Jul 23, 2008 at 10:57:13AM +0400, Kirill Maslinsky wrote: &gt; > > export CLASSPATH=$(build-classpath junit) &gt; Кстати, а почему бы эту конструкцию не завернуть в макрос?
<pre>
Jul 23, 2008  
Kirill Maslinsky wrote:  
> > export CLASSPATH=$(build-classpath junit)  
> Кстати, а почему бы эту конструкцию не завернуть в макрос?


Это дословная конструкция, а не самая удачная.
Это дословная конструкция, а не самая удачная.
Строка 808: Строка 817:
Этот вариант превосходен тем, что malvina не захочет собирться
Этот вариант превосходен тем, что malvina не захочет собирться
до тех пор, пока ее майнтайнер не сменит pierre на buratino.
до тех пор, пока ее майнтайнер не сменит pierre на buratino.
</pre>
----
==== Q: будут ли еще какие-либо макросы для сборки с помощью ant, кроме %ant ? ====
A: Нет, к сожалению, универсальные макросы для %ant
не возможны по самой природе ant.
файлы build.xml по своей природе подобны
самописанным Makefile.
По той же причине для make не существует универсальных
макросов, кроме %make.
Хорошей иллюстрацией к сказанному служат наши макросы
%make_install, %makeinstall_std… итд.
Эти макросы возможны потому, что большинство пакетов
собирается autotools. Поэтому у них Makefile генерированы,
а у генерированных Makefile, в отличие от самописанных
Makefile, соблюдаются определенные соглашения,
что и позволяет создавать дополнительные макросы.
Эти дополнительные макросы с самописанной системой сборки
работать не будут. Другое дело, что для С в большинстве своем
самописанные системы сборки вымерли :)
файлы build.xml у нас в основном не генерируются,
и соблюдения каких-либо доп. соглашений от них ожидать нельзя.
{{Category navigation|title=Java|category=Java|sortkey={{SUBPAGENAME}}}}
{{Category navigation|title=FAQ|category=FAQ|sortkey={{SUBPAGENAME}}}}

Текущая версия от 16:19, 11 апреля 2018

42px-Wikitext-ru.svg.png
Эту статью следует викифицировать.



Одни и те же пакеты с разными именами в jpackage и в Сизифе

lsv >
одни и те же пакеты с разными именами
viy >
есть, но тут все просто.
1) есть compat-пакеты одной и той же библиотеки разных версий с разными ABI/API
напр. тот же jcommon0 и jcommon.
2) есть переименованные пакеты и пакеты со старым именем с совместимым содержимым.
Например xmlgraphics-batik и batik.
последние уходят в Obsolete после окончания переезда на новое имя.

Что означает jpp5 в релизе?

Пакеты, импортированные роботом из JPackage и Fedora, имеют релиз вида alt<M>_<N>jpp<K>, где M - релиз в альт, N - релиз в JPackage или Fedora, K - версия JVM, для которой собран данный пакет. Текущие значения:

  • 1.7 (от JPackage 1.7) java 1.4 и выше
  • 5 (от JPackage 5 и Java 5) java 1.5 и выше
  • 6 (от JPackage 6 и Java 6) java 1.6 и выше

Пакеты, собранные человеком, для которых нет аналога в Fedora/JPackage, имеют релиз вида alt<M>_jvm<K>, где M - релиз в альт, K - версия JVM, для которой собран данный пакет. Текущие значения:

  • 5 (от Java 5) java 1.5 и выше
  • 6 (от Java 6) java 1.6 и выше

Это удобно: не заглядывая в пакет, можно сказать, под какими JVM он будет запускаться, а под какими нет.

Нужен ли Epoch: в java пакетах?

Не нужен, если это оригинальный пакет для ALT Linux.

Однако, в импортированных пакетах, а их большинство из имеющихся, стоит Epoch:0 и выше. Это нужно для совместимости с JPackage. Epoch:0 разные версии rpm обрабатывают по-разному, поэтому, чтобы не зависеть от rpm. JPackage пакеты всегда имеют Epoch: и часто ссылаются на другие пакеты с явным указанием Epoch:, например, Requires: jakarta-commons-cli >= 0:1.1

Поэтому для частичной сборочной и установочной совместимости все пакеты, которые соответствуют пакетам из JPackage, должны иметь Epoch: не меньше того, который в JPackage.

Для оригинальных пакетов ALT Linux, аналог которых в JPackage отсутствует, Epoch: указывать не нужно.

Epoch в jpackage пакетах

Damir >
apt или rpm по-разному воспронимают сравнение V-R и S:V-R.
То есть для apt или rpm между двумя строчками:
Conflicts: foo < version-release
и
Conflicts: foo < 0:version-release
есть большая разница. В первом случае Serial не сравниваются, а во втором - сравниваются.
Это принуждает например jpackage использовать явно указанный Epoch:0 во всех спеках.
Что, кстати, совсем не понимают наши роботы, которые выводят разницу в
changelog-ах для обновившихся пакетов. Это давно мозолит глаз.

Что такое jppimport и как использовать

viy >
вы srpm руками пишете или через jppimport ?
lsv >
jppimport, потом смотрю что на выходе, spec этого пакета
viy >
эта система задумывалась на автоматизацию сопровождения, т. е. хранить в hooks алгоритм правок и накладывать его каждый раз при выходе новой версии.
lsv >
хорошая задумка
viy >
иначе вырастает трудоемкость
при выходе новой версии надо разбираться, что и где правилось.
/src/repo/jppimport.git/jppmass --strategy altup -c '- updated to new jpackage release' `cat viy-java-files-list` |& tee altup
это, например, запуск робота с заданием конвертировать новые версии пакетов из jpackage в сизиф.
потом я
for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log
и уже руками делаю новые хуки для фикса того, что не пересобралось автоматом.
lsv >
отлично
viy >
еще пример ?
/src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`
запуск робота с заданием конвертировать версии пакетов из jpackage, которых в сизифе нет.
я после того, как руками подаботаю, запускал /src/repo/jppimport.git/jppmass --strategy jpppick `cat jpackage-list`
и for i in ./OUT/*.rpm; do echo hsh-ing $i; hsh --with-stuff --mountpoints=/proc /tmp/hasher $i ; done |& tee hsh.log
сразу давал улов.
запускаю в цикле, пока новые пакеты не перестают сами собой собираться, потом смотрю, что мешает дальнейшей сборке.
отсюда пожелание, как то документировать правки, чтобы их можно было написать как hooks.

jpackage-xx-compat

lsv >
что такое jpackage-1.4-compat
почему jppimport его вставляет в spec?
viy >
идея jpackage-xx-compat
в том, что в jpackage сборчная среда богаче, чем хешер. в нем прописаны requires на эту среду
(unzip, ant-junit, ...)
это jpackage-generic-compat.
кроме того, есть еще 2 пакета для ленивых
jpackage-1.4-compat и jpackage-1.5-compat
jpackage-1.4-compat это на самом деле require jpackage-generic-compat + set java 1.4.2
проще собрать сразу java-1.4.2. тогда автоматом source и target в значении 1.4

jboss и все, все все

viy >
jboss альтовский. собран java 1.5 и его нельзя использовать при сборке с java 1.4
а все собирать самой свежей жавой тоже нельзя ? оно просто не соберется.
lsv >
в jpackage идет разделение по веткам.
viy >
в jpackage целых 3 jboss
2 в 1.7 и 1 в 5.0.
наш jboss примерно соответствует по версии тому в в 5.0., но собран с другим бубном.
на примере jboss это легко решается.
переименовать его в jboss42-j2se15 и собрать рядом из jpackage. я давно бы так сделал, будь это ничей пакет.

java-софт в сизифе, что где когда

viy >
я написал скрипт jppstat. в jppimport.git:
он генерирует списки всех java пакетов в Сизифе с владельцами согласно acl.

Пакеты с лицензией Sun Binary Code License.

viy >
сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.
сантехника = Sun Binary Code License.

Про поддержку пакетов в jpackage

lsv >
мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.
viy >
да. конечно. но проблема в следующем. утрируя, можно сказать
кому они нужны?
типичный всюду плотный пакет из jpackage сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,
звено пищевой цепочки зависимостей. как в природе
для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.
пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же jpackage до 20. может, до 10 на самом деле.
более того, в jpackage особо и нет например, пакетов GUI, мелких утилит пользователя. он по замыслу предоставляет библиотечно полную базовую среду для сборки такого рода софта. нечто вроде java basesystem.
lsv >
это хорошо
viy >
с такого рода софтом другая крайность
в С хоть есть соглашения о именовании библиотек, а в жабе нет. я тогда пытался сослаться.
там дискуссия есть, как это правильно будет. например maven использует подход
публичный url.

Что сейчас возможно сделать, для пересборки jpackage-хозяйства.

viy >
поэтому реальная ценность jpackage
в том, что он задает стандарты именования. Потому и топы (RH/FC Md Su SE? etc) сидят на нем.
lsv >
ну это на поверхности. Достаточно глянуть на jpackage.org и все понятно становится
viy >
теперь конкретно по 2 мантейнеры в jpackage не блещут. из вышеизложенного следует,
что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar.
lsv >
да, это пожалуй центральный момент
viy >
а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг
1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage.
несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные.

Все ли java пакеты требуют jpackage полиси?

lsv >

при каком случаи пакет может не требовать полиси?

viy >
в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс?
обоснование.
1) есть Jpackage FHS ему надо следовать _всегда._
в смысле куда что ложить.
2) есть jpackage build system (build-classpath), другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?
ответ -- если человек пишет спек с нуля (в jpackage нет) не обязательно, но желательно.
lsv >
в jpackage -- основной момент имя пакета
и имя jar-файла
утилита build-classpath и find-jar -- удобны, но и без них можно жить
viy >
3) в в jpackage -- основной момент имя пакета и имя jar-файла.
если даного пакета в jpackage нет, то как узнать его имя?
lsv >
нужно назвать его так, чтобы не было конфликта имен при условии появления его в jpackage
viy >
здесь могут быть только рекомендации. 100% угадать нельзя.
lsv >
понятно что нет
viy >
в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано?
lsv >
а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета
viy >
например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим
симлинками и Provides.
lsv >
на мой взгляд лучше переписать jpackage policy оствавив только FHS и общие рекомендации по имени
пакета, добавив alt-specific, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage
viy >
не точно.
если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета.
с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ?
имитатор просто разрушит систему сборки импортированных пакетов.
ok. итак, имитатор просто разрушит систему сборки импортированных пакетов. почему:
jpackage является 'почти' (95% случаев) правильным репозиторием. java зависимости не автоматические
но они 'правильные' поскольку взяты с 'правильного' т. е. живого и тестируемого репозитория. если
у имитатора не хватает provides/requires, либо не предоставляет интерфейс альтернативами, либо не хватает симлинка
50% вероятности, что сборка сломается.
viy >
это не версионированные jar чаще ломают, чем версионированные jar,
но отсутствие версионированных jar тоже может сломать (и ломает)

Автоопределение зависимостей для java

lsv >
А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build?
Для полноты счастья и мира во всем мире.
Алексей Турбин >
Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают.
Типа вот http://git.altlinux.org/people/at/packages/?p=rpm-build-java.git;a=summary
Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.

Обсуждение определителя зависимостей и загрузчика классов

[devel] Java: no magic wand / [devel] Java: no magic wand, no magic hammer начиная с http://lists.altlinux.org/pipermail/devel/2008-January/068361.html.

Почему все пакеты собираем jav'ой 1.4.2?

viy >
цитирую наше полиси:
Необходимо обеспечивать максимальную запускаемость на разных JVM
11.03.2006
mhz@ сообщает: 
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые
теперь выбираются по умолчанию в сборочной среде, появилась новая
особенность при сборке пакетов на Java.  Компилятор JDK 1.5 по умолчанию
создает class-файлы, несовместимые с ранними версиями J2SE. Поэтому
необходимо следить, чтобы в сборочных скриптах для ant или make
компилятор вызывался с параметрами source и target в значении 1.3 или
меньше (т.к. у нас в Sisyphus есть еще j2se1.3-sun), если код не требует
иного. Если в коде используется ключевое слово assert, нужно ставить как
минимум 1.4; пакетов, использующих нововведения Java SE 5, в Sisyphus
пока не отмечено.

viy: 
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 
(Не злоупотреблять. только если код написан под Java 5).
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.
viy >
править build.xml крайне ресурсоемко,
ant -Dsource -D target - фича 1.7 и по моим наблюдениям, глючит с javadoc
в jpackage люди сами выбирают чем собирать
java 1.4.2 в основном и собирают :) source и target в значении 1.3 или
меньше ленятся прописывать :(
openjdk
в jpackage люди сами выбирают чем собирать. у нас выбирает hasher. для
него костыль, иначе он всегда поставит 1.7

Почему у java-пакета дикие зависимости?

ОТВЕТ: эти библиотеки, вообще говоря, друг другу по зависимостям нужны, так как в каких-то случаях используются.

Это то же самое, если gnomer/gtkшник поставил себе какой-нибудь kfurrent, а тот ему пол kde в систему втянул. Никто же по этому поводу не ругается и не предлагает линковать kfurrent с qt4 и kde libs статически.

Да, первый kde пакет затянет в систему пол kde, зато потом второй kde пакет и последующие ничего в систему тянуть не будут.

Почему же такое возмущение по поводу java?

Там то же самое: первый java пакет затянет в систему пол java, зато потом второй java пакет и последующие ничего в систему тянуть не будут. Кто хочет без зависимостей, ставьте себе в хомяк.

см. тж. обсуждение https://bugzilla.altlinux.org/show_bug.cgi?id=18456

Hasher

damned >
при сборке в hasher получаю:
/usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
lost >
добавьте allowed_mountpoints=/proc в /etc/hasher-priv/system и --mountpoints=/proc в параметры hsh; также man hasher-priv.conf

java-select

deprecated
lsv >
существует переключалка между jvm'ами? аналог select-gcc ?
viy >
нет.
lsv >
вот жшь
viy >
там 5-7 альтернатив сразу переключить надо :(
совместимость называется ;(
lsv >
ну да
уродство
viy >
не знаю как побороть лучше.
наверно проще будет одномоментно обновить все jvm.

Правила для Java

msp >
Игорь, я так понял, что Вы jasperReports просто переложили из JPackage?
viy >
сконвертировал с помощью http://git.altlinux.org/people/viy/packages/jppimport.git
msp >
У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки или можно упаковать самому, соблюдая какие-нибудь правила?
viy >
скорее наоборот:
Если пакет есть на JPackage, незачем делать дурную работу за робота.
Если его там нет, то придется паковать. И тут в помощь ALT Java Policy

Переименовывать ли пакеты Java?

Обсуждение с Виталием
viy >
есть серьезные причины не трогать имена,
как такой вариант -- суффикс?
почти все пакеты имеют в релизе пакета суффикс jppX.X
можно дополнить для остальных суффикс jvmX.X
например maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm
Lav >
Я собственно хотел бы, чтобы причины сформулированы в полиси
viy >
причина - совместимость.
например, libz.so можно было бы назвать
libz-pureС-altcore.so
и патчить все configure.am, чтобы линковаться
-lz-pureС-altcore
Но так не делают.
Lav >
Какое отношение название пакета имеет к линковке?
И почему-то вся значимая информация в сиюминутном поле релиза :)
viy >
аналог линковки -- создание classpath: java -cp a:b:c:d run
Lav >
Я, если честно, в java мало понимаю.
Это пример запуска программы?
viy >
для библиотек есть 1) фиксированный путь
/lib + /usr/lib
2) канонические имена (libz.so.*)
поэтому имя rpm пакета в Prov особой роли не играет...
Lav >
А для java какую роль пакет играет?
viy >
проприетарщина для C может указывать зависимости вида libXft.so(64bit) и
они будут дистрибутивно не зависимы, имя пакета особой роли не играет.
Открытые программы тоже могут сказать хотим -lXft
с java это не пройдет они просто не найдут друг друга
Поэтому есть стандарт и все rpm дистрибутивы ему следуют.
иначе куча работы как в примере выше с libz-pureС-altcore.so
Lav >
Нет, я никак не пойму связи названия пакета и classpath
viy >
Это другая тема.
поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.
я хочу, чтобы до окончания работ
1) оставалась возможность установить сторонние пакеты (мне не важно)
2) всегда оставалась возможность
иметь совместимость по srpm
(т. е. чтобы я мог разрабатывать в ALT
java пакеты, которые после нативной пересборки работают
от fedora до novell)
это мне важно.
3) очень многих пакетов в Сизифе еще нет.
добавление их в несовместимую среду потребует кучу пустой работы наподобие -lz-pureС-altcore.
Lav >
все нормальные программы используют pkgconfig и не заботятся о названии библиотек :)
viy >
но заботятся о названии pc - файла.
что будет, если программа надеется на libpcre.pc, а в Сизифе лежит пакет с libpcre-pureC.pc ?
Lav >
До окончания каких работ?
viy >
я хочу создать полную среду разработки.
в которой нет необходимости ставить сторонние пакеты.
Lav >
То есть в FC и в Novell вот так же накиданы пакеты?
viy >
да.
Lav >
И я всё же не понимаю, какая разница - указывать в спеке Requires: java-isorelax
или
Requires: isorelax
Это же просто вопрос принятого соглашения.
viy >
оно не бесплатно.
Lav >
Дело в том, что после создания полной среды разработки пакетов будет столько,
что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.
viy >
нет. я же руками ничего не делаю.
отшлифовываю робота для проведения массовых операций.
с ним мне не принципиально, пересобрать 2 пакета или 2000.
у меня спеки правит робот.
Lav >
Таким образом, есть надежда, что со временем робота можно переучить?
viy >
мне важно 2) -- чтобы всегда оставалась возможность
иметь совместимость по srpm
(т. е. чтобы я мог разрабатывать в ALT
java пакеты, которые после нативной пересборки работают
от fedora до novell)
Lav >
Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)
viy >
робот работает согласно jpackage.org policy.
раньше у нас не было совместимости с jpackage.
Lav >
В общем ситуацию я примерно понял... Спасибо за объяснение...
viy >
ok.
для java библиотек вменяемые спеки и не нужны.
не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.
Эта ситуация когда отсутствует сборочная среда.
когда она уже есть, тогда можно уже собирать приложения.
они и требуют ручной работы.
от библиотек требуется. чтобы они были.
Lav >
По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage
viy >
1) несовместимостей много
2) нельзя будет проверки зависимостей внедрить и т. д.
у меня спеки заменяет набор хуков для робота.
в простых случаях их нет. в запущенных имеем
...
: $jpp->disable_package('plugin-jalopy');
< и другие примеры команд роботу>
...

Обсуждение с Денисом
viy >
хотел бы попросить рассказать что неудобно
Mithraen >
Отсутствие префиксов типа java- или аналогичных
viy >
я уже говорил с lav@
уже де-факто есть суффикс.
Mithraen >
Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)
Какой суффикс?
viy >
можно это выписать в полиси и к пакетам добавлять
jvmX.Y (работает с java X.Y и выше) либо jppP.Q
jpackage repository P.Q/
jvm4.2==jpp1.7
jvm5.0==jpp5.0
Mithraen >
Гм.
Не уверен что такая подробность (версия в имени) нужна
А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен
viy >
можно будет написать робот такого типа:
vpupkin@ собрал пакет с суффиксом jvm4.2
но он собран 1.6.0 без -target 1.4
соответственно в 1.4\1.5 работать не будет.
Mithraen >
К примеру log4j -- без поллитры не поймешь что это жаба :)
А с provides/requires при этом что делать?
Они-ж еще и по файлам пересекаться небось будут :(
Или делать abc-jvm4.2 conflicts abc-jvm5.0?
viy >
нет. пакет должен быть собран для наименьшей возможной java.
т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.
пример junit (jvm4.2) и junit4 (jvm5.0)
Mithraen >
А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?
viy >
да.
Mithraen >
Их придется дублировать
viy >
лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.
а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.
автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.
в ней любой пакет можно будет по отдельности пересобрать.
Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.
Mithraen >
Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей
Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни
viy >
можно...
но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте.
Не нравилось мне работать в <чужом дистрибутиве>.
Соответственно совместимость это полезная вещь, она денег стоит.
Смысла ее ломать из-за эстетических соображений я не вижу.
Это удар по разработчикам.
Mithraen >
Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя
viy >
бесполезная работа отнимает кучу время/денег тоже.
Mithraen >
А соображения эти не эстетического характера, а следствия элементарного удобства
Mithraen >
apt-cache search log | grep java -- это удобно
viy >
я же предложил суффикс :)
pcregrep '(jvm|jpp)\d\.\d$'
Mithraen >
Суффикс это точно такое же переименование
От необходимости делать provides на jpackage name не спасет
viy >
нет. он же в Release. на зависимости не влияет.
Mithraen >
А.. в release...
Ужас :)

Советы по сборке пакетов с помощью maven2

Nov 14, 2007 
 Slava Dubrovskiy wrote: 
QA Team Download Robot пишет: 
> List of files which have been downloaded from the "devel" 
> incoming: maven2-2.0.4-alt1_10jpp1.7.src.rpm 
Ура! Заждались уже.

В связи с этим несколько hints.
1) /usr/bin/mvn -- это обычный "онлайновый" maven2.
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,
который вызывает mvn с -Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars

2) для сборки, кроме mvn, нужен еще репозиторий pom'ов.
В отсутствие maven2 в сизифе, часть пакетов была собрана
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)
но я надеюсь быстро пересобрать такие пакеты, так что
относительно полноценный (по модулю -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions)
репозиторий pom'ов будет.

3) Свежие примеры сборки с помощью maven2
plexus-cdc-1.0-alt1_0.a4.3jpp1.7.src.rpm
plexus-logging-provider-test-1.0-alt1_0.a2.1jpp1.7.src.rpm
уже лежат в инкоминге. Они попадут в Сизиф, как только там
будет опубликован maven2.

4) костыль maven2-plugins-2.0.4-alt1
вытягивает maven2 вместе со всеми plugins.
Удобен, когда заранее неизвестно, какие плагины понадобятся.

разбор полетов с maven2
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)
Nov 26, 2007 Slava Dubrovskiy wrote:
> На выходных сделал подход к снаряду. 
> На текущей пакетной базе это 
> сделать нельзя, т.к. в репозитории нет плагинов и pom которые нужны для
> сборки (не хватает очень много, мне кажется %80).

Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня
экзотики там мало, почти все зависимости уже собраны.

Там проблема, решаемая, скорее не в отсутствии
зависимостей, а в неинформированности maven2.
Я ее опишу далее.

С плагинами несколько по другому, там
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,
а плагины с groupId:org.codehaus.mojo я просто еще не выложил в сизиф,
там целый букет плагинов
mojo-maven2-plugin-axistools, ...-build-helper, ...-castor, ...-changes,
...-clirr, ...-cobertura, ...-commons-attributes, ...-dependency,
...-exec,
...-fit, ...-idlj, ...-javacc, ...-javancss, ...-jdepend, ...-jdiff,
...-jpox, ...-jspc, ...-jxr, ...-keytool, ...-sql, ...-taglist,
...-xdoclet, ...-xmlbeans, ...-xslt
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные
плагины.

Это достаточно скоро будет.
> Собрал с закачкой из инета после чего локальный репозиторий (папка .m2) 
> стал размером в 250MB.

кстати, листинг find .m2 -type f вышлите, пожалуйста.
очень был бы удобен чтобы одним взглядом увидеть все зависимости.
> Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в 
> репозиториях интернета? Как можно помочь ускорить этот процесс?

Как я говорил, большинство зависимостей уже есть.
Когда-то было проблемой сказать maven2 где они 
наивный подход к сборке (иногда даже использовался, с maven1)
создать в RPM/BUILD/name папку .m2 и набросать туда,
копируя структуру /.m2, симлинки вида
groupid/artifactid-version.jar -> /usr/share/java/real.jar

Проблема была в том, что структура /usr/share/java/
не совпадает со структурой maven-репозитория.

Чтобы преодолеть эту трудность, используется описанный в
maven2-manual в /usr/share/doc/maven2-2.0.4/maven2-jpp-readme.html
следующий прием.
В файле /etc/maven/maven2-depmap.xml
каждому pom сопоставляется real.jar в /usr/share/java/.
Этот файл собирается из кусочков в /etc/maven/fragments/*
при %post/%postun java пакетов.

Другие приемы считаются устаревшими, я о них говорить не буду.

Таким образом, если пакет устанавливает свой pom в /usr/share/maven2/poms,
и свой depmap в /etc/maven/fragments/, то maven2 его найдет при поиске
зависимостей.
Иначе будет ситуация, что пакет установлен, jar в /usr/share/java/ есть,
но maven2 его не видит.

И затруднение в том, что еще не так много пакетов это делает
(носит для своих jar'ов pom'ы и depmap fragments).

Однако и решение достаточно просто. можно сделать пакет для сборочной
среды, который будет устанавливать для maven2 нужные pom и fragments.

Потом можно будет разложить эти pom и fragments по соответствующим
пакетам, и нужда в костыле отпадет.

вопросы по упаковке пользовательских приложений на java

использование build-classpath из jpackage-utils

вопрос

Jan 29, 2008 
Alexey I. Froloff wrote: 
> $ sudo apt-get install jakarta-commons-cli log4j
> The following NEW packages will be installed:
> jpackage-utils log4j rpm-build-java
raorn >
.o0( ох проклянут меня за азуреусовские зависимости... )
viy >
скорее за их отсутствие :)
если не будет зависимостей, средняя софтина на java
будет тянуть 40-200 Mb. 1 софтина как весь
дистрибутив. а так они разделяют зависимости...
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.
C++ basesystem тоже ж не 10 Mb.
Особенно смущают jpackage-utils и rpm-build-java.
jpackage-utils здесь потому, что в log4j есть приложения.
для их запуска рекомендуется строить classspath с помощью
скрипта build-classpath
а не указывать библиотеки явно.
Например
java -cp \
$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \
<class>
Кстати, это советую сделать для azaureus.
с rpm-build-java, боюсь, findreq наshellил.
в свободное время посмотрю.
raorn >
а из jpackage-utils можно и -devel какой выделить если надо будет?
viy >
надо, но руки не доходят... увы, не многорукое Шиво...
там java-common Миши Забалуева был по сути попыткой написать
jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.
raorn >
ага, я видел. вкусные функции там
а дока есть? или экспортируемые переменные большой секрет?
viy >
дело в другом, что есть jpackage стандарты упаковки, и им следовать.
документация разная есть, в процессе написания, сейчас брошу ссылки
http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on
1) перевод полиси http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java
2) текущие заготовки http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings?v=wbt&search=Java

приложения с разделяемыми библиотеками

raorn >
а ещё build-classpath не умеет абсолютные пути к жарам
viy >
в смысле? нельзя ж абсолютные пути.
raorn >
у меня софтина в /usr/share/azureus/Azureus2.jar
или в %_javadir положить?
я при сборке плагинов говорю ant -lib %_datadir/azureus
он находит Azureus2.jar
viy >
по стандарту

http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java

библиотека ищется в нескольких местах
raorn >
это я уже подсмотрел
viy >
проблема в линковке. по сути в скрипте запуска происходит линковка,
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.
что касается /usr/share/azureus/Azureus2.jar --
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека,
и ее нужно паковать в %_javadir и вообще соблюдать policy.
если же это глубоко личная библиотека приложения, то хоть в /opt :)
raorn >
это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются
viy >
юзают его для сборки => разделяемая библиотека. тогда в %_javadir.
raorn >
а использование java -jar с правильным Class-Path в манифесте не приветствуется?
это в корне неверно?
viy >
да, неверно. граблей слишком много,
raorn >
я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...
но если говоришь надо - переделаю ;-)
мне ещё наверно зымбру собирать...
viy >
_javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется
('*' в classpath у нас запрещены, чревато Dependency conflicts )
а от явного указания и в /opt не скроешься.
raorn >
ну тогда ладно

Советы по замене устаревших макросов set/add_classpath

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

%set_classpath %_javadir/junit.jar
export CLASSPATH=$(build-classpath junit)

Замечание. build-classpath junit
в отличие от %set_classpath %_javadir/junit.jar
ищет junit.jar в нескольких местах,
кроме того, выругается, если его не найдет.

ну и
 %ant_build \
 %ant \
Jul 23, 2008 
Kirill Maslinsky wrote: 
> > export CLASSPATH=$(build-classpath junit) 
> Кстати, а почему бы эту конструкцию не завернуть в макрос?

Это дословная конструкция, а не самая удачная.
Как если бы перевести "I have a friend" через
"Я имею друга".

Расскажу на абстрактном примере сборки пакета malvina.
Пусть в build.xml этого пакета добавлена проверка на
наличие в classpath класса boy.class, при наличии
которого malvina.jar собирается с новыми возможностями.

Пусть ранее boy.class предоставлялся pierre.jar.
В результате изменений pierre.jar исчез, а
появился buratino.jar, который и предоставляет boy.class.

Теперь рассмотрим, что произойдет при использовании
в спек-файле различных конструкций.

1) %add_classpath /usr/share/java/pierre.jar
В этом случае пакет молча пересоберется без замечаний,
но malvina.jar потеряет существенную часть функциональности.

2) export CLASSPATH=$CLASSPATH:$(build-classpath pierre)
В этом случае пакет пересоберется,
malvina.jar потеряет существенную часть функциональности,
но в процессе сборки будет ругань, которую внимательный
майнтайнер может заметить и исправить пакет,
заменив pierre на buratino.

3) обычно при сборке через ant подключаемые библиотеки
ищутся в ./lib. В таком случае можно написать
ln -s $(build-classpath pierre) ./lib
Этот вариант превосходен тем, что malvina не захочет собирться
до тех пор, пока ее майнтайнер не сменит pierre на buratino.

Q: будут ли еще какие-либо макросы для сборки с помощью ant, кроме %ant ?

A: Нет, к сожалению, универсальные макросы для %ant не возможны по самой природе ant. файлы build.xml по своей природе подобны самописанным Makefile. По той же причине для make не существует универсальных макросов, кроме %make.

Хорошей иллюстрацией к сказанному служат наши макросы %make_install, %makeinstall_std… итд.

Эти макросы возможны потому, что большинство пакетов собирается autotools. Поэтому у них Makefile генерированы, а у генерированных Makefile, в отличие от самописанных Makefile, соблюдаются определенные соглашения, что и позволяет создавать дополнительные макросы. Эти дополнительные макросы с самописанной системой сборки работать не будут. Другое дело, что для С в большинстве своем самописанные системы сборки вымерли :)

файлы build.xml у нас в основном не генерируются, и соблюдения каких-либо доп. соглашений от них ожидать нельзя.