問題タブ [spring-boot-maven-plugin]

スプリング ブート バージョンを 1.3.2 から 1.4.0 にアップグレードして、@MockBean アノテーションを使用して単体テストで Bean をモックできるようにしましたが、プロジェクト全体で「インポートをタイプコンパイルに解決できません」というエラーがまだ残っているためです。 、しかし、私はEclipseからmavenプロジェクトの依存関係を更新し、ファイルシステムからリポジトリフォルダーを削除し、mavenがそれを再ダウンロードできるようにしましたが、無駄でした.

ところで、コマンドラインmavenコマンド「mvn clean install」からプロジェクトをクリーンアップしてインストールできます。

アイデアはありますか？

編集

Spring クラウドの依存関係のバージョンを Brixton.BUILD-SNAPSHOT から Brixton.SR5 に変更しました。これにより、クラウドのインポートと @EnableDiscoveryClient アノテーションの問題は解決しましたが、依存関係の問題はまだあります。

次のエラーがあります

エラーメッセージはタイムアウトの問題であることを示しているようですが、他のすべてのjarと依存関係がダウンロードされ、インターネット接続は非常に良好で、コンパイルエラーなしでmavenコマンドラインからビルドできました.

以下の問題に約1週間苦労しましたが、同じ問題を抱えている人を見つけることができません。

以下に示すように、いくつかのサブモジュールで構築された Maven プロジェクトがあります。

B と C の統合テストでは、統合テストの前に WAR を実行し、統合テストの後に停止する spring-boot-maven-plugin を使用しています。

子モジュールに移動して「mvn verify」を実行しても問題ありません。ただし、親モジュールで「mvn verify」を実行すると、子 A と B は合格しますが、静的コンテンツと JSP ページが見つからないため、子 C は失敗します。

Maven が子モジュールからではなく親モジュールからアプリケーションを実行するため、リソースと WEB-INF フォルダーが何らかの理由で tomcat によって見つからないという事実による問題だと思います。

たとえば、親プロジェクトで次のコマンドを実行します。

子 C を開始しますが、アプリケーションは静的リソースを見つけられません。ただし、子 C モジュールからの次のコマンドは正常に機能します。

また、自分のプロジェクトの依存関係で怪しいことをしていないことを確認するために、Spring Boot Tomcat JSP の例をダウンロードし、次のような親 POM を作成しました。

そして、Spring Boot サンプル pom の親を以下のように変更しました。

親モジュールから以下を実行すると

そして、ブラウザでhttp://localhost:8080を開きます。

そのため、親モジュールから spring-boot:run が機能しないようです。この問題の回避策はありますか。WAR/JAR を開始する前に、子モジュールに移動するように Maven またはスプリング ブート プラグインに指示することは可能ですか?

最近、「標準」のSpring MVCプロジェクトをSpring Bootに移植したことに注意してください。スプリング ブートの前に、スプリング ブート プラグインの代わりに tomcat maven プラグインを使用しましたが、完全に正常に動作していました。

を使用して WAR をパッケージ化しmvnw -Pprod packageます。JHipsterのウェブサイトによると：

この WAR ファイルは、ビルド時に選択したプロファイルを使用することに注意してください。前のセクションで prod ファイルを使用してビルドされたため、prod プロファイルで実行されます。

また:

実稼働アプリケーションを WAR ファイルから実行する場合、デフォルトでは、パッケージング中に使用されたのと同じプロファイルが使用されます。これをオーバーライドしたい場合は、VM 引数で明示的に代替を指定できます。

ただし、WAR を なしで実行すると、プロファイル--spring.profiles.active=prodの下で実行されます。dev何を与える？

次のモジュールを含むマルチモジュール Maven プロジェクトがあります。

• コモンズ
• モデル
• リポジトリ
• サービス
• ウェブ

私たちはグーグルで検索しましたが、プロジェクトがこの種の構造を持っている場合に実行可能な jar を作成する方法が見つかりませんでした。

親 pom.xml は次のとおりです。

したがって、非常に基本的な親 pom.xml です。パッケージングが pom の場合、Spring Boot Maven プラグインを使用できないことがわかっているため、Web モジュールの pom.xml で定義しました。

他のモジュールの残りの pom.xml はほとんど同じです。Service の pom.xml には Repository.jar が含まれ、Repository には Model と Common が含まれます。

問題 1: を実行するmvn installと、プラグインが Web モジュールのターゲット フォルダーにファット jar を作成します。しかし、それを実行しようとするとjava -jar name-of-jar、Service モジュールの一部のクラスについて java.lang.NoClassDefFoundError が返されます。Web の pom.xml から、Service モジュールが含まれていることがわかります (Web にはライブラリとしてパックされた Service.jar もあります)。ジャー）

問題 2: 興味深いのは、Web.jar 内の Service.jar にも、Web.jar に既に存在するほぼすべての依存関係が含まれていることです。基本的にそれらは重複しています。

Spring Boot Maven プラグインと Maven Module プロジェクト構造を使用して、実行可能なファット jar を作成できた人はいますか?

Activiti Explorer Maven プラグインを Activiti Spring ブート アプリと統合することは可能ですか?

スプリング ブートで rest-api を使用してプロセス エンジンをクエリできることはわかっていますが、デプロイ時に maven プラグインとして追加することで、スプリング ブートでエクスプローラーを実行できるかどうかを知りたいですか?それとも、activit-explorer を微調整できますか? .war どういうわけか、スプリングブート Activiti エンジンを指しますか?

次のような単純な Spring Boot クラスがあります。

Foo.java および Bar.java ファイルは、依存関係として現在の jar ファイル内にネストされ、@SpringBootApplication で注釈が付けられたメイン クラス ファイルです。jar ファイルの構造を以下に示します。

これは、Starter.java を起動しようとしているときに Eclipse から正常に動作しますが、maven でプロジェクトをビルドしようとすると例外が発生します。

Starter POM ファイルからの抜粋を次に示します。

プロジェクト構造は次のようなものです。

親プロジェクトとしてアグリゲーター POM があり、親も spring-boot-starter として宣言されています。Foo、Bar、および Starter プロジェクトはすべて、親プロジェクトの子です。

spring-boot-maven-plugin でネストされたすべての依存関係を持つ単一のファット jar を作成したいと考えています。渡されたパラメーターに従って、スターターメインクラスから必要なプロジェクトを開始できるようにします。スプリングブーツで可能ですか？このようにクラスローダーを使用してFooとBarのメインメソッドを呼び出そうとしましたが、このアプローチは機能しません。クラスローディングが初めてなので、何か間違っている可能性があります。

誰かがこれを達成する方法を提案できますか? どんなアイデアでも大歓迎です。

Spring Boot で構築されたマイクロサービスのリリース管理方法に関するアドバイスを探しています。

私が取り組んできたほとんどのプロジェクトでは、リリース プラグイン (maven) を使用してタグを作成し、maven プロジェクト (jar、war、rpm) をリリースします。通常、これは、リリース プロセス中のすべてのサブプロジェクト (jar、wars) の Maven の親子関係に依存します (モノリス ソース コード、すべて単一の git リポジトリに存在します)。人々はどのようにさまざまなブート プロジェクト (マイクロサービス) を維持し、リリースを行っているのだろうか。

私の見方では、次のような戦略が考えられます。

1. リリースが個別に管理されるように、git リポジトリごとに 1 つの Spring Boot プロジェクト (マイクロサービス Maven プロジェクト)。
2. 各モジュールがマイクロサービスであるマルチモジュール Maven プロジェクト。すべてのサブモジュール (マイクロサービス) をまとめてリリースする必要があります。親 pom は、Boot の親 pom を使用する必要があります。
3. リリースに基づいて特定のサブモジュールのみをリリースする maven-release-plugin 機能に依存します。これにより、各 Maven サブモジュールのバージョンが (潜在的に) 異なります。

あなたのチームは何を役に立ちましたか? 私は Boot のプログラミング モデルが好きですが、物事をシンプルに保つという Boot モデルと一致するリリース戦略を使用できることを願っています。