Использование зависимостей с закрытым исходным кодом с Maven

У меня есть проект с закрытым исходным кодом, который я хотел бы построить с помощью Maven. Он имеет зависимость от двух java-библиотек, которые недоступны в любом публичном репозитории, который я смог найти (libGoogleAnalytics.jar и FlurryAgent.jar в этом случае, но вопрос относится к любой зависимой от закрытого источника).

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


Как управлять зависимостями с закрытым исходным кодом, которые maven не знает, как разрешить?

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

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

Все эти проблемы исчезнут для меня, если я смогу каким-то образом использовать наш существующий scm (hg в этом случае, но это может быть git или svn или что-то еще) для хранения зависимостей. Наш исходный репозиторий управления резервным копированием уже создан, он будет в основном всегда доступен разработчикам, выполняющим сборки, и его разрешения уже разрешены.

Но мне еще не удалось выяснить, как управлять зависимостями maven с помощью hg, если это возможно.

Ответы

Ответ 1

Получается, что ответ Манфреда не совсем сработал у меня. Приложение скомпилировано, но оно не запускалось на моем устройстве Android, потому что отсутствовали необходимые классы аналитики Google.

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

В заключение я добавил следующие значения в мой pom.xml. Параметры groupId, artifactId и версия были составлены мной с использованием разумных значений:

<dependencies>
    ...
    <dependency>
        <groupId>com.google.android.apps.analytics</groupId>
        <artifactId>libGoogleAnalytics</artifactId>
        <version>1.1</version>
    </dependency>
    <dependency>
        <groupId>com.flurry</groupId>
        <artifactId>FlurryAgent</artifactId>
        <version>1.24</version>
    </dependency>
</dependencies>

Затем я добавил определение репозитория для того, где я храню зависимости третьей стороны в дереве исходных текстов проекта:

    <repository>
        <id>third.party.closed.source.repo</id>
        <url>file://${basedir}/../maven_repo_3rd_party</url>
    </repository>

Затем я переместил файлы jar в следующее расположение:

./maven_repo_3rd_party/com/google/android/apps/analytics/libGoogleAnalytics/1.1/libGoogleAnalytics-1.1.jar
./maven_repo_3rd_party/com/flurry/FlurryAgent/1.24/FlurryAgent-1.24.jar

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

Ответ 2

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

Поместите файл jar в папку libs так же, как в прошлые дни (помните Ant.. ouch).., а затем объявите зависимость каждой банке с помощью системы области и пути.

В качестве примера можно привести это для описанного здесь

http://www.simpligility.com/2010/01/how-to-mavenize-a-typical-web-application-build-jasperserver-3-7-sample-webapp/

В частности, зависимость будет, например, выглядите так

<dependency>
  <groupId>jasperreports</groupId>
  <artifactId>jasperreports-chart-themes</artifactId>
  <version>3.7.0</version>
  <scope>system</scope>
  <systemPath>${project.basedir}/src/main/webapp/WEB-INF/lib/jasperreports-chart-themes-3.7.0.jar</systemPath>
</dependency

О, и теперь, когда я сказал вам, как это сделать, имейте в виду, что это ПЛОХАЯ практика и есть куча проблем, но она будет работать...

Ответ 3

Использовать выделенный сервер репозитория

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

Совершенно верно. Настройте сервер хранилища maven с несколькими репозиториями, например. это:

  • internal-releases
  • internal-snapshots
  • external-opensource
  • external-closedsource (здесь мы говорим о lib)

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

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

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

Стандартные серверы репозитория (например, Sonatype Nexus) являются прочными. Если он когда-либо зависает, просто перезапустите контейнер приложения/сервлета, на котором он запущен. Кроме того, после того, как разработчики загрузили библиотеку из репо, она останется в локальном репо, поэтому даже если репо не работает, не должно быть проблем (но вы не можете ссылаться на новую зависимость, когда сервер не работает).

Использовать существующий SCM в качестве хранилища maven

ОК, если вы действительно хотите использовать свой SCM как репозиторий maven, вот как это сделать:

http://maven-svn-wagon.googlecode.com/svn/site/index.html

В этой статье описывается, как настроить репозиторий maven на основе SVN для вашего собственного проекта. Но если вы хотите развернуть стороннее репо, просто создайте pom с указанным здесь конфигом и используйте этот pom для deploy: deploy-file ваша библиотека.

(Существуют и другие реализации wagon/scm, и конфигурация немного отличается, но решение остается тем же: создайте pom в соответствии с используемой вами реализацией вагона, а затем выполните deploy:deploy-file (см. дополнительную информацию о страница использования)