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

6,543 views

Published on

Published in: Technology

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

  1. 1. これであなたもOSS開発者! Mavenセントラルリポジトリに 自作ライブラリをUPするときの いろんなコツの話 @nabedge = 渡辺 祐 http://mixer2.org/ 2014/2/15 2014/4/5 第5回 #渋谷java
  2. 2. CM 2
  3. 3. Mixer2というライブラリを作ってる者です http://mixer2.org JavaでWebアプリを作るための テンプレートエンジン 3
  4. 4. CMおわり 4
  5. 5. 今日のおはなし •  Mixer2というテンプレートエンジンって すごい便利なんだぜ •  例えばMixer2みたいなJavaライブラリ (本体は *.jar ファイル一つ)を Mavenセントラルリポジトリに登録する にはどんなふうにしたらいいの? 5
  6. 6. つまりこんなふうに 6 http://repo1.maven.org/maven2/org/mixer2/mixer2/1.2.22
  7. 7. 論より証拠! いまこの場で、 Mixer2-1.2.xxの mavenセントラルリポジトリへの リリース作業を開始します。 7 デモ
  8. 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. 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. 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. 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. 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. 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. 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. 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. 16. •  「maven-release-pluginを使うな」 とは言ってません。 •  人間、慣れている方法が一番! 16
  17. 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. 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. 19. バージョン番号の固定観念を捨ててみる 「trunk(開発の本線)のpom.xmlはずっと <version>1.0-SNAPSHOT</version> のまま」 というルールにしてしまう! 1.  それで開発してて、意外と困らない。 2.  trunk配下のpom.xmlの<version>を リリースのたびに書き換える面倒は無くなる 3.  リリースのときに<version>1.2.3</version>に書 き換えてtagを切るのはセオリーどおりで。 19
  20. 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. 21. ${BUILD_NUMBER} ?? 21 ${BUILD_NUMBER} version 1.2.22の ビルド履歴ココ
  22. 22. ビルド失敗=バージョン番号が飛ぶ=気にしない version 1.2.22 の 次のリリースが 1.2.30 だと 何か困ることが あるか? たぶん無い。 22 欠番 欠番 実際リリース したバージョン
  23. 23. <version>を整えたらあとはデプロイ 23 mvn clean deploy -Dgpg.keyname=[自分のgpg鍵id] -Dgpg.passphrase=[gpg鍵のパスフレーズ]
  24. 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. おまけ:パスワードはマスク 25 Jenkins Maskpasswords Plugin
  26. 26. おしまい ご清聴ありがとうございました! 26

×