Должен ли я связать исходные файлы и файлы классов в одном и том же JAR?

Question

Отдельные файлы JAR

При создании файлов JAR я всегда держал источник отдельно и предлагал его в качестве дополнительной опции.

Например:

• Foo.jar
• Foo-source.jar

Кажется, что это очевидный способ сделать что-то, и он очень распространен.Преимущества:

1. Сохраняет бинарный файл небольшим
2. Источник не может быть открытым / общедоступным
3. Быстрее для загрузчика классов?(Понятия не имею, просто догадываюсь)

Single Jar

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

1. Классы + источник по-прежнему ничтожно мал (и останется таким):
2. Источник открыт
3. Скорость загрузки классов этой банки не имеет значения

Сохранение источника с классами, однако, дает новые преимущества:

1. Одиночная зависимость
2. Нетпроблемы несоответствия версий между источником и классами
3. Разработчики, использующие этот jar, будут всегда иметь источник в руках (для отладки или проверки)

Эти новые преимущества действительно привлекательны для меня.Да, я мог бы просто заархивировать исходный код, классы и даже javadoc в zip-файл и позволить клиентам моего компонента решать, что они хотят использовать (как Google делает с библиотеками guava ), нодействительно ли это того стоит?

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

Я ошибаюсь?Есть ли лучший способ?

Answer 1

Да, я мог бы просто заархивировать исходный код, классы и даже javadoc в zip-файл и позволить клиентам моего компонента решать, что они хотят использовать (как Google делает с библиотеками гуавы), но стоит ли это того?

Конечно, оно того стоит! Это займет около 2 секунд или всего несколько минут, чтобы изменить ваши сценарии сборки.

Именно так большинство людей, распространяющих исходники и двоичные файлы, справляются с этой проблемой.

EDIT

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

• Они не собираются использовать исходный код на платформе развертывания.
• Следовательно, размещение исходного кода в двоичном JAR-файле является пустой тратой дискового пространства, замедляет развертывание и замедляет запуск приложения.
• Если они хотят что-то с этим сделать, у них есть проблема. Как они восстанавливают файл JAR, чтобы избавиться от исходного кода? Откуда они знают, что безопасно оставить вне дома?

С точки зрения развертывателя / пользователя, здесь нет положительных сторон, только отрицательные.

Наконец, ваше мнение о том, что люди не могут отслеживать исходные или двоичные версии, на самом деле не выдерживает критики. Большинство людей, которые были бы заинтересованы в исходном коде, вполне способны сделать это. Кроме того, есть несколько простых вещей, которые вы можете сделать для решения проблемы, например, использование имен файлов JAR, которые включают номер версии вашего программного обеспечения, или помещение номера версии в манифест.

Answer 2

Насколько маленький маленький и почему ваша банка должна действовать не так, как другие?

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

Я говорю это потому, что если ваш кувшин не должен отличаться от других, то вы должны исходить из того, что другие должны делать то же, что и вы.Если это так, то размер банки не важен, потому что он дублируется на все «маленькие» банки.Тогда моя WAR намного больше, чем нужно, что, по общему признанию, не является серьезной проблемой, но это не то, что я бы выбрал для производства, когда я так легко могу загрузить исходники в DEV.

Answer 3

Я только что натолкнулся на потенциальную ловушку для классов java + в одном jar.

Если у вас есть java-файлы в jar-е, и этот jar-файл включен в classpath последующего выполнения javac, выНЕОБХОДИМО убедиться, что временные метки файла Java меньше, чем временные метки файла класса.

Этот сценарий может возникнуть, когда вы копируете / перемещаете файлы java или класса перед упаковкой в ​​jar-файл.

Если java-файл новее, чем класс, то даже если java-файл найден в пути к классам (а не в качестве аргумента для javac), javac попытается скомпилировать этот java-файл, а затем потенциально может привести к дублированию ошибок классана этапе компиляции.

По этой причине я бы рекомендовал хранить исходный код в отдельном фляге для файлов классов.

Обратите внимание, что соответствующие флаги в javac не позволят вам предпочесть класс над источником: http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#searching

Answer 4

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

Answer 5

Я предпочитаю «Отдельные банки».

Поскольку двоичный класс jar предназначен для работы на JVM, а источник - нет. Источник должен тщательно поддерживаться вашей системой контроля версий (SVN). Если исходный код должен быть освобожден, поместите его в отдельную банку. Многие открытые исходники разделяют класс jar и источник один.