移行 _project.shのjava_HOME

DBFluteクライアントのメンテ？
そもそも _project.shとは？
java_HOME調整の移行

DBFluteクライアントのメンテ？

DBFluteランタイムやDBFluteエンジンはアップグレードされても、DBFluteクライアントはアップグレードされません。アプリの情報を保存しておく場所なので、基本的にはそれで問題ありません。

ただ、何年も続くプロジェクトだと大昔のDBFluteで作ったDBFluteクライアントが時々ギャップになることもあるかもしれないので、その代表的な例を一つお話します。

(最新のDBFluteにアップグレードしたときに、DBFluteクライアントの最新テンプレートとアプリのものを比べる習慣があると理想ではあります)

そもそも _project.shとは？

MacやLinuxなどシェルベースのOSにて manage.sh を実行する時に、真っ先に呼び出されるファイルです。 DBFluteタスクをシェルから実行する上で必要な設定がされます。

e.g. _project.sh @Shell
#!/bin/bash

export ANT_OPTS=-Xmx512m

export DBFLUTE_HOME=../mydbflute/dbflute-1.2.6

export MY_PROPERTIES_PATH=build.properties

java_VERSION=1.8+

# auto-setting for java_HOME (keeping exiting java_HOME)
if [[ -z "${java_HOME}" ]]; then
  if [[ `uname` = "Darwin" ]]; then
    export java_HOME=$(/usr/libexec/java_home -v ${java_VERSION})
  fi
fi

Apache Ant のメモリ設定
DBFluteエンジンの場所
内部propertiesの名前
java_HOMEの調整 (DBFluteエンジンが実行されるjavaのバージョンを決める)

内部的なものが多いですが、アプリ側で一番意識する可能性があるのは、java_HOMEでしょう。

java_HOME調整の移行

java_HOMEの調整部分は、昔と変わっている部分があります。

昔の書き方

以前は、"Macだったらjava8を使う" になっていました。 (ただし、java8がなければ無視されます)

e.g. 昔の_project.shのjava_HOME調整 @Shell
if [ `uname` = "Darwin" ]; then
  export java_HOME=$(/usr/libexec/java_home -v 1.8)
fi

これは、開発者のPCにまだ java6,7 が入ってることが多い時代、java8版のDBFluteがjava6,7で実行されないようにするためのものでした。 java6,7の時代は過ぎても、DBFluteをjava8で実行するのは一番マッチしているので、この処理はそのまま利用されていました。

ただ、今度はjava8が開発者のPCに入っていないケースも多くなってきました。PC上のjava_HOMEも開発プロジェクトに合わせた(より新しい)javaが指定されていることも多くなりました。

ですが、昔の調整処理だと、PC上のjava_HOMEを無視してjava8を指定してしまいます。 java8がたまたま入っている人はjava8で動き、そうでない人は別のjavaのバージョンで実行されます。

それでも、ほとんどの場合は問題ありませんが、時々実行するjavaのバージョンの違いで結果が変わってしまう可能性もあるので、それで不都合が生じることもあります。

今の書き方

いまは、"java_HOMEが設定されてなくてMacだったらjava8以上を使う" になります。

e.g. 今の_project.shのjava_HOME調整 @Shell
java_VERSION=1.8+

# auto-setting for java_HOME (keeping exiting java_HOME)
if [[ -z "${java_HOME}" ]]; then
  if [[ `uname` = "Darwin" ]]; then
    export java_HOME=$(/usr/libexec/java_home -v ${java_VERSION})
  fi
fi

つまり、すでにPCで既存のjava_HOMEが設定されていれば、それを優先するということです。

開発プロジェクトがjava8よりも新しいjavaバージョンを使っていて、開発者みんなでjava_HOMEを合わせているのであれば、こちらの調整の方がバージョン違い可能性は減ります。

ゆえに、もし既存のDBFluteクライアントの_project.shが、昔の書き方になっているのであれば、今の書き方も修正することを検討しても良いでしょう。

アプリ独自の書き方

開発者同士でPC上のjava_HOMEを統一してるわけではないけどjava8より新しいバージョンで統一したい...とかであれば逆に昔の書き方でjavaのバージョンだけ変えてベタッと強制させても良いでしょう。

e.g. アプリで独自に_project.shのjava_HOME調整 @Shell
if [ `uname` = "Darwin" ]; then
  export java_HOME=$(/usr/libexec/java_home -v 17)
fi

ただし、アプリのjavaのバージョンがアップされたときに、こちらも修正し忘れないようにしましょう。 (忘れても大抵は問題ないでしょうが、結局みんなでバージョンがバラバラになる可能性があります)

このように、開発現場の都合に合わせてうまくjava_HOMEを調整してもOKです。ベストプラクティスは現場次第です。