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

Материал из ALT Linux Wiki
Нет описания правки
Нет описания правки
Строка 1: Строка 1:
[[Категория:Policy]]
[[Категория:Policy]]
{{MovedFromFreesourceInfo|AltLinux/Policy/Java/ClassPathInManifest}}
{{викифицировать}}
{{викифицировать}}


Строка 6: Строка 5:
О причинах и последствиях можно почитать на [https://www.zarb.org/pipermail/jpackage-discuss/2003-June/002141.html https://www.zarb.org/pipermail/jpackage-discuss/2003-June/002141.html]
О причинах и последствиях можно почитать на [https://www.zarb.org/pipermail/jpackage-discuss/2003-June/002141.html https://www.zarb.org/pipermail/jpackage-discuss/2003-June/002141.html]
тж. [http://lists.altlinux.org/pipermail/devel/2008-January/068470.html обсуждение в devel@], [http://lists.altlinux.org/pipermail/devel/2008-January/068470.html gmane view]
тж. [http://lists.altlinux.org/pipermail/devel/2008-January/068470.html обсуждение в devel@], [http://lists.altlinux.org/pipermail/devel/2008-January/068470.html gmane view]
<blockquote>
DS> Хотя у нас есть еще одна вещь — в META-INF может быть жестко прописаный
DS> classpath. Я не знаю какие недостатки у этого решения, но плюсы очевидны:
DS> — можно делать простые файловые зависимости,
DS> — их удовлетворение может автоматически означать возможность запустить приложение.


IV: ----
{{начало цитаты|источник=DS}}
Хотя у нас есть еще одна вещь — в META-INF может быть жестко прописаный
classpath. Я не знаю какие недостатки у этого решения, но плюсы очевидны:
 
— можно делать простые файловые зависимости,
 
— их удовлетворение может автоматически означать возможность запустить приложение.
{{конец цитаты}}
{{начало цитаты|источник=IV}}
jpackage policy не зря запрещает жестко прописаный в META-INF classpath.
jpackage policy не зря запрещает жестко прописаный в META-INF classpath.


Строка 47: Строка 49:
Придется искать jar’ы по файлопомойкам интернета, откуда угодно,
Придется искать jar’ы по файлопомойкам интернета, откуда угодно,
но только не из родного дистрибутива. Кому тогда они вообще нужны?
но только не из родного дистрибутива. Кому тогда они вообще нужны?
</blockquote>
{{конец цитаты}}


=== Общая информация о classpath ===
=== Общая информация о classpath ===
По поводу задания пеменной classpath.
По поводу задания переменной classpath.
[http://javahowto.blogspot.com/2006/06/6-ways-of-setting-java-classpath.html http://javahowto.blogspot.com/2006/06/6-ways-of-setting-java-classpath.html]
[http://javahowto.blogspot.com/2006/06/6-ways-of-setting-java-classpath.html http://javahowto.blogspot.com/2006/06/6-ways-of-setting-java-classpath.html]
[http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html]
[http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html]

Версия от 13:12, 1 ноября 2008

42px-Wikitext-ru.svg.png
Эту статью следует викифицировать.


В MANIFEST.MF не должно быть атрибута Class-Path. О причинах и последствиях можно почитать на https://www.zarb.org/pipermail/jpackage-discuss/2003-June/002141.html тж. обсуждение в devel@, gmane view

DS:

Хотя у нас есть еще одна вещь — в META-INF может быть жестко прописаный classpath. Я не знаю какие недостатки у этого решения, но плюсы очевидны:

— можно делать простые файловые зависимости,

— их удовлетворение может автоматически означать возможность запустить приложение.

IV:

jpackage policy не зря запрещает жестко прописаный в META-INF classpath.

см. http://www.freesource.info/wiki/Altlinux/Policy/Java/ClassPathInManifest

The Class-Path system of MANIFESTs is evil http://jpackage.org/jpprequest.php

https://www.zarb.org/pipermail/jpackage-discuss/2003-June/002095.html

Кроме того, добавлю к вышесказанному, что с одной стороны, это аналог -rpath, а стандартных мест, где может быть библиотека, несколько, наподобие /lib и /usr/lib. Посмотрите «Глава 3. Структура директорий» http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation#h11610-10

скрипт build-classpath обходит все эти места, чтобы найти нужную библиотеку. Тот же самый $(build-classpath xml-commons-apis) может развернуться в /usr/share/java/xml-commons-apis.jar, а может в /usr/lib/jvm-exports/jre-1.6.0-sun/xml-commons-apis.jar -> /usr/lib/jvm/java-1.6.0-sun-1.6.0.04/jre/lib/rt.jar

Как и в сишных библиотеках, в дистрибутиве -rpath скорее мешает.

С другой стороны, и это killer, жестко прописаный в META-INF classpath сделает такие библиотеки непригодными для разработчика.

Так бы люди использовали для своих проектов дистрибутивные jar, но с жестко прописаным в META-INF classpath поведение программы с такими библиотеками будет на чужой машине разрушительно непредсказуемым. Кто знает, что и какой версии оно там загрузит, чтобы начать Великую Войну За Тапки ?

Придется искать jar’ы по файлопомойкам интернета, откуда угодно, но только не из родного дистрибутива. Кому тогда они вообще нужны?

Общая информация о classpath

По поводу задания переменной classpath. http://javahowto.blogspot.com/2006/06/6-ways-of-setting-java-classpath.html http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html

Если используется конструкция вида java -jar, то classpath должен быть задан в MANIFEST.MF, атрибут Class-Path. При использовании ключа jar игнорируется значение ключей classpath и cp

как следствие, в дистрибутиве использование java -jar для запуска приложений не приветствуется.