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

Текущая версия от 08:36, 29 марта 2009

Эту статью следует викифицировать.

В 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 для запуска приложений не приветствуется.

Java

Java Policy • Java/ClassPathInManifest • Java/HOWTO • Java/LibericaJDK • Java/OracleSDK • Java/JavaPackagingFAQ • JavaPlugin • Java/JPackagePolicyTranslation • Java/JPackageSpecTemplate

@@ Строка 1: / Строка 1: @@
-[[Category:Policy]]
+{{викифицировать}}
-{{MovedFromFreesourceInfo|AltLinux/Policy/Java/ClassPathInManifest}}
 В MANIFEST.MF не должно быть атрибута Class-Path.
 О причинах и последствиях можно почитать на [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]
-<blockquote>
-DS> Хотя у нас есть еще одна вещь -- в META-INF может быть жестко прописаный
-DS> classpath. Я не знаю какие недостатки у этого решения, но плюсы очевидны:
-DS>  - можно делать простые файловые зависимости,
-DS>  - их удовлетворение может автоматически означать возможность запустить  приложение.
-IV: ----
+{{начало цитаты|источник=DS}}
+Хотя у нас есть еще одна вещь — в META-INF может быть жестко прописаный
+classpath. Я не знаю какие недостатки у этого решения, но плюсы очевидны:
+— можно делать простые файловые зависимости,
+— их удовлетворение может автоматически означать возможность запустить приложение.
+{{конец цитаты}}
+{{начало цитаты|источник=IV}}
 jpackage policy не зря запрещает жестко прописаный в META-INF classpath.
 см.
 [http://www.freesource.info/wiki/Altlinux/Policy/Java/ClassPathInManifest http://www.freesource.info/wiki/Altlinux/Policy/Java/ClassPathInManifest]
@@ Строка 23: / Строка 25: @@
 Кроме того, добавлю к вышесказанному, что
 с одной стороны, это аналог -rpath, а стандартных мест,
 где может быть библиотека, несколько, наподобие /lib и /usr/lib.
-Посмотрите "Глава 3. Структура директорий"
+Посмотрите «Глава 3. Структура директорий»
 [http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation#h11610-10 http://www.freesource.info/wiki/Altlinux/Policy/Java/JPackagePolicyTranslation#h11610-10]
@@ Строка 44: / Строка 46: @@
 Великую Войну За Тапки ?
-Придется искать jar'ы по файлопомойкам интернета, откуда угодно,
+Придется искать jar’ы по файлопомойкам интернета, откуда угодно,
 но только не из родного дистрибутива. Кому тогда они вообще нужны?
-</blockquote>
+{{конец цитаты}}
 === Общая информация о 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://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html]
 <div style="display: inline; color: red;">Если используется конструкция вида java -jar, то classpath должен быть задан в MANIFEST.MF, атрибут Class-Path.
 При использовании ключа jar игнорируется значение ключей classpath и cp</div>
 как следствие, в дистрибутиве использование java -jar для запуска приложений не приветствуется.
+{{Category navigation|title=Java|category=Java|sortkey={{SUBPAGENAME}}}}