простой способ развертывания сторонних зависимостей в репозиторий maven - PullRequest
5 голосов
/ 20 октября 2011

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

Я хотел бы использовать среду Spring & Hibernate для наших приложений и использовать maven для разрешения зависимостей и построения проекта..

Я установил нексус-репозиторий "Сторонний" на локальном сервере, теперь пришло время фактически добавлять библиотеки.Hibernate 3.6.7.Final поставляется со следующими банками:

./hibernate-testing.jar
./hibernate3.jar
./lib/required/commons-collections-3.1.jar
./lib/required/dom4j-1.6.1.jar
./lib/required/jta-1.1.jar
./lib/required/slf4j-api-1.6.1.jar
./lib/required/antlr-2.7.6.jar
./lib/required/javassist-3.12.0.GA.jar
./lib/jpa/hibernate-jpa-2.0-api-1.0.1.Final.jar
./lib/optional/c3p0/c3p0-0.9.1.jar
./lib/optional/swarmcache/swarmcache-1.0RC2.jar
./lib/optional/proxool/proxool-0.8.3.jar
./lib/optional/jbosscache/jbosscache-core-3.2.1.GA.jar
./lib/optional/oscache/oscache-2.1.jar
./lib/optional/infinispan/infinispan-core-4.2.1.CR1.jar
./lib/bytecode/javassist/javassist-3.12.0.GA.jar
./lib/bytecode/cglib/cglib-2.2.jar

Spring 3.0.6.RELEASE поставляется со следующим:

org.springframework.aop-3.0.6.RELEASE.jar                
org.springframework.jdbc-3.0.6.RELEASE.jar
org.springframework.asm-3.0.6.RELEASE.jar                
org.springframework.jms-3.0.6.RELEASE.jar
org.springframework.aspects-3.0.6.RELEASE.jar            
org.springframework.orm-3.0.6.RELEASE.jar
org.springframework.beans-3.0.6.RELEASE.jar              
org.springframework.oxm-3.0.6.RELEASE.jar
org.springframework.context-3.0.6.RELEASE.jar            
org.springframework.test-3.0.6.RELEASE.jar
org.springframework.context.support-3.0.6.RELEASE.jar    
org.springframework.transaction-3.0.6.RELEASE.jar
org.springframework.core-3.0.6.RELEASE.jar               
org.springframework.web-3.0.6.RELEASE.jar
org.springframework.expression-3.0.6.RELEASE.jar         
org.springframework.web.portlet-3.0.6.RELEASE.jar
org.springframework.instrument-3.0.6.RELEASE.jar         
org.springframework.web.servlet-3.0.6.RELEASE.jar
org.springframework.instrument.tomcat-3.0.6.RELEASE.jar  
org.springframework.web.struts-3.0.6.RELEASE.jar

Я понимаю, что 2 предпочтительных метода развертыванияЗависимости

1) настроить пом;используйте команду "mvn deploy"

2) используйте командную строку, например, для отдельных jar-файлов:

 mvn deploy:deploy-file -Durl=file://C:\m2-repo \

                   -DrepositoryId=some.id \

                   -Dfile=your-artifact-1.0.jar \

                   [-DpomFile=your-pom.xml] \

                   [-DgroupId=org.some.group] \

                   [-DartifactId=your-artifact] \

                   [-Dversion=1.0] \

                   [-Dpackaging=jar] \

                   [-Dclassifier=test] \

                   [-DgeneratePom=true] \

                   [-DgeneratePom.description="My Project Description"] \

                   [-DrepositoryLayout=legacy] \

                   [-DuniqueVersion=false]

Для 1) я понимаю, что могу создать один pom для всего спящего режимапроект или создать несколько poms, я думаю, 1 для каждой внешней библиотеки.Например, cglib-2.2.jar может быть своим собственным pom, потому что я знаю, что у Spring аналогичная зависимость, поэтому из-за отсутствия (2) x cglib (s) у меня будет 1 cglib, а затем я включу его какзависимость в моих pom org.spring и org.hibernate соответственно.

Для 2) Я думаю, я мог бы написать сценарий оболочки, чтобы прочитать список файлов и проанализировать информацию GAV из, возможно, другого списка и вывести ихчтобы сделать репо 1 на 1, тогда каждая банка будет указана как зависимость в POM моего проекта.

Эта последняя часть вызывает у меня некоторое замешательство ... Если я разверну весь выпуск Spring как 1 группу - org.Spring иHibernate в другой организации. Hibernate, могут ли быть конфликты между зависимостями (например, cglib)?

Итак, я думаю, мой вопрос:

Какой самый простой, быстрый и требующий минимальных усилий способразвернуть загруженные версии Spring и Hibernate в моем локальном репозитории nexus, чтобы я мог быстро использовать их в своем проекте?(Не нужно перечислять слишком много зависимостей в слишком большом количестве poms.)


Редактировать:

Небольшое разъяснение того, что я хочу.У меня 1 менеджер Nexus работает на локальном сервере (с доступом к интернету).Я хочу иметь возможность загружать из интернет-хранилищ всех зависимостей, которые мне нужны для запуска Spring & Hibernate.Я хочу сделать это ТОЛЬКО ОДИН РАЗ , затем пусть они сидят в моем ВНУТРЕННЕМ Хранилище (Nexus), о котором я хочу НИКОГДА поговорить с центральным, jboss,пружина или любой другой ОБЩЕСТВЕННЫЙ ХРАНИТЕЛЬ, пока я ОСОБЕННО не разрешу.Я хочу иметь возможность включать и выключать это как переключатель.

ON mode = " вы можете получить зависимости от публичных репозиториев"

OFF mode = "вы не должны подключаться к чему-либо внешнему"

Мне кажется, что это можно сделать, выполнив следующие действия:

в Nexus

1) Создать группу

2) Установите прокси для каждого необходимого вам внешнего репозитория

3) Поместите все ваши прокси в 1 группу

на рабочей станции разработчика (это часть I ')я не уверен насчет)

1) отредактируйте файл settings.xml, чтобы переопределить центральное расположение и указать хранилище для локальной группы Nexus, как описано здесь:

зеркала хранилища maven

и здесь

Отключить центральный репозиторий Maven

и здесь

http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html

2) запустить mvn install иликомпилировать или что-то еще, чтобы захватить зависимости.

После этого я не совсем уверен, как это будет работать.Каким-то образом попросите maven отразить внешнюю группу в одном из моих локальных репозиториев Nexus?Я думаю, что я попробую это, вернусь и опубликую свое решение в случае успеха.В то же время, не стесняйтесь комментировать или советовать.

Ответы [ 4 ]

4 голосов
/ 20 октября 2011

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

JFrog Artifactory имеет аналогичную функцию (может определять шаблоны include / exclude бесплатно).

1 голос
/ 20 октября 2011

Не уверен, поможет ли это, но мы уже давно используем maven-proxy из Codehaus.Я бы посоветовал запустить прокси, настроить файл settings.xml (см. Ниже) и выполнить mvn eclipse:evlipse, чтобы загрузить все зависимости через кеш.Вы также можете заполнить кеш вручную.После этого вы можете настроить кэш, чтобы он обслуживал нужные вам пакеты и ничего больше.

Если вы получаете пакеты, которые вам не нужны, вам нужно добавить исключения для них в свои файлы pom.xml.:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring</artifactId>
    <version>2.0.6</version>
    <exclusions>
        <exclusion>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
        </exclusion>
        <exclusion>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Прокси - это Java-приложение, которое работает на одном из наших блоков разработки.В нашем файле settings.xml у нас есть что-то вроде следующего:

<settings>
 <mirrors>
    <mirror>
      <id>maven-proxy</id>
      <name>Maven-Proxy Mirror</name>
      <url>http://mvnproxy.some-host-name.com:9999/repository</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
    <mirror>
      <id>maven-proxy</id>
      <name>Maven-Proxy Mirror</name>
      <url>http://mvnproxy.some-host-name.com:9999/repository</url>
      <mirrorOf>plugins</mirrorOf>
    </mirror>
  </mirrors>
  ...

Вот наш стартовый скрипт, который, я не думаю, идет с выпуском:

#!/bin/sh
umask 022
cd /var/www/maven-proxy
java -jar maven-proxy-standalone-0.2-app.jar maven-proxy.prop >| maven-proxy.log 2>&1 &
echo $! > mp.pid
0 голосов
/ 24 октября 2011

Разобрался.

Вот как это работает.Я начну с настройки Nexus.

У нас есть 2 "группы" со следующими репозиториями:

1) Наш репо (установка Nexus на наш сервер)

-3-я сторона

-Релизы

-Снапшоты

2) Внешние прокси

-Мева центральная

-Пружина

-Hibernate

-etc.

На рабочей станции dev в файле conf / settings.xml (основной файл настроек для mvn) есть следующее: 2 группы, 2 зеркала, 2профили.Выглядит так:

<mirrors>
<mirror>
  <!--This sends everything else to nexus repo -->
  <id>nexus</id>
  <mirrorOf>*</mirrorOf>
  <url>http://<ip>:8081/nexus/content/groups/nexus</url>
</mirror>
 <mirror>
  <!--This sends everything else to /public -->
  <id>external</id>
  <mirrorOf>*</mirrorOf>
  <url>http://<ip>:8081/nexus/content/groups/external</url>
</mirror>
</mirrors>

И:

 <profiles>
  <profile>
  <id>external</id>
  <!--Enable snapshots for the built in central repo to direct -->
  <!--all requests to nexus via the mirror -->
  <repositories>
    <repository>
      <id>central</id>
      <url>http://central</url>
      <releases><enabled>true</enabled></releases>
      <snapshots><enabled>true</enabled></snapshots>
    </repository>
  </repositories>
 <pluginRepositories>
    <pluginRepository>
      <id>central</id>
      <url>http://central</url>
      <releases><enabled>true</enabled></releases>
      <snapshots><enabled>true</enabled></snapshots>
    </pluginRepository>
  </pluginRepositories>
</profile>

<profile>
  <id>nexus</id>
  <!--Enable snapshots for the built in central repo to direct -->
  <!--all requests to nexus via the mirror -->
  <repositories>
    <repository>
      <id>central</id>
      <url>http://central</url>
      <releases><enabled>true</enabled></releases>
      <snapshots><enabled>true</enabled></snapshots>
    </repository>
  </repositories>
 <pluginRepositories>
    <pluginRepository>
      <id>central</id>
      <url>http://central</url>
      <releases><enabled>true</enabled></releases>
      <snapshots><enabled>true</enabled></snapshots>
    </pluginRepository>
  </pluginRepositories>
</profile>
</profiles>

И:

<activeProfiles>
<activeProfile>external</activeProfile>   
<activeProfile>nexus</activeProfile>
</activeProfiles>

Рабочий процесс выглядит следующим образом.

Maven использует зеркалав порядке поступления.То есть, если вы зеркально отображаете *, то, что вы перечисляете первым (первое зеркало), - это единственное, что проверяется.Поэтому я перечисляю Nexus (локальный сервер) в качестве первого репо по умолчанию для зеркала *.Таким образом, он будет вынужден использовать только пакеты в локальных репозиториях.Что произойдет, если пакет отсутствует?Я говорю maven, чтобы использовать «внешнее» зеркало.Я редактирую

conf / settings.xml

и ставлю внешний как первое зеркало.Это скажет maven получить пакеты из внешних репозиториев и кэшировать их в хранилище на машине nexus.Как только у меня есть пакеты, и я вижу, что процесс сборки работает, я делаю следующее.

1) Отключаем nexus.

2) при установке nexus найдите эту папку:

sonatype-work / nexus / storage /

Здесь nexus кэширует пакеты для репозиториев.Обратите внимание, что он не кэширует их по группам, а по отдельным репозиториям.Это будет важно через секунду.Теперь, когда у меня есть нужные мне пакеты от внешних прокси-серверов, мне нужно просмотреть их, убедиться, что все они действительны, и переместить их в мою ветку "Сторонние поставщики" на Nexus.Я делаю следующее (вы можете написать скрипт оболочки для этого):

1) Перевести нексус в автономный режим

2) для каждого внешнего прокси

cp * из sonatype-работа / связь / хранение / от типа соната работа / связь / хранение / третья сторона

3) Вывести нексус онлайн

4) В GUI щелкните правой кнопкой мыши по третьей стороне репо и сделайте:

a) Восстановить метаданные

b) Восстановить индекс

Готово.

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


Редактировать :

Одна вещь дляОбратите внимание на тему плагинов, я изменил свой файл conf / settings.xml, чтобы позволить maven получать плагины из центрального офиса.В обоих профилях выполните:

<pluginRepositories>
<pluginRepository>
  <id>central</id>
  <url>http://repo1.maven.org/maven2/</url>
  <releases><enabled>true</enabled></releases>
  <snapshots><enabled>true</enabled></snapshots>
</pluginRepository>
</pluginRepositories>

Это не совсем оптимально на 100%, так как я не имею полного контроля над тем, что здесь делает Maven, но кажется, что 90% Maven зависит от управлениясложные отношения зависимости плагинов, поэтому я решил, что позволю ему самостоятельно управлять этим аспектом.

Если у кого-нибудь есть совет, как лучше упростить этот процесс, я весь слух.

0 голосов
/ 20 октября 2011

Я бы повторно использовал существующие pom для этих проектов, чтобы эффективно создать зеркало публичных репозиториев.

...