
こんにちわ、みけです。
あ、また、例によって記事が長いので、
結論だけ見たい人は前半部分だけを見て下さい。 – 大体5分以内。
で、gradleでのmaven centralへのライブラリー登録方法を知りたい方は中盤部分まで読んで下さい。 – トータル15分。
で、僕の強引なgradle遊びまで読みたい方は最後まで読むといいかもしれません。 – トータル30分。
前半部分
ここ数日gradle1.4以降についかされたmaven-publishプラグインを使って
maven centralへのライブラリー登録方法を調べていましたが、
maven-publishプラグインでのmaven central repoへの登録はまだサポートされてません
ようです。
元記事はこちらです。
以下、簡単な意訳+要約文
質問
maven-publishプラグインを使ってレポジトリー情報の設定と、それと別個に、singningプラグインを使ってartifactsへのサインを行うことができますが、それらを連携させることができません。
どのようにすればmaven-publishプラグインで、artifactsとサインファイル(.ascファイル)をアップロードするようにできますか?
回答
今のところmaven-publishプラグインを使ってartifactとsignatureをアップロードすることはサポートされていません。Gradleに「.asc」ファイル(サインしたファイル)が通常のartifactではなく、特別なartifactであることを伝える手段がないことが問題となっています。
こちらのロードマップを参照下さい。なお、この機能に関する優先順位は高くありません。
再質問
現在、古い方法でのアップロードはサポートされていますか?それとも手作業でやらないと駄目ですか?
回答
古い方法でのアップロードは利用できます。
提案
ありがとうございました。
ところで、ドキュメントの方で新しいプラグインではmaven centralにアップロード出来ないという記述がないので追加してもらえますか?
とのことで、maven-publishプラグインでのmaven central repoへのアップロードはまだ対応されていないようです。これはこれで従来のmavenプラグインよりも便利なので、maven centralへのアップロードも可能になって欲しいとろこです。
中盤部分
なお、日本語でも情報は入手出来ますが、念の為にこちらにも記述しておきます。
現状のgradleを用いたmaven centralへのアップロード方法
概要は、山本裕介氏のこちらの記事を参照して下さい。
また、gradleでの方法についてはこちらを参照して下さい。
- Automated Gradle project deployment to Sonatype OSS Repository(英語)
- GradleでMaven Central Repositoryに成果物をリリースする(日本語)
両方の記事に共通していますが、Sonatypeからmaven centralにアップロードする場合は、
- PGPによる署名の作成
- 求められた規約の順守
が求められます。
なんでこんな面倒くさいのか?
maven centralにおいてあるライブラリーの品質や、pomなどの情報がバラバラで、一定の品質を保てなかったからのようです。
詳しくはこちらをお読み下さい(英語)。
central repositoryの品質向上のためにmaven central repoでは下記の規約を儲けています。
pom.xmlへの要求事項
<modelVersion>–4.0.0を設定する<groupId>– 申請するときにもgroupIdの申請が必要です。Sonatypeに申請するときはベースになるドメイン名で申請する必要があります。例えば、「org.mikeneck」は大丈夫ですが、「mikeneck」というgroupIdでは駄目です。<artifactId>– ライブラリーの名前ですね。<version>– バージョン番号です。なお、1.0.0-SNAPSHOTというようなSNAPSHOTというバージョンはSonatypeではmaven central repoには乗せてくれませんの、注意して下さい。<packaging>– 基本的にはjarです。<name>– プロジェクトの名前です。<description>– ライブラリーに関する情報です。何をしてくれるライブラリーであるかを記述します。<url>– プロジェクトのurlを設定します。<licenses>– ライセンスに関する情報を設定します。中には下記の情報が一つ以上入っていることが求められます。<license><name>– ライセンス名(ApacheライセンスとかLGPLとか)<license><url>– ライセンス条項のurlを記述します<license><distribution>–repoを設定します。<scm><url>– レポジトリーのurlを記述します。git-hubの場合はsshのアドレス設定します。bitbucketのMercurialの場合はレポジトリーをWebで見る場合のurlを記述します。<scm><connection>– git-hubであればsshのところで得られるurlの先頭にscm:git:を加えます。bitbucketのMercurialの場合はWebで見る場合のアドレスの先頭にscm:hg:を付与します。<developers>– 開発者情報を記入します。その中の構成は次のとおりです。<developer><id>– 開発者のID。通名とかでも良いようです。僕の場合はmike_neckを記入します。<developer><name>– 開発者の名前です。僕の場合はShinya Mochidaになります。<developer><email>– 開発者のメールアドレスです。僕の場合はmike <at> mikeneck.orgとしています。
配布するファイルへの規約
<packaging>がjarの場合にはjarファイルにはjavaクラスが入っていること- 名前が
projectname-version-javadoc.jarというjavadocのjarが入っていること - 名前が
projectname-version-sources.jarというソースのjarが入っていること - すべてのartifact(
pom.xml、projectname-version.jar、projectname-version-javadoc.jar、projectname-version-sources.jar)に対してPGPによる署名がなされていること - 公開鍵が公開鍵サーバーから取得可能になっていること
となっています。
また、何らかの理由でjavadocのjarやsourcesのjarが作られない場合でも、READMEというファイルを含んだjavadocのjarよsourcesのjarを作る必要があります。
gradleでmaven centralにアップロードするためのbuild.gradle
では、サンプルのbuild.gradleをここに上げておきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 | |
また、よく使いまわす変数についてはgradle.propertiesに書いておきます。
1 2 3 | |
また、署名関連の変数などについては~/.gradle/gradle.propertiesに書いておきます。
1 2 3 4 5 6 7 8 | |
あとは、gradleコマンドでuploadArchivesを記述すれば、
Sonatypeの方にアップロードされます。
1
| |
なお、事前にSonatypeでのJIRAでissueを登録しておくことや、
Nexus UIで最終的なステージング操作をする必要があります。
参考までに、僕が以前作ったissueのリンクを張っておきます。
OSSRH-4119 request for creating repository for Graffiti-mike
中盤終わり
gradleであそぶコーナー
TBDと書きたいのですが…
上記の古いgradleでのアーカイブアップロードの方法は、
やや難点があります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 | |
uploadArchivesのところを見ると、
archives configurationに登録されているすべてのartifactsをアップロードする
と書かれています。
ただ、これだと、ひとつのアップロードしか書いていくことができないので、
非常に面倒です。
たとえば、こういった局面があります。
- in-houseリポジトリーにも登録する
- maven centralにも登録する
- 異なるartifactsをアップロードする
- dependenciesにトリッキーなことをしているので、dependenciesの記述を書き換えたい
こういったケースでは、
一つ一つ別々のタスクとして記述をしていかないとできない場合があります。
gradleは柔軟性も求めるツールなので、
これらの要望も吸収して
簡単な記述でできるように常に進化を遂げています。
それを満たす機能が、今回のテーマのmaven-publishプラグインです。
maven-publishプラグインではarchives configuration以外の成果物も
柔軟に発行できますし、依存性を書き換えることもできます。
記述はこんな感じになります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 | |
上記の例でやっていることは
- ドキュメント読まないのでclassesとsourcesだけをアーカイブ化
- ちろっとpom.xmlに情報を追加
- dependenciesを書き換え
一般常識的に考えれば、dependenciesの書き換えはマズイと思われますが…
某有名なライブラリーのpom.xmlでありもしないartifactを参照しているライブラリーがあり、
compile configurationではプロジェクトのdependencyを指定するのではなく、
1 2 3 | |
と異なるconfigurationを設定して、
プロジェクトのdependencyを設定する場合などがあります。
某有名ライブラリーとはorg.eclipse.jetty:jetty-serverというんですけどね…
さて、もう少し遊んでいるんですが、
それは別の記事にしますね。