плагин сборки maven добавляет определенные файлы зависимостей, недоступные в JAR зависимостей

#java #maven #zip #maven-assembly-plugin

#java #maven #zip #maven-assembly-plugin

Вопрос:

Чтобы сократить время сборки многомодульного проекта maven, я хотел бы иметь собственные проекты для архивов развертывания.

У нас есть несколько автономных пакетов, которые поставляются в упакованном виде.ZIP с помощью maven-assembly-plugin. Поскольку в настоящее время упаковка ZIP-файла выполняется непосредственно из сборки пакетных модулей, нет проблем с тем, чтобы эти две вещи были внутри ZIP:

  • /lib со всеми банками зависимостей (включая банку со всеми нашими пакетами)
  • /script папка, которая не содержится ни в пакетной папке модуля, ни в его папке /target . Содержит некоторые .BATs / .CMDs и .properties, которые используются для разработки.

Когда дело доходит до создания собственного проекта для создания этого ZIP, у меня нет проблем с получением наших зависимостей (включая наш пакет-jar, содержащий все пакеты на основе Java и прочее), но я не знаю, как включить эту папку / script, которая не является частью модулей / целевого вывода.

Единственный способ, которым мне удалось собрать это вместе, — это иметь относительное определение этой папки, выглядящее примерно так:

 <fileSet>
        <directory>${basedir}../my-batches-project/src/main/scripts</directory>
        <includes>
            <include>*</include>
        </includes>
        <outputDirectory>/scripts</outputDirectory>
</fileSet>
  

Это работает только в том случае, если новый проект извлекается на том же уровне, что и проект multip-module.
Я задавался вопросом, есть ли лучший способ включить определенные файлы проекта maven.

Редактировать:

Возвращаясь к некоторым товарищам по команде, мы решили дублировать вышеупомянутую папку / script в обоих проектах. Внутри проекта развертывания, который создает ZIP, он останется в src / main / scripts, в то время как в пакетном модуле он будет находиться в src / test / scripts, чтобы разрешить локальное выполнение пакетов… однако мне это не нравится.

Ответ №1:

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

Учитывая, что это немного перегруженное решение в нашем контексте, в настоящее время мы утверждаем, что упаковка ZIP-файлов с очень близким развертыванием для наших пакетов происходит на назначенном сервере сборки, где есть другие файлы «только для производства», которые заменяются нашими файлами «только для разработки». мы можем житьс относительным путем, поскольку каждый из наших проектов maven проверяется на этом сервере сборки.