Проект maven строит свои собственные зависимости?

Question

С maven возможно ли иметь проект верхнего уровня с типом упаковки "war", который будет собирать себя и все зависимые от него модули (упакованные как jar) и генерировать файл project.war?

Большая часть примеров документации и других примеров, которые я видел, часто используют проект верхнего уровня с типом упаковки "pom", и проект служит только для объединения модулей. Могу ли я избежать этого?

Таким образом, в основном мне нужно что-то вроде объявления <module>my-module</module> для maven для сборки, и в том же POM, объявление <dependency>...my-module's artifact...</dependency> в том же модуле, который нужно построить. Может быть плагин, как кто-то уже предложил?

Обновление : Другими словами (для упрощения проблемы): Если у меня есть project A и project B, где project A зависит от project B - есть ли способ выполнить сборка на project A, а также автоматическая сборка project B (и включение project B в качестве своей зависимости - создание projectA.war, который содержит projectB.jar)?

Answer 1

super_aardvark предложил правильный путь, но,
Для требования я бы предложил следующую структуру. Подходит и хорошо структура также:

Consedering ProjectA as project-webapp, ProjectB as project-core

Вы можете иметь следующую структуру:

Ваш грандиозный проект:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>com.mycompany.project</groupId>
    <artifactId>project</artifactId>
    <version>2.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <name>Project Repository System</name>
    <description>Project Repository System R2</description>

    <modules>
        <module>project-core</module>
        <module>project-webapp</module>
    </modules>
 </project>

Ваш проект WebApp:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <parent>
        <groupId>com.mycompany.project</groupId>
        <artifactId>project</artifactId>
        <version>2.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>project-webapp</artifactId>
    <version>2.0-SNAPSHOT</version>
    <packaging>war</packaging>
    <name>Project Web Application</name>
    <description>Project Repository</description>
    <dependency>
            <groupId>com.mycompany.project</groupId>
            <artifactId>project-core</artifactId>
            <version>2.0-SNAPSHOT</version>
     </dependency>

 </project>

Ваш основной проект:

<project>
    <parent>
        <groupId>com.mycompany.project</groupId>
        <artifactId>project</artifactId>
        <version>2.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>project-core</artifactId>
    <version>2.0-SNAPSHOT</version>
    <packaging>jar</packaging>
    <name>Project Core</name>
    <description>ProjectCore</description>

 </project>

Ваш Структура каталогов должна выглядеть следующим образом:

-------Grand Parent.pom
  |
  |--------project-webapp
  |                     |
  |                     project-webapp.pom
  | 
  | -------project-core.pom
                        |
                       project-core.pom

Из родительского модуля выполните mvn clean install, он создаст как веб-приложение, так и основной проект

Answer 2

Это невозможно в Maven 1, 2 или 3.

Я бы рекомендовал отказаться от этой идеи, потому что вся цель Maven - обеспечить стандартизированный процесс разработки . Не боритесь со структурой, просто создайте родительский модуль POM и создайте под ним модуль WAR и другие зависимости.

Answer 3

Это не совсем то, для чего нужен проект верхнего уровня.Ваш WAR-проект имеет зависимости, которые представляют собой артефакты (например, jars), которые будут включены в WAR (в WEB-INF / lib) при запуске mvn package.Ваш родительский проект WAR может иметь проект верхнего уровня в качестве своего родителя, но он не должен быть родителем его зависимостей.Возможно, вы захотите, чтобы этот проект верхнего уровня был родительским как для проекта WAR, так и для проектов JAR, которые являются зависимостями в WAR.

Answer 4

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

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

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

Профили Maven могут помочь, и вот хорошая статья на этот счет:

Использование агрегатных и родительских POM

Также обратите внимание в статье на концепцию пакетного помпа, о которой я раньше не знал.

Помните, что mvn clean install поместит ваш артефакт в локальный репозиторий. Таким образом, если модуль A зависит от модуля B, если в вашем локальном репо установлена ​​последняя сборка модуля B, у вас все должно быть в порядке. Таким образом, если бы существовал внешний инструмент, который следил за изменениями в модуле B и автоматически собирал их, когда они были, и помещал эти изменения в локальное хранилище, тогда, когда модуль A был перестроен, он бы воспринял эти изменения. Существуют инструменты непрерывной интеграции (CI), которые могут сделать это, такие как Jenkins. Но вам потребуется локальная установка, чтобы эта работа работала напрямую с вашим локальным репо. Это все еще вариант, хотя.

Еще один вариант - для среды CI перенести ваши сборки на внешнее хранилище maven (или даже на то, которое вы настроили локально с помощью чего-то вроде Nexus). Затем вы настраиваете свои сборки CI так, чтобы вытащить их из этого места.

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

Я бы порекомендовал исследовать непрерывную интеграцию и непрерывную доставку для получения дополнительной информации и идей.

Answer 5

В родительском pom вы должны определить последовательный порядок модулей для компиляции. Вы можете добавить военный упаковочный модуль к последнему в этом списке. Он просто объединит весь предыдущий скомпилированный код.

Answer 6

NetBeans имеет опцию, которая позволяет вам делать именно это с проектами Maven, но я не знаю ни одного чистого решения Maven.Я думаю, что задача больше подходит для IDE, потому что она знает, для каких зависимых проектов у вас есть код (в зависимости от того, какие проекты вы открыли в рабочей области).Как сам Maven различает зависимость, которую вы хотите построить, и зависимость, которую нужно получить из репозитория.А для тех, кто должен быть собран, где он должен искать исходный код?

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

Answer 7

Не совсем - (ну, я могу придумать пару способов, но я бы не стал их использовать, поскольку они запутаны и идут вразрез с основными идеями / практиками Maven).

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