私は OSGI と Karaf の上にアプリケーションを構築することに決めました - 私はこれが本当に好きです。ただし、ローカルの開発マシンでの毎日の展開には少し苦労しています。つまり..変更を加えてから、ローカルの Karaf インスタンスでテストしたいと思います。そして、それは1時間に数回発生する可能性があります。
私が現在行っている方法は、JAR バンドルを作成し、Karaf の deploy ディレクトリにコピーする Maven ビルドです。決してエレガントではないと思います。
私は回避策を見つけようとしていました（グーグル）。Karaf の機能について読みましたが、アプリ全体を展開するための優れたメカニズムであるという事実にもかかわらず、私の問題は解決されないようです。私が正しく理解しているように、SNAPSHOT jar の新しいバージョンがローカルの Maven リポジトリに表示されたかどうかはチェックされませんよね?
karaf の更新メカニズムを機能させるための鍵は、デプロイ フォルダーを使用する代わりに、maven からデプロイすることです。次のようにバンドルをインストールします。
install -s mvn:groupid/artifactID/version
また
install -s mvn:groupid/artifactID/version/typeOfMavenArtifact
2 つ目は、たとえば war/wab アーティファクトのインストールに役立ちます。完全な Maven プロトコル仕様は、ここにあります。
その後、Karaf はバンドルがどこから来たのかを知っています。を使用して確認することもできますla -u。これにより、karaf は更新場所を表示します。これは現在、maven uri である必要があります。すべての karaf バンドルにこのような更新場所があるわけではありません。
Maven を使用してプロジェクトの新しいビルドを作成すると、最終的にローカルの Maven リポジトリになります。次に、単に実行します
update <bundleid>
これにより、karaf は更新場所 (この場合はローカルの Maven リポジトリ) をチェックし、そこからバンドルをリロードします。
を使用して、これをさらに自動化することもできます
dev:watch
またはkaraf 3+の場合
bundle:watch
これにより、karaf はデプロイした SNAPSHOT バンドルの変更について Maven リポジトリをチェックし、これらを自動的に再デプロイします。
これは、リモート デバッグと組み合わせても非常にうまく機能します。使用する
export KARAF_DEBUG=true
カラフを始める前に。次に、ポート 5005 でデバッガーをリッスンします。
その後、同じポートでリモート デバッグ Eclipse セッションを開始し、karaf でアプリケーションを適切にデバッグできます。上記のアプローチのいずれかを使用してバンドルを変更した場合でも、これは非常にうまく機能します。したがって、デバッグし、問題を見つけ、コードを変更し、ビルドして、変更されたバージョンでデバッグを続けることができます。
これは、karaf 独自のバンドルのほとんどでも機能するため、karaf コード ベース自体で作業するときにも頻繁に使用します。