20140405 mavenセントラルリポジトリへの登録のコツ 第5回渋谷java
Post on 27-May-2015
4.168 Views
Preview:
TRANSCRIPT
これであなたもOSS開発者! Mavenセントラルリポジトリに 自作ライブラリをUPするときの いろんなコツの話
@nabedge = 渡辺 祐 http://mixer2.org/
2014/2/15 2014/4/5 第5回 #渋谷java
CM
2
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
• アップロード権限をもらうための申請
• Mixer2の場合はどうだった? • ビルドとリリースに関する3つのポイント
• 仮想OS + Jenkinsを使う • maven-release-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
• 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
なぜ仮想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
• 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
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
• 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
よくあるバージョン番号の考え方
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
top related