Ant に加えて、サブプロジェクトを含むプロジェクトをサポートし、Eclipse プロジェクトを生成および維持するためのプラグインを備えた Maven を使用することもできます。Hibernate のものを 1 つの JAR サブプロジェクトにしてから、2 つのサイトをすべて POM ベース プロジェクトの下にある WAR プロジェクトにすることができます。
これを手動で行う場合は、デバッガーが機能するようにプロジェクトを IDE 内でフックすることをお勧めします。
注意点: Hibernate JAR を Hibernate のみにする場合、基本的に同じ DB を指す 2 つの Hibernate を実行することになり、そのままでは機能しません。問題は、デフォルトを購入すると、Hibernate が DB を制御し、多くのキャッシュを実行することを好みます。したがって、たとえば、ドメイン オブジェクトを 1 回読み込んだ後、別のコードで同じオブジェクトを読み込んだ場合、理論的には、Hibernate はオブジェクトが既にキャッシュされているかどうかを確認し、キャッシュされている場合はそれを使用します。最終的に、2 つの Hibernate が同じテーブルのセットに対して読み取りと書き込みを行っている場合、それらは簡単に同期しなくなる可能性があります。
この問題を回避する方法はいくつかあります。1 つの方法は、読み取りが共有キャッシュをチェックするように、2 つの間で共有キャッシュをセットアップすることです。これは、同じコードが複数のアプリ サーバーで実行されているが、すべてが同じテーブルにアクセスしているクラスター化された環境がある場合の典型的なアプローチです。ここでの欠点は、セットアップがより複雑になることです。
もう 1 つのアプローチは、Hibernate をより偏執的になるように構成することです。これは通常、バッチ プロセスなど、アプリの外部の何かがテーブルに書き込むことができる状況にある場合に行われます。Hibernate は、キャッシュされた読み取りを無視し、書き込みの前にバージョン チェックを行うように構成できます。ここでの欠点は、いくつか、場合によっては多く、またはパフォーマンスを放棄していることです。
最後の方法は、スタンドアロン アプリケーションとして動作するコードにアクセスするためのサービス レイヤーを作成することです。これをどのように行うかは、何に慣れているか、どのように統合したいか、および考慮しなければならないアーキテクチャ上の決定に大きく依存します。このアプローチでは、隠れて Hibernate を使用するサービス層を作成し、Web アプリが使用できる「API」を公開します。API は、JMS (すべてのコードが同じアプリケーション サーバーで実行されている場合に推奨)、RESTful または非 RESTful Web サービス、さらには RMI や CORBA などのリモート メソッド呼び出しメカニズムからの任意のものにすることができます。実装によっては、これにより、将来的にアプリケーションを拡張する機能が実際に追加されます。