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

今日のおはなし
•  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を参考に。

•  *.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
　　　　↓　　　　　リリース→ tags/1.0.1
•  リリースタグを切るときに<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

More Related Content

What's hot

More from Y Watanabe