dbflute成果物をjarで管理する。

Toolとして使用する場合だけではなく、
プロダクトとして利用する場合も、「開発中」には適応できるかもしれませんね。
（当然リリースもDB機能をまとめてjarにしてしまうというのも当然ありかもしれませんが。）

gensrcと、jarについては、生成担当者が管理し、
開発者はgensrcから該当部分をソースフォルダにコピーしてロジックを追加していく。
そっちはjarとしてではなく、ソースとして管理していく。（色んなひとがいじることが想定されるため。）

※切り分けとしては、allcommonとかに手を入れるような場合は、jarとして管理でもよいかも。

何よりもメリットは、
ちょっと時間がかかる処理が、jarを作る人だけに絞られる。
というのと、見通しがよくなるという点。

また、正確な計測とはいえませんが、
ソースで管理した場合、
テストとして、ConditionBean#toDisplayStringを表示するだけのメソッド実行に関して、
1分40秒かかり、
jarの場合、30秒程度で済んだりもしました。

※しつこいようですが、正確な計測とはいえません。
そのときの、ログからの割り出しです。
ただ、まぁ体感的にもその位の差はあります。
※ソースのコンパイルではなく、コンパイル後の実行に関する話です。
コンパイルは・・・orz

デメリットは、結局はいじるBhvなどを探してコピーするところ。
さらに、ついうっかり「移動」とかやらかす人がいそう
といったところでしょうか。

あとはjarもでかくなり、かつ、gensrcもソース管理するとなると容量的な問題。
（些細な問題だが）

ちなみに前述の
buildにはソースを含むようにしているが、
gensrcがあるので最悪含まなくてもよいかも。

さらに、0.7.6以降からは
torque.isSkipGenerateIfSameFile = true
と設定すると、差分なしは生成対象とならないため、
コンパイル時に差分コンパイルとなり、リソース消費を抑えられるので
積極的に利用する。