Наличие проекта maven для создания собственных зависимостей?
С maven возможно иметь проект верхнего уровня, тип упаковки которого - "война", который будет строить себя и все свои зависимые модули (упакованные как jar) и иметь сборку, генерирующую проект.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
как его зависимость - создание проекта.война, которая содержит projectB.jar)?
7 ответов
Это не совсем то, что проект верхнего уровня является. Ваш проект WAR имеет зависимости, которые являются артефактами (например, jars), которые будут включены в WAR (в WEB-INF/lib) при запуске "пакета mvn". Ваш проект WAR pom может иметь проект верхнего уровня в качестве родителя, но он не должен быть родителем его зависимостей. Возможно, вы захотите, чтобы этот проект верхнего уровня был родителем как проекта войны, так и проектов JAR, которые являются зависимостями в войне.
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
от родительского pom execute mvn clean install
он будет строить как веб-приложение, так и основной проект
Это невозможно в Maven 1, 2 или 3.
Я бы рекомендовал отказаться от этой идеи, потому что вся цель Maven заключается в обеспечениистандартизация процесса разработки. Не боритесь со структурой, просто создайте Родительский модуль POM и сделайте модуль WAR и другие зависимости под ним.
когда у вас есть многомодульный проект, и вы делаете работу в нескольких модулях одновременно, это может быть утомительно и подвержено ошибкам, чтобы убедиться, что все необходимые зависимости обновлены.
в моей ситуации я хотел бы, чтобы моя система сборки обнаруживала изменения и создавала только необходимые модули. Один из способов это может быть возможно с maven для кого-то написать пользовательский плагин, который делает это, что не кажется непреодолимым, учитывая, что уже есть сложные Плагины доступно, как плагин Maven release.
другие уже упоминали концепцию агрегации pom, которая повторяется и создает необходимые артефакты. Но иногда вы построили больше, чем вам действительно нужно.
профили Maven могут помочь, и вот хорошая статья в этом отношении:
использование Aggregate и родительских POMs
также отметим в статье концепцию пакетного пом, которой у меня раньше не было знать.
помните, mvn clean install будет толкать ваш артефакт в локальное РЕПО. Поэтому, если модуль A зависит от модуля B, пока ваше локальное РЕПО имеет последнюю сборку модуля B, вы должны быть настроены. Таким образом, если бы был внешний инструмент, который наблюдал за изменениями в модуле B и автоматически построил его, когда они были, и подтолкнул эти изменения в локальное РЕПО, тогда, когда модуль A был перестроен, он бы принял эти изменения. Существует непрерывная интеграция (CI) инструменты, которые могут это сделать, как Дженкинс. Но вам понадобится локальная установка, чтобы иметь эту работу непосредственно с вашим локальным РЕПО. Это все еще вариант.
другой вариант был бы для среды CI, чтобы подтолкнуть ваши сборки к внешнему репозиторию maven (или даже к тому, который вы устанавливаете локально с чем-то вроде Nexus). Затем вы настраиваете свои сборки CI, чтобы вытащить из этого места.
Итак, есть решения, которые полагаются на другие инструменты или потенциальные плагины, чтобы делать то, что вы хотите - просто зависит от того, сколько времени и усилий нужно вложить, чтобы получить все настройки. Но, как только вы преодолеете это препятствие, у вас будет система (а также знания и опыт), которую вы можете использовать во всех своих проектах, не говоря уже о том, что вы будете знакомы с тем, сколько магазинов/команд разработки работают.
Я бы рекомендовал исследовать непрерывную интеграцию и непрерывную доставку для получения дополнительной информации и идей.
в Родительском pom вы должны определить последовательный порядок модулей для компиляции. Вы можете добавить модуль упаковки войны к последнему в этом списке. Он просто объединит весь предыдущий скомпилированный код вместе.
не совсем - (Ну, я могу придумать пару способов, но я бы не использовал их, поскольку они запутаны и идут против основного этоса/практики Maven).
Не забывайте, что другой целью POM верхнего уровня является предоставление единой точки для установки общих деталей, таких как конкретные версии зависимостей, используемых в модулях проекта.
NetBeans имеет опцию, которая позволяет вам делать именно это с проектами Maven, но я не знаю никаких чистых решений Maven. Я думаю, что задача больше подходит для IDE, потому что она знает, для каких зависимых проектов у вас есть код (на основе каких проектов вы открыли в рабочей области). Как Maven сам различает зависимость, которую вы хотите построить, и зависимость, которую нужно извлечь из репозитория. А для тех, кого нужно построить, где его искать исходный код?
во всяком случае, другое решение проблемы, которое я успешно использовал несколько раз, заключается в создании простого сценария оболочки, который переходит в ваши папки проектов и запускает сборку, а затем ждет ее завершения, затем переходит к следующему проекту и так далее.