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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

<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.

Answer 2

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

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

Пример, который я мог сделать, описан здесь

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

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

Answer 3

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

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

Точно. Настройте сервер репозитория maven с несколькими репозиториями, например, это:

• internal-releases
• internal-snapshots
• external-opensource
• external-closedsource (вот где идет речь о том, о чем мы говорим)

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

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

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

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

---

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

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

http://maven -svn-wagon.googlecode.com / СВН / сайт / index.html

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

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