Java/JavaPackagingFAQ

---

Одни и те же пакеты с разными именами в 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:0 и часто ссылаются на другие пакеты с явным указанием Epoch:, например, Requires: jakarta-commons-cli >= 0:1.1 Поэтому для частичной сборочной и установочной совместимости все пакеты, которые соответствуют пакетам из JPackage, должны иметь тот же Epoch:.

Для оригинальных пакетов 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

---

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.

---

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

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

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

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

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