Hudson と Mercurial を利用した Maven 成果物のリリース管理

たまには何か書かないと PV が増えないので、今回は HudsonMercurial を利用した Maven 成果物 (artifact) のリリース管理について書いてみたいと思います。

ご存じの方もいるかと思いますが、私は OSSRH を利用して Maven Central Respository に Java 系成果物を公開しています。一例としては Google Login Plugin for Hudson とかですね。

ところで、Maven にはバージョンの末尾に -SNAPSHOT が付くと、リリース前のスナップショットとして扱われるという慣例があります。例えばバージョン X.Y-SNAPSHOT はバージョン X.Y より前のスナップショットという意味になり、Maven のリポジトリーでも別枠となります。

さてここまでを前置きとして、今回紹介するのは Hudson と Mercurial を利用して、成果物のリリースを半自動化してしまう手法です。

Hudson の使い方については別途調べてもらうとして、Hudson を使うことで Maven 成果物のデプロイ (deploy) までは自動化可能です。スナップショットの段階なら Hudson が新しいリビジョンを見つけるたびに自動デプロイしても何ら問題はありませんが、正式のリリースとなるとそうも言っていられません。

一応 OSSRH にステージング機能があるので、デプロイしてもいきなりリリースされることはないのですが、リリースしないものは破棄しなければなりませんので、リリース バージョンの自動デプロイは極力減らしたいところです。

そこで活用するのが Mercurial のブックマークです。例えばブックマーク release-candidate をリリース用のブランチに作成して、Hudson ではこのブックマークを追跡して自動デプロイするようにジョブを作っておきます。こうすると release-candidate の移動に伴ってリリース候補が OSSRH のステージング領域に自動デプロイされることになりますので、リリース OK となったら最後のリリース候補をリリースして残りを破棄すればリリース完了という流れです。

注意点としては、一旦リリースしたら次のリリースまでブックマークを移動しない (つまり自動デプロイしない) ようにすることでしょうか。Git でもブランチの移動を工夫すれば同様のことは可能だと思いますので、ぜひ試してみてください。

RAD Studio アプリケーションのローカライズ

RAD Studio アプリケーションのローカライズに使うリソース DLL プロジェクトについてなのですが、フォルダーに XLIFF 形式のファイルが作られるので、Transifex のような外部サービスを使って翻訳できるのかと思ったら、全く読み込んでくれませんでしたね。リソース DLL プロジェクトは RAD Studio コマンド プロンプトから MSBuild を使ってビルドすることもできませんし、全く困ったものです。

Jenkins 用 RAD Studio Plugin

過去記事を調べてみたらブログには書いてなかったことに気づいたので、改めて RAD Studio Plugin を紹介しておきます。

このプラグインの機能は、RAD Studio (Delphi もしくは C++Builder) のプロジェクトを簡単にビルドできるようにするだけです。必要な環境変数の設定は RAD Studio コマンド プロンプト用のバッチファイルから読み取るので、RAD Studio 各バージョンのインストール先をそれぞれ設定しておけば、ビルドに利用するバージョンを選択して、プロジェクトファイルと MSBuild のコマンド スイッチを指定するだけで、ビルドすることができます。もうバッチ ファイルで細工する必要ありません。

もし役に立つと感じたら、フィードバックをいただけるとありがたいです。

Jenkins 用 Tool Labels Plugin

先日の RAD Studio Plugin に続き、調子に乗って Tool Labels Plugin を公開いたしました。

このプラグインの機能は、インストール済みツールによりノードに動的にラベルを追加するというものです。ツールのインストール有無によりビルドを実行するノードを限定するのが目的で製作しました。

実を言えば、RAD Studio Plugin の新機能として企画していたのですが、他のツールにも使えることに気づいて、急遽 独立したプラグインに仕立てたものなのですけどね。例えば、RAD Studio XE7 に bds15.0 というラベルを付けておくと、インストール済みノードに動的にこのラベルが付くので、ビルドを実行するノードを限定するのに使えるようになる訳です。

便利だと感じたらフィードバックをいただけるとありがたいです。

IPv6 ソケット API プログラミングの基礎知識 (シリーズ第 2 回)

IPv6 ソケット API を使うための構造体を紹介した前回に続きまして、第 2 回はサーバーでは必須となる特定ポートへのバインドの基本的なやり方について書いてみます。

まず、sockaddr_in6 構造体を用意しなくてはなりませんが、今回はよく利用されるバインドするアドレスを指定しないやり方を扱うことにします。一般的なソケット API プログラミングと同様に <netinet/in.h> ヘッダーをインクルードすると (前回は書きましたっけ? ^^;)、in6addr_any オブジェクトを利用することができます。

const struct in6_addr in6addr_any;

このオブジェクトは IPv4 での INADDR_ANY に相当するものですが、IPv6 では構造体になので少しばかり勝手が異なります。例としてはこのように使います:

#include <netinet/in.h>
#include <arpa/inet.h> /* htons のため */

#define PORT ポート番号

int bind_in6_example1(int socket_fd) {
    struct sockaddr_in6 sa = {0}; /* 全メンバーを 0 に初期化 */
    sa.sin6_family = AF_INET6;
    sa.sin6_port = htohs(PORT);
    sa.sin6_flowinfo = 0; /* 初期化済みなので実際には不要 */
    sa.sin6_addr = in6addr_any;
    sa.sin6_scope_id = 0; /* 初期化済みなので実際には不要 */
    return bind(socket_fd, (const struct sockaddr *) &sa,
            sizeof (struct sockaddr_in6));
}

in6addr_any はオブジェクトですが、初期化子として利用する場合のために IN6ADDR_ANY_INIT マクロも用意されています。C99 で導入された記法を使うと、例えば次のように書くことができます:

#include <netinet/in.h>
#include <arpa/inet.h> /* for htons */

#define PORT ポート番号

static const struct sockaddr_in6 sa_init = {
    .sin6_family = AF_INET6,
    .sin6_flowinfo = 0, /* 暗黙的に初期化されるので実際には不要 */
    .sin6_addr = INADDR6_ANY_INIT,
    .sin6_scope_id = 0, /* 暗黙的に初期化されるので実際には不要 */
};

int bind_in6_example2(int socket_fd) {
    struct sockaddr_in6 sa = sa_init;
    sa.sin6_port = htohs(PORT);
    return bind(socket_fd, (const struct sockaddr *) &sa,
            sizeof (struct sockaddr_in6));
}

IPv4 の INADDR_ANY とは違って、初期化と代入で書き方が異なることに注目してくださいね。

それでは第 2 回はここまでです。例によって次回も期待しないで待っていてください。

IPv6 ソケット API プログラミングの基礎知識 (シリーズ第 1 回)

xllmnrd を製作する過程で習得した IPv6 ソケット API に関する知見を、少しずつ書いていこうという不定期連載企画です。反応が薄ければ うやむやにするかもしれませんが…。

さて記念すべき第 1 回ですが、まずは sockaddr_in6 構造体の紹介で始めたいと思います。IPv4 の sockaddr_in 構造体に対応するものですが、この構造体には以下のメンバーがあります (OS によっては他のメンバーがあることもありますが ここでは触れません):

sa_family_t sin6_family;
アドレスファミリーです。IPv6 では AF_INET6 を指定します。
in_port_t sin6_port;
ポート番号です。IPv4 と同様にネットワーク バイト オーダーで指定します。
uint32_t sin6_flowinfo;
これは IPv6 に特有のメンバーで、トラフィック クラスとフロー情報を指定します。とりあえず 0 としておきましょう。
struct in6_addr sin6_addr;
お待ちかね、IPv6 アドレスです。in6_addr 構造体については後述します。
uint32_t sin6_scope_id;
これも IPv6 に特有のメンバーで、スコープ ID を指定します。スコープを指定する必要がない場合は 0 としておきます。

IPv6 アドレスを指定する in6_addr 構造体には以下のメンバーがあります:

uint8_t s6_addr[16];
IPv6 アドレスをバイト列で指定します。IPv4 とは違ってバイト列なので、バイト オーダーは意識する必要がありません。

第 1 回はここまでにしておきます。次回はいつになるか分かりませんが、期待しないで待っていてください。

Java SE 8 の非互換性

まず Java SE 7 の java.lang.refrect.TypeVariable と Java SE 8 の java.lang.refrect.TypeVariable を比べてほしい。簡潔に書けば Java SE 8 で getAnnotatedBounds() が追加されたことが分かるはずである。

このように既存のインターフェースにメソッドが追加された場合、このインターフェースを実装するクラスはそのままでは Java SE 8 でコンパイルできなくなってしまう。通常なら追加されたメソッドの実装を追加すれば解決するのであるが、ここで getAnnotatedBounds() の戻り型 AnnotatedType[] に注目してほしい。java.lang.reflect.AnnotatedType は Java SE 8 で追加されたので、Java SE 7 には存在していない。つまり getAnnotatedBounds() を実装してしまうと Java SE 7 ではもうコンパイルできなくなってしまうのである。何という非互換性だろうか。

本来なら新しいメソッドを追加した別のインターフェースを追加するか、Java SE 7 のクラス実装のままでもコンパイル可能なようにデフォルト メソッドを提供するべきだったのでしょうが、そこまで気が回らなかったんでしょうかねえ。

 

GlassFish 構成の紹介

せっかく Jenkins が復旧したことなので、このサイトで使っている GlassFish の構成を紹介してみようと思います。

まず GlassFish の「ドメイン」には管理サーバーがあるわけですが、これは表に出していません。管理サーバーとは別にクラスター インスタンスと今回新たに追加したスタンドアローン インスタンスがそれぞれ別の java プロセスで動作していています。それぞれのインスタンスには AJP (mod_jk) 対応のリスナーが追加してあり、フロントエンドの Web サーバーから間接的にアクセスするように設定しています。

結局 3 個の Java プロセスが動いているということになるわけですが、運用の勉強のつもりで動かしているクラスターは、実際にクラスターを組めるほどのインスタンス数がないので、将来的にはスタンドアローン インスタンスに一元化してしまうかもしれません。