できたぁ。
torque.isAvailableHotDeploy = true とすると、
basicInfoMap.dfpropでisAvailableHotDeploy = trueとすると、
dbflute-creator.dicon と dbflute-customizer.diconができます。
creator.dicon で dbflute-creator.dicon をincludeでできあがり。
ソースの出力先をRootPackage配下に置くこと。ただ、これだけだと...LinkageErrorの嵐...
強引Loadで回避しても次から次へとLinkageError。Behavior/Dao以外のDicon登録している独自Classを削除しても発生。
(しかし、そのときLinkageError発生Classは別のClassになります)なので、NamingConventionでallcommonだけIgnore指定としました。
すると、万事うまくいきました。
ConditionBeanすらもHotDeployClassLoaderがきっちり読んでいます。というわけで現状：
「NamingConventionでallcommonだけIgnoreにすることで可能」
(allcommonだけRootPackageの外へ配置もOK)どうやらInterfaceとかは、DBFluteが拡張しているS2DaoのClassたちが
利用しているため、WebappClassLoaderに読まれてしまうのかと。
S2DaoInteceptorとかDaoMetaDataImplとかDaoMetaDataFactoryImplとか。
これらInteceptorや拡張クラスもCreatorで作ればallcommonも
HotDeployにできるだろうか？とりあえず、
Creator自体は非常に便利なものとわかったので、
Creatorの限界を知る上でも検討してみるのもいいかな！？
(RootPackage以外のPackageにもCreatorを使ってRegistしたいくらい
→ HotDeployに関係なくCreator + CustomizerでComponent登録したいくらい)補足：
allcommonはHotDeployである必要性はないのだが、
「newする側される側両方ともHotDeployClassLoaderで読まれていれば...」
というのがあるので、できればHotDeployClassLoaderに読まれるようにしたい。DBFluteとして、HotDeploy機能を正式Supportするのは、
・この辺(allcommonの扱い)の問題
・Dolteng(拡張)によるcreator.diconとかのサポート
が解決してからとなります。
でないと結構環境周りの色んなエラーがでてユーザが大変です(玄人向け機能!?)。
(Doltengで生成された既存のdaoCustomizerは消さないとエラーになったりとか)
