Hatena::ブログ(Diary)

Fly me to the Juno! このページをアンテナに追加 RSSフィード

2012-08-22

github pagesにmvn site-deployする。

githubにmaven3のプラグインやらなんやらを公開し、使う事が増えてきたので、github pagesにmvn siteの内容をデプロイしてみたので、そのメモをまとめる。

GitHub Pagesに「手動」でgh-pagesブランチを公開する。

AdminページのAutomatic Page Generatorを押して作成すると、gh-pagesを更新しても公開されているコンテンツは公開されなかった。もう一度Automatic Page Generatorを押すと、生成したページの編集ページが開く。なので、優先順位みたいなものがあるかもしれない。https://help.github.com/articles/creating-project-pages-manually を参考に空のgh-pagesブランチを作成し、pushする。

$ cd repo

$ git checkout --orphan gh-pages
# 親ブランチを持たない(orphan)gh-pagesブランチを作り、gh-pagesに切り替える。

git rm -rf .
# ワーキングツリーの内容を削除する
$ echo "My GitHub Page" > index.html
$ git add .
$ git commit -a -m "First pages commit"
$ git push origin gh-pages

pom.xmlに下記の操作を行う

<build>のmaven-site-pluginの設定にwagon-gitsiteを追加する。
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-site-plugin</artifactId>
        <version>3.1</version>
        <configuration>
          <locales>en</locales>
        </configuration>
        <dependencies>
          <dependency>
            <groupId>com.github.stephenc.wagon</groupId>
            <artifactId>wagon-gitsite</artifactId>
            <version>0.4.1</version>
          </dependency>
          <dependency>
            <groupId>org.apache.maven.doxia</groupId>
            <artifactId>doxia-module-markdown</artifactId>
            <version>1.3</version>
          </dependency>
        </dependencies>
      </plugin>

doxia-module-markdownは、追加するとsrc/site/markdown以下に*.mdファイルを置くとMarkdown形式として処理してくれるので便利!

<distributeManagement><site>の設定を改める。
  <distributionManagement>
    <repository>
      <id>kompiro.org</id>
      <name>kompiro.org repoisitory</name>
      <url>scp://kompiro.org/home/kompiro/kompiro.org/maven</url>
    </repository>
    <site>
      <id>github</id>
      <url>gitsite:git@github.com/kompiro/notification-maven-plugin.git</url> 
    </site>
  </distributionManagement>

2011-06-19

Jenkins Maven Repository Server Pluginが簡単すぎて鼻血でた。

Maven3になり、Eclipseプラグインも安心してビルドできる、ってのもあって、最近Mavenでビルドする事が増えてきています。JenkinsでCIを回してるんですが、別立てでApacheを立てたりするの面倒じゃないですか。で、そういうのを解決するプラグインないか探してみたらありましたわよ奥様。

Jenkins Maven Repository Server - Jenkins - Jenkins Wikiでございます。

使い方は簡単です。Jenkinsのプラグイン管理画面からJenkins Maven Repository Serverプラグインをインストールすると、あら不思議。

[JenkinsのURL]/project/repository/everything

の下にJenkinsでビルドしている成果物全てのMaven Repositoryができているではありませんか。例えば先日のtraineing.assertライブラリをビルドした結果はこんなかんじ。

http://build.kompiro.org/plugin/repository/everything/

プロジェクトやビルドごとにもリポジトリを参照できるようなので、お試し下さい。

2008-05-01

MavenにおけるISO-8859-1阻止祭りに感じる違和感

http://d.hatena.ne.jp/kkawa/20080425/p1

最初に言っちゃいますが、僕はMavenユーザーではありません。それからJavaのRuntimeについての詳しい仕様に関してはまったくの無知とほぼ等価です。ただ、ネットイナゴよろしく、日本人だらけのコメントと、その論調を見ているとどうしようもなく違和感を感じていたので、AKYで行きたいと思います。

この提案の目的って何だっけ?

すいません。Mavenの提案をもう一度見直してみてください。

Mavenの各Pluginごとにソースのエンコードを指定するのって面倒だよね。
じゃ、Pluginごとのソースのを統一するためのプロパティを一個追加しておいて、
各Pluginはこの設定をデフォルトのソースエンコーディングとして参照できるようにしようか。
そして、今んところ各PluginでデフォルトのエンコーディングとしてISO-8859-1を指定しているものも多いみたいだし、
とりあえずISO-8859-1をデフォルトにしてみようか。

って僕の拙い英文読解力は読み取ったんす。間違った解釈ですかね。

pom.xmlを書いていたのは2年くらい前なので、すっかり忘れているので、試しにSeasar2のpom.xmlを覗いてみたんです。たしかにソースのエンコード指定のUTF-8が点在しているのが見受けられますね。「あー、メンドッチー」じゃないでしょうか。これ一括で指定できないの?何で?って思いませんか?とりあえず、ISO-8859-1をデフォルトとして指定されているPluginも既にあるわけですよ。少なくとも現行でもそいつはエンコードを指定しないと動かせないわけです。この提案が通れば、一ヶ所エンコードを指定すればすべてのPluginに設定する必要がなくなりますよね。

じゃUTF-8をデフォルトにすれば解決すんの?

少なくともソースのエンコーディングにUTF-8を使っているプロジェクトの場合、システムエンコーディングがUTF-8のプラットフォームってモダンなLinuxくらいだったりするから、Seasar2プロジェクトのようにどのプラットフォームにも依存しないようにUTF-8をpom.xmlに指定しておいてあるんじゃないですかね。

あー、そういえばできる限りMavenプロジェクトの移植性を高めたいということもこの提案の目的の一つだった気がするんす。UTF-8ってどの環境のJDKでも必ずサポートされているんですかね。リソースの少ない組み込み系Javaのランタイム環境でも必須なんすかね。あー、考慮しないといけないのは開発の方であって、クラスを実行する環境(ランタイム)じゃないから関係ないのか。

で、どんなプロジェクトに影響があるんだろ。

なんとなーく被害を被ると想像したのは、ソースのエンコーディングについて特に考えていなくて、プロジェクトの開発環境のポータビリティ(どんなOSでも開発できるよ!って意味でのポータビリティ)についても考えていない環境ではなかろうかと思うんですよ。そういうちょっとバランスの悪い環境でもMavenって使われてるのかなー、と。

どっちにしろ思うのは

他のアジア圏のMavenユーザーの声を聞いてみたいですね。僕はMavenユーザーではないですが、自分の管理しているEclipseのPlugin開発プロジェクトではエンコードを指定するように気をつけてます。いろんな環境で開発したいので。だからいっそのことエンコード指定を必須にしてしまえ!という案には結構賛成です。そうするとMavenのハードルをさらに上げる気もしますが、最初にMavenプロジェクト作るときのコマンドで、pom.xmlにエンコード指定がさりげなくされた状態になっててくれればいいんじゃないかと思うんですが、どうすかね。あ、でも既存のプロジェクトで困るプロジェクトが結構ありそうだというのがこの祭りの発端か。じゃ、Maven3にてこの提案が採用!とかだったら既存のプロジェクトには影響なさそうですね。

2008-01-29

EclipseのPlugin開発するためのMavenがないわけを考えてみた。

今から二年近く前。自分のプロジェクトとして初めてEclipse RCPを作ろうと思い立ったとき、当時は自分も便利そうだし、使った事のなかったMaven2を使ってプラグインの開発環境を作ろうと思いました。しかし、その当時もどーしてもやれませんでした。今に至ってもMaven2を使ってプラグインを開発しているという話は聞いたことがありません。この程一通り自動ビルド、テスト環境を作ってみて、なんでMaven2のプラグインにEclipseビルド用のプラグインがないか、語れそうな気がしてきたので、書いてみます。

Maven2を使う理由は主に、pom.xmlライブラリ名を書くと、依存するライブラリを自動で引っ張ってきてくれるという機能ではないでしょうか。この仕組みの相性がそもそもよろしくないです。

Eclipseのプラグインに組み込むライブラリは、各プラグインの中に入れることもできますが、他のプラグインからも利用できるように別のプラグインとして切り出しておく事が多いです。現にEclipse IDEにはAntやluceneなどApacheプロジェクトの成果物がプラグインが組み込まれていますが、これらは特定のプラグインにライブラリとして導入されているわけではありません。そうしておくことにより、Eclipse IDEの開発者以外の開発者からも同じライブラリをプラグイン開発に利用できるように開放しています。Eclipseの各プロジェクトで利用するライブラリを管理するためのプロジェクトとしてOrbit | The Eclipse Foundationがあります。

また、プラグイン同士の依存はマニフェストファイル(META-INF/MANIFEST.MF)に記述しますが、pom.xmlにも記述しないとならないとなると情報が重複します。pom.xmlに記述している情報とマニフェストファイルに記述している内容を管理する必要が出てきます。これだけで全然うれしくないですよね。

また、Maven2に用意されているゴールですが、ほぼすべてのものが既存の環境、つまりアプリケーションを構成するクラスローダーが一つの環境で動作するものばかりではないでしょうか。OSGiのように、プラグイン(Bundle)ごとにクラスローダーが用意されている環境で動作できるゴールを僕は知りません。(Maven Bundle PluginっていうOSGi環境を構築するためのMaven2プラグインがあるってことは知ってますが、使ったことありません。OSGi環境といってもFelixであって、Equinoxではないのでプラグイン開発環境に使えるかは、未知数です。)Testや、Packageなどのゴールを使えないのだとしたらMaven2を使う理由はどこなんでしょうか。

Eclipse ProjectにはArchived Projects | The Eclipse FoundationというEclipseプラットフォーム上で動作するアプリケーションを構築するためのプロジェクトがあります。このプロジェクトには10年以上びるだーの仕事を経験したまいすたーがたくさんいるわけですよ。ShellスクリプトやらAntスクリプトやらバッチなどが書けるメンバーだらけなわけなので、Maven2を使わないでも全然いけちゃうメンバーだらけな訳です。それにプラグイン開発者からしてみればEclipse上でほとんどすべての作業ができる(自動化除く)ので、Maven2みたいなコンソールを叩く作業が流行らなかったのかなと思います。

そんな感じなのでMaven2を使ったEclipse Plugin開発が行われないのかなと思いました。なお、依存するライブラリを自動で解決する件ですが、Equinox Provisioning(通称p2)というプロジェクトが現在走ってます。このプロジェクトでは特定のリポジトリにつないで、利用したいライブラリを選択すると、自動的にそれに付随するライブラリをダウンロードできる環境を目指して開発が進んでいるようなので、Maven2を使った場合よりも便利な環境が出きるんじゃないかと僕は期待してます。(今のところ中を追っかけてみたい気もしてますが、そこまで手を回せてません。)

関連エントリー

Equinox Provisioning (通称 p2) - Fly me to the Juno!