Как определить общие конфигурации в Maven проектах - PullRequest
0 голосов
/ 11 января 2019

Я надеюсь, что это правильное место и правильное обсуждение для начала.

Что я хочу

Я ищу хороший / правильный способ для работы с несколькими проектами Maven, которые имеют общую конфигурацию, которая в моем случае

  1. Установка версии maven-compiler-plugin с исходной / целевой версией компиляции
  2. Установить подключаемый модуль maven-source-plugin для присоединения источников к артефактам
  3. Определить сервер локального хранилища
  4. Определение общих зависимостей (с помощью dependencyManagement и зависимостей).

Что я сделал

Моим первым подходом было создание многомодульного проекта. Но поскольку модули на самом деле независимы, когда дело доходит до релиза (то есть не одного и того же цикла релиза), это кажется большим бременем выгоды. Я также не смог сделать так, чтобы я мог независимо работать с подмодулем в IntelliJ и иметь для каждого подмодуля свою собственную работу Jenkins. Для меня это всегда было все или нет

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

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

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

Спасибо за чтение, и я надеюсь, что это было понятно

Ответы [ 2 ]

0 голосов
/ 11 января 2019

Вы можете повторно использовать раздел управления зависимостями из другого pom, используя <scope>import</scope>, описанный здесь , но это будет работать только для зависимостей, и вы не можете сделать это для свойств, репозиториев и т. Д.

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

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

0 голосов
/ 11 января 2019

Просто создайте родительский POM с общими настройками и оставьте остальные отдельно. Опубликуйте это POM в (локальном) хранилище отдельно как отдельную сущность с pom упаковкой (на этом уровне нет подмодулей).

Взгляните на родительский POM Spring Boot в качестве примера.

Единственным изменением в ваших проектах будет использование нового POM в качестве родительского POM.

<project ... >
  <parent>
      <groupId>my-group</groupId>
      <artifactId>my-parent</artifactId>
      <version>1</version>
  </parent>
  ...

Обратите внимание, однако, что обычно не стоит жестко кодировать зависимости в родительском POM (определение версий с помощью dependencyManagement - это нормально, но пусть каждый проект явно указывает, какая зависимость ему действительно нужна).

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