プラグイン フレームワーク アプローチ
ホットコードスワッピングが必要だと述べましたが、実際に必要なのは疎結合モジュールと実行時に解決する機能です。率直に言って、成熟した OSGi (以下で説明します) を含め、どのプラグイン フレームワークも役立つ可能性があります。

あなたはある種の PoC を行っているので、次の例を確認することをお勧めします。
- いくつかの拡張ポイント (メタファーの説明) が定義されたメタ アプリケーションがあります。
- アップグレードまたは置換される機能は、疎結合モジュール (プラグイン) として実装されます。
- メタ アプリケーションは、(定義された拡張ポイントに従って) 更新された「機能」を見つけるために、要求によって、または自動的に解決を実行します。
単純なアップグレード シナリオを定義することを提案できます。
- ユーザーがアプリケーションを使用する
- ユーザーは、1 つまたは複数の拡張ポイントの新しい実装を含む JAR (他のタイプのバンドル) をインストール (コピー) します。
- ユーザーが新しい更新のグローバル システム解決またはシステム スキャンをトリガーするか、ユーザーが何らかの機能にアクセスしようとするたびにシステムが解決を実行する
このようにして、メタ アプリケーションは再起動せずに新しい機能または更新された機能を提供できます。だからあなたはできる:
- いくつかの単純な Java プラグイン フレームワーク (たとえば、Java Simple Plugin Framework など) を使用してみてください。5 分で動作します。XML はありません。このアプローチは少し醜いようです。
- ここで提案されているように、clojure の動的な性質を使用する
また、Waterfront (Clojure 用の Clojure ベースのエディター) の調査結果を確認して採用することもできます (ライフサイクル管理の強化などに必要になる場合があります)。
実装に関しては、Waterfront はコンテキスト パターンに基づいています。これにより、イベント ハンドラーが機能的な (副作用のない) 方法で通信できるようになります。これに加えて、Waterfront の構成ファイルで指定されたプラグインをロードするプラグイン ローダー メカニズムがあります。これは、機能を簡単に追加または削除できることを意味します (デバッグ時に非常に便利です!)。
OSGI アプローチ
提案されたように、OSGi は問題を解決する良い方法のようです。また、OSGi は優れており、成熟しており、すぐに使用できる多くの機能を提供しますが、多少複雑でもあることに注意してください。

ところで、OSGi は clojure コミュニティの長期的な目標です。Clojure Todoを確認できます:
> better modularization for OSGi etc
> * names
> * no single namespace pool
> * namespaces found via classes, thus tracks classloader and modules
> * deal with import proxying a la Class.forName stack walk?
すでに利用可能なソリューションがいくつかあります。
- clojure-osgi-utils
- clojure.osgi
2 番目のプロジェクトは、clojure と OSGi を使用した Producer-Consumer の例を提供します。
ハッピーコーディング。