Преимущества / недостатки построения одной огромной банки, а не нескольких меньших?

Я видел такие программы, какhttp://one-jar.sourceforge.net/ а такжеhttp://fjep.sourceforge.net/index.html Содействуйте сворачиванию вашего jar приложения и любых зависимостей в один исполняемый jar.

Каковы основные причины за / против этого?

Ответы на вопрос(5)

За:

Пакетирование библиотек и нативный кодОбеспечить правильное упорядочение во время выполнения элементов classpathУдалить необходимость для установщиков

против:

Новый загрузчик классов верхнего уровня может привести к проблемам, не замеченным во время нормального цикла разработкиЗаконность переупаковки библиотек на разных условиях лицензии

В общем, если это небольшое служебное приложение, я соберу его в одну банку. Для более крупных приложений (которые, вероятно, в любом случае потребуются установщик) или, если это библиотека для других, я не буду беспокоиться. Это будет просто еще одно звено в цепочке вещей, которые могут сломаться.

Решение Вопроса

За:

более легкое распространение,устраняет проблему с classpath,может быть упакован даже в презентацию MS PowerPoint в виде кликабельного значка, вероятно, OpenOffice также справится с этим.

против:

сложная упаковка - иногда вы попадаете в угол, например: как упаковать собственные расширения,требует дополнительного шага сборки,генерирует большие банки,может нарушить лицензионное соглашение библиотеки,убивает понятие повторного использования библиотеки,делает обновления иотладка (из-за дополнительного загрузчика classpath) сложнее.

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

Распространение FTW! Это намного проще, если пользователь свернулся с одним.

Распространение лицензий, применимых к зависимостям, является одной из основных причин против создания «убер» фляги. Когда создается jar-файл uber, происходит распределение любых зависимостей посредством распространения jar-файла uber. А в регионах, где прецедентное право не охватывает этот сценарий должным образом, можно быть готовым к ответственности.

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

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

которую я видел на рабочем месте, связана с тем, что поставщик предоставляет банки исправлений, которые должны предшествовать исходной версии в пути к классам.
Тем не менее, это приложение запускается через веб-запуск java (jnlp), и начиная с версии 6 Java, порядок зависимостей файла jar больше не гарантируется.
Поэтому единственный способ убедиться, что дублированные файлы классов находятся в правильной последовательности, - это повторно упаковать их в Uber JAR, сохранив самые последние пропатченные файлы классов и отбросив старые дубликаты.

 Rekin28 сент. 2010 г., 21:39
+1 за очень интересный вариант использования

Ваш ответ на вопрос