Размещение репозитория Maven на github

У меня есть вилка из небольшой библиотеки с открытым исходным кодом, над которой я работаю на github. Я хотел бы сделать его доступным для других разработчиков через maven, но я не хочу запускать свой собственный сервер Nexus, и, поскольку это форк, я не могу легко развернуть его на oss.sonatype.org.

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

9 ответов

Решение

Лучшее решение, которое мне удалось найти, состоит из следующих шагов:

  1. Создать ветку под названием mvn-repo разместить ваши Maven артефакты.
  2. Используйте плагин github site-maven-plugin, чтобы перенести ваши артефакты в github.
  3. Настройте maven для использования вашего пульта mvn-repo в качестве хранилища Maven.

Есть несколько преимуществ использования этого подхода:

  • Maven-артефакты хранятся отдельно от вашего источника в отдельной ветке, которая называется mvn-repo так же, как страницы GitHub хранятся в отдельной ветке под названием gh-pages (если вы используете страницы GitHub)
  • В отличие от некоторых других предлагаемых решений, это не противоречит вашим gh-pages если вы их используете.
  • Естественно связан с целью развертывания, поэтому нет новых команд maven для изучения. Просто используйте mvn deploy как обычно

Типичным способом развертывания артефактов в удаленном репозитории Maven является использование mvn deploy Итак, давайте исправим этот механизм для этого решения.

Сначала скажите maven развернуть артефакты во временной промежуточной папке внутри вашей целевой директории. Добавьте это к вашему pom.xml:

<distributionManagement>
    <repository>
        <id>internal.repo</id>
        <name>Temporary Staging Repository</name>
        <url>file://${project.build.directory}/mvn-repo</url>
    </repository>
</distributionManagement>

<plugins>
    <plugin>
        <artifactId>maven-deploy-plugin</artifactId>
        <version>2.8.1</version>
        <configuration>
            <altDeploymentRepository>internal.repo::default::file://${project.build.directory}/mvn-repo</altDeploymentRepository>
        </configuration>
    </plugin>
</plugins>

Теперь попробуйте запустить mvn clean deploy, Вы увидите, что он развернул ваш репозиторий Maven в target/mvn-repo, Следующий шаг - заставить его загрузить этот каталог в GitHub.

Добавьте вашу аутентификационную информацию в ~/.m2/settings.xml так что гитхаб site-maven-plugin может нажать на GitHub:

<!-- NOTE: MAKE SURE THAT settings.xml IS NOT WORLD READABLE! -->
<settings>
  <servers>
    <server>
      <id>github</id>
      <username>YOUR-USERNAME</username>
      <password>YOUR-PASSWORD</password>
    </server>
  </servers>
</settings>

(Как уже было отмечено, пожалуйста, убедитесь, что chmod 700 settings.xml чтобы никто не мог прочитать ваш пароль в файле. Если кто-то знает, как заставить site-maven-plugin запрашивать пароль, а не запрашивать его в конфигурационном файле, дайте мне знать.)

Тогда скажите GitHub site-maven-plugin о новом сервере, который вы только что настроили, добавив следующее в ваш pom:

<properties>
    <!-- github server corresponds to entry in ~/.m2/settings.xml -->
    <github.global.server>github</github.global.server>
</properties>

Наконец, настройте site-maven-plugin загрузить из вашего временного репо на ваш mvn-repo филиал на Github:

<build>
    <plugins>
        <plugin>
            <groupId>com.github.github</groupId>
            <artifactId>site-maven-plugin</artifactId>
            <version>0.11</version>
            <configuration>
                <message>Maven artifacts for ${project.version}</message>  <!-- git commit message -->
                <noJekyll>true</noJekyll>                                  <!-- disable webpage processing -->
                <outputDirectory>${project.build.directory}/mvn-repo</outputDirectory> <!-- matches distribution management repository url above -->
                <branch>refs/heads/mvn-repo</branch>                       <!-- remote branch name -->
                <includes><include>**/*</include></includes>
                <repositoryName>YOUR-REPOSITORY-NAME</repositoryName>      <!-- github repo name -->
                <repositoryOwner>YOUR-GITHUB-USERNAME</repositoryOwner>    <!-- github username  -->
            </configuration>
            <executions>
              <!-- run site-maven-plugin's 'site' target as part of the build's normal 'deploy' phase -->
              <execution>
                <goals>
                  <goal>site</goal>
                </goals>
                <phase>deploy</phase>
              </execution>
            </executions>
        </plugin>
    </plugins>
</build>

mvn-repo Филиал не должен существовать, он будет создан для вас.

Теперь беги mvn clean deploy снова. Вы должны увидеть, что maven-deploy-plugin "загружает" файлы в локальный промежуточный репозиторий в целевом каталоге, а затем site-maven-plugin фиксирует эти файлы и отправляет их на сервер.

[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building DaoCore 1.3-SNAPSHOT
[INFO] ------------------------------------------------------------------------
...
[INFO] --- maven-deploy-plugin:2.5:deploy (default-deploy) @ greendao ---
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/1.3-SNAPSHOT/greendao-1.3-20121223.182256-3.jar (77 KB at 2936.9 KB/sec)
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/1.3-SNAPSHOT/greendao-1.3-20121223.182256-3.pom (3 KB at 1402.3 KB/sec)
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/1.3-SNAPSHOT/maven-metadata.xml (768 B at 150.0 KB/sec)
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/maven-metadata.xml (282 B at 91.8 KB/sec)
[INFO] 
[INFO] --- site-maven-plugin:0.7:site (default) @ greendao ---
[INFO] Creating 24 blobs
[INFO] Creating tree with 25 blob entries
[INFO] Creating commit with SHA-1: 0b8444e487a8acf9caabe7ec18a4e9cff4964809
[INFO] Updating reference refs/heads/mvn-repo from ab7afb9a228bf33d9e04db39d178f96a7a225593 to 0b8444e487a8acf9caabe7ec18a4e9cff4964809
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8.595s
[INFO] Finished at: Sun Dec 23 11:23:03 MST 2012
[INFO] Final Memory: 9M/81M
[INFO] ------------------------------------------------------------------------

Посетите github.com в своем браузере, выберите mvn-repo филиал, и убедитесь, что все ваши двоичные файлы теперь там.

Поздравляем!

Теперь вы можете развернуть свои артефакты Maven в публичном репо бедного человека, просто запустив mvn clean deploy,

Есть еще один шаг, который вы хотите сделать, это настроить любые poms, которые зависят от вашего pom, чтобы знать, где находится ваш репозиторий. Добавьте следующий фрагмент к pom любого проекта, который зависит от вашего проекта:

<repositories>
    <repository>
        <id>YOUR-PROJECT-NAME-mvn-repo</id>
        <url>https://raw.github.com/YOUR-USERNAME/YOUR-PROJECT-NAME/mvn-repo/</url>
        <snapshots>
            <enabled>true</enabled>
            <updatePolicy>always</updatePolicy>
        </snapshots>
    </repository>
</repositories>

Теперь любой проект, которому требуются ваши jar-файлы, будет автоматически загружать их из вашего репозитория github maven.

Изменить: чтобы избежать проблемы, упомянутой в комментариях ("Ошибка создания коммита: неверный запрос. Для" properties / name "nil не является строкой"), убедитесь, что вы указали имя в своем профиле на github.

Не используйте GitHub в качестве репозитория Maven.

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

Лучший вариант - сотрудничать с оригинальным проектом

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

Альтернатива - поддерживать свой собственный Fork

Так как вы разветвили библиотеку с открытым исходным кодом, и ваш форк также является открытым исходным кодом, вы можете загрузить свой форк в Maven Central (см. Руководство по загрузке артефактов в Центральный репозиторий), дав ему новый groupId и может быть новый artifactId,

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

Действительно подумайте, является ли вилка правильным вариантом. Прочитайте бесчисленные результаты Google, чтобы узнать, почему бы не раскошелиться

аргументация

Раздувание вашего хранилища банками увеличивает размер загрузки без какой-либо выгоды

Баночка это output вашего проекта, он может быть восстановлен в любое время из его inputs, и ваш репозиторий GitHub должен содержать только inputs,

Не веришь мне? Затем проверьте результаты Google на предмет "не хранить бинарные файлы в git".

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

Определение нескольких репозиториев в вашем pom.xml замедляет сборку на количество репозиториев, умноженное на количество артефактов.

Стивен Коннолли говорит:

Если кто-либо добавляет ваше репо, он влияет на производительность его сборки, поскольку теперь у него есть другое репо для проверки артефактов... Это не большая проблема, если вам нужно только добавить одно репо... Но проблема растет, и следующая вещь, которую вы знаете, ваша maven build проверяет 50 репо на каждый артефакт, а время сборки - собака.

Вот так! Maven должен проверять каждый артефакт (и его зависимости), определенные в вашем pom.xml, для каждого определенного вами репозитория, поскольку более новая версия может быть доступна в любом из этих репозиториев.

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

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

Вы можете прочитать больше о репозиториях в документации Maven по введению в репозитории.

Вы можете использовать JitPack, чтобы представить свой репозиторий GitHub как артефакт Maven. Это очень просто. Ваши пользователи должны добавить это в свой pom.xml:

  1. Добавить репозиторий:
<repository>
    <id>jitpack.io</id>
    <url>https://jitpack.io</url>
</repository>
  1. Добавить зависимость:
<dependency>
    <groupId>com.github.User</groupId>
    <artifactId>Repo name</artifactId>
    <version>Release tag</version>
</dependency>

Как уже говорилось в другом месте, идея в том, что JitPack создаст ваш репозиторий GitHub и будет обслуживать банки. Требование - наличие файла сборки и выпуска GitHub.

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

С 2019 года вы можете использовать новую функцию, называемую реестром пакетов Github.

В основном процесс:

  • сгенерируйте новый токен личного доступа из настроек github
  • добавить информацию о репозитории и токене в свой settings.xml
  • развернуть с помощью

    mvn deploy -Dregistry=https://maven.pkg.github.com/yourusername -Dtoken=yor_token  
    

Другой альтернативой является использование любого веб-хостинга с поддержкой webdav. Конечно, вам понадобится место для этого где-то, но его легко настроить, и это хорошая альтернатива использованию полноценного сервера Nexus.

добавьте это в свой раздел сборки

     <extensions>
        <extension>
        <artifactId>wagon-webdav-jackrabbit</artifactId>
        <groupId>org.apache.maven.wagon</groupId>
        <version>2.2</version>
        </extension>
    </extensions>

Добавьте что-то подобное в ваш раздел управления дистрибуцией

<repository>
    <id>release.repo</id>
    <url>dav:http://repo.jillesvangurp.com/releases/</url>
</repository>

Наконец, убедитесь, что вы настроили доступ к хранилищу в вашем файле settings.xml

добавьте это в ваш раздел серверов

    <server>
        <id>release.repo</id>
        <username>xxxx</username>
        <password>xxxx</password>
    </server>

и определение вашего раздела репозиториев

            <repository>
                <id>release.repo</id>
                <url>http://repo.jillesvangurp.com/releases</url>
                <releases>
                    <enabled>true</enabled>
                </releases>
                <snapshots>
                    <enabled>false</enabled>
                </snapshots>
            </repository>

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

Преимущества: у вас есть собственный репозиторий Maven. Недостатки: у вас нет никаких возможностей управления в Nexus; вам нужно где-то настроить webdav

В качестве альтернативы Bintray предоставляет бесплатный хостинг репозиториев maven. Это, вероятно, хорошая альтернатива Sonatype OSS и Maven Central, если вы абсолютно не хотите переименовывать groupId. Но, пожалуйста, по крайней мере, приложите усилия, чтобы ваши изменения были интегрированы в апстрим или переименованы и опубликованы в Central. Другим намного легче использовать вашу вилку.

Я пришел сюда, чтобы сделать то же самое, бесплатно разместить мой репозиторий Maven, но после дополнительных исследований я оказался здесь:https://jfrog.com/start-free/

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

Пока я действительно очень доволен!

Я хотел бы добавить еще одну альтернативу, плагин Gradle, над которым я работал в последнее время: magik.

В основном это позволяет публиковать прямо в репозитории github, выступающем в качестве репозитория maven.

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

Другие вопросы по тегам