Java-зависимости при разработке и развертывании

Question

У меня общий вопрос о том, как правильно управлять зависимостями JAR для компиляции и развертывания. Я обычно выкладываю каталоги dev, как показано ниже, для простой библиотеки / приложения.

Calculator
   src
   test
   build
   lib
   …

Есть много способов сделать это, но это мой типичный макет для типовых проектов. Мой вопрос вращается вокруг каталога lib. Обычно я помещаю файлы jar, от которых зависит мой проект, в каталог lib (log4j и т. Д.), Поэтому во время компиляции я могу установить различные пути как lib \ log4j.jar или что-то подобное. Теперь, когда мы создаем распространяемый пакет, я старался отразить это расположение.

dist
   Calculator.jar
   lib
      log4j.jar
      addition.jar
      subtraction.jar

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

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

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

dist
   ScentificCalculator.jar
   lib
      Calculator.jar
      lib 
         Log4j.jar
         addition.jar
         subtraction.jar

Конечно, это может выйти из-под контроля, чем глубже ваше дерево зависимостей:

SuperWhizBangCalculator.jar
lib
   ScientificCalculator.jar
   lib 
      Calculator.jar
      lib
         log4j.jar
         addition.jar
         subtraction.jar

Другой вариант - расплющить дерево:

SuperWhizBangCalculator
   lib
      ScientificCalculator.jar
      Calculator.jar
      log4J.jar
      addition.jar
      subtraction.jar

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

Спасибо за время ...

Answer 1

Перейти к вашему последнему варианту - каталог плоских библиотек. Это то, что вы найдете, если загрузите любой проект с открытым исходным кодом, который имеет зависимости (они могут использовать другой уровень подкаталога, если есть ряд связанных JAR-файлов).

Не путайте структуру каталогов с управлением зависимостями - это совершенно разные вещи. Если вам нужно интеллектуальное управление зависимостями, вам нужно взглянуть на что-то вроде Maven, ANT с Ivy или, возможно, на какую-нибудь модульную систему с явными зависимостями (OSGi).

Answer 2

Чтобы повторить другой ответ: «Почему бы просто не использовать Maven?»

Maven будет управлять всеми вашими зависимостями за вас, и когда другой проект захочет использовать ваш jar, им будет намного, намного проще это сделать. Если в мире Java существует стандарт для сборки, компоновки и зависимостей, то это Maven.

Answer 3

Не отвечает на ваш вопрос напрямую. Но вы можете взглянуть на Apache Maven 2, который может сделать для вас большую часть «управления зависимостями».

Имейте в виду, что есть некоторая кривая обучения для запуска, работы и работы Maven 2:)

Кроме этого, третий вариант имеет смысл для меня.

Answer 4

здесь есть два типа вещей

1. Внешняя зависимость от сторонних библиотек, таких как log4j
2. Внутренняя зависимость внутри проекта

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

Answer 5

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

Я думаю, что ваш третий вариант самый лучший.

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

Answer 6

Важная информация - как будут загружаться классы. В ситуации «java -jar SuperWhizBang.jar» у вас будет один загрузчик классов, загружающий все классы. Тогда имело бы смысл объединить зависимости.

Если вы решите использовать отдельные загрузчики классов, то иерархия будет хорошей идеей. Обычно это происходит в настройках OSGi, но это, вероятно, излишне для вашего решения.

Answer 7

Я бы абсолютно согласился с последним подходом. Представьте себе программу A, использующую библиотеки B и C, в обеих из которых используется D. В структурированной компоновке у вас будет два экземпляра D, что просто требует конфликтов версий.