Java/JavaPackagingFAQ
Материал из ALT Linux Wiki
(→Пакеты с лицензией Sun Binary Code License.) |
(→java-софт в сизифе, что где когда) |
||
Строка 112: | Строка 112: | ||
;viy > | ;viy > | ||
:как видим, не так уж много пакетов. | :как видим, не так уж много пакетов. | ||
+ | ---- | ||
==== Пакеты с лицензией Sun Binary Code License. ==== | ==== Пакеты с лицензией Sun Binary Code License. ==== |
Версия 15:01, 15 августа 2008
Общая концепция импорта java-пакетов в Сизифе
- viy >
- для меня цель достигнута если мы импортируем все [[1]] в сизиф.
Одни и те же пакеты с разными именами в jpackage и в Сизифе
- lsv >
- одни и те же пакеты с разными именами
- хотя бы в имени релиза
- viy >
- есть, но тут все просто.
- 1) есть пакеты с разными ABI/API
- напр. тот же jcommon0 и jcommon
- 2) есть пакеты с одним и тем же содержимым.
- это мусор, я стараюсь чистить.
- примеров мало.
- по памяти помню вроде bsf vs. jakarta-bsf.
- они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..
Текущий список задач и статус пересборки пакетов из jpackage в Сизиф.
какие-то отметки хранятся в deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes
Что такое 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?
- ага, типа у нас пакет называется одним боком, а у них другим
- а он прослойка для rpm'а
- нет. то нас пакет называется одним боком, а у них другим ? это я просто хаки делал на чужие пакеты.
- viy >
- напимер надо было xerces-j фиксить. Я Женю 3 недели упрашивал. :(
- или месяц, уже не помню... а пока ждал, то совал сюда provides, symlinks, requires место которых ? в соотв. пакетах.
- идея 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-софт в сизифе, что где когда
- lsv >
- не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все
- viy >
- я написал скрипт jppstat. в jppimport.git:
- viy >
- wc java-alt-packages.owners
- 361 java-alt-packages.owners
viy > $ grep nobody java-alt-packages.owners --je @nobody-- trang @nobody
- viy >
- как видим, не так уж много пакетов.
Пакеты с лицензией 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 > да 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 полиси?
lsv > при каком случаи пакет может не требовать полиси& viy > в смысле строгого соблюдения jpackage полиси? у меня ответ ? те и только те, которые есть в jpackage. Парадокс? viy > обоснование. viy > 1) есть Jpackage FHS ему надо следовать _всегда._ viy > в смысле куда что ложить. viy > 2) есть jpackage build system (build-classpath), другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться? viy > ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда. viy > если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать тогда да. имеет. lsv > в jpackage -- основной момент имя пакета viy > а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева, только интегрировать ее с jpackage-utils. проще и доступнее. lsv > и имя jar-файла lsv > утилита 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 и общие рекомендации по имени пакета, добавив altspecific, типа имя релиза ? это alt$_jpp$ ? если пакет из jpackage viy > не точно. viy > если даного пакета в jpackage нет, то только FHS и общие рекомендации по имени пакета. viy > с пакетом, имеющим те же provides, что и в jpackage, этот номер не пройдет. Подобный пакет ? имитатор просто разрушит систему сборки импортированных пакетов. viy > 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 Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.
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
Почему все пакеты собираем jav'ой 1.4.2?
viy > цитирую наше полиси: 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 крайне ресурсоемко, viy > ant -Dsource -D target - фича 1.7 и по моим наблюдениям, глючит с javadoc viy > в jpackage люди сами выбирают чем собирать java 1.4.2 в основном и собирают :) source и target в значении 1.3 или меньше ленятся прописывать :( viy > openjdk viy > в jpackage люди сами выбирают чем собирать. у нас выбирает hasher. для него костыль, иначе он всегда поставит 1.7
Hasher
2007/10/26, Yury A.Romanov <damned&altlinux.ru>: > пытаюсь собрать 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@altlinux.org> : добавьте allowed_mountpoints=/proc в /etc/hasher-priv/system --mountpoints=/proc в параметры hasher.
и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(
java-select
lsv > существует переключалка между jvm'ами? lsv > аналог select-gcc ? viy > нет. lsv > вот жшь viy > там 5-7 альтернатив сразу переключить надо :( viy > совместимость называется ;( lsv > ну да lsv > уродство viy > не знаю как побороть лучше. viy > наверно проще будет одномоментно обновить все jvm.
Правила для Java
From: Michael Pozhidaev <msp@altlinux.ru>
> Здравствуйте! > Игорь, я так понял, что Вы jasperReports просто переложили из JPackage?
сконвертировал с помощью http://git.altlinux.org/people/viy/packages/jppimport.git. см. http://www.freesource.info/wiki/Altlinux/Policy/Java/JavaMainThings
>У меня всё-таки остался вопрос на будущее касательно правил сборки пакетов Java. >Если пакета нет на JPackage , то какая политика предполагается: >лучше вообще воздержаться от упаковки >или можно упаковать самому, соблюдая какие-нибудь правила?
скорее наоборот: Если пакет есть на JPackage, незачем делать дурную работу за робота. Если его там нет, то придется паковать. И тут в помощь ALT Linux Java Policy
Переименовывать ли пакеты 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> Я собственно хотел бы, чтобы причины сформулированы в полиси [00:03:27] <viy> причина - совместимость. например, libz.so можно было бы назвать libz-pureС-altcore.so и патчить все configure.am, чтобы линковаться -lz-pureС-altcore Но так не делают. [00:03:49] <Lav> Какое отношение название пакета имеет к линковке? [00:04:23] <Lav> И почему-то вся значимая информация в сиюминутном поле релиза :) [00:05:30] <viy> аналог линковки -- создание classpath: java -cp a:b:c:d run [00:07:07] <Lav> Я, если честно, в java мало понимаю. Это пример запуска программы? [00:07:11] <viy> для библиотек есть 1) фиксированный путь /lib + /usr/lib 2) канонические имена (libz.so.*) поэтому имя rpm пакета в Prov особой роли не играет...
[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
On Wed, Nov 14, 2007 at 08:57:29AM +0200, 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) но я надеюсь быстро пересобрать такие пакеты, так что относительно полноценный (по модулю -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) On Mon, Nov 26, 2007 at 11:33:07AM +0200, 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
вопрос On Tue, Jan 29, 2008 at 02:28:58PM +0300, 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> надо, но руки не доходят... увы, не многорукое Шиво... <viy> там java-common Миши Забалуева был по сути попыткой написать jpackage-utils, есть еще rpm-build-java, дублирует по макросам... их три слить в 1-2.
<raorn> ага, я видел. вкусные функции там <raorn> а дока есть? или экспортируемые переменные большой секрет? [12:05:52] <viy> дело в другом, что есть jpackage стандарты упаковки, и им следовать. документация разная есть, в процессе написания, сейчас брошу ссылки <viy> 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 <raorn> или в %_javadir положить? <raorn> я при сборке плагинов говорю ant -lib %_datadir/azureus [12:24:08] <raorn> он находит Azureus2.jar
<viy> по стандарту http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation?v=rgg&search=Java библиотека ищется в нескольких местах <raorn> это я уже подсмотрел
<viy> проблема в линковке. по сути в скрипте запуска происходит линковка, у нас и вообще в мире какого-то стандартного линковщика нет, а библиотеки могут скакать. <viy> что касается /usr/share/azureus/Azureus2.jar -- если есть потенциальная возможность, что его кто-то будет использовать, (внешние плагины?) то это разделяемая библиотека, и ее нужно паковать в %_javadir и вообще соблюдать policy. если же это глубоко личная библиотека приложения, то хоть в /opt :)
<raorn> это главная программа. плагины юзают его для сборки, но сами по себе они не запускаются <viy> юзают его для сборки => разделяемая библиотека. тогда в %_javadir.
<raorn> а использование java -jar с правильным Class-Path в манифесте не приветствуется? <raorn> это в корне неверно? <viy> да, неверно. граблей слишком много, <raorn> я бы просто не хотел приватную даже не либу, а софтину в публичные диры выкладывать... <raorn> но если говоришь надо - переделаю ;-) <raorn> мне ещё наверно зымбру собирать... <viy> _javadir не публична :) только явно указав в classpath, кто-то с ней (с Azareus) слинкуется ('*' в classpath у нас запрещены, чревато Dependency conflicts ) а от явного указания и в /opt не скроешься. <raorn> ну тогда ладно
Советы по замене устаревших макросов set/add_classpath
здесь пример избавления от макросов.
54c54
< %set_classpath %_javadir/junit.jar
> export CLASSPATH=$(build-classpath junit)
Замечание. build-classpath junit в отличие от %set_classpath %_javadir/junit.jar ищет junit.jar в нескольких местах, кроме того, выругается, если его не найдет.
ну и
56c56
< %ant_build \
> %ant \
On Wed, Jul 23, 2008 at 10:57:13AM +0400, 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.