The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от opennews on 27-Сен-10, 17:11 
Терри Каррез (Thierry Carrez), возглавляющий разработку серверной сборки Ubuntu, подытожил (http://fnords.wordpress.com/2010/09/24/the-real-problem-with.../) в своем блоге проблемы, возникающие при поставке программ на языке Java в составе Linux-дистрибутивов и приводящие к тому, что множество Java-программ не доступны в пакетах для Linux-дистрибутивов или поставляются через сторонние репозитории.


Главная проблема возникает из-за наличия в Java собственный унифицированных инструментов сборки и распространения пакетов, что приводит к тому, что фактически разработчики открытых проектов на Java не выпускают готовый для пересборки релиз в исходных текстах, а занимаются поставкой уже готовых бинарных пакетов, включающих откомпилированный набор классов и связанных внешних Java-библиотек. Преобразовать такой Java-пакет в другой формат пакетов для включения в репозиторий Linux-дистрибутива не так просто, так как каждая Java-программа может требовать для своей работы разн...

URL: http://lwn.net/Articles/406884/rss
Новость: http://www.opennet.dev/opennews/art.shtml?num=28082

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


2. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от User294 (ok) on 27-Сен-10, 17:24 
Невольно вспомнился анекдот. Смотрит доктор пациента.
- Хорошо.... Хорошо.... Очень хорошо!
- А что хорошо, доктор?
- Хорошо то что это - не у меня.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +6 +/
Сообщение от Fcuku email(ok) on 27-Сен-10, 17:51 
На деле-то все проще:
Разработчики дают бинарь с исходниками, обвязанными ТАКИ-И-ИМИ XML для сборки, что без ПОЛНОГО проникновения в тему собрать на Фре, скажем, просто нереально :)

И ОТТАТПТЫВАЮТ СЕБЕ, таким образом, "кормовую площадку" :)

Поза такая: GPL, бинарь под пару магистральных Линей, исходники, "вот XML, мы сами, мамой клянусь, этим XML ночные сборки делаем!!!"

А дальше - "можно купить поддержку" :)
Или сам давай сырцы читай, жадина :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

23. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от iZEN (ok) on 27-Сен-10, 20:16 
Дохтур, и это тоже у тебя, только ты об этом не знаешь. Ты же на Ubuntu живёшь, а значит проблемы кучи пакетиков .deb для обеспечения нормальной работы Java тебя не миновали. К примеру, на Debian-based для русификации Java всё ещё требуется доустанавливать sun-java6-fonts.deb. В то время, как на взрослых системах поддержка i18n/l10n идёт в одном пакете c JDK или с JRE и доустанавливать ничего не надо.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

25. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от User294 (ok) on 27-Сен-10, 20:33 
>Ты же на Ubuntu живёшь, а значит проблемы кучи пакетиков .deb
>для обеспечения нормальной работы Java тебя не миновали.

У меня нет ни 1 программы на яве. И ни 1 сервака с ней. Поэтому да, у *меня* никаких проблемой с явой и ее нормальной работой - *нет*. Вот глядя на все это мне и вспомнился анекдот :)))

> К примеру, на Debian-based для русификации Java всё ещё требуется доустанавливать

Вам требуется? Вы и доустанавливайте, имхо.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

59. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Zenitur on 29-Сен-10, 09:43 
Теперь понятно, почему в любом дистрибутиве Azureus, он же Vuze, работает сразу. А в Убунте пакетнй менеджер тянет много других пакетов. Если верить юзеру. Потому-то он явой и не пользуется, что в Убунте это затруднено.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

62. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от stimpack on 12-Окт-10, 13:45 
Азуреус-азуреус...
Мастера делать простое сложным, мастера жрать проц и память, чертов комбайн вместо торрента... Слава богу, что есть нормальные аналоги. Тот же transmission - выглядит чуть ли не модальным окном, а функций - столько же. И работает на порядок приятнее.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  –1 +/
Сообщение от аноним on 27-Сен-10, 17:33 
>Дистрибутивы стремятся к поставке единой версии библиотеки для всех программ, в то время как Java-приложения проповедуют принцип поставки нужного набора библиотек в составе каждого пакета.

при чём тут проповедуют, если просто вынуждены так делать.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Аноним (??) on 27-Сен-10, 17:35 
Это почему же? В репозиториях иногда встречаются рахные версии одних и тех же библиотек.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

55. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Andrey Mitrofanov on 28-Сен-10, 12:33 
> просто вынуждены так делать.

Вильям наш Гейц Третий с Усамой Беновичем Ладданом стояли над ними и... о! принуждали. Бе-е-е-едненькие!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от none (??) on 27-Сен-10, 18:11 
есть спецификации на jvm
есть jdk, кот. спокойно уживаются, в разных версиях, на компе (alternative для jre)
ИМХО - достаточно "притянутые" проблемы
а для ОСС особенно
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

57. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от nuclight email(ok) on 28-Сен-10, 22:39 
Это Вы, видимо, не сталкивались с программами, требующими конкретную версию JDK.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

58. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от iZEN (ok) on 29-Сен-10, 00:15 
> Это Вы, видимо, не сталкивались с программами, требующими конкретную версию JDK.

Я сталкивался с программами, требующими конкретную версию JDK для определённой архитектуры команд CPU. Ничего — уживаются два разных JDK для [i386] и [amd64] на одной машине в одной операционной системе. ;)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

10. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от pro100master (ok) on 27-Сен-10, 18:13 
очень энтерпрайзно так - каждой тулзе по своей версии libc :))) (саpказмъ)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Аноним (??) on 27-Сен-10, 18:29 
Тут не .so имеются в виду, а .jar
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

13. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +1 +/
Сообщение от Аноним (??) on 27-Сен-10, 19:06 
Подотрите сопли, истерика ни к чему.
В моей gentoo сосуществуют как минимум 3 версии одной и той же jpeg либы.
Сосущесвуют? Да.
Без проблем? Нет, не без проблем.

Где тут джава? В воспаленном воображении спорщиков.
Пакетные менеджеры не так хороши, как хотелось бы, вот и все.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

15. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от szh (ok) on 27-Сен-10, 19:30 
> как минимум 3 версии одной и той же jpeg либы.

когда будет 300 версий комбинаций из десятков библиотек весом в xx мегабайт,
для 300 программ, когда ты будешь оплачивать доп расходы на поддержку такой кучи,
тогда и порассуждаешь о сопельках.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

16. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Аноним (??) on 27-Сен-10, 19:37 
ты мне не тыкай, и не передергивай. В реальном мире версии зависимостей единицами считают, а не сотнями.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

18. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от szh (ok) on 27-Сен-10, 19:52 
вводная аргументация "Подотрите сопли, истерика ни к чему." располагает.

> В реальном мире версии зависимостей единицами считают, а не сотнями.

по ссылке другое мнение.

Package all versions of libraries

The next obvious solution is to make separate packages for every version of library that the software uses. The problem is that there is no real convergence on “commonly-used” versions of libraries. There is no ABI protection, nor general guidelines on versioning. You end up having to package each and every minor version of a library that the software happens to want. That doesn’t scale well: it creates an explosion in the number of packages, code duplication, security update nightmares, etc. Furthermore, sometimes the Java project patches the libraries they ship with to include a specific feature they need, so it doesn’t even match with a real library version anymore.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

24. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +3 +/
Сообщение от Аноним (??) on 27-Сен-10, 20:30 
1.
> В моей gentoo сосуществуют как минимум 3 версии одной и той же jpeg либы.
> Сосущесвуют? Да.
> Без проблем? Нет, не без проблем.

Различные приложения(!не джава!) требуют различные версии либы(!не джава!). Проблема версионирования вообще не из джавы, ею все страдают. Взять хоть эпопею с двумя питонами, ведь ужас какой-то.

2. У джавистов тоже автоматическая сборка (кто бы мог подумать??? ай-яй-яй), поэтому поставляют они все, и исходный код и бинари, и в исходниках версии зависимостей прописаны прекрасно.

3. Существует полная аналогия между размещением *.so в файловой системе и размещением там же *.jar
Какую либу приложению в PATH подсунешь, на той он и поедет. В этом смысле приложения на джаве ничем не отличается от приложений на си, питоне и т.д.

4. Защитой на уровне ABI никто не страдает, ни *.jar, ни *.so

Вывод: проблемы существуют на уровне пакетных менеджеров дистрибутивов

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

30. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +2 +/
Сообщение от Fcuku email(ok) on 27-Сен-10, 21:23 
Нет, проблемы существуют на уровне совести разработчиков, НЕ предоставляющих исходники в пригодном для мультиплатформенной сборки виде.
Немножко жилят, вымогая денежек с тех, кому надо перебрать пакет, а сил вникать нету.
Соответственно, разводится такой зверинец, от которого страдают и дистры.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

33. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +1 +/
Сообщение от Аноним (??) on 27-Сен-10, 21:37 
>Нет, проблемы существуют на уровне совести разработчиков, НЕ предоставляющих исходники в пригодном
>для мультиплатформенной сборки виде.
>Немножко жилят, вымогая денежек с тех, кому надо перебрать пакет, а сил
>вникать нету.
>Соответственно, разводится такой зверинец, от которого страдают и дистры.

Оpenoffice уж на что монстр, а собирается в gentoo из исходников. Выходит проблема не в джаве, а в конкретных разработчиках.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

61. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Frank email(??) on 30-Сен-10, 14:45 
Оpenoffice написан на сях, не на яве
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

37. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +1 +/
Сообщение от VoDA (ok) on 27-Сен-10, 23:19 
> Нет, проблемы существуют на уровне совести разработчиков, НЕ предоставляющих исходники
> в пригодном для мультиплатформенной сборки виде.
> Немножко жилят, вымогая денежек с тех, кому надо перебрать пакет, а сил
> вникать нету.
> Соответственно, разводится такой зверинец, от которого страдают и дистры.

Java сама по себе мультиплатформенна - СЮРПРИЗ =))) Исходники кстати сразу идут в мультиплатформенном виде, maven вообще сам подтянет из центрального репо требуемые либы.

Дело в том, что C/C++ приложения точатся под отдельный дистр и для них делаются скрипты привинчивающие к определенной системе. Java для платформо и дистро независимости не привинчивается к системе, потому и вынуждена таскать набор либок.


Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

53. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Fcuku email(ok) on 28-Сен-10, 12:28 
> Java сама по себе мультиплатформенна...

Читаете ли вы то, что комментируете??? :)

И насколько вы способны собрать Java проект БЕЗ "билд-тулза", НАМЕРЕННО искоцанный разработчиками от референс-дизайна?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

48. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от б.б. on 28-Сен-10, 05:38 
> Различные приложения(!не джава!) требуют различные версии либы(!не джава!). Проблема
> версионирования вообще не из джавы, ею все страдают. Взять хоть эпопею
> с двумя питонами, ведь ужас какой-то.

У меня в дебиане одновременно сразу 4 питона (Пусть эта змеюка подавится!).

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

26. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от mike lee on 27-Сен-10, 20:48 
> В моей gentoo сосуществуют как минимум 3 версии одной и той же jpeg либы.

зачем? у меня например одна 8b.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

29. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  –1 +/
Сообщение от Аноним (??) on 27-Сен-10, 21:08 
>> В моей gentoo сосуществуют как минимум 3 версии одной и той же jpeg либы.
>
>зачем? у меня например одна 8b.

А зачем на торрентах лежат N сезонов симпсонов? Оставили бы последний, чего на остальные место тратить?
Разным людям нравятся разные сезоны, а разным приложениям нравятся разные версии либы.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

31. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Fcuku email(ok) on 27-Сен-10, 21:25 
>>> В моей gentoo сосуществуют как минимум 3 версии одной и той же jpeg либы.
>>
>>зачем? у меня например одна 8b.
>
>А зачем на торрентах лежат N сезонов симпсонов? Оставили бы последний, чего
>на остальные место тратить?
>Разным людям нравятся разные сезоны, а разным приложениям нравятся разные версии либы.
>

Это у вас симлинки "сосуществуют" :)
А библиотека - одна :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

34. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +4 +/
Сообщение от Аноним (??) on 27-Сен-10, 21:42 
>[оверквотинг удален]
>>>
>>>зачем? у меня например одна 8b.
>>
>>А зачем на торрентах лежат N сезонов симпсонов? Оставили бы последний, чего
>>на остальные место тратить?
>>Разным людям нравятся разные сезоны, а разным приложениям нравятся разные версии либы.
>>
>
>Это у вас симлинки "сосуществуют" :)
>А библиотека - одна :)

Я Вас покусаю :) В гентушном менеджере есть "слоты", позволяющие иметь в системе несколько версий одной либы, это факт. Ведь не городили бы огород, не будь версий библиотеки более одной.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

54. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Fcuku email(ok) on 28-Сен-10, 12:31 
> Я Вас покусаю :) В гентушном менеджере есть "слоты", позволяющие иметь в
> системе несколько версий одной либы, это факт. Ведь не городили бы
> огород, не будь версий библиотеки более одной.

К теме!
Libjpeg - сколько?
"Три" или, все же единственный экземпляр 8.х?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

51. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Андрей (??) on 28-Сен-10, 11:21 
не всегда. например, тот же nxclient хочет openssl-0.9.8, хотя все остальное прекрасно пересобралось с openssl-1.0.0. или тот же вайн@этерсофт, не смотря на то, что libpng разделили на два слота - >=1.4.3 и <1.4.3, не собирается, пока в системе присутствует >=1.4.3 (не смотря на присутствие так же <1.4.3). Но потом прекрасно (насколько это возможно ;) ) работает, когда вернешь >=1.4.3.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

49. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +1 +/
Сообщение от б.б. on 28-Сен-10, 05:40 
>>> В моей gentoo сосуществуют как минимум 3 версии одной и той же jpeg либы.
>>
>>зачем? у меня например одна 8b.
> А зачем на торрентах лежат N сезонов симпсонов? Оставили бы последний, чего
> на остальные место тратить?
> Разным людям нравятся разные сезоны, а разным приложениям нравятся разные версии либы.

Сколько нынче дядек дают за одну бузину на центральном рынке Киева?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

14. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +2 +/
Сообщение от Аноним123321 (ok) on 27-Сен-10, 19:18 
все проблемы (лучше даже саазать вот так: "все эти вендовенькие проблемы") -- решаются прописыванием ИНДИВИДУАЛЬНЫХ переменных окружения для каждого из Java-приложений

(да и вообще слово Java -- тут непричём. для Java это CLASSPATH, для Python это PYTHONPATH, для обычного C/C++ это LD_LIBRARY_PATH, ... так-что суть не меняется)

манипулированием путей для переменных окружения -- пусть занимаются пакетные манеджеры (эти пакетные менеджеру уже сегодня способны копировать библиотеки не просто в [помойку] /usr/lib/ , а аккуратненько: в /usr/lib/my_super_lib_v1/ или /usr/lib/my_super_lib_v2/ )

для прописывания же индивидуальных переменных окружения внутри запускаемой программы  (ведущщим к путям где библиотеки) -- пусть используются sh-скрипты`Wrapper`ы

....в чом проблемато?

не придётся же для каждой программы которая использует /usr/lib/my_super_lib_v2/ делать индивидуально каждый раз копию директории /usr/lib/my_super_lib_v2/ ... так-что в какомто смысле принцип "единой библиотеки для всех" остаётся

********************************************************************************

мало того! если расширить проблему ещё глубже, то я вообще щитаю, что _всё_ что установленно как _зависимости_программ_ (а не как _требуется_для_человека_ ) -- не должно класться _напрямую_ в /usr/bin/ и /usr/lib/ .... всё это должнобыть _строго_ в /usr/bin/my_program_version_X.Y.Z/ и /usr/lib/my_library_version_X.Y.Z/

...а вот если _именно_человек_ хочет для себя (а не для решения зависимости) установить какойнить программный пакет, то в этом случае пусть пакетный-менеджер распокует для человека sh-скрипт-Wrapper , внутрь директории /usr/bin/ , (который внутри своего sh-кода будет ссылаться на /usr/bin/my_program_version_X.Y.Z/ и /usr/lib/my_library_version_X.Y.Z/ )

ато захломили весь GNU/Linux всяким гавном внутри ${PATH} и ${LD_LIBRARY_PATH} , аж тошнит!!.

я хочу какуюнить прогу поставить, а мне всемте с этой программой ещё кучу утилит внутри ${PATH} появляется :-/ ... ЗАЧЕМ ОНИ МНЕ? они НЕ МНЕ нужны а той программе которую я устанавливаю!! а мне ненужны! а если будут нужны то я установлю их!

...например если я хочу установить себе Gajim, а Gajim требует для себя Python и SQLite.... ... ... то ПУСТЬ пакетный менеджер установит Python (какой-нить там Python-2.6) внутри отдельной подериктории!, которая не будет поумолчанию в _человеческом_ ${PATH} .
...а человек же для себя может постановить индивидуальный Python (ту версию которую он хочет), и ВОТ ТОГДА-ТО внутри ${PATH} должна появиться команда "python" ! но не раньше!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

17. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  –1 +/
Сообщение от segoon email(ok) on 27-Сен-10, 19:39 
У меня 13 программ в $PATH хотят питон, 10 из них весят 2-100 кб.  На каждый из них ставить свой питон со всеми питонолибами? :0)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

20. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +2 +/
Сообщение от Aquarius (ok) on 27-Сен-10, 19:57 
это концепция, выпускай дистрибутив
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

27. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +1 +/
Сообщение от Прохожий (??) on 27-Сен-10, 20:50 
>это концепция, выпускай дистрибутив

Такой дистр уже есть. В нем каждая прога ставиься в свою структуру каталогов вместе со всеми зависимостями - все свое ношу с собой :) Название дистра не помню и он непопулярен.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

28. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Ytch on 27-Сен-10, 21:00 
>Такой дистр уже есть. В нем каждая прога ставиься в свою структуру каталогов вместе со всеми зависимостями - все свое ношу с собой :) Название дистра не помню и он непопулярен.

Windows? :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

35. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Motif (ok) on 27-Сен-10, 22:26 
GoboLinux.

http://distrowatch.com/table.php?distribution=gobo

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

50. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +1 +/
Сообщение от б.б. on 28-Сен-10, 05:43 
>>это концепция, выпускай дистрибутив
> Такой дистр уже есть. В нем каждая прога ставиься в свою структуру
> каталогов вместе со всеми зависимостями - все свое ношу с собой
> :) Название дистра не помню и он непопулярен.

Это примерно как решать проблемы пробок созданием сотни изолированных друг от друга дорог - "Базар-Вокзал" "Базар-Баня" "Вокзал-Баня" и т.п., вместо проектирования грамотной развязки.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

56. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Aquarius (ok) on 28-Сен-10, 13:35 
>>>это концепция, выпускай дистрибутив
>> Такой дистр уже есть. В нем каждая прога ставиься в свою структуру
>> каталогов вместе со всеми зависимостями - все свое ношу с собой
>> :) Название дистра не помню и он непопулярен.
> Это примерно как решать проблемы пробок созданием сотни изолированных друг от друга
> дорог - "Базар-Вокзал" "Базар-Баня" "Вокзал-Баня" и т.п., вместо проектирования грамотной
> развязки.

в реальной жизни это абсурд, а в информационном - вполне себе решение

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

60. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Aquarius (ok) on 29-Сен-10, 14:07 
>>>>это концепция, выпускай дистрибутив
>>> Такой дистр уже есть. В нем каждая прога ставиься в свою структуру
>>> каталогов вместе со всеми зависимостями - все свое ношу с собой
>>> :) Название дистра не помню и он непопулярен.
>> Это примерно как решать проблемы пробок созданием сотни изолированных друг от друга
>> дорог - "Базар-Вокзал" "Базар-Баня" "Вокзал-Баня" и т.п., вместо проектирования грамотной
>> развязки.
> в реальной жизни это абсурд, а в информационном - вполне себе решение

поправка: в реальном мире это абсурд, а в информационном - вполне себе решение
так лучше звучит

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

38. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +1 +/
Сообщение от VoDA (ok) on 27-Сен-10, 23:22 
Хоть одно адекватное мнение =)))
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

22. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  –1 +/
Сообщение от iZEN (ok) on 27-Сен-10, 20:08 
Осильте уже Apache Maven и перестаньте ныть!
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

32. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Fcuku email(ok) on 27-Сен-10, 21:29 
>Осильте уже Apache Maven и перестаньте ныть!

Э-э-э...
Вы уверены, что в Каноникал про Maven ничего не слышали?
А вы им - письмо! :)
Пусть прозреют! :)
Ссылку кинуть не забудьте!!! :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

36. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от iZEN (ok) on 27-Сен-10, 23:02 
>>Осильте уже Apache Maven и перестаньте ныть!
> Э-э-э...
> Вы уверены, что в Каноникал про Maven ничего не слышали?
> А вы им - письмо! :)
> Пусть прозреют! :)
> Ссылку кинуть не забудьте!!! :)

Какой там Maven — они JDK не могут собрать в один пакет, чтобы "как у всех всё работало". Пользователям приходится по кусочкам целостную платформу собирать, ища пакетики по ключевым словам траблов из серии "русский язык в Java не работает в Ubuntu" в Гугле. Вот до чего доводит концепция "рекомендуемых, но необязательных пакетиков".


Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

39. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от VoDA (ok) on 27-Сен-10, 23:24 
Это 3.14дец =)))

так в Ubuntu получается не JavaDK? ибо Java должна уметь по дефолту кучку языков и т.п. Если не могет - не java, а подобие типа gcj...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

40. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +1 +/
Сообщение от VoDA (ok) on 27-Сен-10, 23:27 
По мне проблемы две.
1. не доведенная до ума модульность в java. Проект jugsaw, пара JSR на эту тему. Обещают в JDK 8 асилить.
2. пакетные менеджеры дистрибутивов не умеют работать с java-менеджером зависимостей maven. А java разработчики конечно же не будут запиливаться на один дистр, если можно остаться кроссплатформенными.

Выход научиться из apt-get использовать maven и его зависимости + при запуске приложения грамотно собирать CLASSPATH.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

41. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от iZEN (ok) on 28-Сен-10, 00:12 
> По мне проблемы две.
> 1. не доведенная до ума модульность в java. Проект jugsaw, пара JSR
> на эту тему. Обещают в JDK 8 асилить.

Чем .class файлы не модули? Помниться, до изобретения JAR, апплеты загружались в браузеры только class-файлами и начинали работать сразу, как только скачается первый из них. По мере задействования нового байткода подгружались недостающие class-файлы. То есть программа на Java уже работала даже тогда, когда ещё не все её части подгрузились на клиентский компьютер.

> 2. пакетные менеджеры дистрибутивов не умеют работать с java-менеджером зависимостей maven.

Пакетные менеджеры умеют запускать предварительно сконфигурированные скрипты для обеспечения корректной инсталляции бинарного пакета. mvn — это скрипт с параметрами для сопровождения всего жизненного цикла программных сущностей (приложений и библиотек) различных версий, всех фаз сборки/тестирования/инсталляции/запуска.


Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

44. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +1 +/
Сообщение от VoDA (ok) on 28-Сен-10, 01:07 
> Чем .class файлы не модули? Помниться, до изобретения JAR, апплеты загружались в браузеры только class-файлами и начинали работать сразу, как только скачается первый из них. По мере задействования нового байткода подгружались недостающие class-файлы. То есть программа на Java уже работала даже тогда, когда ещё не все её части подгрузились на клиентский компьютер.

java либы очень маленькие и узкоспециализированные, потому их просто немеренно даже для малого проекта. Либо приходится поднимать JavaEE compatible сервер и пользоваться еще бОльшим набором либ/систем в комплекте. Косяк именно в большом кол-ве различных либ.

Если jar B зависит от A версии 1 и jar C зависит от A версии 2, при этом версии 1 и 2 несовместимы, то нет возможности написать java приложение зависящее от B и C одновременно. Будут феерические баги из-за двух несовместимых либ в класс-пасе или попытки подоткнуть не ту jar-ку.

java modules это фикс для подобной ситуации. Все остальное в java могут сделать maven & OSGi

> Пакетные менеджеры умеют запускать предварительно сконфигурированные скрипты для обеспечения корректной инсталляции бинарного пакета. mvn — это скрипт с параметрами для сопровождения всего жизненного цикла программных сущностей (приложений и библиотек) различных версий, всех фаз сборки/тестирования/инсталляции/запуска.

1. по сути нужно вытащить зависимости из mvn и уложить на пакетную базу целевого дистрибутива.
2. Дальше перегнать mvn repo в репо для целевой системы.
3. В результирующих WAR / EAR / иных сборках заменить jar из lib на ссылки на установленные пакеты из п.2

По сути куча механической работа + оттестировать. Только кто заплатит за развлечение?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

47. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от iZEN (ok) on 28-Сен-10, 03:49 
> java либы очень маленькие и узкоспециализированные, потому их просто немеренно даже для малого проекта.

Вообще, .class-файлов немеряно, да. Гранулированность Java-приложений, несмотря на повсеместное запаковывание class-файлов в JAR/WAR/EAR довольно большая. Другими словами, архивирование байткода является способом уменьшить гранулированность на файловом уровне, но не на уровне библиотек. На уровне библиотек и приложений гранулированность никуда не девается.

> Либо приходится поднимать JavaEE compatible сервер и пользоваться еще бОльшим набором либ/систем в комплекте. Косяк именно в большом кол-ве различных либ.

Я думаю, косяк в перепаковке и потере целостности. Дебианщики упускают целостное восприятие Java-кода в погоне за его перепаковкой в DEB.

> Если jar B зависит от A версии 1 и jar C зависит
> от A версии 2, при этом версии 1 и 2 несовместимы,
> то нет возможности написать java приложение зависящее от B и C
> одновременно. Будут феерические баги из-за двух несовместимых либ в класс-пасе или
> попытки подоткнуть не ту jar-ку.
> java modules это фикс для подобной ситуации. Все остальное в java могут
> сделать maven & OSGi

Да, в Maven это разруливается легко на основе информации о версии в имени файлов jar.

>> Пакетные менеджеры умеют запускать предварительно сконфигурированные скрипты для обеспечения корректной инсталляции бинарного пакета. mvn — это скрипт с параметрами для сопровождения всего жизненного цикла программных сущностей (приложений и библиотек) различных версий, всех фаз сборки/тестирования/инсталляции/запуска.
> 1. по сути нужно вытащить зависимости из mvn и уложить на пакетную
> базу целевого дистрибутива.

Но зачем? Перепаковка портабельного кода ничего не даёт кроме головной боли мантейнерам. (что и наблюдаем)
Гораздо лучше работать с локальным репозиторием Maven из пакетного менеджера, рулить mvn, чтобы тот производил все необходимые действия по сопровождению кода Java.

> 2. Дальше перегнать mvn repo в репо для целевой системы.

Перепаковка не нужна.

> 3. В результирующих WAR / EAR / иных сборках заменить jar из
> lib на ссылки на установленные пакеты из п.2

Жизненный цикл (загрузка, выгрузка, обновление) WAR/EAR — вотчина сервера пиложений Java EE, а не пакетного менеджера.

> По сути куча механической работа + оттестировать. Только кто заплатит за развлечение?

Достаточно в пакетном менеджере имплементировать интерфейс взаимодействия с Maven и Java EE-сервером, переложив ответственность за сопровождение Java программ на них.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

52. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от VoDA (ok) on 28-Сен-10, 11:51 
> Я думаю, косяк в перепаковке и потере целостности. Дебианщики упускают целостное восприятие Java-кода в погоне за его перепаковкой в DEB.

Это есть.

> Да, в Maven это разруливается легко на основе информации о версии в
> имени файлов jar.
> Но зачем? Перепаковка портабельного кода ничего не даёт кроме головной боли мантейнерам.
> (что и наблюдаем)
> Гораздо лучше работать с локальным репозиторием Maven из пакетного менеджера, рулить mvn,
> чтобы тот производил все необходимые действия по сопровождению кода Java.
> Жизненный цикл (загрузка, выгрузка, обновление) WAR/EAR — вотчина сервера пиложений
> Java EE, а не пакетного менеджера.

Вы читали задачи которые должна решать система java modules?

Там не только сборка приложения и подтыкание правильных jar для сборки (это делает mvn), но и создание системного репо и каждое приложение вместо того, чтобы тянуть с собой кучу либ - просто запрашивает требуемые либы (по версиям) у java, сама java уже ищет/качает с центрального сайта и т.п.

В этом одна из задач jugsaw.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

43. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +1 +/
Сообщение от Marbleless on 28-Сен-10, 00:36 
>не доведенная до ума модульность в java.

Это просто у многих дистростроителей бзик с этой модульностью. Упаковывают Жабу в 5 разных пакетов, а потом "У меня русский язык в Жабе не работает". Особенно хорошо когда есть "Полная версия", "Почти полная версия" и "Совсем маленькая версия". А особенно хорошо, когда часть программ в дистре зависит от, скажем, OpenJDK а часть от GCJ, причем оба их поставить одновременно нельзя.

Жаба привыкла скачиваться и ставиться одним пакетом. На всех. Вообще. И чтобы на всех платформах ПО на Java работало одинаково. Но нет ведь, и тут надо взять и сделать чертов зоопарк.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

42. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +/
Сообщение от Аноним (??) on 28-Сен-10, 00:33 
С переменными окружения надо быть аккуратнее.
Если, к примеру задаем LD_LIBRARY_PATH, и запускаем файловый менеджер, то все программы запущенные этим файловыйм менеджером, могут получить неправильное окружение, и вследствии чего подгрузить не те библиотеки.
То же самое касается CLASSPATH.
Лучше использовать rpath или манифесты.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

45. "Анализ проблем с поставкой Java-приложений в Linux-дистрибут..."  +1 +/
Сообщение от VoDA (ok) on 28-Сен-10, 01:10 
> С переменными окружения надо быть аккуратнее.
> Если, к примеру задаем LD_LIBRARY_PATH, и запускаем файловый менеджер, то все программы
> запущенные этим файловыйм менеджером, могут получить неправильное окружение, и вследствии
> чего подгрузить не те библиотеки.
> То же самое касается CLASSPATH.
> Лучше использовать rpath или манифесты.

Не совсем. CLASSPATH формируется независимо для каждого запускаемого приложения.

По другому дела идут в контейнерах и АппСерверах - там клиентские надстройки (WAR/EAR) запускаются в рамках контейнера и контейнер модифицирует класс-лоадинг для выполнения своих задач. К примеру для DI или поддержки штатных функций, потому часть либ-ок шарится между АппСервером и приложениями им запускаемыми.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру