1. これであなたもOSS開発者！
Mavenセントラルリポジトリに
自作ライブラリをUPするときの
いろんなコツの話
@nabedge = 渡辺 祐 http://mixer2.org/
2014/2/15 2014/4/5 第５回 #渋谷java

2. CM
2

3. Mixer2というライブラリを作ってる者です
http://mixer2.org
JavaでWebアプリを作るための
テンプレートエンジン
3

4. CMおわり
4

5. 今日のおはなし
• Mixer2というテンプレートエンジンって
すごい便利なんだぜ
• 例えばMixer2みたいなJavaライブラリ
（本体は *.jar ファイル一つ）を
Mavenセントラルリポジトリに登録する
にはどんなふうにしたらいいの？
5

6. つまりこんなふうに
6
http://repo1.maven.org/maven2/org/mixer2/mixer2/1.2.22

7. 論より証拠！
いまこの場で、
Mixer2-1.2.xxの
mavenセントラルリポジトリへの
リリース作業を開始します。
7
デモ

8. さっきのデモみたいな流れに至るまでのコツ
• 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を参考に。

9. • pom.xmlを調整する
• <groupId>, <artifactId>,親pomの指定
• GPG鍵とmaven-gpg-plugin
• *.md5, *.sha1 チェックサムはmaven-install-plugin
• maven-souces-plugin, maven-javadoc-plugin
• アップロード権限をもらうための申請
• Mixer2の場合はどうだった？
• ビルドとリリースに関する3つのポイント
• 仮想OS + Jenkinsを使う
• maven-release-pluginのことを忘れる
• 細かいバージョン番号を自分で決めない
9

10. アップロード権限をもらう
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

11. 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. • pom.xmlを調整する
• <groupId>, <artifactId>,親pomの指定
• GPG鍵とmaven-gpg-plugin
• *.md5, *.sha1 チェックサムはmaven-install-plugin
• maven-souces-plugin, maven-javadoc-plugin
• アップロード権限をもらうための申請
• Mixer2の場合はどうだった？
• ビルドとリリースに関する3つのポイント
• 仮想OS + Jenkinsを使う
• maven-release-pluginのことを忘れる
• 細かいバージョン番号を自分で決めない
12

13. なぜ仮想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. • pom.xmlを調整する
• <groupId>, <artifactId>,親pomの指定
• GPG鍵とmaven-gpg-plugin
• *.md5, *.sha1 チェックサムはmaven-install-plugin
• maven-souces-plugin, maven-javadoc-plugin
• アップロード権限をもらうための申請
• Mixer2の場合はどうだった？
• ビルドとリリースに関する3つのポイント
• 仮想OS + Jenkinsを使う
• maven-release-pluginのことを忘れる
• 細かいバージョン番号を自分で決めない
14

15. maven-release-pluginのことを忘れる
1. mvn release:prepare release:perform のように簡単
なコマンド一発にできるが、pom.xmlがややこしくなり
がち。
2. どうせjenkinsを使うのだから、pom.xmlにややこしい設
定を書く代わりにビルドジョブ上にUNIXコマンドを書く
ようにするほうがわかりやすい＆メンテしやすい。
3. 「maven-release-pluginは、-SNAPSHOTなversion指
定が自分自身や依存先に指定されていないかまで
チェックしてくれるんだぜ！」
→そういうのも最近はセントラルリポジトリ（のステージ
ング環境）にUPする段階で自動チェックしてくれるから
必ずしも自分でやらなくてもいい。
15

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

17. • pom.xmlを調整する
• <groupId>, <artifactId>,親pomの指定
• GPG鍵とmaven-gpg-plugin
• *.md5, *.sha1 チェックサムはmaven-install-plugin
• maven-souces-plugin, maven-javadoc-plugin
• アップロード権限をもらうための申請
• Mixer2の場合はどうだった？
• ビルドとリリースに関する3つのポイント
• 仮想OS + Jenkinsを使う
• maven-release-pluginのことを忘れる
• 細かいバージョン番号を自分で決めない
17

18. よくあるバージョン番号の考え方
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

19. バージョン番号の固定観念を捨ててみる
「trunk（開発の本線）のpom.xmlはずっと
<version>1.0-SNAPSHOT</version>
のまま」
というルールにしてしまう！
1. それで開発してて、意外と困らない。
2. trunk配下のpom.xmlの<version>を
リリースのたびに書き換える面倒は無くなる
3. リリースのときに<version>1.2.3</version>に書
き換えてtagを切るのはセオリーどおりで。
19

20. 細かいバージョン番号を自分で決めない
versions-maven-pluginでpom.xmlの
<version>1.2-SNAPSHOT</version>を
<version>1.2.3</version>
に自動書き換え。
20
mvn versions:set –DnewVersion=1.2.${BUILD_NUMBER}

21. ${BUILD_NUMBER} ??
21
${BUILD_NUMBER}
version 1.2.22の
ビルド履歴ココ

22. ビルド失敗＝バージョン番号が飛ぶ＝気にしない
version 1.2.22 の
次のリリースが
1.2.30 だと
何か困ることが
あるか？
たぶん無い。
22
欠番
欠番
実際リリース
したバージョン

23. <version>を整えたらあとはデプロイ
23
mvn clean deploy
-Dgpg.keyname=[自分のgpg鍵id]
-Dgpg.passphrase=[gpg鍵のパスフレーズ]

24. 全体の流れ
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. おまけ：パスワードはマスク
25
Jenkins Maskpasswords Plugin

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