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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

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

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

Más de Y Watanabe

Más de Y Watanabe (16)

Último

Último (12)