Как определить специфичный для организации родительский пом - PullRequest
Новая
       17

Как определить специфичный для организации родительский пом

2 голосов
/ 10 июня 2011

Конверт: Maven 2.2.1 У меня есть два Java-проекта под SVN (ProjectA, ProjectB).Моя структура maven выглядит следующим образом .. 

For projectA 
pom.xml (contains ProjectA parent pom definitions)

   module moduleA
   module moduleB


For projectB 
pom.xml (contains ProjectB parent pom definitions)

   module moduleC
   module moduleD

projectA / pom.xml и projectB / pom.xml содержат общие определения, такие как плагины junit, selenium, compiler, eclipse, которые являются общими для обоих проектов.(например, приведенный ниже) 

    <dependency>
        <groupId>commons-lang</groupId>
        <artifactId>commons-lang</artifactId>
        <version>2.4</version>
        <type>jar</type>
        <scope>compile</scope>
    </dependency>

    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.7</version>
        <scope>test</scope>
    </dependency

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

EDIT1:

company / pom.xml 

<modelVersion>4.0.0</modelVersion>

<groupId>com.mycompany</groupId>
<artifactId>company</artifactId>
<packaging>pom</packaging>

<name>parent</name>
<version>1.0.0</version>

<build>
    <defaultGoal>install</defaultGoal>
</build>

<dependencies>
    <dependency>
        <groupId>commons-lang</groupId>
        <artifactId>commons-lang</artifactId>
        <version>2.4</version>
        <type>jar</type>
        <scope>compile</scope>
    </dependency>

    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>servlet-api</artifactId>
        <version>2.5</version>
        <scope>provided</scope>
    </dependency>
</dependencies>

projectA / pom.xml 

<modelVersion>4.0.0</modelVersion>

<parent>
    <groupId>com.mycompany</groupId>
    <artifactId>company</artifactId>
    <version>1.0.0</version>
</parent>

<groupId>com.mycompany</groupId>
<artifactId>projectA</artifactId>
<packaging>pom</packaging>

<name>projectA</name>
<version>1.0.0</version>

<modules>
    <module>moduleA</module>


<build>
    <defaultGoal>install</defaultGoal>
</build>

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

projectA / moduleA / pom.xml 

<modelVersion>4.0.0</modelVersion>

<parent>
    <groupId>com.mycompany</groupId>
    <artifactId>projectA</artifactId>
    <version>1.0.0</version>
    <relativePath>../pom.xml</relativePath>
</parent>

<groupId>com.mycompany</groupId>
<artifactId>moduleA</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>

<name>moduleA</name>

<build>
    <finalName>moduleA</finalName>
    <defaultGoal>install</defaultGoal>
</build>

<dependencies>
    <dependency>
        <groupId>commons-lang</groupId>
        <artifactId>commons-lang</artifactId>
    </dependency>

    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>servlet-api</artifactId>
    </dependency>
</dependencies>

Выдает следующую ошибку: 

Project ID: com.mycompany:moduleA
POM Location: c:\temp\maven\projectA\moduleA\pom.xml
Validation Messages:

    [0]  'dependencies.dependency.version' is missing for commons-lang:comm
ons-lang:jar
    [1]  'dependencies.dependency.version' is missing for javax.servlet:ser
vlet-api:jar

Ответы [ 3 ]

5 голосов
/ 15 июня 2011

Я бы серьезно пересмотрел добавление зависимостей в «супер» POM, это излишне объединяет проекты (но может намекать на то, что если проекты не несопоставимы, то их все равно следует объединить). Я думаю, что последний комментарий @lexicore является также острым, чтобы расширить аналогию с ООП, это также похоже на «смешивание уровней абстракции».

Алекс Гительман дает правильный ответ, вам нужно использовать dependencyManagement , как показано здесь Зависимость

Maven3 - это предполагается, что поддерживает фрагменты POM, см. Как использовать миксины Maven 3? , которые я так долго ждал.

У нас есть организация Über POM, но она содержит: 

<organization>
    <name>...</name>
    <url>...</url>
</organization>

<developers>
    <developer>
        <id>...<id>
        <name>...</name>
        <email>...</email>
        <roles>
            <role>...</role>
        </roles>
    </developer>

<distributionManagement>
    ...
</distributionManagement>

<repositories>
    <!-- your proxy repo here -->
</repositories>

Это вещи, которые меняются очень редко (если мы изменим наше хранилище / управление распределением, тогда все проекты должны измениться, если разработчик покинет или присоединится, мы можем обновить POM проекта в любое удобное время).

Зависимости относятся конкретно к рассматриваемому модулю, просто потому, что два независимых проекта имеют общие зависимости, не означает, что они всегда будут. Я полностью понимаю раздражение, возникающее из-за необходимости копировать «n» вставки групп XML для каждого проекта (плагин компилятора, плагины отчетности, junit и т. Д.), Но разные уровни активности в каждом проекте наверняка означают, что в какой-то момент они расходятся.

Каскад WRT строится в режиме непрерывной интеграции, если проект А требует изменения POM супер-зависимостей, тогда все вам придется перестраивать другие проекты - возможно, хорошо, если у вас всего 2 проекта, но даже Затем вы проверяли и строили оба, прежде чем вносить изменения?

4 голосов
/ 10 июня 2011

Если вам нужно повторно использовать только зависимости, создайте другой проект с упаковкой pom и укажите там зависимости. Давайте назовем это OrgDependencies Затем включите его как зависимость в ваши projectA и projectB. Он будет транзитивно извлекать все зависимости из проекта OrgDependencies.

В вашем примере в проекте A вместо 

<parent>
    <groupId>com.mycompany</groupId>
    <artifactId>company</artifactId>
    <version>1.0.0</version>
</parent>

Попробуйте поставить 

<dependencies>
  <dependency>
    <groupId>com.mycompany</groupId>
    <artifactId>company</artifactId>
    <version>1.0.0</version>
  </dependency>
</dependencies>

И удалить зависимости от commons-lang и т. Д. Из модулей.

Обновление.

Хотя мое предыдущее решение с транзитивными зависимостями должно работать, на самом деле то, что вам нужно это раздел <dependencyManagement> в вашей компании pom.xml

Здесь вы определяете версии.

Примечание: Все, что находится в разделе dependencyManagement, на самом деле не является зависимостью, а просто дескриптором, который позволяет указать версию и исключить транзитивные зависимости (при необходимости) в случае, если обычный раздел dependencies указывает эту зависимость. Таким образом, вы можете поместить столько элементов в dependencyManagement, сколько захотите, это не сделает зависимыми от них всех потомков.

Я проверил это, и оно работает: 

<?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/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>com.mycompany</groupId>
    <artifactId>company</artifactId>
    <packaging>pom</packaging>

    <name>parent</name>
    <version>1.0.0</version>

    <build>
        <defaultGoal>install</defaultGoal>
    </build>

    <dependencyManagement>
        <dependencies>
        <dependency>
            <groupId>commons-lang</groupId>
            <artifactId>commons-lang</artifactId>
            <version>2.4</version>
            <type>jar</type>
            <scope>compile</scope>
        </dependency>

        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
            <version>2.5</version>
            <scope>provided</scope>
        </dependency>
        </dependencies>
    </dependencyManagement>
</project>
3 голосов
/ 10 июня 2011

В проектах ОС я обычно использую 3+ уровня POM:

  • «POM для всей компании» содержит определения для всего разработчика, такие как управление распространением, отдельные версии плагинов и т. Д. Очень стабильный, обычно имеет версию с одним номером. Пример: Sonatype OSS Parent .
  • «Project POM» содержит определения для всего проекта: версия компилятора Java, управление зависимостями и т. Д. Родитель - это POM для всей компании. Пример: Базовый проект JAXB2 . Версия обновляется с каждым выпуском.
  • «Модуль POM» на разных уровнях. Перечислите отдельные зависимости (версии зависимостей унаследованы от POM проекта), добавьте «специальные» этапы сборки. Пример: Основы JAXB .

Я видел похожую модель и в других проектах ОС (например, в Apache).

Еще несколько комментариев:

  • У вас также может быть «POM отдела» или «POM продукта» в зависимости от размера компании и организации продукта.
  • Думайте о наследовании POM почти так же, как о наследовании ООП. Что бы вы поместили в какой абстрактный класс, чтобы иерархия классов была стабильной, но динамичной? Например, не имеет смысла определять версии зависимостей в POM для всей компании, поскольку версии меняются слишком часто. Напротив, определение управления распределением в начале проектов повредит принципу СУХОЙ.
...