2015-03-12

個人/社内 Maven Repository を作る

Scala sbt

オープンソースの Scala ライブラリは sonatype を経由して Maven Central にデプロイするのが定番となっています。Maven Central のアカウントを持っていない、とかクローズドにしておきたい、などの理由から自前で Maven リポジトリを持ちたくなることがあるでしょう。

Maven リポジトリはなんとなくセットアップが面倒そうに思われていそうですが、実際には Web サーバ上にルールに従ってファイルが配置されているだけです。Artifactory や Nexus などの管理ツールもありますが、それらをインストールしなくとも簡単にセットアップが可能です。

例えば、gh-pages をリポジトリにしている人はたまに見かけます。自分も Sonatype のアカウントを作る前はそうしていました。それから svn リポジトリに jar を突っ込み、それを web 上に公開している人もいます。そういう風にリポジトリを公開するには、まず自分のローカルに Maven リポジトリを作り、それをアップロードする、という手順を踏みます。

自分のローカルにリポジトリを作るのがめんどうな場合は、WebDAV や scp を利用して、直接 Web 上のリポジトリにライブラリをデプロイすることも可能です。今回は WebDAV を使うことにしました。

まずは Web サーバの設定です。これは簡単で、WebDAV を有効にするだけです。Apache であれば次のような設定となります。 http://mvnrepo がリポジトリの URL です。

<VirtualHost *:80>
  Servername mvnrepo
  DocumentRoot /var/www/mvnrepo
  DavLockDB /var/lock/apache2/DavLock
  DAVMinTimeout 600
  <Location />
    DAV On
  </Location>
</VirtualHost>

リポジトリができたら、リリース用のディレクトリとスナップショット用のディレクトリを切りましょう。例えば、リリース用のディレクトリは http://mvnrepo/releases, スナップショット用のディレクトリは http://mvnrepo/snapshots という風にします。

次に、build.sbt に設定を追加します。

// Maven スタイルでデプロイする
publishMavenStyle := true

// テストは含めない
publishArtifact in Test := false

// 他のリポジトリのライブラリに依存することを許容する設定
pomIncludeRepository := { _ => false }

// リポジトリの設定
// SNAPSHOT バージョンであれば、http://mvnrepo/snapshots に
// リリースバージョンであれば、http://mvnrepo/releases にデプロイする
publishTo := {
  val inhouse = "http://mvnrepo/"
  if (version.value.trim.endsWith("SNAPSHOT"))
    Some("inhouse snapshots" at inhouse + "snapshots")
  else
    Some("inhouse releases"  at inhouse + "releases")
}

他に pomExtra の設定などもありますが、Maven Central ではないのでなくてもデプロイできるので割愛します。

さて、これであとは publish コマンドを打つだけですが、一つ問題があります。 sbt の問題か、sbt が依存するライブラリの問題かはわかりませんが、デプロイをするとき、パスの途中のディレクトリを作ってくれないのです。たとえば com.example という group_id で hello というライブラリの scala 2.11.x 用のバージョン 0.1.0 をデプロイしようとすると、その配置ディレクトリは /releases/com/example/hello_2.11/0.1.0/ ですが、このディレクトリを作る処理をせず、いきなりファイルを配置しようとするため、エラーが発生してしまいます。

これを避けるためには、自分で WebDAV の MKCOL リクエストを送る必要があります。もしくは Apache ではなく nginx を使って、create_full_put_path の設定を on にします。

今回は諸事情により、Apache を使うことになったので、自前で MKCOL を打つことになりますが、そんなことはやってられないので、解決策を探したところ、webdav4sbt という sbt プラグインを見つけました。このプラグインをインストールすると、sbt が publish の前に MKCOL リクエストを送ってくれるようになります。

しかし残念ながらこのライブラリはメンテナンスされておらず、ダウンロードもできない状態だったので Fork しました。scala 2.11 対応させ、名前も sbt-automkcol という風に変えました。

https://github.com/tototoshi/sbt-automkcol

注: 以下、情報が古くなっているのでGitHubのREADMEを参照してください

project/plugins.sbt に

addSbtPlugin("com.github.tototoshi" % "sbt-automkcol" % "1.5.1")

build.sbt に

import com.github.tototoshi.sbt.automkcol.Plugin._

AutoMkcol.globalSettings

と設定してください。

Apache の認証情報は ~/.sbt/0.13/build.sbt に書きます。

credentials += Credentials("inhouse maven repository", "mvnrepo", "user", "password")

これで Apache の場合でもデプロイができるようになります。

Maven リポジトリのセットアップ方法を紹介しましたが、オープンソースのライブラリであれば sonatype のアカウントを手にいれるなどして、Maven Central へデプロイすることを強くお勧めします。野良リポジトリの多くはいつのまにか管理されなくなり、ライブラリがダウンロードできなくなっているというのをよく見かけるからです。今回 Fork した webdav4sbt もリポジトリがなくなっていました。その点 Maven Central にデプロイすれば削除できないのでライブラリが消えることもありませんし、sbt に resolver の設定を追加する必要もありません。

2015-03-02

Flyway プラグインを Play 2.4 対応しました

Play Scala

<a href="https://github.com/flyway/flyway-play">flyway/flyway-play</a>

Play 2.1-2.3 向けにサードパーティプラグインとして play-flyway を開発してきましたが、少し前に Flyway の GitHub Organization に加えてもらい、めでたく公式モジュールとなりました。groupId も com.github.tototoshi から org.flywaydb になりました。

Play 2.4 はまだ final がリリースされてないのでまだスナップショット版ですが、今の最新である Play 2.4-M2 向けにビルドしたものをリリースしておきました。

build.sbt に

resolvers +=
  "Sonatype OSS Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots"

libraryDependencies +=
  "org.flywaydb" %% "flyway-play" % "2.0.0-SNAPSHOT"

と書いた上で、conf/play.plugins ではなく、conf/application.conf に

play.modules.enabled += "org.flywaydb.play.PlayModule"

と書くと有効になります。そのほかは今までの play-flyway と同様です。

2015-02-11

Ansible を使ってみた感想

Ansible

ここ数日 Ansible を触ってみてた。 MoinMoin Wiki のセットアップとか試しにやってみた。

tototoshi/ansible-playbook-moinmoin · GitHub

Chef の代替というよりも Chef + Capistrano/Fabric という感じ。

インストールが楽。設定ファイルもほとんどなし。
デフォルトでできることが多い。Apache の Basic 認証設定とか PostgreSQL のユーザー作成とかまで最初っから使えるのが良い。
ドキュメントが充実しているしサンプルも併記してくれていて親切。
あまりハマらない。

シンプルで良いツールだと思った。

yaml なので簡単なことは簡単にかけるけれど、手続きっぽいことを書くのは当然つらい。そこは仕方ないかというところ。まあ数日使った程度ではそこまで困ることはなかった。

シェルスクリプトでは手続きを書くのに対し、こういうツールでは冪等性うんぬんってやつでどんな状態に収束するかを書くので、 yaml で宣言的に書くほうが向いている（という都合の良い見方）。

あと一つ一つの記述は宣言的だけど、それでいて処理は上からべたーっと順番に行われるのはわかりやすい。

うまく動いてくれないなーって思ったのが handlers。難しいものではないんだけれど、試行錯誤しているうちに間接的な原因で意図通りに発火してくれないことがある。notify 書き忘れとかもあるし普通に最後に明示的に reload,restart とかしたほうがシンプルかも。

Chef はいろいろめんどくせーと思ってやらなかったけど Ansible ならイケると思ったし、おいしいところだけ使うで十分得られるものが多そう。簡単なのでまだ試してない人も一度触ってみると良いんじゃないかな。

2015-02-02

IntelliJ IDEA を無料で使う方法

Scala Java

IntelliJ IDEA は Community Edition であれば無料で使えますが、 Ultimate Edition になると大体初期２万＋維持費１万／年くらいの課金をする必要があります。

機能比較

これをどう見るかは人によると思いますが、自分は Scala はほとんど Emacs で書いてしまって、たまに気分で IntelliJ IDEA を使うくらいのノリなので少し高く感じています。

しかし、実は Ultimate Edition をタダで使う方法が存在します。Open Source License というヤツです。

IntelliJ IDEA 14.x Open Source License

Open Source License はオープンソースのプロジェクトの開発に使用できるライセンスです。ライセンスの発行には審査が必要です。条件は、

プロジェクトのリーダー、または常にコミットしていること
プロジェクトがオープンソースの定義を満たしていること
資金援助などを受けていないこと
アクティブに開発されていること
コミュニティがアクティブであること
ウェブサイトを持っていること
定期的にリリースがされていること

と、一見厳しそうですが、コミュニティとかウェブサイトがどうとかは GitHub のリポジトリや issues がその役目を果たしますし、規模とかはあまり関係なく、真面目に開発してる感さえあれば大丈夫だと思います。

というわけで、今回は tototoshi/scala-csv で申請してライセンスを発行してもらえました。ライセンスの発行には大体数日必要らしいですが、以前 PhpStorm のライセンスを tototoshi/staticmock に対して発行してもらったときは１ヶ月くらいかかった（絶対忘れてただろ）ので気長に待ちましょう。

Open Source License の有効期間は１年で、更新のときは期限切れの直前にメールでお願いする必要があるようです。

というわけで、自信のない人もとりあえず申請してみればよいと思います。JetBrains もそれなりに儲けてそうだし皆さんがタダで使っても潰れないでしょう。

追記: はてぶコメントで補足してくれてる方がいますが、仕事には使えないので会社に Commercial License を買ってもらいましょう

2015-01-31

build.sbt の変更を検知する sbt プラグインを作りました

Scala sbt

git でブランチを切り替えたらうまくビルドできなくなって困ったけど、build.sbt が変わっているのに sbt の reload をするのを忘れていただけだった、ということがたまに起こります。これを防ぐために、.sbt や project/.scala が変更されていたら警告を表示する sbt プラグインを作りました。

tototoshi/sbt-build-files-watcher

作りました、というかよしださんの https://gist.github.com/xuwei-k/6278769 をだいたいパクった感じです。

インストールはプロジェクトごとに設定するよりはグローバルの設定にすると便利だと思います。

~/.sbt/0.13/plugins/build.sbt

addSbtPlugin("com.github.tototoshi" % "sbt-build-files-watcher" % "0.1.1")

~/.sbt/0.13/build.sbt

showMessageOnBuildFilesChanged

sbt-git などを使っている場合は showMessageOnBuildFilesChanged が sbt-git のshowCurrentGitBranch とぶつかるので messageOnBuildFilesChanged という関数を使って shellPrompt キーを設定します。

shellPrompt := { state =>
  messageOnBuildFilesChanged(state) + GitCommand.prompt(state)
}

これで .sbt や project/.scala を編集すると reload しろという警告が出るようになります。めでたし。

f:id:tototoshi:20150131000659p:plain

2015-01-27

Flyway は複数人での開発に向かないという誤解について

Flyway Java Scala

“データベースマイグレーションについて考えないといけないことや諦めないといけないことが結構あるでよ” http://t.co/BYna6w5luj 期待して記事見たが、複数人開発時におけるバージョン番号の衝突について説明がなかったのが残念。紙面が限られてるししゃあない。
— 早すぎる最適化オジサン (@makotokuwata) 2014, 12月 29

flyway って､V1_ みたいな prefix をつけるけど､integer を increment するのって､ブランチきって平行で開発してる場合どうなるの?という気がしている
— tokuhirom (@tokuhirom) 2014, 7月 30

flywayのマイグレーションについて見てたけど、これ、バージョン番号をファイル名につける感じなのですかね。まだよく見てないが。Railsのマイグレーションと比べて複数人開発に強くないですねぇ。
— でこくん (@dekokun) 2013, 3月 26

というように、Flyway は複数人開発に向かないという噂をたまに聞くのですが、多分誤解です。

誤解が生まれるのは公式ドキュメントで Flyway のマイグレーションスクリプトのファイル名として、V1__Add_new_table.sql みたいなファイル名が例に出されており、これが V2__、V3__ のような名前をつける必要があるという印象を与えるためかと思われます。

ドキュメントを良く読むと、バージョンのルールは

One or more numeric parts
Separated by a dot (.) or an underscore (_)
Underscores are replaced by dots at runtime
Leading zeroes are ignored in each part

なので、もう少し柔軟です。だから rails のようにタイムスタンプベースのファイル名付けちゃえば良いです。

sql
├── V20150127114055__create_user_table.sql
├── V20150127114322__add_country_column.sql
└── V20150127114323__add_age_column.sql

このようにタイムスタンプベースのバージョン付けを行うとブランチをマージしたときなどに順番が狂うという問題が発生しますが、 outOfOrder という設定があるのでこいつを on にしてやれば OK です。

WEB+DB PRESS VOL.84 の Flyway の記事にもなかったので書いてみました。

2015-01-20

play-json で snake_case な json を camelCase な case class にマッピングする

Play Scala

play-json を使えば json を case class にマッピングすることは簡単にできますが、json のキーがそのまま case class のフィールドに対応するため、snake_case な json API を case class にマッピングするためには、case class のフィールドも snake_case にする必要があります。Scala は camelCase にするのが主流ですから少し気持ち悪いですね。

snake_case な json を camelCase な case class にマッピングするためには、いつも使っている Json.format[T] のラッパーを作る必要があります。作りました。

tototoshi/play-json-naming · GitHub

build.sbt に

libraryDependencies += "com.github.tototoshi" %% "play-json-naming" % "0.1.0"

して使ってください。

使い方は、JsonNaming.snakecase を呼び出すだけの単機能ライブラリです。

import com.github.tototoshi.play.json.JsonNaming

case class Name(firstName: String, lastName: String)
case class User(id: Int, nameData: Name)

// Json.format[T] をラップする
implicit val nameFormat = JsonNaming.snakecase(Json.format[Name])
implicit val userFormat = JsonNaming.snakecase(Json.format[User])

val jsonString = """{"id":1,"name_data":{"first_name":"Toshiyuki","last_name":"Takahashi"}}"""

Json.parse(jsonString).validate[User]
Json.toJson(User(1, Name("Toshiyuki", "Takahashi")))

イメージとしては

          +---------------+
          |  json string  |
          +---------------+
                 ⇅  
          +---------------+
          |    JsValue    |
          +---------------+
                 ⇅  JsonNaming.snakecase
          +---------------+
          |    JsValue    |
          +---------------+
                 ⇅  
          +---------------+
          |  case class   |
          +---------------+

こんなかんじで、json の内部表現である JsValue に対して変換をかけています。

snake_case 以外にもよくある規則があれば取り込みますので pull-req ください。