githubでのMavenリポジトリーのホスティング


312

私はgithubで作業している小さなオープンソースライブラリのフォークを持っています。私はmavenを介して他の開発者が利用できるようにしたいのですが、自分のNexusサーバーを実行したくありません。これはフォークなので、oss.sonatype.orgに簡単にデプロイできません。

他の人がmavenを使用してアクセスできるように、それをgithubにデプロイします。これを行う最良の方法は何ですか?


5
OSS Sonatypeで直面しているライセンスの問題は何ですか?自分で使っているので気になる。
アルキメデストラハノ2014

5
Mavenを介してGitHubリポジトリを直接公開できるツールがあります。jitpack.io stackoverflow.com/a/28483461/3975649
metrimer

1
Githubは、mavenをサポートするパッケージレジストリも発表しました。現在public-beta:github.com/features/package-registry
Kaan

回答:


484

私が見つけた最良の解決策は、次のステップで構成されています。

  1. mvn-repoMavenアーティファクトをホストするために呼び出されるブランチを作成します。
  2. github site-maven-pluginを使用して、アーティファクトをgithubにプッシュします。
  3. リモートmvn-repoをMavenリポジトリーとして使用するように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.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に、ファイル内のパスワードを誰も読み取れないようにしてください。設定ファイルでパスワードを要求するのではなく、site-maven-pluginにパスワードの入力を求める方法を誰かが知っている場合は、お知らせください。)

次にsite-maven-plugin、pomに以下を追加して、構成した新しいサーバーについてGitHubに通知します。

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

最後に、site-maven-plugin一時的なステージングリポジトリからmvn-repoGithubのブランチにアップロードするようにを設定します。

<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

実行したいもう1つのステップは、リポジトリにあるpomに依存する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リポジトリから自動的にダウンロードされます。

編集:コメントで言及されている問題を回避するには(「コミットの作成エラー:リクエストが無効です。「プロパティ/名前」の場合、nilは文字列ではありません。)」、githubのプロファイルに名前を明記してください。


25
このソリューションは、デプロイするたびに以前のアーティファクトを上書きすることにも注意してください。これはスナップショットリポジトリに適していますが、リリースされたアーティファクトには適していません。この動作を無効にするに<merge>true</merge>は、site-maven-plugin構成で設定します。ただし、その場合は、githubにmvn-repoブランチを手動で作成し、最初にそのすべてのファイルを削除する必要があると思います。
emmby

13
+1賢く、よく表示されます。私の唯一の批判は、Mavenプラグインサイトgithub.com/github/maven-pluginsへのリンクを含めなかったことです。Thx Mavenサイトをgithubに公開する方法を探していました!
マーク・オコナー

7
githubでTwo-Factor認証が使用されている場合、このアプローチは機能しません。ここの問題の私のメモを参照してください:github.com/github/maven-plugins/issues/36#issuecomment-31005606
Dag

18
これをマルチモジュールプロジェクトで機能させるために<altDeploymentRepository>internal.repo::default::file://${user.dir}/target/mvn-repo</altDeploymentRepository>maven-deploy-pluginsite-maven-plugin<outputDirectory>${user.dir}/target/mvn-repo</outputDirectory>一緒に使用することもできます。これにより、すべてのアーティファクトがルート(「親」)プロジェクトにデプロイされ、githubのそれぞれの親ディレクトリにプッシュされます。そうでない場合、各サブモジュールのビルドは、以前にビルドされたサブモジュールのビルドを上書きします...
sd

7
それを機能させる2つの提案(少なくとも私にとって):Githubプラグインの現在のバージョンを設定します(現時点では0.11になります)。また、パスワードの代わりにOAUTHトークンを使用することをお勧めします。「設定->アプリケーション->パーソナルアクセストークン」で生成できます。また、それをPOMにインライン化して、トークンを環境変数として保存することもできます。 <github.global.userName>YourUserName</github.global.userName> <github.global.password>${GITHUB_OAUTH_TOKEN</github.global.password>
Florian Loch、

120

GitHubをMavenリポジトリーとして使用しないでください。

編集:このオプションは多くの反対票を獲得しますが、その理由についてのコメントはありません。これは、GitHubで実際にホストする技術的な機能に関係なく、正しいオプションです。GitHubでのホスティングは、以下に概説するすべての理由で間違っており、コメントがないと、問題を明確にするための回答を改善できません。

最適なオプション-元のプロジェクトとのコラボレーション

最善のオプションは、元のプロジェクトを説得して変更を含め、元のプロジェクトを忠実に守ることです。

代替案-独自のフォークを維持する

あなたは、オープンソースのライブラリをフォークしている、とあなたのフォークもオープンソースですので、あなたは(読みのMaven Centralにあなたのフォークをアップロードすることができ、中央リポジトリにアップロードしてアーティファクトにガイドを、それを新しい与えることによって)groupIdと、おそらく新しいのartifactId

このオプションを検討するのは、変更が元のプロジェクトに組み込まれるまでこのフォークを維持し、その後、このフォークを放棄する必要がある場合のみです。

フォークが適切なオプションであるかどうかを本当によく考えてください。「フォークしない理由」に関するGoogleの無数の結果を読む

推論

jarでリポジトリを肥大化するとダウンロードサイズが増加し、メリットがなくなります

jarはoutputプロジェクトの1つであり、jar からいつでも再生成できinputsます。GitHubリポジトリにはのみを含める必要がありますinputs

信じられない?次に、Googleの結果で「バイナリをgitに保存しない」を確認します。

GitHubのヘルプ大きなファイルの操作も同じことがわかります。確かにjarのサイズは大きくありませんが、ソースコードよりも大きく、リリースによってjarが作成されると、バージョン管理する理由がなくなります。これが新しいリリースの目的です。

pom.xmlに複数のリポジトリを定義すると、リポジトリの数とアーティファクトの数の倍数だけビルドが遅くなります

スティーブン・コノリーは言います

誰かがあなたのレポを追加すると、アーティファクトをチェックする別のレポがあるため、ビルドパフォーマンスに影響を与えます... 1つのレポを追加するだけでよい場合、それは大きな問題ではありません...しかし、問題は大きくなり、次に知っていることはMavenビルドはすべてのアーティファクトについて50リポジトリをチェックしており、ビルド時間は犬です。

そのとおり!Mavenは、pom.xmlで定義されたすべてのアーティファクト(およびその依存関係)を、定義したすべてのリポジトリに対してチェックする必要があります。これらのリポジトリのいずれかで新しいバージョンが利用できる可能性があるためです。

自分で試してみると、遅いビルドの痛みを感じるでしょう。

アーティファクトの最適な場所は、jarの中心的な場所であるMavenセントラルです。これは、ビルドがチェックする場所は1つだけであることを意味します。

リポジトリの詳細については、Mavenのドキュメント「リポジトリの概要」を参照してください。


3
完全に同意し、しばらくの間保持したいフォークには理にかなっています。しかし、これは既存のプロジェクトへの小さなパッチだけでは、多くのオーバーヘッドになる可能性があります。
emmby 2014年

5
Githubがこの機能を有効にするプラグインを作成したため、Githubに問題があるとは思えません。私はそれがアイデアより少ないことに同意しますが、c'est la vieです。
Phy6 2014年

4
オープンソースプロジェクトをSonatypeにデプロイできるとは限りません。たとえば、プロジェクトが、まだデプロイされていない別のオープンソースプロジェクトに依存している場合(およびsonatype要件を満たさないためにデプロイできない場合)。
ガブ2014

1
@Gabでは、依存関係は実際にはオープンソースではありません。他のプロジェクトに連絡してこれを説明し、ライセンスを修正してもらう必要があります。(太陽は過去のこの行動の犯人でした)
Bae

1
@Baeライセンスの問題ではありません。一部のプロジェクトオーナーは、優先事項ではないという理由だけで中央に公開しないことにしました。あなたのやり方は現実の世界では不可能です。テストする場合:これを説得して、Central code.google.com/p/sd-dssで公開します。これは、EUコミュニティから資金提供を受けた大きなオープンソースプロジェクトです。:
Gab

48

あなたは使用することができますJitPack Mavenの成果物としてあなたのGitHubのリポジトリを公開する(公開Gitリポジトリのための無料の)。それは超簡単。ユーザーはこれを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リポジトリを構築してjarファイルを提供するという考えです。要件は、ビルドファイルとGitHubリリースがあることです。

導入とアップロードを処理する必要がないというのは素晴らしいことです。独自のアーティファクトリポジトリを維持したくなかったため、ニーズに最適です。


JitPackはかなり良いですが、周りにあるすべてのgroupIdを変更する必要があります。これは回避できると言われていますが、会社のDNSにエントリを追加する必要があります。これは、ほとんどの場合、まったく実用的ではありません。私は一度JPを試しましたが、これは愚かすぎて先に進めないと判断しました。
zakmck 2015

1
プロジェクトのgroupIdを変更する必要はありません。「com.github.User」のgroupIdを使用して、これらのプロジェクトをインストールできます。しかし、おそらくあなたのユースケースは異なります。
Andrejs

はい、とてもそうです。私の組織と外部ユーザーの周りにはすでに何十ものそれらがあり、私はそれらに自分のブランドが欲しいので。私を自分のgroupIdに強制しようとするのがどれほど愚かであるかは、私がキャリアを変えることを考えている理由の1つです。
zakmck 2015

さらに、私はJPの人たちがそのような要件を私に投げる必要が本当にあるとは思いません(リポジトリの仕様からのMavenリクエストを傍受するだけの可能性があります)。
zakmck 2015

1
いい考え、私はそれをやった:github.com/jitpack/jitpack.io/issues/209、ありがとう:-)
zakmck

9

もう1つの方法は、webdavをサポートするWebホスティングを使用することです。もちろん、このためにある程度のスペースが必要になりますが、セットアップは簡単で、本格的なネクサスサーバーを実行するための優れた代替手段です。

これをビルドセクションに追加します

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

このようなものをdistributionManagementセクションに追加します

<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リポジトリーがある欠点:ネクサスには管理機能がありません。どこかにいくつかのwebdavセットアップが必要です


9

2019年から、Githubパッケージレジストリと呼ばれる新機能を使用できるようになりました。

基本的にプロセスは次のとおりです。

  • githubの設定から新しい個人用アクセストークンを生成する
  • リポジトリとトークン情報を settings.xml
  • 使用して展開

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

2019年現在、これが最良のオプションです。
HRJ

1
しかし、他の誰かがそれを使用するためには、彼/彼女は、それぞれのURLと認証情報でsettings.xmlを設定する必要があるようです
hemu

非常に奇妙です...あなたはあなたの公開パッケージを作成しましたが、他の人はそれを取得する前に認証を必要としています
非常に多くの

ただし、プライベートリポジトリの場合、特定の使用量/月の後、料金が適用されます
Lokeshwar Tailor

8

別の方法として、BintrayはMavenリポジトリの無料ホスティングを提供しています。groupIdの名前を変更したくない場合は、Sonatype OSSやMaven Centralに代わる良い方法でしょう。しかし、少なくとも、変更を上流に統合するように努力するか、名前を変更してCentralに公開してください。他の人があなたのフォークを使うのをずっと簡単にします。


3
試してみたら信じられませんでしたが、Bintrayはスナップショットをサポートしていません。役に立たない。
zakmck 2015

6
もう無料ではありません。月額$ 150。
AndroidDev 2016年

オープンソースソフトウェアプロジェクトの料金だと思います:jfrog.com/open-source
iBiber

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.