Лучший способ поделиться частями Maven pom.xml между несвязанными проектами? - PullRequest
8 голосов
/ 11 ноября 2010

Наша компания определила ряд «лучших практик» в отношении мавенских помпонов. Например, указание utf-8 для обработки ресурсов, папки для фильтрации, обработка модульных тестов и интеграционных тестов и параметры компилятора.

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

Есть ли какой-нибудь способ, которым мы можем предоставить / применить эти настройки и свойства через Maven? Это почти как предоставление каждому проекту родительского pom.xml, но я не хочу (и не могу), чтобы все эти проекты ссылались на одного и того же родительского pom.

Нам нужен подход, который будет работать как на машинах разработчика, так и на нашем сервере Hudson CI.

Ответы [ 5 ]

8 голосов
/ 11 ноября 2010

Единственное решение maven - общий родитель. Возможно, если бы вы использовали «освобожденного» родителя, вы могли бы сделать это?

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

4 голосов
/ 03 октября 2012

(это старый поток, я просто добавляю эту информацию для справки)

Для зависимостей вы можете использовать блок импорта "dependencyManagement" (но он будет работать только с зависимостями, а не со свойствами,и т. д.).

Просто создайте «библиотечный» модуль, определяющий различные зависимости как обычно (с их исключениями и конкретными версиями).

Затем в главном модуле вашего проекта выимпортируйте этот раздел зависимостей в ваш раздел "dependencyManagement": все зависимости, определенные в библиотеке pom, будут импортированы.И, кроме того, каждая версия, определенная в этом dependencyManagement, будет всегда используемой Maven (Maven не будет использовать другую версию, чем та, которая определена в dependencyManagement).Это почти обязательно для того, чтобы управлять вашим classpath, если у вас есть разные проекты, использующие один и тот же набор библиотек.

В pom вашего основного проекта импортируйте pom библиотеки следующим образом:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.mycompany.mylibrary</groupId>
            <artifactId>mylibrary-artifact</artifactId>
            <version>mylibrary-version</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        ...

Чек онлайновая документация maven

4 голосов
/ 11 ноября 2010

Вы можете создать архетип проекта maven с настройками, которые соответствуют рекомендациям вашей компании. Это скорее «обеспечение», чем «принудительное» решение, и, возможно, его может быть недостаточно (в зависимости от того, каковы эти передовые практики на самом деле). http://maven.apache.org/guides/mini/guide-creating-archetypes.html

3 голосов
/ 11 ноября 2010

Это почти как предоставление каждому проекту родительского pom.xml, но я не хочу (и не могу), чтобы все эти проекты ссылались на один и тот же родительский pom.

IЯ не говорю, что обязательно помещать все в родительское POM, но в корпоративной среде, это действительно хорошая идея иметь корпоративное POM верхнего уровня (как показано в разделе 3.6.2.2. Мультимодульный Enterprise Project из книги maven), с собственным циклом выпуска.

Но этого будет недостаточно, чтобы что-то навязать, и я предлагаю посмотреть на Плагин Maven Enforcer , который предлагает существующие правила , но также позволяет писать свои собственные правила, используя maven -forcer-rule-api .Я не могу комментировать, как далеко вы можете пойти с пользовательскими правилами, хотя.Во всяком случае, я очень рекомендую этот плагин.Если вы еще не используете его, определенно пора начинать:)

2 голосов
/ 11 ноября 2010

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

...