Java/JavaPackagingFAQ
Материал из ALT Linux Wiki
(→Пакеты с лицензией Sun Binary Code License.) |
(→Hasher) |
||
(66 промежуточных версий не показаны.) | |||
Строка 1: | Строка 1: | ||
- | |||
{{Викифицировать}} | {{Викифицировать}} | ||
- | |||
__TOC__ | __TOC__ | ||
- | |||
- | |||
- | |||
- | |||
---- | ---- | ||
==== Одни и те же пакеты с разными именами в 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 после окончания переезда на новое имя. | |
- | + | ||
- | : | + | |
---- | ---- | ||
- | ==== | + | ==== Что означает 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 между двумя строчками: | ||
+ | :<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>? | ||
- | |||
- | |||
- | |||
;viy > | ;viy > | ||
- | |||
- | |||
:идея <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-софт в сизифе, что где когда ==== | ||
- | |||
- | |||
;viy > | ;viy > | ||
:я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>: | :я написал скрипт <tt>jppstat</tt>. в <tt>jppimport.git</tt>: | ||
- | + | :он генерирует списки всех java пакетов в Сизифе с владельцами согласно acl. | |
- | : | + | ---- |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
==== Пакеты с лицензией Sun Binary Code License. ==== | ==== Пакеты с лицензией Sun Binary Code License. ==== | ||
Строка 142: | Строка 164: | ||
==== Что сейчас возможно сделать, для пересборки 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> и все понятно становится |
- | + | ;viy > | |
- | viy > а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг 1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но | + | :теперь конкретно по 2 мантейнеры в <tt>jpackage</tt> не блещут. из вышеизложенного следует, |
+ | :что для 90% пакетов (не сервера, не GUI) кривизна спека не играет роли, лишь бы на выходе были правильно названные jar. | ||
+ | ;lsv > | ||
+ | :да, это пожалуй центральный момент | ||
+ | ;viy > | ||
+ | :а стандартность играет. по опыту, и это прискорбно, у меня расход сил на пляску с бубном вокруг | ||
+ | :1 нестандарта от старой team был приблиз. равен расходу сил на импорт 10-30 jar из jpackage. | ||
+ | :несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но не стандартные. | ||
---- | ---- | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
==== Все ли java пакеты требуют jpackage полиси? ==== | ==== Все ли java пакеты требуют jpackage полиси? ==== | ||
- | lsv > при каком случаи пакет может не требовать полиси | + | ;lsv > : |
- | viy > в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс? | + | при каком случаи пакет может не требовать полиси? |
- | + | ;viy > | |
- | + | :в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс? | |
- | + | :обоснование. | |
- | + | :1) есть <tt>Jpackage FHS</tt> ему надо следовать _всегда._ | |
- | + | :в смысле куда что ложить. | |
- | + | :2) есть <tt>jpackage build system (build-classpath)</tt>, другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться? | |
- | + | :ответ -- если человек пишет спек с нуля (в jpackage нет) не обязательно, но желательно. | |
- | + | ;lsv > | |
- | + | :в jpackage -- основной момент имя пакета | |
- | + | :и имя jar-файла | |
- | + | :утилита <tt>build-classpath</tt> и <tt>find-jar</tt> -- удобны, но и без них можно жить | |
- | + | ;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 и общие рекомендации по имени пакета, добавив | + | :в смысле строгого соблюдения jpackage полиси -- у меня ответ -- те и только те, которые есть в jpackage. Обосновано? |
- | viy > не точно. | + | ;lsv > |
- | + | :а если такой же пакет появляется в jpackage с другим именем, обязан ли мантейнер сменить имя своего пакета | |
- | + | ;viy > | |
- | + | :например Дамир регулярно в ant добавляет симлинки и Provides:. xerces-j тоже так совместим | |
- | jpackage является 'почти' (95% случаев) правильным | + | :симлинками и 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 | + | ;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? |
- | Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук. | + | :Для полноты счастья и мира во всем мире. |
- | + | ;Алексей Турбин > | |
- | + | :Дело здесь совсем не в сроках. Многие программы, грубо говоря, давно уже написаны и работают. | |
- | + | :Типа вот [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] | |
- | + | :Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук. | |
- | + | ||
- | + | ||
---- | ---- | ||
+ | ==== Обсуждение определителя зависимостей и загрузчика классов ==== | ||
+ | [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 > |
- | + | :цитирую наше полиси: | |
+ | :Необходимо обеспечивать максимальную запускаемость на разных 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 по умолчанию | ||
Строка 230: | Строка 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 пока не отмечено. |
- | + | </pre> | |
- | фича 1.7 и по моим наблюдениям, глючит с javadoc | + | |
- | + | ;viy > | |
- | java 1.4.2 в основном и собирают :) source и target в значении 1.3 или | + | :править <tt>build.xml</tt> крайне ресурсоемко, |
- | меньше ленятся прописывать :( | + | :<tt>ant -Dsource -D target</tt> - фича 1.7 и по моим наблюдениям, глючит с <tt>javadoc</tt> |
- | + | :в jpackage люди сами выбирают чем собирать | |
- | + | :<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 | + | <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" | + | "Damir Shayhutdinov" > |
добавьте | добавьте | ||
allowed_mountpoints=/proc в /etc/hasher-priv/system | allowed_mountpoints=/proc в /etc/hasher-priv/system | ||
--mountpoints=/proc в параметры hasher. | --mountpoints=/proc в параметры hasher. | ||
- | + | Также man hasher-priv.conf | |
+ | </pre> | ||
---- | ---- | ||
==== java-select ==== | ==== java-select ==== | ||
- | + | <div style="display: inline; color: red;">deprecated</div> | |
- | lsv > существует переключалка между jvm'ами? | + | ;lsv > |
- | + | :существует переключалка между jvm'ами? аналог select-gcc ? | |
- | viy > нет. | + | ;viy > |
- | lsv > вот жшь | + | :нет. |
- | viy > там 5-7 альтернатив сразу переключить надо :( | + | ;lsv > |
- | + | :вот жшь | |
- | lsv > ну да | + | ;viy > |
- | + | :там 5-7 альтернатив сразу переключить надо :( | |
- | viy > не знаю как побороть лучше. | + | :совместимость называется ;( |
- | + | ;lsv > | |
+ | :ну да | ||
+ | :уродство | ||
+ | ;viy > | ||
+ | :не знаю как побороть лучше. | ||
+ | :наверно проще будет одномоментно обновить все jvm. | ||
+ | ---- | ||
==== Правила для Java ==== | ==== Правила для Java ==== | ||
- | From: Michael Pozhidaev | + | <pre> |
- | + | From: Michael Pozhidaev | |
+ | Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? | ||
+ | From: Igor Vlasenko | ||
сконвертировал с помощью [http://git.altlinux.org/people/viy/packages/jppimport.git http://git.altlinux.org/people/viy/packages/jppimport.git]. | сконвертировал с помощью [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] | см. [http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings] | ||
- | + | ||
+ | From: Michael Pozhidaev | ||
+ | У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. | ||
+ | Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки | ||
+ | или можно упаковать самому, соблюдая какие-нибудь правила? | ||
+ | |||
+ | From: Igor Vlasenko | ||
скорее наоборот: | скорее наоборот: | ||
Если пакет есть на JPackage, незачем делать дурную работу за робота. | Если пакет есть на JPackage, незачем делать дурную работу за робота. | ||
- | Если его там нет, то придется паковать. И тут в помощь | + | Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux Java Policy]] |
- | [[Java|ALT Linux Java Policy]] | + | </pre> |
+ | ---- | ||
==== Переименовывать ли пакеты Java? ==== | ==== Переименовывать ли пакеты Java? ==== | ||
- | ===== Обсуждение с Виталием ===== | + | =====Обсуждение с Виталием===== |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ;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 > |
- | + | :Я собственно хотел бы, чтобы причины сформулированы в полиси | |
- | + | ;viy > | |
- | + | :причина - совместимость. | |
- | java -cp a:b:c:d run | + | :например, <tt>libz.so</tt> можно было бы назвать |
- | + | :<tt>libz-pureС-altcore.so</tt> | |
- | Это пример запуска программы? | + | :и патчить все <tt>configure.am</tt>, чтобы линковаться |
- | + | :<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... | ||
+ | :Ужас :) | ||
+ | |||
+ | ---- | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
==== Советы по сборке пакетов с помощью maven2 ==== | ==== Советы по сборке пакетов с помощью maven2 ==== | ||
- | + | <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 | + | |
Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp, | Для сборки rpm пакетов надо использовать /usr/bin/mvn-jpp, | ||
- | который вызывает mvn с | + | который вызывает mvn с -Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars |
- | - | + | |
- | 2) | + | 2) для сборки, кроме mvn, нужен еще репозиторий pom'ов. |
- | для сборки, кроме mvn, нужен еще репозиторий pom'ов. | + | |
В отсутствие maven2 в сизифе, часть пакетов была собрана | В отсутствие maven2 в сизифе, часть пакетов была собрана | ||
"без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle) | "без-pom'ощными", есть хак вокруг (maven2-bootstrap-bundle) | ||
Строка 441: | Строка 581: | ||
репозиторий 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 | ||
Строка 448: | Строка 587: | ||
будет опубликован 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) | ||
- | + | Nov 26, 2007 Slava Dubrovskiy wrote: | |
+ | > На выходных сделал подход к снаряду. | ||
+ | > На текущей пакетной базе это | ||
+ | > сделать нельзя, т.к. в репозитории нет плагинов и pom которые нужны для | ||
+ | > сборки (не хватает очень много, мне кажется %80). | ||
Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня | Я бегло просмотрел корневой pom и pom'ы в подпроектах верхнего уровня | ||
Строка 464: | Строка 609: | ||
зависимостей, а в неинформированности maven2. | зависимостей, а в неинформированности maven2. | ||
Я ее опишу далее. | Я ее опишу далее. | ||
+ | |||
С плагинами несколько по другому, там | С плагинами несколько по другому, там | ||
плагины с groupId:org.apache.maven.plugins у нас в основном должны быть, | плагины с groupId:org.apache.maven.plugins у нас в основном должны быть, | ||
Строка 476: | Строка 622: | ||
и мне хотелось собрать все сразу, не выковыривая из сборки отдельные | и мне хотелось собрать все сразу, не выковыривая из сборки отдельные | ||
плагины. | плагины. | ||
+ | |||
Это достаточно скоро будет. | Это достаточно скоро будет. | ||
- | + | > Собрал с закачкой из инета после чего локальный репозиторий (папка .m2) | |
+ | > стал размером в 250MB. | ||
кстати, листинг find .m2 -type f вышлите, пожалуйста. | кстати, листинг find .m2 -type f вышлите, пожалуйста. | ||
очень был бы удобен чтобы одним взглядом увидеть все зависимости. | очень был бы удобен чтобы одним взглядом увидеть все зависимости. | ||
- | + | > Вопрос: Возможно ли чтобы в пакетах maven2 было все что есть в | |
+ | > репозиториях интернета? Как можно помочь ускорить этот процесс? | ||
Как я говорил, большинство зависимостей уже есть. | Как я говорил, большинство зависимостей уже есть. | ||
- | Когда-то было проблемой сказать maven2 где они | + | Когда-то было проблемой сказать maven2 где они |
+ | наивный подход к сборке (иногда даже использовался, с maven1) | ||
создать в RPM/BUILD/name папку .m2 и набросать туда, | создать в RPM/BUILD/name папку .m2 и набросать туда, | ||
копируя структуру /.m2, симлинки вида | копируя структуру /.m2, симлинки вида | ||
Строка 516: | Строка 666: | ||
Потом можно будет разложить эти 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 вопрос] | ||
- | |||
- | |||
- | |||
- | + | <pre> | |
- | < | + | 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 | |
- | + | </pre> | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | < | + | |
- | + | ||
- | + | ;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 | ||
+ | :а не указывать библиотеки явно. | ||
- | + | :Например | |
- | < | + | :<tt>java -cp \ |
- | + | :$(build-classpath xerces-j xml-commons-jaxp-1.3-apis commons-logging) \ | |
+ | :<class></tt> | ||
- | + | :Кстати, это советую сделать для azaureus. | |
- | + | ||
- | + | :с rpm-build-java, боюсь, findreq наshellил. | |
- | документация разная есть, в процессе написания, сейчас брошу ссылки | + | :в свободное время посмотрю. |
- | + | ||
- | 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 не умеет абсолютные пути к жарам | |
- | + | ;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 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 > | |
+ | :это я уже подсмотрел | ||
- | + | ;viy > | |
- | у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать. | + | :проблема в линковке. по сути в скрипте запуска происходит линковка, |
- | + | :у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать. | |
- | если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, | + | :что касается /usr/share/azureus/Azureus2.jar -- |
- | и ее нужно паковать в %_javadir и вообще соблюдать policy. | + | :если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, |
- | если же это глубоко личная библиотека приложения, то хоть в /opt :) | + | :и ее нужно паковать в %_javadir и вообще соблюдать policy. |
+ | :если же это глубоко личная библиотека приложения, то хоть в /opt :) | ||
- | + | ;raorn > | |
- | + | :это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются | |
+ | ;viy > | ||
+ | :юзают его для сборки => разделяемая библиотека. тогда в %_javadir. | ||
- | + | ;raorn > | |
- | + | :а использование java -jar с правильным Class-Path в манифесте не приветствуется? | |
- | + | :это в корне неверно? | |
- | + | ;viy > | |
- | + | :да, неверно. граблей слишком много, | |
- | + | ;raorn > | |
- | + | :я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать... | |
- | ('*' в classpath у нас запрещены, чревато [http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Dependency conflicts] ) | + | :но если говоришь надо - переделаю ;-) |
- | а от явного указания и в /opt не скроешься. | + | :мне ещё наверно зымбру собирать... |
- | + | ;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 ==== | ||
Строка 596: | Строка 779: | ||
здесь пример избавления от макросов. | здесь пример избавления от макросов. | ||
- | + | <pre> | |
- | + | %set_classpath %_javadir/junit.jar | |
- | + | export CLASSPATH=$(build-classpath junit) | |
Замечание. build-classpath junit | Замечание. build-classpath junit | ||
Строка 606: | Строка 789: | ||
ну и | ну и | ||
- | + | %ant_build \ | |
- | + | %ant \ | |
- | < | + | </pre> |
- | + | <pre> | |
+ | Jul 23, 2008 | ||
+ | Kirill Maslinsky wrote: | ||
+ | > > export CLASSPATH=$(build-classpath junit) | ||
+ | > Кстати, а почему бы эту конструкцию не завернуть в макрос? | ||
Это дословная конструкция, а не самая удачная. | Это дословная конструкция, а не самая удачная. | ||
Строка 644: | Строка 831: | ||
Этот вариант превосходен тем, что 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}}}} |
Текущая версия на 15:16, 13 ноября 2010
Одни и те же пакеты с разными именами в 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
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. Также man hasher-priv.conf
java-select
- lsv >
- существует переключалка между jvm'ами? аналог select-gcc ?
- viy >
- нет.
- lsv >
- вот жшь
- viy >
- там 5-7 альтернатив сразу переключить надо :(
- совместимость называется ;(
- lsv >
- ну да
- уродство
- viy >
- не знаю как побороть лучше.
- наверно проще будет одномоментно обновить все jvm.
Правила для Java
From: Michael Pozhidaev Здравствуйте! Игорь, я так понял, что Вы jasperReports просто переложили из JPackage? From: Igor Vlasenko сконвертировал с помощью [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] From: Michael Pozhidaev У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. Если пакета нет на JPackage , то какая политика предполагается: лучше вообще воздержаться от упаковки или можно упаковать самому, соблюдая какие-нибудь правила? From: Igor Vlasenko скорее наоборот: Если пакет есть на JPackage, незачем делать дурную работу за робота. Если его там нет, то придется паковать. И тут в помощь [[Java|ALT Linux 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 у нас в основном не генерируются, и соблюдения каких-либо доп. соглашений от них ожидать нельзя.