Maven: сохранение зависимых банок в контроле версий проекта

Итак, у меня есть военный проект с несколькими зависимыми баночками, которые недоступны ни в одном репозитории. До недавнего времени я держал их в src/main/webapp/WEB-INF/lib и добавлял их в pom с системной областью.

Я понимаю, что это проблематично, поэтому я ищу, чтобы очистить мою сборку. Я полу-вручную установил банки в мой .m2/repository через плагин install:install-file. Это здорово для меня, но как насчет других людей в моей команде? Мы крошечные, и настройка Nexus на самом деле не вариант для нас. Я прибегал к добавлению комментариев к pom.xml, объясняющим, как запускать install:install-file для каждой банки.

Я в порядке с решением install:install-file, но мне все же хотелось бы включить эти артефакты в мой контроль над версиями проекта, а не просто использовать их в моей файловой системе.

Сохранение их в src/main/webapp/WEB-INF/lib не работает, так как это автоматически добавляет их в результирующий военный артефакт (отступление: если maven просто перейдет и добавит их в путь к классам, здесь я буду сделан, нет необходимости устанавливать: установка файл)

Вопрос: есть ли санкционированное место в макете каталога maven, где я могу привязать эти файлы .jar, чтобы я мог сохранить их как часть моего проекта?

Я понимаю, что происходит здесь: Maven пытается сохранить зависимые баночки за пределами моей сборки, так что, когда другие проекты зависят от моей сборки, они могут разрешать транзитивные зависимости. Это отлично подходит для проектов с открытым исходным кодом, которые идут в общественные репозитории maven, но я бы сказал, что подавляющее большинство людей, использующих Maven, работают над такими "листовыми" проектами, как это, и было бы очень удобно иметь способ включить файлы jar как часть проекта, не пробираясь так много обручей.

Ответ 1

Если настроить Nexus или просто простое резервное копирование файлового сервера, как было предложено Ян, это слишком много проблем, вот некоторые другие варианты:

Просто включите JAR и script, которые установят их все в каталоге по вашему выбору в управлении версиями. Нет необходимости в структуре Maven для ее разрешения.
Используйте свою систему управления версиями в качестве хоста для хранилища, либо на отдельной ветке в основном проекте, либо в виде отдельного проекта. Пусть любая резервная копия, безопасность и т.д., Которые вы уже используете в управлении версиями, относятся к репозиторию, не включая банки в набор файлов, которые на самом деле проверяются и совершаются.
Включить баннеры в папку, которая действует как мини-репозиторий, который выгружается с остальной частью кода. Попросите pom.xml указать эту папку в качестве репозитория, который он использует. Я не уверен на 100%, что это возможно, но похоже, что это так.

Ответ 2

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

Однако, чтобы прямо ответить на ваш вопрос, вот шаблон для хранения зависимостей в управлении версиями с помощью Maven: http://brettporter.wordpress.com/2009/06/10/a-maven-friendly-pattern-for-storing-dependencies-in-version-control/

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

Ответ 3

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

Отметьте Maven DOC о том, как настроить внутренний репозиторий.

Ответ 4

В моей компании мы используем Archiva, это, безусловно, самый простой менеджер репозитория, который настраивается и обслуживается. Особенно, если вы идете с автономной версией. Каждый разработчик просто устанавливает profile в своем файле ~/.m2/settings.xml, чтобы указать на внутренний репозиторий. Если это слишком много, просто поместите внутренний репозиторий в <repositories/> в pom.xml напрямую, но это действительно плохая практика. Если URL-адрес репозитория когда-либо перемещается, вам необходимо обновить все ваши проекты pom.xml. Где, как использование settings.xml, ложится на разработчика, чтобы обновить их локальную конфигурацию.

<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
    <profiles>
        <profile>
            <id>internal</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <repositories>
                <repository>
                    <id>mycompany.internal</id>
                    <name>Internal Release Repository</name>
                    <url>http://maven.mycompany.com/repository/internal/</url>
                    <releases>
                        <enabled>true</enabled>
                    </releases>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                </repository>
                <repository>
                    <id>mycompany.snapshots</id>
                    <name>Internal Snapshot Repository</name>
                    <url>http://maven.mycompany.com/repository/snapshots/</url>
                    <releases>
                        <enabled>false</enabled>
                    </releases>
                    <snapshots>
                        <enabled>true</enabled>
                    </snapshots>
                </repository>
            </repositories>
        </profile>
    </profiles>


    <servers>
        <server>
            <id>internal</id>
            <username>guest</username>
        </server>
        <server>
            <id>snapshots</id>
            <username>guest</username>
        </server>
    </servers>

</settings>

Если настроить диспетчер хранилища слишком много, я думаю, вам нужно пересмотреть альтернативу ручного добавления материала в свой локальный репозиторий вручную, что очень подвержено ошибкам и требует много времени. Я запускаю экземпляр Archiva для моего личного развития только потому, что так легко добавлять release подключаемые версии и управлять версиями, не забудьте запомнить все параметры arcane -D, необходимые для добавления материала в локальный репозиторий на каждом компьютере. Копирование файла ~/.m2/settings.xml очень простое, и если оно работает на одной машине, оно работает на всех них.

Вот что вы добавили в свой pom.xml, чтобы включить автоматическое выполнение релизов и нажатие артефактов в репозиторий, в моем случае это Archiva.

<distributionManagement>
   <repository>
       <id>internal</id>
       <name>Internal Archiva Repository</name>
       <url>http://maven.mycompany.com/repository/internal/</url>
       <layout>default</layout>
       <uniqueVersion>false</uniqueVersion>
   </repository>
   <snapshotRepository>
       <id>snapshots</id>
       <name>Internal Archiva Repository</name>
       <url>http://maven.mycompany.com/repository/snapshots/</url>
       <layout>default</layout>
       <uniqueVersion>false</uniqueVersion>
   </snapshotRepository>
</distributionManagement>

Затем все, что вы делаете, это mvn clean release:prepare, чтобы автоматически обновить pom.xml версию проверить, тег и необязательно ветвь выпуск и упакуйте все артефакты, а затем mvn release:perform, чтобы подтолкнуть артефакты к удаленному репозиторию и проверить обновленную версию pom.xml, и вы готовы к следующей версии, чтобы начать разработку.

Снимки добрались до snaphots и выпуски автоматически перейдут в internal с помощью подключаемого модуля. Вам также нужно настроить плагин scm, но это всего лишь несколько строк конфигурации, которые вам нужно только коснуться один раз.

Это то, что похоже на git, мы используем Gitorious как наш git Менеджер репозитория

<scm>
    <connection>scm:git:git://gitorious.mycompany.com:myproject/myproject.git</connection>
    <developerConnection>scm:git:ssh://[email protected]/myproject/myproject.git</developerConnection>
    <url>http://gitorious.mycompany.com/myproject/myproject</url>
</scm>

Старый настольный компьютер под управлением Linux может обрабатывать обязанности репозитория, подобные этому для команды разработчиков, без привлечения закупок и ИТ.

Ответ 5

Я не использовал это в реальной жизни, но, похоже, он работает: просто придерживайтесь макета репозитория внутри исходного дерева (используя install: install-file, я полагаю) и проверяю его. Используйте запись для указания к этому репо. pom нравится так:

<?xml version="1.0" encoding="utf-8"?>
<project>
  <modelVersion>4.0.0</modelVersion>
  <name>Depending project</name>

  <groupId>com.example</groupId>
  <artifactId>dependent</artifactId>
  <version>0.9</version>
  <packaging>jar</packaging>

  <dependencies>
    <dependency>
      <groupId>com.example</groupId>
      <artifactId>dependency</artifactId>
      <version>0.9.3</version>
      <type>jar</type>
    </dependency>
  </dependencies>

  <repositories>

    <repository>
      <id>project-specific-deps</id>
      <name>project-specific-deps</name>
      <url>file:///${basedir}/repo</url>
    </repository>

  </repositories>

</project>

Пример дерева:

.
|-- pom.xml
|-- repo
|   `-- com
|       `-- example
|           `--dependency
|               |-- 0.9.3
|               |   |-- dependency-0.9.3.jar
|               |   |-- dependency-0.9.3.jar.md5
|               |   |-- dependency-0.9.3.jar.sha1
|               |   |-- dependency-0.9.3.pom
|               |   |-- dependency-0.9.3.pom.md5
|               |   `-- dependency-0.9.3.pom.sha1
|               |-- maven-metadata.xml
|               |-- maven-metadata.xml.md5
|               `-- maven-metadata.xml.sha1
|-- src
|   `-- main
|       `-- java
|           `-- com
|               `-- example
|                   `-- dependent
|                       `-- Foobar.java

Как это звучит?

Для полноты:

$ mvn -version
Apache Maven 2.2.1 (rdebian-4)
Java version: 1.6.0_20
Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre
Default locale: sv_SE, platform encoding: ISO-8859-1
OS name: "linux" version: "2.6.32-3-686" arch: "i386" Family: "unix"