Maven: хранение зависимых фляг в контроле версий проекта - PullRequest
12 голосов
/ 14 марта 2011

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

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

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

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

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

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

Ответы [ 5 ]

5 голосов
/ 14 марта 2011

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

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

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

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

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

2 голосов
/ 14 марта 2011

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

<?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"
2 голосов
/ 14 марта 2011

В моей компании мы используем 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 и управлять версиями, не запоминая все таинственные опции -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://git@gitorious.mycompany.com/myproject/myproject.git</developerConnection>
    <url>http://gitorious.mycompany.com/myproject/myproject</url>
</scm>

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

2 голосов
/ 14 марта 2011

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...