Хостинг сховища Maven на github


312

У мене є вилка невеликої відкритої бібліотеки, над якою я працюю над github. Я хотів би зробити це доступним для інших розробників через maven, але я не хочу запускати свій власний сервер Nexus, і тому що це роздрібнене, я не можу легко розгорнути його на oss.sonatype.org.

Що я хотів би зробити, це розгорнути його в github, щоб інші могли отримати доступ до нього за допомогою Maven. Який найкращий спосіб зробити це?


5
з якими проблемами ліцензування ви стикаєтеся в OSS Sonatype? Просто цікаво, оскільки я сам його використовую.
Архімед Траяно

5
Існує інструмент, який дозволяє безпосередньо піддавати репортаж GitHub через Maven. jitpack.io stackoverflow.com/a/28483461/3975649
metrimer

1
Github також оголосив реєстр пакетів, який підтримує maven. Наразі в публічній бета-версії: github.com/features/package-registry
Каан

Відповіді:


483

Найкраще рішення, яке мені вдалося знайти, складається з таких кроків:

  1. Створіть відділення, закликане mvn-repoрозмістити ваші артефакти Maven.
  2. Використовуйте плагін github- site-maven-плагін, щоб підштовхнути свої артефакти до 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. Ви побачите, що він розгорнув ваше сховище Maventarget/mvn-repo . Наступним кроком є ​​його завантаження в GitHub.

Додайте інформацію про аутентифікацію, щоб ~/.m2/settings.xmlgithub 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 ніхто не зможе прочитати ваш пароль у файлі. Якщо хтось знає, як зробити підказку сайту-maven-плагін для пароля, а не вимагати його у конфігураційному файлі, дайте мені знати.)

Потім скажіть GitHub site-maven-pluginпро новий сервер, який ви тільки що сконфігурували, додавши до пам’яті наступне:

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

The mvn-repoГілки не повинні існувати, він буде створений для вас.

Тепер біжіть mvn clean deployзнову. Ви повинні побачити, що maven -loy-plugin "завантажує" файли у ваше місцеве сховище інсценізації у цільовому каталозі, після чого сайт-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 .

Ще один крок, який ви хочете зробити, - це налаштувати будь-які особи, які залежать від вашого пом, щоб знати, де знаходиться ваше сховище. Додайте такий фрагмент до пам’яті будь-якого проекту, що залежить від вашого проекту:

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

Редагувати: щоб уникнути проблеми, зазначеної в коментарях ("Помилка створення комісії: недійсний запит. Для" властивостей / імені ", nil не є рядком."), Переконайтеся, що ви вказали ім'я у своєму профілі на github.


25
Зауважте також, що це рішення замінить ваші попередні артефакти щоразу, коли ви розгортаєтесь. Це підходить для сховищ знімків, але не для випущених артефактів. Щоб відключити таку поведінку, встановіть <merge>true</merge>у конфігурації вашого веб-сайту maven-plugin. Якщо ви це зробите, я думаю, вам доведеться вручну створити гілку mvn-repo в github та видалити всі її файли вперше.
emmby

13
+1 розумний і добре представлений. Моя єдина критика - ви не включили посилання на сайт плагінів Maven: github.com/github/maven-plugins . Thx я шукав спосіб опублікувати свій сайт Maven в github!
Марк О'Коннор

7
Цей підхід не працює, коли на github використовується двофакторна автентифікація. Дивіться мою записку у випуску тут: github.com/github/maven-plugins/isissue/36#issuecomment-31005606
Даг

18
Для того, щоб зробити цю роботу для мультимодульних проектів , ви також можете просто використовувати <altDeploymentRepository>internal.repo::default::file://${user.dir}/target/mvn-repo</altDeploymentRepository>з maven-opens-plugin та <outputDirectory>${user.dir}/target/mvn-repo</outputDirectory>з site-maven-plugin . Це дозволить розгорнути всі артефакти в кореневому ("батьківському") проекті та перемістити їх у відповідний батьківський каталог на github. В іншому випадку збірка кожного підмодуля замінить конструкцію підмодулю, побудованого до ...
sd

7
Дві пропозиції, які змушують його працювати (принаймні для мене): Встановіть поточну версію плагіна Github (зараз це було б 0,11). Також я б запропонував усім використовувати маркер OAUTH замість пароля. Ви можете їх генерувати у розділі "Налаштування-> Програми-> Маркери особистого доступу". Тоді ви також можете вбудувати його в POM через та зберегти маркер як змінну середовища. <github.global.userName>YourUserName</github.global.userName> <github.global.password>${GITHUB_OAUTH_TOKEN</github.global.password>
Флоріан Лох

120

Не використовуйте GitHub як сховище Maven.

Редагувати: Цей параметр отримує багато голосів за відмову, але немає коментарів щодо того, чому. Це правильний варіант незалежно від технічних можливостей фактично розміщуватись на GitHub. Хостинг на GitHub невірний з усіх наведених нижче причин, і без коментарів я не можу покращити відповідь, щоб уточнити ваші проблеми.

Найкращий варіант - співпрацюйте з оригінальним проектом

Найкращий варіант - переконати оригінальний проект включити свої зміни та дотримуватися оригіналу.

Альтернатива - підтримуйте власну вилку

Оскільки ви розщедрили бібліотеку з відкритим кодом, а ваша форка також є відкритим кодом, ви можете завантажити свою вилку в 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 про Вступ до сховищ


3
Повністю згоден і має сенс для виделок, які ви хочете тримати довкола. Але це може бути багато накладних витрат лише за невеликий виправлення до існуючого проекту.
emmby

5
Я сумніваюся, у Github є проблема з цим, оскільки вони написали плагін, який дозволяє цю можливість. Я згоден, це менше ідеї, але c'est la vie.
Phy6

4
Не завжди можливо розгортати проект із відкритим кодом на Sonatype. Наприклад, коли ваш проект залежить від іншого проекту з відкритим кодом, він ще не розгорнувся (і його не можна розгорнути, оскільки він не відповідає вимогам сонатипу).
Габ

1
@Gab, то ваша залежність насправді не є відкритим кодом. Вам слід зв’язатись з іншим проектом та пояснити це та надати їм можливість виправити своє ліцензування. (Сонце було винуватцем такої поведінки в минулому)
Бе

1
@Bae Це не питання ліцензування. Деякі власники проекту вирішують не публікувати на центральному просто тому, що це не їх пріоритет. Ваш шлях неможливий у реальному світі. Якщо ви хочете перевірити: переконайте це, щоб опублікувати на Central code.google.com/p/sd-dss . Це великий проект з відкритим кодом, який фінансується спільнотою ЄС :)
Габ

48

Ви можете використовувати JitPack (безкоштовно для публічних сховищ Git), щоб відкрити своє сховище 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.

Приємно, що вам не потрібно обробляти розгортання та завантаження. Оскільки ви не хотіли підтримувати власне сховище артефактів, це добре відповідає вашим потребам.


JitPack досить хороший, але змушує вас змінити кожну групу, яку ви маєте. Вони кажуть, що цього можна уникнути, але потрібно додати запис до DNS своєї компанії, що в більшості випадків абсолютно непрактично. Я колись намагався з JP, тоді я вирішив, що це занадто нерозумно, щоб йти вперед.
zakmck

1
Не потрібно змінювати групу ID своїх проектів. Ви все ще можете встановити ці проекти, використовуючи 'com.github.User' groupId. Але можливо ваш випадок використання інший.
Андрейс

Так, це дуже багато. Тому що в мене вже є десятки навколо моєї організації та зовнішніх користувачів, і тому, що я хочу власний бренд на них. Як можна бути таким дурним, щоб спробувати примусити мене до своєї власної групи. Ідея - це те, чому я думаю про те, щоб змінити кар'єру.
zakmck

Більше того, я не бачу реальної потреби у хлопців JP кидати на мене таку вимогу (вони могли просто перехопити запити Maven із специфікації сховища).
zakmck

1
Хороша ідея, я це зробив: github.com/jitpack/jitpack.io/isissue/209 , дякую :-)
zakmck

9

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

Нарешті переконайтеся, що налаштуйте доступ до сховища у ваших налаштуваннях.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 Downsides: у вас немає жодних можливостей управління в Nexus; десь потрібна установка webdav


9

З 2019 року тепер ви можете використовувати нову функціональність під назвою реєстр пакетів Github .

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

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

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

Станом на 2019 рік це найкращий варіант.
HRJ

1
Але для того, щоб використовувати його кимось іншим, схоже, йому потрібно налаштувати settings.xml з відповідною URL-адресою та інформацією про автентифікацію
hemu

Дуже дивно ... Ви створюєте свій загальнодоступний пакет, але перед тим, як отримати його, потрібна інша автентифікація
Смішний

Однак для приватних репостів, після підтвердження звичаїв / місяць, ціноутворення входить у світ
Локешвар Кравець

8

Як альтернатива, Bintray пропонує безкоштовний хостинг сховищ Maven. Це, мабуть, хороша альтернатива Sonatype OSS та Maven Central, якщо ви абсолютно не хочете перейменувати groupId. Але будь-ласка, принаймні докладіть зусиль, щоб внести свої зміни вгору або перейменувати та опублікувати в Central. Іншим людям значно легше користуватися виделкою.


3
Я не міг повірити, коли спробував, але Bintray не підтримує знімків. Марно.
zakmck

6
Це вже не безкоштовно. 150 доларів на місяць.
AndroidDev

Я думаю, це плата за проекти програмного забезпечення з відкритим кодом: jfrog.com/open-source
iBiber

0

Якщо у вас є лише файл aarабо jarсам файл або просто не хочете використовувати плагіни - я створив простий скрипт оболонки . Ви можете домогтися того ж і з ним - опублікувавши свої артефакти в Github і використовуйте його як публічний Maven repo.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.