Hostowanie repozytorium Maven na github

Mam widelec małej biblioteki o otwartym źródle, nad którą pracuję nad github. Chciałbym udostępnić go innym programistom za pośrednictwem maven, ale nie chcę uruchamiać własnego serwera Nexus, a ponieważ jest to rozwidlenie, nie mogę go łatwo wdrożyć na oss.sonatype.org.

Chciałbym wdrożyć go na github, aby inni mogli uzyskać do niego dostęp za pomocą maven. Jak najlepiej to zrobić?

Najlepsze rozwiązanie, jakie udało mi się znaleźć, składa się z następujących kroków:

1. Utwórz gałąź nazywaną mvn-repodo przechowywania artefaktów raju.
2. Użyj wtyczki github site-maven-plug, aby wypchnąć swoje artefakty do github.
3. Skonfiguruj maven, aby używał twojego pilota mvn-repojako repozytorium maven.

Korzystanie z tego podejścia ma kilka zalet:

• Artefakty Maven są trzymane oddzielnie od źródła w oddzielnej gałęzi o nazwie mvn-repo, podobnie jak strony github są przechowywane w osobnej gałęzi o nazwie gh-pages(jeśli używasz stron github)
• W przeciwieństwie do niektórych innych proponowanych rozwiązań, nie koliduje z twoim, gh-pagesjeśli ich używasz.
• Naturalnie łączy się z celem rozmieszczania, więc nie ma nowych poleceń do nauki. Po prostu używaj mvn deployjak zwykle

Typowym sposobem rozmieszczania artefaktów w zdalnym repozytorium maven jest użycie mvn deploy, więc załatajmy ten mechanizm dla tego rozwiązania.

Najpierw powiedz maven, aby rozmieścił artefakty w tymczasowej lokalizacji przemieszczania w katalogu docelowym. Dodaj to do 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>

Teraz spróbuj uruchomić mvn clean deploy. Zobaczysz, że wdrożył twoje repozytorium maven do target/mvn-repo. Następnym krokiem jest pobranie tego katalogu do GitHub.

Dodaj informacje uwierzytelniające, aby ~/.m2/settings.xmlgithub site-maven-pluginmógł przesyłać do 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>

(Jak wspomniano, pamiętaj, aby upewnić się, chmod 700 settings.xmlże nikt nie może odczytać Twojego hasła w pliku. Jeśli ktoś wie, jak poprosić wtyczkę site-maven o podanie hasła zamiast wymagać go w pliku konfiguracyjnym, daj mi znać.)

Następnie powiedz GitHub site-maven-plugino nowym serwerze, który właśnie skonfigurowałeś, dodając do pom:

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

Na koniec skonfiguruj site-maven-pluginprzesyłanie z tymczasowego repozytorium przemieszczania do swojego mvn-repooddziału w 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-repoOddział nie musi istnieć, to zostanie utworzony dla Ciebie.

Teraz uruchom mvn clean deployponownie. Powinieneś zobaczyć maven-deploy-plugin „upload” plików do lokalnego repozytorium przemieszczania w katalogu docelowym, a następnie wtyczkę site-maven zatwierdzającą te pliki i wypychającą je na serwer.

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

Wejdź na github.com w przeglądarce, wybierz mvn-repooddział i sprawdź, czy wszystkie Twoje pliki binarne już tam są.

Gratulacje!

Teraz możesz rozmieścić swoje artefakty z raju w publicznym repozytorium biedaka, po prostu biegając mvn clean deploy.

Jest jeszcze jeden krok, który chcesz zrobić, a mianowicie skonfigurować wszystkie poms, które zależą od pom, aby wiedzieć, gdzie jest twoje repozytorium. Dodaj następujący fragment kodu do pom pom projektu zależnego od projektu:

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

Teraz każdy projekt, który wymaga plików jar, automatycznie pobierze je z repozytorium github maven.

Edytuj: aby uniknąć problemu wymienionego w komentarzach („Błąd podczas tworzenia zatwierdzenia: nieprawidłowe żądanie. W przypadku„ właściwości / nazwa ”zero nie jest łańcuchem.”), Upewnij się, że podałeś nazwę w swoim profilu na github.

Nie używaj GitHub jako repozytorium Maven.

Edycja: Ta opcja ma dużo głosów negatywnych, ale nie ma komentarzy na temat przyczyny. Jest to prawidłowa opcja niezależnie od technicznych możliwości hostowania w GitHub. Hosting na GitHub jest nieprawidłowy z wszystkich powodów wymienionych poniżej i bez komentarzy nie mogę poprawić odpowiedzi, aby wyjaśnić twoje problemy.

Najlepsza opcja - współpraca z oryginalnym projektem

Najlepszym rozwiązaniem jest przekonanie oryginalnego projektu, aby uwzględnił zmiany i trzymał się oryginału.

Alternatywa - utrzymanie własnego widelca

Ponieważ rozwidliłeś bibliotekę typu open source, a twój widelec jest również oprogramowaniem typu open source, możesz przesłać swój widelec do Maven Central (przeczytaj Przewodnik po przesyłaniu artefaktów do centralnego repozytorium ), nadając mu nowy, groupIda może nowy artifactId.

Rozważ tę opcję tylko, jeśli chcesz zachować ten rozwidlenie, dopóki zmiany nie zostaną włączone do oryginalnego projektu, a następnie powinieneś go porzucić.

Naprawdę mocno zastanów się, czy widelec jest właściwą opcją. Przeczytaj niezliczone wyniki Google dla „dlaczego nie rozwidlać”

Rozumowanie

Nadmuchiwanie repozytorium słojami zwiększa rozmiar pobierania bez żadnych korzyści

Słoik należy do outputtwojego projektu, można go w dowolnym momencie zregenerować inputs, a Twoje repozytorium GitHub powinno zawierać tylko inputs.

Nie wierzysz mi? Następnie sprawdź wyniki Google pod kątem „nie przechowuj plików binarnych w git” .

Pomoc GitHub Praca z dużymi plikami powie ci to samo. Wprawdzie słoiki nie są duże, ale są większe niż kod źródłowy, a gdy jar zostanie utworzony przez wydanie, nie ma powodu, aby być wersjonowanym - po to jest nowe wydanie.

Zdefiniowanie wielu repozytoriów w pliku pom.xml spowalnia kompilację według liczby repozytoriów razy liczby artefaktów

Stephen Connolly mówi :

Jeśli ktoś doda twoje repozytorium, wpłynie to na jego wydajność kompilacji, ponieważ mają teraz kolejne repozytorium do sprawdzenia artefaktów ... Nie jest to duży problem, jeśli musisz dodać tylko jedno repo ... Ale problem rośnie i następna rzecz, którą znasz build maven sprawdza 50 repozytoriów dla każdego artefaktu, a czas budowy to pies.

Zgadza się! Maven musi sprawdzić każdy artefakt (i jego zależności) zdefiniowane w pliku pom.xml z każdym zdefiniowanym repozytorium , ponieważ nowsza wersja może być dostępna w każdym z tych repozytoriów.

Wypróbuj sam, a poczujesz ból powolnej budowy.

Najlepsze miejsce na artefakty znajduje się w Maven Central, ponieważ jest to centralne miejsce na słoiki, a to oznacza, że ​​twoja kompilacja sprawdzi tylko jedno miejsce.

Możesz przeczytać więcej o repozytoriach w dokumentacji Mavena na temat Wprowadzenie do repozytoriów

Możesz użyć JitPack (bezpłatny dla publicznych repozytoriów Git), aby ujawnić swoje repozytorium GitHub jako artefakt Maven. To jest bardzo łatwe. Twoi użytkownicy będą musieli dodać to do swojego pom.xml:

1. Dodaj repozytorium:

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

2. Dodaj zależność:

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

Zgodnie z odpowiedzią gdzie indziej chodzi o to, że JitPack zbuduje Twoje repozytorium GitHub i będzie obsługiwał słoiki. Wymagane jest posiadanie pliku kompilacji i wersji GitHub.

Zaletą jest to, że nie musisz zajmować się wdrażaniem i przesyłaniem. Ponieważ nie chciałeś utrzymywać własnego repozytorium artefaktów, to dobrze pasuje do twoich potrzeb.

Inną alternatywą jest użycie dowolnego hostingu z obsługą webdav. Oczywiście będziesz potrzebować trochę miejsca, ale jest to prosta konfiguracja i dobra alternatywa dla uruchamiania w pełni funkcjonalnego serwera Nexus.

dodaj to do sekcji kompilacji

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

Dodaj coś takiego do swojej sekcji managementManagement

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

Na koniec skonfiguruj dostęp do repozytorium w pliku settings.xml

dodaj to do sekcji serwerów

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

oraz definicję sekcji repozytoriów

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

Wreszcie, jeśli masz jakiś standardowy hosting php, możesz użyć czegoś takiego jak sabredav, aby dodać funkcje webdav.

Zalety: masz własne repozytorium maven Wady: nie masz żadnych możliwości zarządzania nexusem; potrzebujesz gdzieś konfiguracji webdav

Od 2019 r. Możesz teraz korzystać z nowej funkcji o nazwie rejestr pakietów Github .

Zasadniczo proces jest następujący:

• wygeneruj nowy osobisty token dostępu z ustawień github
• dodaj do repozytorium i dane tokena settings.xml

• wdrożyć za pomocą

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

Alternatywnie Bintray zapewnia bezpłatny hosting repozytoriów maven. Jest to prawdopodobnie dobra alternatywa dla Sonatype OSS i Maven Central, jeśli absolutnie nie chcesz zmieniać nazwy groupId. Ale proszę, przynajmniej staraj się zintegrować swoje zmiany w górę lub zmień nazwę i opublikuj w Central. Ułatwia innym korzystanie z widelca.

Jeśli masz tylko plik aarlub jarsam plik, albo po prostu nie chcesz używać wtyczek - stworzyłem prosty skrypt powłoki . Możesz osiągnąć to samo - publikując swoje artefakty w Github i wykorzystując je jako publiczne repozytorium Maven.