【概要】
現状は、BehaviorやEntityと共にフレームワークも自動生成している。
それはまさしくallcommonパッケージのクラスである。

メリット：
　・デバッグ作業がしやすい
　・仕組みの理解に役に立つ
　・依存ライブラリが少なくシンプル

デメリット：
　A. コンパイルスピードの劣化
　B. mydbfluteのSVNコミット・更新が遅い
　C. パッケージエクスプローラでバァァッ
　D. 複数DB構成時に別パッケージ同名クラス名がたくさん
　E. フレームワーク内部のメンテコストが高い

「A」はクラス数が多いからである。
「B」はテンプレートファイルが多いからである。
「C」はパッケージ構成が多いからである。

「D」は以前から課題で、今の構成の一番弱いところである。
プレフィックスを付けることを推奨しているが、それでも
紛らわしいこともあるし、プレフィックスを付けたくない人も多くいるだろう。

「E」は将来的にSpring対応(*1)やLucy対応する際に今の構成は足枷となる。
S2ContainerやS2DaoのJARがなくても動作するようにするには、
ある程度の処理の補完をしなければならないが、Velocityのテンプレートのまま
それをやるのはかなりキツイ（それは実質無理）。

*1:
今でのSpringで動作するが、S2ContainerのJARファイルと
その周辺JARが必要であり、実際のところ現実的でない。

【構成】
allcommonパッケージのクラスを以下の二つに分類：
　・JARファイルへ
　・自動生成対象(そのまま)

自動生成対象は以下のクラス：

【自動生成対象】
　o allcommon.BuriDef *When using Buri Only
　o allcommon.CacheBehaviorSelector
　o allcommon.CDef
　o allcommon.DBCurrent
　o allcommon.DBFluteConfig
　o allcommon.EntityDefinedCommonColumn
　o allcommon.DBFluteInitializer
　o allcommon.ImplementedCommonColumnAutoSetupper (implements CommonColumnAutoSetupper)
　o allcommon.ImplementedInvokerAssistant (implements InvokerAssistant)
　o allcommon.ImplementedSqlClauseCreator (implements SqlClauseCreator)
　o allcommon.dbmeta.DBMetaInstanceHandler (implements DBMetaProvider)

DBFluteのJARファイルを追加する代わりにS2DaoのJARファイルを
利用しないようする。依存を外すために幾つかの処理を補完する。

o BeanMetaData
o (Sql)Node
o もろもろのインターフェース

【タスク】
＜依存関係の整理＞
allcommon配下の依存関係を明確にしておくことが大事。
そのため0.8.8にて上記の構成を満たす依存関係の整理をする。
　→ ☆既に実施 (InternalBindVariableUtilだけ0.8.8.2より)

＜JARプロジェクトの作成＞
dbflute-basic-exampleで生成したプロジェクトをコピーしてそのままJARプロジェクトに。
自動生成対象のクラスをsrc/test/javaに持っていくことでそのままテスト環境とする。
　→ ☆これから
　→ ☆プロジェクトだけ作ってみた

リファクタリングを公開前に行うべきであるが、
ユーザが利用する可能性のあるクラスのクラス名は変えない。
主に修正するのはパッケージである。
(どのみち全てのクラスがパッケージが変わるので)
ひとまずのリファクタリング候補：

o s2daoパッケージ配下のPrefixとパッケージ構造
o outsidesqlパッケージをcbeanから独立
o MapString系のクラスのパッケージ構造
o ConditionBeanSetupperとEntityListSetupperのパッケージ
o PagingResultBeanやListResultBeanのパッケージ
o ...その他検討中

＜テンプレートの修正＞
JARファイル対象クラスは除去。
自動生成対象クラスからJARファイル対象クラスへの参照(import文)を修正。
(自動生成したクラスをEclipseで「インポートの編成」を一括でやってテンプレートへ反映)

＜JARのMaven化＞
Mavenから利用できるようにインフラ的に準備をする。
確定でないがSeasarのMavenリポジトリを利用予定。

＜EMechaの改良＞
構成が変わるということで、環境的な煩雑な面を
できるだけプラグイン支援でどうにかしたい。
（内容は要検討）
そもそも改良したい機能もある：
DBFLUTE-400
DBFLUTE-401
DBFLUTE-402
※Viliでのサポートを考えると、JARファイル化を先にやったほうがよいかも！？
　→ ☆JARファイル化を先にやる(Viliにて既に上記の機能を入れてもらえそう)

＜セットアップドキュメントの修正＞
DBFluteのサイトとGihyo.jpのサイト。
(Gihyo.jpは要相談)

＜Spring対応・Lucy対応＞
同時タイミングである必要はないので、
このIssueとしてはオプションタスク。
解決しなければならないライブラリの洗い出し：

o BeanDesc
o PropertyDesc
o ValueType
o ResultSetWrapper
o OgnlUtil
o もろもろのインターフェース

【マイルストーン】
2009年1月に「0.8.8」をリリース。
依存関係の整理だけされた現状と同じ構成のバージョンとして安定版を目指す。
バグは「0.8.8.x」で対応することとする。(場合によって「0.8.9」も利用する)

その後、EMechaの改良を粛々と。。。

2009年x月に安定した「0.8.8.x」で自動生成したallcommonパッケージを基に
JARプロジェクトの作成をする。そして、その後のタスクをこなす。

2009年y月にEMechaと共に「0.9.0」をリリース。
Spring対応・Lucy対応と共に出すかはまだ未定。