2016-02-25 1 views
0

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

Утвержденные библиотеки поддерживаются специальной репозиторией (в экземпляре Artifactory).

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

Итак, я сконфигурировал раздел repository в пом и pluginRepository.

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

Я удалил локальный репозиторий и перекомпилировал протестированный проект, а сборка завершилась неудачно, как ожидалось, с неразрешимой зависимостью.

Я искал в Интернете и не нашел конкретного ответа на этот вопрос. Существует ожидающий запрос на мавена отделить локальные кэши для каждого хранилища, но это, кажется, только в обзор для Maven 4 государства: https://cwiki.apache.org/confluence/display/MAVEN/Local+Repository+Separation

https://issues.apache.org/jira/browse/MNG-3655 https://issues.apache.org/jira/browse/MNG-4302

The Maven-силовика-плагин имеет вид концепции здесь с bannedDependencies, но для этого требуется обширная конфигурация, и я хотел бы идти в ногу с одобренными в настоящее время релизами без ручного взаимодействия.

Любые идеи по этому поводу? Я пропустил конфигурацию?

Update1:

Ну даже пытаться перечислить все разрешенные в зависимости Инфорсер плагин не работает для меня:

<dependency> 
     <groupId>commons-io</groupId> 
     <artifactId>commons-io</artifactId> 
     <version>2.2</version> 
    </dependency> 
    ... 
     <plugin> 
      <groupId>org.apache.maven.plugins</groupId> 
      <artifactId>maven-enforcer-plugin</artifactId> 
      <version>1.4.1</version> 
      <executions> 
       <execution> 
        <id>enforce-versions</id> 
        <goals> 
         <goal>enforce</goal> 
        </goals> 
        <configuration> 
         <rules> 
          <bannedDependencies> 
           <excludes> 
            <exclude>*:*</exclude> 
           </excludes> 
           <includes> 
            <include>commons-io:commons-io:1.4</include> 
            ... 
           </includes> 
          </bannedDependencies> 
         </rules> 
         <fail>true</fail> 
        </configuration> 
       </execution> 
      </executions> 
     </plugin> 

Моделировочная должен терпеть неудачу здесь, но [INFO] BUILD SUCCESS.

Update 2:

Что еще более удивительно, что в документации Maven вопрос уже адресован быть зафиксированы изменения в версии 3: https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository

Разрешение от местного Repository The локальный репозиторий, используемый Maven 3.x, был расширен, чтобы отслеживать, с каких удаленных репозиториев был устранен артефакт. Эта информация о происхождении артефакта используется для обеспечения того, чтобы сборщики могли получать доступ к локально кэшированным артефактам, если у них настроены соответствующие репозитории. Следовательно, проекты, которые не имеют требуемых удаленных репозиториев в POM, могут не работать при создании с Maven 3. Это улучшает воспроизводимость сборки, устраняя последствия непреднамеренного совместного использования артефактов через локальный репозиторий.

+0

Я бы проверял artifactory, если у него есть какая-то закупка (термин nexus), который решает эту проблему ... буквально определение этого в сборке maven не имеет смысла, потому что любой, кто может изменить файл pomfile, может изменить это. .., который не имеет смысла в конце ... – khmarbaise

+0

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

+0

Maven, конечно, использует артефакты. К компилятору вы имеете в виду JDK? В противном случае это не имеет смысла, потому что maven-compiler-plugin также нуждается в артефактах, иначе вы не сможете скомпилировать свой код. Из этого можно установить параметры settings.xml с разделенными maven-плагинами и другими артефактами, которые обычно не выполняются. – khmarbaise

ответ

0

Хорошо, я наконец выяснил, что вызвало мою головную боль. Прежде всего, я хочу иметь самостоятельный проект. Никаких специальных настроек user.xml s для запуска (с зеркалами, которые будут блокировать другие проекты от работы, если вам нужно переключиться).

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

<repository> 
    <id>central</id> 
    <url>http://${company-repo-manager}/${project-repository}</url> 
</repository> 
... 
<pluginRepository> 
    <id>central</id> 
    <url>http://${company-repo-manager}/${plugin-repository}</url> 
</pluginRepository> 

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

Теперь я знал, что Maven 3 предполагается ввести своего рода local repo management я имел более близкий взгляд на моем локальном хранилище, и нашел файл с именем _remote.repositories с этим содержимым:

commons-io-2.2.jar>central= 
commons-io-2.2.pom>central= 

Здесь вы можете увидеть, что Maven помнит из хранилища появился артефакт, но он помнит идентификатор репозитория, а не его URL-адрес! Как я сконфигурировал свой репозиторий плагинов и мой репозиторий проектов как с id central maven смешанными кешированными артефактами обоих репозиториев.

Решение, наконец было попытаться отключить центральное хранилище и настроить проект и плагин хранилище с индивидуальным именем:

<repository> 
    <id>${project-repository}</id> 
    <url>http://${company-repo-manager}/${project-repository}</url> 
</repository> 
<repository> 
    <id>central</id> 
    <name>Maven Central</name> 
    <url>http://repo1.maven.org/maven2</url> 
    <releases> 
    <enabled>false</enabled> 
    </releases> 
    <snapshots> 
    <enabled>false</enabled> 
    </snapshots> 
</repository> 
... 
<pluginRepository> 
    <id>maven-plugins-repo</id> 
    <url>http://${company-repo-manager}/${plugin-repository}</url> 
</pluginRepository> 
<pluginRepository> 
    <id>central</id> 
    <name>Maven Central</name> 
    <url>http://repo1.maven.org/maven2</url> 
    <releases> 
    <enabled>false</enabled> 
    </releases> 
    <snapshots> 
    <enabled>false</enabled> 
    </snapshots> 
</pluginRepository> 

К сожалению you can not remove central от разрешения и поэтому различные проекты будут взаимодействовать с местной сборкой, если они используйте репозиторий с именем central.

Maven Enforcer - это плагин, который я все еще буду искать, но это была проблема с базовой конфигурацией, которую я пытался решить.

Если я начинаю с чистого кеша (например, в сборке CI), я получаю именно ту неудачу сборки, которую я ожидаю.

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