私はgithubで作業している小さなオープンソースライブラリのフォークを持っています。私はmavenを介して他の開発者が利用できるようにしたいのですが、自分のNexusサーバーを実行したくありません。これはフォークなので、oss.sonatype.orgに簡単にデプロイできません。
他の人がmavenを使用してアクセスできるように、それをgithubにデプロイします。これを行う最良の方法は何ですか?
私はgithubで作業している小さなオープンソースライブラリのフォークを持っています。私はmavenを介して他の開発者が利用できるようにしたいのですが、自分のNexusサーバーを実行したくありません。これはフォークなので、oss.sonatype.orgに簡単にデプロイできません。
他の人がmavenを使用してアクセスできるように、それをgithubにデプロイします。これを行う最良の方法は何ですか?
回答:
私が見つけた最良の解決策は、次のステップで構成されています。
mvn-repo
Mavenアーティファクトをホストするために呼び出されるブランチを作成します。mvn-repo
をMavenリポジトリーとして使用するようにMavenを構成します。このアプローチを使用することには、いくつかの利点があります。
mvn-repo
、githubページがと呼ばれる別のブランチに保持されるようにgh-pages
(githubページを使用する場合)、ソースとは別のブランチに保持されますgh-pages
それらを使用している場合は競合しません。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にパスワードの入力を求める方法を誰かが知っている場合は、お知らせください。)
次に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-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
。
実行したいもう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のプロファイルに名前を明記してください。
<merge>true</merge>
は、site-maven-plugin構成で設定します。ただし、その場合は、githubにmvn-repoブランチを手動で作成し、最初にそのすべてのファイルを削除する必要があると思います。
<altDeploymentRepository>internal.repo::default::file://${user.dir}/target/mvn-repo</altDeploymentRepository>
、maven-deploy-pluginやsite-maven-pluginと<outputDirectory>${user.dir}/target/mvn-repo</outputDirectory>
一緒に使用することもできます。これにより、すべてのアーティファクトがルート(「親」)プロジェクトにデプロイされ、githubのそれぞれの親ディレクトリにプッシュされます。そうでない場合、各サブモジュールのビルドは、以前にビルドされたサブモジュールのビルドを上書きします...
<github.global.userName>YourUserName</github.global.userName> <github.global.password>${GITHUB_OAUTH_TOKEN</github.global.password>
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のドキュメント「リポジトリの概要」を参照してください。
あなたは使用することができますJitPack Mavenの成果物としてあなたのGitHubのリポジトリを公開する(公開Gitリポジトリのための無料の)。それは超簡単。ユーザーはこれをpom.xmlに追加する必要があります。
<repository>
<id>jitpack.io</id>
<url>https://jitpack.io</url>
</repository>
<dependency>
<groupId>com.github.User</groupId>
<artifactId>Repo name</artifactId>
<version>Release tag</version>
</dependency>
他の場所で回答されているように、JitPackはGitHubリポジトリを構築してjarファイルを提供するという考えです。要件は、ビルドファイルとGitHubリリースがあることです。
導入とアップロードを処理する必要がないというのは素晴らしいことです。独自のアーティファクトリポジトリを維持したくなかったため、ニーズに最適です。
もう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セットアップが必要です
2019年から、Githubパッケージレジストリと呼ばれる新機能を使用できるようになりました。
基本的にプロセスは次のとおりです。
settings.xml
使用して展開
mvn deploy -Dregistry=https://maven.pkg.github.com/yourusername -Dtoken=yor_token
別の方法として、BintrayはMavenリポジトリの無料ホスティングを提供しています。groupIdの名前を変更したくない場合は、Sonatype OSSやMaven Centralに代わる良い方法でしょう。しかし、少なくとも、変更を上流に統合するように努力するか、名前を変更してCentralに公開してください。他の人があなたのフォークを使うのをずっと簡単にします。
aar
またはjar
ファイル自体がある場合、または単にプラグインを使用したくない場合- 簡単なシェルスクリプトを作成しました。アーティファクトをGithubにパブリッシュし、パブリックMavenリポジトリとして使用することで、同じことを実現できます。