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

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


__TOC__
__TOC__


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


==== Текущий список задач и статус пересборки пакетов из 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 и как использовать ====


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


lsv > что такое jpackage-1.4-compat
;lsv >  
lsv > почему jppimport его вставляет в spec?
:что такое <tt>jpackage-1.4-compat</tt>
:почему <tt>jppimport</tt> его вставляет в <tt>spec</tt>?


lsv > ага, типа у нас пакет называется одним боком, а у них другим
;viy >  
lsv > а он прослойка для rpm'а
:идея <tt>jpackage-xx-compat</tt>
viy > нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.
:в том, что в <tt>jpackage</tt> сборчная среда богаче, чем хешер. в нем прописаны <tt>requires</tt> на эту среду
viy > напимер надо было xerces-j фиксить. Я Женю 3 недели упрашивал. :(
:<tt>(unzip, ant-junit, ...)</tt>
viy > или месяц, уже не помню... а пока ждал, то совал сюда provides, symlinks, requires место которых ? в соотв. пакетах.
:это <tt>jpackage-generic-compat</tt>.
viy > идея jpackage-xx-compat
:кроме того, есть еще 2 пакета для ленивых
в том, что в jpackage сборчная среда богаче, чем хешер. в нем прописаны requires на эту среду
:<tt>jpackage-1.4-compat</tt> и <tt>jpackage-1.5-compat</tt>
(unzip, ant-junit, ...)
:<tt>jpackage-1.4-compat</tt> это на самом деле <tt>require jpackage-generic-compat + set java 1.4.2</tt>
viy > это jpackage-generic-compat.
:проще собрать сразу <tt>java-1.4.2</tt>. тогда автоматом source и target в значении 1.4
viy > кроме того, есть еще 2 пакета для ленивых
jpackage-1.4-compat и jpackage-1.5-compat
viy > jpackage-1.4-compat это на самом деле require jpackage-generic-compat + set java 1.4.2
viy > проще собрать сразу java-1.4.2. тогда автоматом source и target в значении 1.4
----
----


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


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


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


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


==== Пакеты с лицензией Sun Binary Code License. ====
==== Пакеты с лицензией Sun Binary Code License. ====
viy > сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.
;viy >  
viy > сантехника = Sun Binary Code License.
:сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.
:сантехника = <tt>Sun Binary Code License.</tt>
----


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


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


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


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


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


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


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


lsv < А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build? Для полноты счастья и мира во всем мире.
;lsv >
Алексей Турбин > Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. Типа вот [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]
:А для java? Поиск автозависимостей когда можно ожидать? Есть какие-нибудь сроки по новому rpm-build?  
Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.
:Для полноты счастья и мира во всем мире.
----
;Алексей Турбин >  
 
:Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают.  
==== /usr/share/java не соответствует /usr/lib ====
:Типа вот [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]
viy > /usr/share/java никак не соответствует /usr/lib. это скорее /opt.
:Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.
viy > PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin то же что
CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar
----
----
==== Обсуждение определителя зависимостей и загрузчика классов ====
[http://lists.altlinux.org/pipermail/devel/2008-January/subject.html [devel]] Java: no magic wand / [devel] Java: no magic wand, no magic hammer
начиная с [http://lists.altlinux.org/pipermail/devel/2008-January/068361.html http://lists.altlinux.org/pipermail/devel/2008-January/068361.html].


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


viy > цитирую наше полиси:
;viy >
viy > Необходимо обеспечивать максимальную запускаемость на разных JVM  
:цитирую наше полиси:
:Необходимо обеспечивать максимальную запускаемость на разных JVM  


<pre>11.03.2006
<pre>11.03.2006
mhz@ сообщает: В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые
mhz@ сообщает:  
В связи с появлением в Sisyphus пакетов j2se1.5-sun{,-devel}, которые
теперь выбираются по умолчанию в сборочной среде, появилась новая
теперь выбираются по умолчанию в сборочной среде, появилась новая
особенность при сборке пакетов на Java.  Компилятор JDK 1.5 по умолчанию
особенность при сборке пакетов на Java.  Компилятор JDK 1.5 по умолчанию
Строка 214: Строка 262:
пока не отмечено.
пока не отмечено.


viy: это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.
viy:  
это актуально всегда, только сейчас у нас наименьшие JVM - это java-1.4.2 sun и blackdown.
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.
соответственно, фраза выглядит теперь так: source и target в значении 1.4 или меньше.
если пакет использует нововведения Java SE 5, то source и target в значении 1.5 (Не злоупотреблять. только если код написан под Java 5).
если пакет использует нововведения Java SE 5, то source и target в значении 1.5  
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.</pre>
(Не злоупотреблять. только если код написан под Java 5).
viy > править build.xml крайне ресурсоемко,
пакетов, использующих нововведения JavaSE 6 и выше, в Sisyphus пока не отмечено.
viy > ant -Dsource -D target -
</pre>
фича 1.7 и по моим наблюдениям, глючит с javadoc
 
viy > в jpackage люди сами выбирают чем собирать
;viy >
java 1.4.2 в основном и собирают :) source и target в значении 1.3 или
:править <tt>build.xml</tt> крайне ресурсоемко,
меньше ленятся прописывать :(
:<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt>
viy > openjdk
:в jpackage люди сами выбирают чем собирать
viy > в jpackage люди сами выбирают чем собирать. у нас выбирает hasher. для него костыль, иначе он всегда поставит 1.7
:<tt>java 1.4.2</tt> в основном и собирают :) source и target в значении 1.3 или
:меньше ленятся прописывать :(
:<tt>openjdk</tt>
:в jpackage люди сами выбирают чем собирать. у нас выбирает <tt>hasher</tt>. для  
:него костыль, иначе он всегда поставит 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 ====
2007/10/26, Yury A.Romanov <damned&altlinux.ru>: &gt; пытаюсь собрать [[Java/OpenXchange|OpenXchange]] сервер под альтом.  При попытке сборки в hasher &gt; выдает следующую ошибку: &gt; /usr/lib/jvm/java/jre/bin/java: error while loading shared libraries: &gt; libjli.so: cannot open shared object file: No such file or directory &gt; error: Bad exit status from /usr/src/tmp/rpm- tmp.68276 (%prep)


"Damir Shayhutdinov" <damir@altlinux.org> :
;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>
allowed_mountpoints=/proc в /etc/hasher-priv/system
;lost >
--mountpoints=/proc в параметры hasher.
: добавьте <tt>allowed_mountpoints=/proc</tt> в {{path|/etc/hasher-priv/system}} и <tt>--mountpoints=/proc</tt> в параметры {{cmd|hsh}}; также {{cmd|man hasher-priv.conf}}
 
</pre>
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(
----
----


==== java-select ====
==== java-select ====


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


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


сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git].
;msp >
см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings]  
: Игорь, я так понял, что Вы jasperReports просто переложили из JPackage?
&gt;У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. &gt;Если пакета нет на JPackage , то какая политика предполагается: &gt;лучше вообще воздержаться от упаковки &gt;или можно упаковать самому, соблюдая какие-нибудь правила?
 
скорее наоборот:
;viy >
Если пакет есть на JPackage, незачем делать дурную работу за робота.
: сконвертировал с помощью [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 -->
Если его там нет, то придется паковать. И тут в помощь  
 
[[Java|ALT Linux Java Policy]]
;msp >
: У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки или можно упаковать самому, соблюдая какие-нибудь правила?
 
;viy >
: скорее наоборот:<br>Если пакет есть на JPackage, незачем делать дурную работу за робота.<br>Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Java Policy]]


==== Переименовывать ли пакеты Java? ====
==== Переименовывать ли пакеты Java? ====
===== Обсуждение с Виталием =====
=====Обсуждение с Виталием=====
[23:59:11] <viy> есть серьезные причины не трогать имена,
как такой вариант -- суффикс?
почти все пакеты имеют в релизе пакета суффикс jppX.X
можно дополнить для остальных суффикс jvmX.X
например maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm


[00:00:37] <Lav> Я собственно хотел бы, чтобы причины сформулированы в полиси
;viy >
[00:03:27] <viy> причина - совместимость.
:есть серьезные причины не трогать имена,
например, libz.so можно было бы назвать
:как такой вариант -- суффикс?
libz-pureС-altcore.so
:почти все пакеты имеют в релизе пакета суффикс jppX.X
и патчить все configure.am, чтобы линковаться
:можно дополнить для остальных суффикс jvmX.X
-lz-pureС-altcore
:например <tt>maven-plugin-xdoc-1.1-alt4_0.beta3.2jpp1.7.noarch.rpm</tt>
Но так не делают.
;Lav >  
[00:03:49] <Lav> Какое отношение название пакета имеет к линковке?
:Я собственно хотел бы, чтобы причины сформулированы в полиси
[00:04:23] <Lav> И почему-то вся значимая информация в сиюминутном поле релиза :)
;viy >  
[00:05:30] <viy> аналог линковки -- создание classpath:
:причина - совместимость.
java -cp a:b:c:d run
:например, <tt>libz.so</tt> можно было бы назвать
[00:07:07] <Lav> Я, если честно, в java мало понимаю.
:<tt>libz-pureС-altcore.so</tt>
Это пример запуска программы?
:и патчить все <tt>configure.am</tt>, чтобы линковаться
[00:07:11] <viy> для библиотек есть 1) фиксированный путь
:<tt>-lz-pureС-altcore</tt>
/lib + /usr/lib  
:Но так не делают.
2) канонические имена (libz.so.*)
;Lav >  
поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...
:Какое отношение название пакета имеет к линковке?
:И почему-то вся значимая информация в сиюминутном поле релиза :)
;viy >  
:аналог линковки -- создание <tt>classpath: java -cp a:b:c:d run</tt>
;Lav >  
:Я, если честно, в java мало понимаю.
:Это пример запуска программы?
;viy >
:для библиотек есть 1) фиксированный путь
:<tt>/lib + /usr/lib </tt>
:2) канонические имена (libz.so.*)
:поэтому имя rpm пакета в [[Java/Req/Prov|Prov]] особой роли не играет...
;Lav >
:А для java какую роль пакет играет?
;viy >
:проприетарщина для C может указывать зависимости вида <tt>libXft.so(64bit)</tt> и
:они будут дистрибутивно не зависимы, имя пакета особой роли не играет.
:Открытые программы тоже могут сказать хотим <tt>-lXft</tt>
:с java это не пройдет они просто не найдут друг  друга
:Поэтому есть стандарт и все rpm дистрибутивы ему следуют.
:иначе куча работы как в примере выше с <tt>libz-pureС-altcore.so</tt>
;Lav >
:Нет, я никак не пойму связи названия пакета и classpath
;viy >
:Это другая тема.
:поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.
:я хочу, чтобы до окончания работ
:1) оставалась возможность установить сторонние пакеты (мне не важно)
:2) всегда оставалась возможность
:иметь совместимость по srpm
:(т. е. чтобы я мог разрабатывать в ALT
:java пакеты, которые после нативной пересборки работают
:от fedora до novell)
:это мне важно.
:3) очень многих пакетов в Сизифе еще нет.
:добавление их в несовместимую среду потребует кучу пустой работы наподобие <tt>-lz-pureС-altcore.</tt>
;Lav >
:все нормальные программы используют <tt>pkgconfig</tt> и не заботятся о названии библиотек :)
;viy >
:но заботятся о названии pc - файла.
:что будет, если программа надеется на <tt>libpcre.pc</tt>, а в Сизифе лежит пакет с <tt>libpcre-pureC.pc</tt> ?
;Lav >
:До окончания каких работ?
;viy >
:я хочу создать полную среду разработки.
:в которой нет необходимости ставить сторонние пакеты.
;Lav >
:То есть в FC и в Novell вот так же накиданы пакеты?
;viy >
:да.
;Lav >
:И я всё же не понимаю, какая разница - указывать в спеке <tt>Requires: java-isorelax</tt>
:или
:<tt>Requires: isorelax</tt>
:Это же просто вопрос принятого соглашения.
;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) нельзя будет проверки зависимостей внедрить и т. д.
:у меня спеки заменяет набор хуков для робота.
:в простых случаях их нет. в запущенных имеем
:...
:<tt>: $jpp->disable_package('plugin-jalopy');</tt>
:<tt>< и другие примеры команд роботу></tt>
:...
 
----
 
=====Обсуждение с Денисом=====
;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 >
:<tt>apt-cache search log | grep java</tt> -- это удобно
;viy >
:я же предложил суффикс :)
:<tt>pcregrep '(jvm|jpp)\d\.\d$'</tt>
;Mithraen >
:Суффикс это точно такое же переименование
:От необходимости делать provides на jpackage name не спасет
;viy >
:нет. он же в Release. на зависимости не влияет.
;Mithraen >
:А.. в release...
:Ужас :)
 
----


[00:07:17] <viy> да
[00:07:28] <Lav> А для java какую роль пакет играет?
[00:10:27] <viy> проприетарщина для C может указывать зависимости вида libXft.so(64bit) и они будут дистрибутивно не зависимы, имя пакета особой роли не играет.
Открытые программы тоже могут сказать хотим -lXft
с java это не пройдет они просто не найдут друг  друга
[00:11:40] <viy> Поэтому есть стандарт и все rpm дистрибутивы ему следуют.
иначе куча работы как в примере выше с libz-pureС-altcore.so
[00:15:39] <Lav> Нет, я никак не пойму связи названия пакета и classpath
[00:23:31] <viy> Это другая тема.
поскольку переносимо нет другого способа указать зависимости, остается только указывать имя.
я хочу, чтобы до окончания работ
1) оставалась возможность установить сторонние пакеты (мне не важно)
2) всегда оставалась возможность
иметь совместимость по srpm
(т. е. чтобы я мог разрабатывать в ALT
java пакеты, которые после нативной пересборки работают
от fedora до novell)
это мне важно.
3) очень многих пакетов в Сизифе еще нет.
добавление их в несовместимую среду потребует кучу пустой работы наподобие -lz-pureС-altcore.
[00:16:24] <Lav> все нормальные программы используют pkgconfig и не заботятся о названии библиотек :)
[00:25:46] <viy> но заботятся о названии pc - файла.
что будет, если программа надеется на libpcre.pc, а в Сизифе лежит пакет с libpcre-pureC.pc ?
[00:24:48] <Lav> До окончания каких работ?
[00:25:46] <viy> я хочу создать полную среду разработки.
в которой нет необходимости ставить сторонние пакеты.
[00:25:48] <Lav>То есть в FC и в Novell вот так же накиданы пакеты?
[00:27:22] <viy> да.
[00:27:48] <Lav> И я всё же не понимаю, какая разница - указывать в спеке Requires: java-isorelax
или
Requires: isorelax
Это же просто вопрос принятого соглашения.
[00:28:06] <viy> оно не бесплатно.
[00:28:10] <Lav> Дело в том, что после создания полной среды разработки пакетов будет столько, что вы же первый скажете, что лучше пусть останется как есть, чем всё это менять.
[00:29:31] <viy> нет. я же руками ничего не делаю.
отшлифовываю робота для проведения массовых операций.
с ним мне не принципиально, пересобрать 2 пакета или 2000.
у меня спеки правит робот.
[00:30:09] <Lav> Таким образом, есть надежда, что со временем робота можно переучить?
[00:30:39] <viy> мне важно  2) -- чтобы всегда оставалась возможность
иметь совместимость по srpm
(т. е. чтобы я мог разрабатывать в ALT
java пакеты, которые после нативной пересборки работают
от fedora до novell)
[00:30:28] <Lav> Просто тогда совсем непонятно, почему робот не работает согласно полиси, а как ему проще :)
[00:30:58] <viy> робот работает согласно jpackage.org policy.
[00:31:38] <viy> раньше у нас не было совместимости с jpackage.
[00:33:05] <Lav> В общем ситуацию я примерно понял... Спасибо за объяснение...
[00:35:42] <viy> ok.
для java библиотек вменяемые спеки и не нужны.
не нормальна ситуация, когда чтобы собрать полезную вещь, нужно собрать 200 зависимых пакетов.
Эта ситуация когда отсутствует сборочная среда.
когда она уже есть, тогда можно уже собирать приложения.
они и требуют ручной работы.
от библиотек требуется. чтобы они были.
[00:36:09] <Lav> По моему было проще тогда сделать в ALT среду, которая позволяла бы напрямую ставить готовые пакеты с jpackage
[00:37:01] <viy> 1) несовместимостей много
2) нельзя будет проверки зависимостей внедрить и т. д.
у меня спеки заменяет набор хуков для робота.
в простых случаях их нет. в запущенных имеем
...
: $jpp->disable_package('plugin-jalopy');
< и другие примеры команд роботу>
...
===== Обсуждение с Денисом =====
10:55:12] <viy> хотел бы попросить рассказать что неудобно
[10:55:28] <Mithraen> Отсутствие префиксов типа java- или аналогичных
[10:56:07] <viy> я уже говорил с lav@
уже де-факто есть суффикс.
[10:56:10] <Mithraen> Хотел поинтересоваться что у нас сейчас с поиском зависимостей (я не в курсе что сейчас)
[10:56:22] <Mithraen> Какой суффикс?
[10:58:07] <viy> можно это выписать в полиси и к пакетам добавлять
jvmX.Y (работает с java X.Y и выше) либо jppP.Q
jpackage repository P.Q/
jvm4.2==jpp1.7
jvm5.0==jpp5.0
[10:59:16] <Mithraen> Гм.
[10:59:28] <Mithraen> Не уверен что такая подробность (версия в имени) нужна
[10:59:46] <Mithraen> А вот префикс типа java- для библиотек классов (не приложений!) был бы очень полезен
[11:01:23] <viy> можно будет написать робот такого типа:
vpupkin@ собрал пакет с суффиксом jvm4.2
но он собран 1.6.0 без -target 1.4
соответственно в 1.4\1.5 работать не будет.
[11:01:28] <Mithraen> К примеру log4j -- без поллитры не поймешь что это жаба :)
[11:01:50] <Mithraen> А с provides/requires при этом что делать?
[11:02:00] <Mithraen> Они-ж еще и по файлам пересекаться небось будут :(
[11:02:27] <Mithraen> Или делать abc-jvm4.2 conflicts abc-jvm5.0?
[11:02:36] <viy> нет. пакет должен быть собран для наименьшей возможной java.
[11:03:16] <viy> т.е. если пакет jvm5.0, то его принципиально нельзя собрать для java 1.4.
[11:03:50] <viy> пример junit (jvm4.2) и junit4 (jvm5.0)
[11:03:57] <Mithraen> А могут быть пакеты, которые при сборке другой jvm имеют меньший функционал?
[11:04:08] <viy> да.
[11:04:30] <Mithraen> Их придется дублировать
[11:05:07] <viy> лучше в подпакеты. как правило такая доп. функциональность вынесена в плагины.
[11:05:52] <viy> а в общем случае это как две версии одной библиотеки рядом. не желательно но терпимо.
[11:09:42] <viy> автопоиск зависимостей java хочу начать когда закончу создание сборочной среды.
в ней любой пакет можно будет по отдельности пересобрать. Эти схемы я сначала протестирую вне сизифа, чтобы не ломать Сизиф.
[11:22:38] <Mithraen> Краткий вывод из этого -- на имена можно (и нужно) забить до тех пор, пока не будет этого поиска зависимостей
[11:22:54] <Mithraen> Как будут -- оторвать вездегде только можно ручные requires и радоваться жизни
[11:26:22] <viy> можно...
но я взялся за жабу чтобы разрабатывать пакеты для <других дистрибутивов> в Альте.
Не нравилось мне работать в <чужом дистрибутиве>.
Соответственно совместимость это полезная вещь, она денег стоит.
Смысла ее ломать из-за эстетических соображений я не вижу.
Это удар  по разработчикам.
[11:27:01] <Mithraen> Дык можно чтобы её не ломать, делать provides в каждом пакете на jpackage имя
[11:27:36] <viy> бесполезная работа отнимает кучу время/денег тоже.
[11:27:39] <Mithraen> А соображения эти не эстетического характера, а следствия элементарного удобства
[11:28:13] <Mithraen> apt-cache search log | grep java -- это удобно
[11:28:22] <viy> я же предложил суффикс :)
pcregrep '(jvm|jpp)\d\.\d$'
[11:28:34] <Mithraen> Суффикс это точно такое же переименование
[11:29:02] <Mithraen> От необходимости делать provides на jpackage name не спасет
[11:29:04] <viy> нет. он же в Release. на зависимости не влияет.
[11:29:21] <Mithraen> А.. в release...
[11:29:23] <Mithraen> Ужас :)
==== Советы по сборке пакетов с помощью maven2 ====
==== Советы по сборке пакетов с помощью maven2 ====
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; Ура! Заждались уже.
<pre>
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.
В связи с этим несколько hints.
1)
1) /usr/bin/mvn -- это обычный "онлайновый" maven2.
/usr/bin/mvn <br/>это обычный "онлайновый" maven2.
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp,
который вызывает mvn с
который вызывает mvn с -Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars
-[[Java/Dmaven2.offline|Dmaven2.offline]].mode -[[Java/Dmaven2.ignore|Dmaven2.ignore]].versions -[[Java/Dmaven2.usejppjars|Dmaven2.usejppjars]]


2)
2) для сборки, кроме mvn, нужен еще репозиторий pom'ов.
для сборки, кроме mvn, нужен еще репозиторий pom'ов.
В отсутствие maven2 в сизифе, часть пакетов была собрана
В отсутствие maven2 в сизифе, часть пакетов была собрана
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle)
Строка 425: Строка 567:
репозиторий pom'ов будет.
репозиторий pom'ов будет.


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


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


===== разбор полетов с maven2 =====
===== разбор полетов с maven2 =====


<pre>
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)
Subject: Re: [devel] Сборка и упаковка opennms (используется maven2)
On Mon, Nov 26, 2007 at 11:33:07AM +0200, Slava Dubrovskiy wrote: &gt; На выходных сделал подход к снаряду. &gt; На текущей пакетной базе это &gt; сделать нельзя, т.к. в репозитарии нет плагинов и pom которые нужны для &gt; сборки (не хватает очень много, мне кажется %80).
Nov 26, 2007 Slava Dubrovskiy wrote:
> На выходных сделал подход к снаряду.  
> На текущей пакетной базе это  
> сделать нельзя, т.к. в репозитории нет плагинов и pom которые нужны для
> сборки (не хватает очень много, мне кажется %80).


Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня
Строка 448: Строка 595:
зависимостей, а в неинформированности maven2.
зависимостей, а в неинформированности maven2.
Я ее опишу далее.
Я ее опишу далее.
С плагинами несколько по другому, там
С плагинами несколько по другому, там
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть,
Строка 460: Строка 608:
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные
плагины.
плагины.
Это достаточно скоро будет.
Это достаточно скоро будет.
&gt; Собрал с закачкой из инета после чего локальный репозитарий (папка .m2) &gt; стал размером в 250MB.
> Собрал с закачкой из инета после чего локальный репозиторий (папка .m2)  
> стал размером в 250MB.


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


Как я говорил, большинство зависимостей уже есть.
Как я говорил, большинство зависимостей уже есть.
Когда-то было проблемой сказать maven2 где они <br/>наивный подход к сборке (иногда даже использовался, с maven1)
Когда-то было проблемой сказать maven2 где они  
наивный подход к сборке (иногда даже использовался, с maven1)
создать в RPM/BUILD/name папку .m2 и набросать туда,
создать в RPM/BUILD/name папку .m2 и набросать туда,
копируя структуру /.m2, симлинки вида
копируя структуру /.m2, симлинки вида
Строка 500: Строка 652:
Потом можно будет разложить эти pom и fragments по соответствующим
Потом можно будет разложить эти pom и fragments по соответствующим
пакетам, и нужда в костыле отпадет.
пакетам, и нужда в костыле отпадет.
</pre>
----


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


==== использование build-classpath из jpackage-utils ====
==== использование build-classpath из jpackage-utils ====
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]
[http://lists.altlinux.org/pipermail/devel/2008-January/069085.html вопрос]
On Tue, Jan 29, 2008 at 02:28:58PM +0300, Alexey I. Froloff wrote: &gt; $ sudo apt-get install jakarta-commons-cli log4j
... &gt; The following NEW packages will be installed:
... jpackage-utils log4j rpm-build-java


*raorn .o0( ох проклянут меня за азуреусовские зависимости... )
<pre>
<viy> скорее за их отсутствие :)
Jan 29, 2008
если не будет зависимостей, средняя софтина на java
Alexey I. Froloff wrote:
будет тянуть 40-200 Mb. 1 софтина как весь
> $ sudo apt-get install jakarta-commons-cli log4j
дистрибутив. а так они разделяют зависимости...
> The following NEW packages will be installed:
не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.
> jpackage-utils log4j rpm-build-java
[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.
</pre>
&gt; Особенно смущают 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 >
в свободное время посмотрю.
:.o0( ох проклянут меня за азуреусовские зависимости... )
;viy >
:скорее за их отсутствие :)
:если не будет зависимостей, средняя софтина на java
:будет тянуть 40-200 Mb. 1 софтина как весь
:дистрибутив. а так они разделяют зависимости...
:не azaureus, так что-то другое все равно вытянет java basesystem. Но 1 раз.
:[[Java/C/C|C]]++ basesystem тоже ж не 10 Mb.
:Особенно смущают jpackage-utils и rpm-build-java.
:jpackage-utils здесь потому, что в log4j есть приложения.
:для их запуска рекомендуется строить classspath с помощью
:скрипта build-classpath
:а не указывать библиотеки явно.


<raorn> а из jpackage-utils можно и -devel какой выделить если надо будет?
:Например
<viy> надо, но руки не доходят... увы, не многорукое Шиво...
:<tt>java -cp \
<viy> там java-common Миши Забалуева был по сути попыткой написать  jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.
:$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \
:<class></tt>


<raorn> ага, я видел. вкусные функции там
:Кстати, это советую сделать для azaureus.
<raorn> а дока есть? или экспортируемые переменные большой секрет?
 
[12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать.
:с rpm-build-java, боюсь, findreq наshellил.
документация разная есть, в процессе написания, сейчас брошу ссылки
:в свободное время посмотрю.
<viy> [http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]
 
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]
;raorn >
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]
:а из 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 http://www.freesource.info/wiki/FreeSource?phrase=Java&topic=on]
: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]
----


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


<viy> по стандарту
;viy >  
:по стандарту
[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]
[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]
библиотека ищется в нескольких местах
:библиотека ищется в нескольких местах
<raorn> это я уже подсмотрел
;raorn >  
:это я уже подсмотрел
 
;viy >
:проблема в линковке. по сути в скрипте запуска происходит линковка,
:у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.
:что касается /usr/share/azureus/Azureus2.jar --
:если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека,
:и ее нужно паковать в %_javadir и вообще соблюдать policy.
:если же это глубоко личная библиотека приложения, то хоть в /opt :)


<viy> проблема в линковке. по сути в скрипте запуска происходит линковка,
;raorn >  
у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать.
:это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются
<viy> что касается /usr/share/azureus/[[Java/Azureus2.jar|Azureus2.jar]] --
;viy >  
если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека,
:юзают его для сборки => разделяемая библиотека. тогда в %_javadir.
и ее нужно паковать в %_javadir и вообще соблюдать policy.  
если же это глубоко личная библиотека приложения, то хоть в /opt :)


<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются
;raorn >  
<viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.
:а использование java -jar с правильным Class-Path в манифесте не приветствуется?
:это в корне неверно?
;viy >
:да, неверно. граблей слишком много,
;raorn >
:я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...
:но если говоришь надо - переделаю ;-)
:мне ещё наверно зымбру собирать...
;viy >  
:_javadir не публична :)  только явно указав в classpath, кто-то с ней (с Azareus) слинкуется
:('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )
:а от явного указания и в /opt не скроешься.
;raorn >
:ну тогда ладно


<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется?
----
<raorn> это в корне неверно?
<viy> да, неверно. граблей слишком много,
<raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать...
<raorn> но если говоришь надо - переделаю ;-)
<raorn> мне ещё наверно зымбру собирать...
<viy> _javadir не публична :)  только явно указав в classpath, кто-то с ней (с Azareus) слинкуется
('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] )
а от явного указания и в /opt не скроешься.
<raorn> ну тогда ладно


==== Советы по замене устаревших макросов set/add_classpath ====
==== Советы по замене устаревших макросов set/add_classpath ====
Строка 580: Строка 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
Строка 590: Строка 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)  
> Кстати, а почему бы эту конструкцию не завернуть в макрос?


Это дословная конструкция, а не самая удачная.
Это дословная конструкция, а не самая удачная.
Строка 628: Строка 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}}}}

Текущая версия от 19: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 у нас в основном не генерируются, и соблюдения каких-либо доп. соглашений от них ожидать нельзя.