Понимание зависимостей Maven и сборки

Question

Я не очень разбираюсь в Maven, и его логика компиляции и упаковки приводит меня в замешательство.

У меня есть некоторые зависимости, объявляемые как:

<dependency>
  <groupId>com.dependency_group</groupId>
  <artifactId>dependency_1</artifactId>
  <version>1.0.0</version>
</dependency>


<dependency>
  <groupId>com.dependency_group</groupId>
  <artifactId>dependency_2</artifactId>
  <version>1.0.0</version>
  <scope>provided</scope>
</dependency>

Итак, насколько я понимаю,dependency_1 будет добавлено в classpath моей программы как что-то, что идет вместе с моим jar, а dependency_2, с другой стороны, будет добавлено в classpath как что-то, что система выполнения обеспечит при развертывании.

Затем я запускаю цель package Maven, и ни одна из моих зависимостей не упакована с моим кодом (я использую плагин shade, но даже без него ничего не меняется).

Я ожидал, чтокогда какая-то зависимость установлена ​​как compile scope, она будет экспортирована с моим скомпилированным кодом, начиная с AFAICS, нет смысла устанавливать classpath, говоря, что зависимость придет вместе с моим кодом, а Maven просто не упаковывает этозависимость с ним.Мне кажется, что Мейвен не подчиняется своему контракту.

Итак:

1 - Какая логика стоит за этим?

2 - Нужно ли мне всегда использовать плагин Assembly?

3 - Есть ли случаи, когда люди будут определять зависимость как compile и не захотят, чтобы она была упакована в jar?

Answer 1

Позвольте мне пролить немного света на основной момент здесь.Существуют два основных типа java-артефактов:

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

Для приложений ваши рассуждения имеют смысл.Wars и Ears автоматически упаковывают все свои зависимости компиляции, и для этого вам не нужен плагин сборки.Для библиотек вы не упаковываете зависимости в библиотеку.Maven обрабатывает транзитивное разрешение зависимостей и будет сбит с толку, если вы поместите толстую банку в путь к классам.

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

Answer 2

Вы используете compile scope, когда хотите, чтобы вместе с вашим кодом появились зависимости.Например, вы хотите, чтобы Jackson был частью вашего приложения, если вы используете его для сериализации json.

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

Должен ли я всегда использовать плагин Assembly

Никто не заставляет вас делать это.