Упаковочный многоплатформенный многомодульный проект maven

Question

Я участвую в проекте с открытым исходным кодом (ps3mediaserver), который был перенесен из кода google (SVN) и ANT (для задач сборки) в git (GitHub) и maven. У меня есть собственная вилка (называется pms-mlx), где я хочу, чтобы некоторые плагины были частью стандартной упаковки при выпуске. Я довольно новичок в maven и не слишком уверен, как проект должен быть структурирован, чтобы уважать путь maven.
Начну с описания того, как окружающая среда вела себя ранее, и затем даст мысли о переходе на maven.

Ссылки:

• Старый: SVN + ANT ps3mediaserver project on google code
• Старый: SVN + ANT pms-mlx project on SourceForge
• Новое: Git + Maven ps3mediaserver project on GitHub
• Новое: Git + Maven pms-mlx project on GitHub

Старый поведение:

Структура

Проект:

+--workspace 
     +--plugins 
      +--plugin1 
      build.xml 
      +--plugin2 
      build.xml 
     +--ps3mediaserver_mlx 
      +--plugins 
      build.xml 

Основной проект ps3mediaserver_mlx, все плагины живут в папках, вложенных в папку рабочего пространства/плагинов.
ps3mediaserver_mlx/build.xml содержит целевой объект BuildWithoutLibs, который будет строить банку основного проекта и скопировать его в рабочее пространство/pms_no_libs.jar, которое затем будет ссылаться (в этом месте) плагинами.
При выполнении цели построения любого плагина плагин будет создан, а полученный jar будет скопирован в ps3mediaserver_mlx/plugins/[plugin_name] .jar.
И, наконец, при упаковке приложения с использованием цели сборки в ps3mediaserver_mlx/build.xml плагины, содержащиеся в рабочей области/ps3mediaserver_mlx/plugins, будут упакованы (в установщик exe для windows, dmg для OSX или tar.gz для Linux) ,

Новое поведение Структура проекта была изменена следующим образом:

+-- workspace/ 
+-- pom.xml (global-pom) 
+-- ps3mediaserver/ 
| +-- pom.xml (pms-pom) 
| +-- src/ 
|   ... 
+-- plugins/ 
| +-- pom.xml (plugins-pom) 
| +-- Plugin1/ 
     | pom.xml (plugin1-pom) 
     | src/ 
| +-- Plugin2/ 
     | pom.xml (plugin2-pom) 
     | src/ 
+-- pms-package/ 
    +-- pom.xml (package-pom) 
    +-- src/main/assembly/ 
    +-- src/main/external-resources/ 

ОБЯЗАННОСТИ:
global-pom Корень ПОМ, содержащий все зависимости, используемые PMS. Это позволяет использовать ту же версию без повторного использования их в любом плагине (это хорошая идея?). Строит все и содержит раздел модулей для выполнения те же команды Maven на все проекты

<modules> 
    <module>ps3mediaserver</module> 
    <module>plugins</module> 
    <module>pms-package</module> 
</modules> 

pms-pom: Наследуется от глобального П-andbuilds СУТ банки

plugins-pom: Наследуется от глобального-П; содержит параметр pms (который потребуется для всех плагинов); содержит список всех модулей, имеющих быть построено

pluginX-П: Наследуется из плагин-П и содержит пользовательскую конфигурацию плагина

package-pom: Отвечает упаковать PMS по платформе она строится на.

Эта структура представляет собой способ использования maven для использования?

Все работает до упаковки. Это означает, что основная панель приложения, а также все плагины были построены и должны быть упакованы. Ответственность за это несет пакет-пом.
В исходном приложении есть только один pom.xml, а упаковка выполняется с использованием разных профилей для Windows, Linux и OS X. Тот, над которым я сейчас работаю, предназначен для OSX и использует osxappbundle-maven-plugin, но исходный код никогда не используется будучи упакованными в файл приложения. Это потому, что проект упаковки больше не наследуется от фактического проекта.
Как включить встроенную банку для правильной упаковки в файл приложения?
Я пробовал ссылаться на банку в дополнительных ресурсах и как на путь пользовательского класса, но никогда не с успехом.

Answer 1

Вы определили зависимость, например в плагинах/pom.xml

<dependencies> 
    <dependency> 
    <groupId>net.pms</groupId> 
    <artifactId>pms-mlx</artifactId> 
    <version>1.52.1_mlx_v0.8-SNAPSHOT</version> 
    </dependency> 
</dependencies> 

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

Рекомендуется применять тег modelVersion непосредственно после тега проекта и перед родительским тегом. После того, как родительский тег помещает информацию в текущий модуль как artifactId.

После погружения в проект я заметил, что вы определили в вашем ваших плагинов/WebservicePlugin:

<modelVersion>4.0.0</modelVersion> 
<artifactId>WebservicePlugin</artifactId> 
<version>3-SNAPSHOT</version> 
<packaging>jar</packaging> 

<parent> 
    <groupId>net.pms</groupId> 
    <artifactId>pms-plugins</artifactId> 
    <version>1.52.1_mlx_v0.8-SNAPSHOT</version> 
</parent> 

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

<modelVersion>4.0.0</modelVersion> 

<parent> 
    <groupId>net.pms</groupId> 
    <artifactId>pms-plugins</artifactId> 
    <version>1.52.1_mlx_v0.8-SNAPSHOT</version> 
</parent> 
<artifactId>WebservicePlugin</artifactId> 

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

Еще одна вещь, которую я заметил, что вы определили во многих плагинах (если не все) конфигурацию и использование плагина maven-compiler ... Это должно быть сделано с помощью компонента pluginManagement в вашем корневом pom ... простое обслуживание вашего проекта.

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