Имея проект maven, создайте собственные зависимости?

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

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

В принципе мне нужно что-то, что эффективно, как объявление <module>my-module</module> для maven для сборки, и в том же POM, объявляющем <dependency>...my-module artifact...</dependency> в том же модуле, который нужно построить. Может быть, плагин, как кто-то уже предложил?

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

Ответ 1

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

Ответ 2

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

Закрепление ProjectA как project-webapp, ProjectB как 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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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