[devel] Re: Q: java development

[Vladimir Lettiev]

Mikhail Zabaluev пишет:
>>Надо опубликовать эту policy даже если она ещё полностью не оформлена. 
> 
> В данный момент она существует главным образом в моей голове :)
> Надо оформить в документ, конечно.
> 
Ok. Я подготавливаю свой draft, можно его будет обсудить.

Я не дождался вашего ответа и предпринял разведку боем: позавчера в 
Сизиф ушли 13 java-пакетов:
jakarta-commons-collections, jakarta-commons-daemon, 
jakarta-commons-daemon-jsvc, jakarta-commons-beanutils, 
jakarta-commons-pool, jakarta-commons-launcher, servletapi5, 
jakarta-commons-el, jakarta-commons-digester, jakarta-regexp, jmx, jndi, 
jakarta-commons-dbcp

Вообще их сборка для меня была нужна для того, чтобы как следует 
разобраться в процессе сборки java-пакетов. За их майнтейнерство я не 
держусь, поэтому отдам по первому обоснованному требованию. Пакеты 
выбраны по простому принципу: я просто иду по списку зависимостей tomcat5.
В сборке я придерживался стандартной полиси jpackage, т.е. туча 
симлинков, но зависимости выставлял только самые необходимые.

>>Очень важный момент это правила именования jar'ов (делать ли симлинки?), 
>>поскольку практически в каждом спеке в CLASSPATH должны явно указыватся 
>>пути к этим файлам.
> 
> Я убрал симлинки на версии. Rationale: версии поддерживаются
> rpm и выясняются с помощью его же, а для CLASSPATH они
> не нужны и даже вредны.
> То же с javadoc-каталогами: не удалось найти ни одной причины, почему
> они должны иметь полные номера версий.
> 
> Из других изменений: все явно библиотечные (т.е. не используемые
> напрямую через launcher'ы и проч.) пакеты отнесены в Development/Java,
> иным группы даются по функциональной принадлежности.
> У библиотечных пакетов не ставятся requires на j2se, другие
> java-пакеты, за исключением очевидных жестко заданных случаев.
> У пакетов c launcher'ами (напр. ant, tomcat), наоборот, ставятся
> все requires, необходимые для работы.
> 

Да, вы совершенно правы.
Только я бы ещё предложил создавать симлинк на то имя (*.jar), которое 
изначально задумано разработчиком. Например, jakarta-commons-logging.jar 
<-> commons-logging.jar. Поскольку во многих зависимых пакетах в 
build.xml/build.properties заложены именно такие имена jar'ов.

И ещё все java-пакеты должны зависеть от java-common.

>>У меня есть предложения по изменениям в пакетах java-common и 
>>j2se1.4-sun-doc. Как это лучше обсудить, через bugzilla, рассылку или в 
>>личной переписке?
> 
> В рассылку и Cc: мне -- я сейчас читаю рассылки в мерцающем режиме :(
> Если есть серьезные проблемы, требующие вмешательства, заносите в bugzilla.
> 

Предложения такие.
В пакете j2se1.4-sun-doc создавать симлинк или альтернативу (если вдруг 
ещё есть пакеты, которые провайдят доки):
/usr/share/javadoc/java -> /usr/share/doc/j2se-sun-1.4.2/api

Чтобы при сборке javadoc некоторых пакетов указывать именно такой путь 
(не зависящий от версии SDK), поскольку многие пакеты лезут в инет за 
этой документацией при сборке...

По пакету java-common. Нужно выделить в нём подпакет java-common-devel, 
куда внести хотя бы общие rpm-макросы:

%define _javadir %_datadir/java
%define _javadocdir %_datadir/javadoc
%define _j2sedocdir %_javadocdir/java
%define _javahome %_libdir/jdk

А также расширить кол-во функций. Например, нужна функция, аналог 
AddToClasspath, но не сама экспортирующая CLASSPATH, а просто 
возвращающая его в виде строки. В идеале бы функцию, которая сама 
экспортнёт всё что найдёт в %_javadir ;)

-- 
С уважением, Владимир Леттиев aka crux <crux на syktsu.ru>