20140405 mavenセントラルリポジトリへの登録のコツ第5回渋谷java

これであなたもOSS開発者！ Mavenセントラルリポジトリに自作ライブラリをUPするときのいろんなコツの話

@nabedge = 渡辺祐 http://mixer2.org/

2014/2/15 2014/4/5 第５回 #渋谷java

Mixer2というライブラリを作ってる者です

http://mixer2.org

JavaでWebアプリを作るためのテンプレートエンジン

3

CMおわり

4

今日のおはなし

•  Mixer2というテンプレートエンジンってすごい便利なんだぜ

•  例えばMixer2みたいなJavaライブラリ（本体は *.jar ファイル一つ）を Mavenセントラルリポジトリに登録するにはどんなふうにしたらいいの？

5

つまりこんなふうに

6

http://repo1.maven.org/maven2/org/mixer2/mixer2/1.2.22

論より証拠！

いまこの場で、 Mixer2-1.2.xxの mavenセントラルリポジトリへのリリース作業を開始します。

7

デモ

さっきのデモみたいな流れに至るまでのコツ

•  pom.xmlを調整する •  <groupId>, <artifactId>,親pomの指定 •  GPG鍵とmaven-gpg-plugin •  *.md5/*.sha1チェックサムはmaven-install-plugin •  maven-sources-plugin, maven-javadoc-plugin

•  アップロード権限をもらうための申請

•  Mixer2の場合はどうだった？ •  ビルドとリリースに関する3つのポイント

•  仮想OS + Jenkinsを使う •  maven-release-pluginのことを忘れる •  細かいバージョン番号を自分で決めない

8

今日の話はここだけ

各自ググるあるいは mixer2のpomを参考に。

•  pom.xmlを調整する •  <groupId>, <artifactId>,親pomの指定 •  GPG鍵とmaven-gpg-plugin •  *.md5, *.sha1 チェックサムはmaven-install-plugin •  maven-souces-plugin, maven-javadoc-plugin




9

アップロード権限をもらう

1.  大きなプロジェクトでは自前のリポジトリサーバをセントラルリポジトリサーバが直接rsyncしてくれる。

例： Apache Commons Project 例： Spring Framework Project

2.  小さいプロジェクトの場合は http://oss.sonatype.org に直接アップする。

1.  申請すれば<groupId>ごとにアップロード権限をくれる。例：アカウント”nabedge”は<groupId>org.mxier2</groupId>の配下ならどんなartifactでも登録可能

2.  とりあえず本家の解説を一生懸命読みましょう。 https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide 10

Mixer2の場合はどうだった？

1.  mixer2.org というドメイン名を取得 2.  http://mixer2.org/ にあらかじめmaven siteで作ったページ

を用意。もちろん<groupId>はorg.mixer2

3.  自分のメールアドレスでgpg鍵つくって鍵サーバに登録

4.  pom.xmlを調整

5.  mvn deploy するとステージングリポジトリにUPされる

6.  3で使ったメールアドレスでSonatypeのJIRAにアカウント登録＆チケットを作成。

7.  すんなりリポジトリへのアクセス権をくれた。

8.  NEXUSにJIRAアカウントでログインし、ステージング状態のartifactをリリースするとセントラルリポジトリへ反映される

※以降のリリースでは5と8の作業だけでよい。 11





12

なぜ仮想OS + Jenkinsでやるのか

1.  ビルド＆リリースに使うコマンドやその実行手順を間違えない

2.  ビルドした記録と成果物を保存しやすい

3.  異なるJDK/JREでのmvn testを実行しやすい

•  mixer2はJRE同梱のJAXB実装に依存している。 Java6とJava7とでJAXB実装のバージョンが微妙に異なる。

•  なので、Java7でのmvn testもいつでもやれるようになってる。

4.  確実に環境を一定に保てる

5.  バックアップしやすい

•  「ソースはgithubに入ってるから大丈夫」では甘い。

•  JDK/JRE環境、gpg署名用の秘密鍵、ビルドジョブの設定（≒ビルドとリリースの手順そのもの）、過去の成果物、etcetc…

•  ↑うっかり失うと再構築が面倒くさいという意味でダメージ大 •  仮想OSのイメージファイルで丸ごとバックアップしてしまえ！

13





14

maven-release-pluginのことを忘れる

1.  mvn release:prepare release:perform のように簡単なコマンド一発にできるが、pom.xmlがややこしくなりがち。

2.  どうせjenkinsを使うのだから、pom.xmlにややこしい設定を書く代わりにビルドジョブ上にUNIXコマンドを書くようにするほうがわかりやすい＆メンテしやすい。

3.  「maven-release-pluginは、-SNAPSHOTなversion指定が自分自身や依存先に指定されていないかまでチェックしてくれるんだぜ！」

→そういうのも最近はセントラルリポジトリ（のステージング環境）にUPする段階で自動チェックしてくれるから必ずしも自分でやらなくてもいい。

15

•  「maven-release-pluginを使うな」とは言ってません。 •  人間、慣れている方法が一番！

16





17

よくあるバージョン番号の考え方

trunk/1.0.0-SNAPSHOT

　　　　↓　　　　　リリース→ tags/1.0.0

trunk/1.0.1-SNAPSHOT

　　　　↓　　　　　リリース→ tags/1.0.1

trunk/1.0.2-SNAPSHOT •  リリースタグを切るときに<version>を書き換える。

（これは当然）

•  trunk側も<version>を書き変える必要あるの？

18

バージョン番号の固定観念を捨ててみる

「trunk（開発の本線）のpom.xmlはずっと <version>1.0-SNAPSHOT</version> のまま」というルールにしてしまう！

1.  それで開発してて、意外と困らない。

2.  trunk配下のpom.xmlの<version>をリリースのたびに書き換える面倒は無くなる

3.  リリースのときに<version>1.2.3</version>に書き換えてtagを切るのはセオリーどおりで。

19

細かいバージョン番号を自分で決めない

versions-maven-pluginでpom.xmlの <version>1.2-SNAPSHOT</version>を <version>1.2.3</version> に自動書き換え。

20

mvn versions:set –DnewVersion=1.2.${BUILD_NUMBER}

${BUILD_NUMBER} ??

21

${BUILD_NUMBER}

version 1.2.22のビルド履歴ココ

ビルド失敗＝バージョン番号が飛ぶ＝気にしない

version 1.2.22 の次のリリースが1.2.30 だと何か困ることがあるか？たぶん無い。

22

欠番

欠番

実際リリースしたバージョン

<version>を整えたらあとはデプロイ

23

mvn clean deploy -Dgpg.keyname=[自分のgpg鍵id] -Dgpg.passphrase=[gpg鍵のパスフレーズ]

全体の流れ

24

mvn versions:set –DnewVersion=1.2.${BUILD_NUMBER}

mvn clean deploy -Dgpg.keyname=[自分のgpg鍵id] -Dgpg.passphrase=gpg鍵のパスフレーズ

Git/Subversionにタグを切る ※タイミングは最後じゃないほうがいいかも。 ※下のコマンドはマネしないで！ git commitせずにgit tagしてる（いい加減すぎw）

おまけ：パスワードはマスク

25

Jenkins Maskpasswords Plugin

おしまい

ご清聴ありがとうございました！

26

20140405 mavenセントラルリポジトリへの登録のコツ 第5回渋谷java

Technology

20140405 mavenセントラルリポジトリへの登録のコツ第5回渋谷java