Вход:  Пароль:  
FreeSource: AltLinux/Policy/Java/JavaPackagingFAQ ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Это старая версия AltLinux/Policy/Java/JavaPackagingFAQ за 2007-11-14 20:49:21..

Оглавление документа


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

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


Одни и те же пакеты с разными именами в jpackage и в Сизифе


lsv > одни и те же пакеты с разными именами
lsv > хотя бы в имени релиза
viy > есть, но тут все просто.
viy > 1) есть пакеты с разными ABI/API
viy > напр. тот же jcommon0 и jcommon
viy > 2) есть пакеты с одним и тем же содержимым.
viy > это мусор, я стараюсь чистить.
viy > примеров мало.
viy > по памяти помню вроде bsf vs. jakarta-bsf.
viy > они не конфликтуют, но надо будет написать на инкоминг чтобы выбросили..


Текущий список задач и статус пересборки пакетов из jpackage в Сизиф.

какие-то отметки хранятся в 
deps.notes git.altlinux.ru/people/viy/packages/jppimport.git/deps.notes

Что такое jppimport и как использовать


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


jpackage-xx-compat


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


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


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


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


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


lsv < не понятно, что за софт, живой он или как. куски ява в сизифе валяются и все
viy > я написал скрипт jppstat. в jppimport.git:
viy > wc java-alt-packages.owners
361 java-alt-packages.owners



viy > как видим, не так уж много пакетов. из них:
viy > там осталось половина вне jpackage, и половина сантехника.
lsv > что это костыли или сантехника знаете только вы. любой другой взглянув на это хозяйство не поймет что к чему.
viy > сантехника не свободна. например, если положить в сизиф jvm от IBM, то я тут же сомневаюсь в леальности нахождения их в сизифе.
viy > сантехника = Sun Binary Code License.
viy > т. е. это остатки, около 2 % пакетной массы.
viy > остальное схвачено.


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


lsv > мантейнеры в jpackage не блещут, если кто-нибудь возьмет пакет себе из сизифа то это плюс.
viy < да. конечно. но проблема в следующем. утрируя, можно сказать
кому они нужны?
типичный всюду плотный пакет из jpackage сам по себе никому не нужен. из него нужна библиотека, кусок повторно используемого кода,
звено пищевой цепочки зависимостей. как в природе
для поддержания существования 1 льва через пищевую цепочку нужно больше 10 км2 саванн.
viy > пакетов, реально нуждающихся в ручном присмотре и учете специфики дистра в том же jpackage до 20. может, до 10 на самом деле.
viy > более того, в 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. несмотря на то, что спеки у Миши и Владимира были чистые, понятные, логичные, красивые. но ? не стандартные.


Все ли 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
Тут одна из главных проблем это согласовать со всеми заинтересованными участниками процесса, коих уже имеется не менее нескольких штук.


JAVA и C


viy > java не С.
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 



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>:

> пытаюсь собрать Open Xchange? сервер под альтом. При попытке сборки в 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


deprecated
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 пакета в Req / 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 с
-Dmaven 2?.offline.mode -Dmaven 2?.ignore.versions -Dmaven 2?.usejppjars


2)
для сборки, кроме mvn, нужен еще репозиторий pom'ов.
В отсутствие maven2 в сизифе, часть пакетов была собрана
«без-pom'ощными», есть хак вокруг (maven2-bootstrap-bundle)
но я надеюсь быстро пересобрать такие пакеты, так что
относительно полноценный (по модулю -Dmaven 2?.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.
Удобен, когда заранее неизвестно, какие плагины понадобятся.


 
Файлов нет. [Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]