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

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

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

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

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чтобы github 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://github.com/YOUR-USERNAME/YOUR-PROJECT-NAME/raw/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, чтобы узнать, почему бы не раскошелиться

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Добавить репозиторий:

<repository>
    <id>jitpack.io</id>
    <url>https://jitpack.io</url>
</repository>

2. Добавить зависимость:

<dependency>
    <groupId>com.github.User</groupId>
    <artifactId>Repo name</artifactId>
    <version>Release tag</version>
</dependency>

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

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

Другой альтернативой является использование любого веб-хостинга с поддержкой 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

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

В основном процесс таков:

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

• развернуть с помощью

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

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

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