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

Материал из ALT Linux Wiki
Строка 761: Строка 761:
здесь пример избавления от макросов.
здесь пример избавления от макросов.


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


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


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


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


Это дословная конструкция, а не самая удачная.
Это дословная конструкция, а не самая удачная.
Строка 809: Строка 813:
Этот вариант превосходен тем, что malvina не захочет собирться
Этот вариант превосходен тем, что malvina не захочет собирться
до тех пор, пока ее майнтайнер не сменит pierre на buratino.
до тех пор, пока ее майнтайнер не сменит pierre на buratino.
</pre>
----

Версия от 01:39, 26 августа 2008

42px-Wikitext-ru.svg.png
Эту статью следует викифицировать.
Freesource-logo.png Blue Glass Arrow.svg MediaWiki logo.png
Эта страница была перемещена с freesource.info.
Эта страница наверняка требует чистки и улучшения — смело правьте разметку и ссылки.
Просьба по окончанию убрать этот шаблон со страницы.



Общая концепция импорта java-пакетов в Сизифе

viy >
для меня цель достигнута если мы импортируем все jpackage в сизиф.

Одни и те же пакеты с разными именами в 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 >
да
это пожалуй центральный момент
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. Парадокс?
обоснование.
1) есть Jpackage FHS ему надо следовать _всегда._
в смысле куда что ложить.
2) есть jpackage build system (build-classpath), другие их утилки и примочки итд. Всегда ли есть смысл ими пользоваться?
ответ -- если человек пишет спек с нуля (в jpackage нет) не всегда.
если у него есть силы и желание пробить включение пакета в jpackage и там его сопровождать
тогда да. имеет.
lsv >
в jpackage -- основной момент имя пакета
viy >
а так лучше иметь для начинающих что-то вроде системы сборки Миши Забалуева,
только интегрировать ее с jpackage-utils. проще и доступнее.
lsv >
и имя 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
Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.

/usr/share/java не соответствует /usr/lib

viy >
/usr/share/java никак не соответствует /usr/lib. это скорее /opt.
PATH=$PATH:/opt/foo1/bin:...:/opt/fooN/bin то же что
CLASSPATH=/usr/share/java/jar1.jar:...:/usr/share/java/jarN.jar

Почему все пакеты собираем 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

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.

и совет - заливайте пакеты стадом. очень долго ждать, пока пройдут в сизиф, и в это время ничего зависящего не зальешь :(

java-select

deprecated
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.