Упаковка мультиплатформенного мультимодульного проекта Maven - PullRequest
0 голосов
/ 27 марта 2012

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

Ссылки:

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

Структура проекта:

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

Основной проект - ps3mediaserver_mlx, все плагины находятся в подпапкахпапка workspace / plugins.
ps3mediaserver_mlx / build.xml содержит целевой BuildWithoutLibs, который соберет флягу основного проекта и скопирует ее в workspace / 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 Корневой pom, содержащий все зависимости, используемые pms.Это позволяет использовать одну и ту же версию без повторного выделения их в любом плагине (это хорошая идея?).Создает все и содержит раздел модулей для выполнения одних и тех же команд maven для всех проектов

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

pms-pom : наследуется от global-pom и создает pms jar

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

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

package-pom : Isотвечает за упаковку pms в соответствии с платформой, на которой он построен.

Представляет ли эта структура способ использования mavenment?

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

1 Ответ

1 голос
/ 05 апреля 2012

Вы определили зависимость, например, в plugins / 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-plugin ... Это должно быть сделано с помощью части pluginManagementв вашей корневой папке ... для простого обслуживания вашего проекта.

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

...