Nexus & Maven Corporate Pom — что в нем должно быть?

В настоящее время мы оцениваем возможность создания внутреннего репозитория Nexus компании для нашей разработки Java.

К сожалению, некоторые вопросы остались без ответа, но, возможно, вы сможете помочь.

Лучшей практикой кажется родительский pom для всех проектов внутри компании. Что не ясно, так это то, что должен содержать этот pom, кроме <organization>section.

Лучше всего также указать <distributionManagement> внутри этого pom? Если да, что он должен содержать и как он должен выглядеть, если мы хотим сослаться на связь компании (<site>, <repository>, <snapshotRepository>)?

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

Должны ли мы также указать там разделы <repositories> и <pluginRepositories> (ссылаясь на нашу внутреннюю связь)?

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

Лучше всего было бы, если бы кто-то мог предоставить полный пример корпоративного pom, который можно использовать с внутренним репозиторием Nexus.

Или все-таки лучше положить все это внутрь settings.xml, чтобы не привязывать проект к определенному репозиторию? Но насколько я знаю, <distributionManagement> нельзя указать в settings.xml? Также это будет утомительная работа по обновлению, если URL-адрес нексуса когда-нибудь изменится?

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

Заранее спасибо!


ОБНОВЛЕНИЕ/Решение

Благодаря ответу Michael-O ниже у меня есть необходимая информация.

  1. Теги <repositories> и <pluginRepositories> относятся к тегу settings.xml. Здесь можно указать репозиторий Nexus для "Загрузки" (при необходимости укажите учетные данные, используя <servers>
  2. <distributionManagement> относится к корпоративной базе pom, ссылаясь на базовый репозиторий Nexus для выпусков и снимков. Здесь можно указать репозиторий Nexus для "загрузки" (развертывания).
  3. Если необходимы подрепозитории (для логической группировки проектов), они указываются внутри проектов pom.xml и, следовательно, переопределяют те, которые находятся внутри компании pom. Чтобы упростить это и сохранить базовый URL-адрес нексуса только внутри корпоративного pom (остерегайтесь изменений URL-адреса), может быть полезно/возможно указать репозитории внутри <distributionManagement> следующим образом:

    <repository>
      <id>company-repository</id>
      <name>Internal Releases</name>
      <url>http://my.nexus.repo/releases/${subRepositoryId}-releases</url>
    </repository>
    
  4. Пример корпоративного pom можно найти в этом сообщении.

  5. Чтобы предотвратить изменения конфигурации внутри файлов или настроек pom, можно использовать псевдоним для URL-адреса нексуса. Хотя это потребует дополнительных усилий со стороны администрации.
  6. Если для проекта необходим сайт, общее определение внутри корпоративного pom использовать нельзя, его нужно объявлять индивидуально для каждого pom проекта. Чтобы упростить этот процесс, URL-адрес нексуса сайта может храниться внутри свойства корпоративного pom, на который затем можно ссылаться в управлении распространением сайта pom проекта.

Корпоративный pom может содержать что-то подобное:

  <project>
    ....
    <properties>
      <repository.group>common</repository.group>
      <repository.url.base>http://my.nexus:port/nexus/content</repository.url.base>
      <repository.url.repositories>${repository.url.base}/repositories</repository.url.repositories>
      <repository.url.sites>${repository.url.base}/sites</repository.url.sites>
    </properties>

    <distributionManagement>
      <repository>
        <id>company-repository</id>
        <name>Internal Releases</name>
        <url>${repository.url.repositories}/${repository.group}-releases</url>
      </repository>
      <snapshotRepository>
        <id>company-repository</id>
        <name>Internal Snapshots</name>
        <url>${repository.url.repositories}/${repository.group}-snapshots</url>
      </snapshotRepository>
    </distributionManagement>
    ....
  </project>

Проект pom похож на этот:

  <project>
    ...
    <properties>
      <repository.group>project-group</repository.group>
    </properties>

    <distributionManagement>
      <site>
        <id>company-repository</id>
        <name>Internal Releases</name>
        <url>dav:${repository.url.sites}/project-site</url>
      </site>
    </distributionManagement>
    ...
  </project>

ВНИМАНИЕ: может возникнуть вопрос, почему бы не включить часть сайта напрямую в корпоративный файл pom. Это невозможно, так как вы не можете развернуть несколько сайтов в одном и том же репозитории сайта, не создавая беспорядка. Используя способ, описанный выше, не нужно создавать репозиторий для каждого проекта, но можно логически сгруппировать их в более крупные группы или оставить их в группе/репозитории common-releases/snapshots.


person JDC    schedule 04.11.2015    source источник
comment
Репозитории, которые будут использоваться, должны быть помещены в settings.xml (что приводит к использованию корпоративной связи). на вашем CI-сервере...   -  person khmarbaise    schedule 04.11.2015
comment
Спасибо уже за комментарий. Для локальной разработки я бы поместил свойства внутри профиля внутри settings.xml тогда?   -  person JDC    schedule 04.11.2015
comment
@user1342006 user1342006 Пожалуйста, смотрите мои правки относительно сайтов.   -  person Michael-O    schedule 04.11.2015


Ответы (1)


Вы можете взглянуть на родительский POM Apache или родительский POM Maven. Минимальный корпоративный POM должен выглядеть так:

<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.example</groupId>
  <artifactId>example-parent</artifactId>
  <version>1-SNAPSHOT</version>
  <packaging>pom</packaging>

  <name>Exmaple Parent POM</name>
  <organization>
    <name>Example Inc.</name>
  </organization>

  <!-- This marked as deprecated for Maven 3.x. This is checked by maven-enforcer-plugin -->
  <!-- http://jira.codehaus.org/browse/MNG-5297 -->
  <prerequisites>
    <maven>${maven.version}</maven>
  </prerequisites>

  <scm>
    <connection>scm:svn:https://example.com/repos/svn/ExmapleJava/example-parent/trunk/</connection>
    <developerConnection>scm:svn:https://example.com/repos/svn/ExmapleJava/example-parent/trunk/</developerConnection>
    <url>https://example.com/repos/websvn/browse/ExmapleJava/example-parent/trunk/</url>
  </scm>

  <distributionManagement>
    <repository>
      <id>nexus-example</id>
      <name>Nexus Exmaple Release Repository</name>
      <url>https://example.com/nexus/content/repositories/example-releases</url>
    </repository>
    <snapshotRepository>
      <id>nexus-example</id>
      <name>Nexus Exmaple Snapshot Repository</name>
      <url>https://example.com/nexus/content/repositories/example-snapshots</url>
    </snapshotRepository>
  </distributionManagement>

  <properties>
    <maven.version>3.2</maven.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <surefire.version>2.19</surefire.version>
    <javadoc.version>2.10.3</javadoc.version>
  </properties>

  <build>
    <pluginManagement>
      <plugins>
        <plugin>
          <artifactId>maven-compiler-plugin</artifactId>
          <version>3.3</version>
        </plugin>
        <plugin>
          <artifactId>maven-source-plugin</artifactId>
          <version>2.4</version>
          <configuration>
            <excludeResources>true</excludeResources>
          </configuration>
        </plugin>
        <plugin>
          <artifactId>maven-jar-plugin</artifactId>
          <version>2.6</version>
        </plugin>
        <plugin>
          <artifactId>maven-assembly-plugin</artifactId>
          <version>2.6</version>
        </plugin>
        <plugin>
          <artifactId>maven-release-plugin</artifactId>
          <version>2.5.3</version>
          <configuration>
            <mavenExecutorId>forked-path</mavenExecutorId>
            <autoVersionSubmodules>true</autoVersionSubmodules>
            <useReleaseProfile>false</useReleaseProfile>
            <tagNameFormat>@{project.version}</tagNameFormat>
          </configuration>
        </plugin>
        <plugin>
          <artifactId>maven-deploy-plugin</artifactId>
          <version>2.8.2</version>
        </plugin>
        <plugin>
          <artifactId>maven-help-plugin</artifactId>
          <version>2.2</version>
        </plugin>
        <plugin>
          <artifactId>maven-javadoc-plugin</artifactId>
          <version>${javadoc.version}</version>
          <configuration>
            <quiet>true</quiet>
          </configuration>
        </plugin>
        <plugin>
          <artifactId>maven-resources-plugin</artifactId>
          <version>2.7</version>
        </plugin>
        <plugin>
          <artifactId>maven-surefire-plugin</artifactId>
          <version>${surefire.version}</version>
        </plugin>
        <plugin>
          <artifactId>maven-war-plugin</artifactId>
          <version>2.6</version>
        </plugin>
        <plugin>
          <artifactId>maven-install-plugin</artifactId>
          <version>2.5.2</version>
        </plugin>
        <plugin>
          <artifactId>maven-dependency-plugin</artifactId>
          <version>2.10</version>
        </plugin>
        <plugin>
          <artifactId>maven-clean-plugin</artifactId>
          <version>2.6.1</version>
        </plugin>
        <plugin>
          <artifactId>maven-site-plugin</artifactId>
          <version>3.4</version>
        </plugin>
        <plugin>
          <groupId>org.codehaus.mojo</groupId>
          <artifactId>buildnumber-maven-plugin</artifactId>
          <version>1.4</version>
          <configuration>
            <buildNumberPropertyName>buildRevision</buildNumberPropertyName>
            <timestampPropertyName>buildTimestamp</timestampPropertyName>
            <scmBranchPropertyName>buildScmBranch</scmBranchPropertyName>
            <revisionOnScmFailure>non-SCM</revisionOnScmFailure>
          </configuration>
        </plugin>
        <plugin>
          <groupId>org.codehaus.mojo</groupId>
          <artifactId>versions-maven-plugin</artifactId>
          <version>2.2</version>
          <configuration>
            <generateBackupPoms>false</generateBackupPoms>
          </configuration>
        </plugin>
        <plugin>
          <groupId>org.codehaus.mojo</groupId>
          <artifactId>appassembler-maven-plugin</artifactId>
          <version>1.10</version>
          <configuration>
            <includeConfigurationDirectoryInClasspath>false</includeConfigurationDirectoryInClasspath>
          </configuration>
        </plugin>
        <plugin>
          <groupId>org.codehaus.mojo</groupId>
          <artifactId>build-helper-maven-plugin</artifactId>
          <version>1.9.1</version>
        </plugin>
        <plugin>
          <artifactId>maven-enforcer-plugin</artifactId>
          <version>1.4.1</version>
        </plugin>
        <plugin>
          <artifactId>maven-antrun-plugin</artifactId>
          <version>1.8</version>
        </plugin>
      </plugins>
    </pluginManagement>
    <plugins>
      <plugin>
        <artifactId>maven-enforcer-plugin</artifactId>
        <executions>
          <execution>
            <id>enforce-maven</id>
            <goals>
              <goal>enforce</goal>
            </goals>
            <configuration>
              <rules>
                <requireMavenVersion>
                  <version>${maven.version}</version>
                  <message>This project requires at least Maven ${maven.version}</message>
                </requireMavenVersion>
              </rules>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

  <profiles>
    <profile>
      <id>example-release</id>
      <build>
        <plugins>
          <plugin>
            <artifactId>maven-source-plugin</artifactId>
            <executions>
              <execution>
                <id>attach-sources</id>
                <goals>
                  <goal>jar-no-fork</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <artifactId>maven-javadoc-plugin</artifactId>
            <executions>
              <execution>
                <id>attach-javadocs</id>
                <goals>
                  <goal>jar</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
    </profile>
  </profiles>
</project>

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

Нет информации о развертывании сайта, потому что мы его не используем. Установите его, если вы его используете.

В нет время ваш POM должен содержать <repositories> и <pluginRepositories>, потому что это плохая практика. В идеале ваша работа с группой репо в Nexus должна отражать (в settings.xml) все ваши запросы.

Наследуй и будь счастлив.

Как работать с сайтами: Как правило, каждый проект имеет свой сайт и должен быть переопределен в разделе dist mngt. Это отличается от артефактов. Будете ли вы размещать на Nexus или на веб-сервере, таком как Apache, зависит от вас. Суть в том, что каждому сайту проекта нужен свой отдельный URL.

person Michael-O    schedule 04.11.2015
comment
Спасибо за подробный ответ, это уже помогает! Но есть еще один момент, с которым я не могу работать, используя этот подход. Если теперь у меня есть фактический дочерний проект, наследующий от этого pom, он будет выпущен в репозиторий example-releases. Как мне справиться с тем фактом, что разные проекты должны иметь свои собственные репозитории? (books.sonatype.com/nexus-book/reference/best.html - репозитории для каждого проекта/команды) Или вы бы предложили общие репозитории Partition? И какой смысл включать <distributionMgmt>, но не <repositories>? Тогда это тоже не плохо? - person JDC; 04.11.2015
comment
@user1342006 user1342006 У нас также есть этот вариант использования, и мы выбрали лучшее репозиторий для каждого проекта / команды для каждого производственного сайта. Что вы в конечном итоге сделаете, так это оставите корпоративный POM как есть и переопределите информацию об управлении распространением в вашем Project POM. Вы сделали. Вы всегда можете проверить свой POM с помощью mvn help:effective-pom. Это дает вам интерполированный POM, как его увидит Maven. Имейте в виду, что если вы используете Nexus, у вас есть централизованное управление пользователями, то есть вы можете всегда сохранять идентификатор сервера одним и тем же и ссылаться на него в своем settings.xml. - person Michael-O; 04.11.2015
comment
Невыполнение этого требования в конечном итоге будет означать дублирование учетных данных, что действительно раздражает. См. MNG-5913. - person Michael-O; 04.11.2015
comment
Хорошо, я думаю, что я в основном понимаю, спасибо! Но все же, если я представлю, что, например. 50 различных проектов (просто для преувеличения), которые переопределяют раздел «<distributionManagement›» и изменяют URL-адрес нексуса, это был бы самый худший сценарий. Будет ли идея указать базовый URL-адрес в корпоративном pom, за которым следует свойство (например, ${project.uid}), которое затем устанавливается внутри дочерних pom? Будет ли это работать и иметь смысл? - person JDC; 04.11.2015
comment
Что касается изменяющегося URL-адреса нексуса: или тогда это будет проблема с ИТ, и мы должны просто использовать псевдоним URL-адреса, чтобы быть уверенным...? - person JDC; 04.11.2015
comment
Если вы планируете использовать ровно одно репо для одного проекта, это будет беспорядок (ИМХО). Я бы логически сгруппировал проекты в одно репо и работал с целевыми разрешениями в Nexus, если они вам нужны. Ваш подход ${project.uid} имеет смысл и действительно сработает. Хотя, я никогда не пробовал этот подход. В конце концов, вы должны оценить оба варианта с вашими разработчиками и администраторами и использовать подход с наименьшим объемом работы. В конечном счете, несколько больших репозиториев могут быть лучшим решением, а ваш администратор Nexus сделает все остальное. - person Michael-O; 04.11.2015
comment
Псевдонимы URL-адресов с веб-сервером Apache будут означать либо работу с перенаправлениями (отнимающими много времени), либо псевдонимами реального местоположения, но это все равно будет дополнительной работой администратора. - person Michael-O; 04.11.2015
comment
Вы можете обновить свой вопрос, поделившись своим предпочтительным решением, и я или другие люди могут поделиться своими мыслями. - person Michael-O; 04.11.2015
comment
кто-то на самом деле использует только one корпоративный pom? у нас есть структура наследования множества pom, может быть, около 17, если учесть все pom-зависимости... каждый для разных вариантов использования. - person eis; 04.11.2015
comment
@eis Я думаю, ты прав, и на самом деле это один из следующих шагов, которые я хотел оценить. Но прежде всего мне нужна была самая базовая структура pom/nexus, чтобы начать. Следующие шаги, конечно, будут включать в себя поиск общих черт и предоставление разных родительских pom для разных вариантов использования (например, jee-application, desktop-application и т. д.), в то время как они снова наследуются от базового pom. - person JDC; 04.11.2015
comment
@user1342006 user1342006 Если вы считаете, что мой ответ был полезен, подумайте о том, чтобы проголосовать за него или принять его. - person Michael-O; 04.11.2015