3

理想的な世界では、GWT アプリを JavaScript にコンパイルし、それを静的リソースとして提供し、バックエンド コードを JVM で実行する舞台裏で、うまくいきます。しかし、その理想的な世界は、実行時のプロダクションと呼ばれます。

ただし、開発時に gwt コード サーバーを利用したい場合は...

GWTモジュールのデバッグと再コンパイルの目的で、実行時（ソース+クラス）にGWTコンパイル時の依存関係が必要です。

同時に、spring-boot 1.3.5.RELEASE などでバックエンドをサポートしたい場合があります。

この場合、複数の頻繁なリリースに苦しんでいるスプリング ブートは、この時点で管理された依存関係として追加したいと考えています。たとえば、次のようになります。

<hibernate-validator.version>5.2.4.Final</hibernate-validator.version>

もちろん、これは非常に良いことです。実際、これは春の多くの良い特徴の 1 つです。

一方、Gwt については、次のリンクを参照して ください。 http://www.gwtproject.org/doc/latest/DevGuideValidation.html

はまだ使用する必要があります:

        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-validator</artifactId>
            <version>4.1.0.Final</version>
            <scope>runtime</scope>              
        </dependency>

さて、もしあなたがこう言うなら: 私は生産的な開発には関心がないので、生産環境で適切に動作するものをコンパイルしてください。

実際、次のような方法でプロジェクトを構成することで、上記の問題を自明に解決できます。

ROOT
--- Backend-api
--- Backend-Impl
--- Gwt-Front-end
---- War or stand alone Spring jar module to glue it all together

一部の RPC サービスと DTO について、Gwt-Front エンドをバックエンド API に依存させる場所。pom.xml の依存関係は、ほとんどの場合、バックエンドにある依存関係とは関係なく、フロントエンド モジュールでのみ管理できます。最終的には、gwt コードを静的リソースとして保持し、バックエンド コードとそのすべての依存関係 (Hirbernate バリデーターの最新バージョン) を保持する war、またはスプリング ブートで実行可能な jar を作成します。

ただし、開発目的で機能するpomを取得しようとしている場合、私が見る限り、ROOTのバックエンドレイヤーとフロントエンドレイヤーの間で共通する依存関係をグローバルに管理する必要がありますpom.xml、および依存関係を gwt で必要なバージョンにダウングレードします。

つまり、理想的な世界のシナリオです。ROOT pom.xml は、モジュールとビルド順序を宣言するだけです。そして、back-end-impl に、spring-boot-starter pom.xml などから依存関係を継承したいことを述べる力を持たせます...

理想的なシナリオとは対照的に、開発時に実際に役立つ pom.xml 構成では...まあ、ルートの pom.xml を再検討する必要があるかもしれません。そして、このルート pom.xml に管理された依存関係を追加する必要があるため、GWT フロントエンドとスプリング ブート バックエンドの間で競合する一般的なすべての依存関係について、常に GWT のバージョンを変更してダウングレードする必要があります。所定の位置に。

これにより、gwt:run、dev モードの再コンパイルなどを実行するときに、gwt コンパイラーが Hibernate バージョン 5 を JavaScript でコンパイルしようとするのではなく、GWT 4.1 final で実際にサポートされているバージョンをコンパイルすることが保証されます。もちろん、バックエンド コードに驚きをもたらすかもしれません。最近では、このようなハックを配置することで...

バックエンドとgwtベースのフロントエンドが競合する依存関係の要件を持つことができるマルチモジュールプロジェクトを適切に編成する方法を知っている人はいますか?

最終的に、答えが「いいえ」の場合、私は、純粋な gwt スタンドアローン桟橋と統合する純粋なスタンドアローン スプリング ブート バックエンドを持つことによって、ネットワークの浪費と通信遅延の追加を好むと思います。実際のスプリングブートバックエンドへのリクエストをばかげてキックするだけです。UI によって 1+1 を実行するために呼び出され、実際に 1+1 の実行方法を知っている sprin boot を実行している 2 番目のバックエンドに計算を転送する gwt jetty バックエンドを持つのは、ちょっと哀れです...しかし、これが最も生産的な作業方法であり、開発が生産的であり、生産が予期せずに実行されることを保証する場合は、そうしてください.

フィードバックをお寄せいただきありがとうございます。理想的には、既存の Maven プロジェクトとして Eclipse にインポートできる multi-pom プロジェクトを見て、これを実現する方法を示したいと思います。

4

4 に答える 4

2

はい、私がやりたかったことは、些細なことではありませんが、実際に実行できます... まったくできません。

gwt バリデータ依存関係または springboot バリデータ依存関係のいずれかを選択する必要なく、バックエンド コードとフロントエンド コードの両方のコード スワップを取得できるという意味で、生産的に使用できる Maven マルチ モジュール pom をセットアップするには、基本的に私は整理します私のプロジェクトは次のとおりです。

あなたが持っている：

LEVEL 1: myproject-root
----- LEVEL 2: myproject-backend
---------- LEVEL 3: myproject-backend-api
---------- LEVEL 3: myproject-backend-impl
------ LEVEL 2: myproject-frontend
------ LEVEL 2: myproject-runner
-----------LEVEL 3: myproject-runner-jar
-----------LEVEL 3: myproject-runner-war

myproject-root では、当然、サブモジュールを宣言します。あなたは、surefire プラグインなどの無害なプラグインで依存関係の管理を行います。Java ソースとターゲットのコンパイル言語を制御します。あなたはそれ以上のことはほとんどしません。横断的に構成できるプラグインがいくつかある場合は、それらをプラグイン管理に入れることもできます。

myproject-backend では、基本的に、依存関係管理に以下を追加することで、依存関係管理に springboot 依存関係を継承させます。

<dependencyManagement>
        <dependencies>
            <!-- Inherit dependencies from spring boot dependency management pom -->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-parent</artifactId>
                <version>${version.spring.boot}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

2 つのサブモジュールを宣言すると、終了です。ここでは、横断的な依存関係を宣言しません。依存関係管理のみを使用します。フロントエンド コンポーネントは api サブモジュールにヒットし、バックエンド pom で依存関係の磁石を作成したくないため、ここでは可能な限り保守的です。

myproject-backend-api では、このサブモジュールを jar サブモジュールにすることから始めます。最終的には、エントリポイントの性質によって API を細分化することで、API コンポーネントをさらに分岐させたいと思うでしょう。まず、-api コンポーネントには、サーバーとフロントエンド間の通信に必要な API が含まれます。これは、ドキュメントで一般的に見られる「共有」のようなものです。ここでは、依存関係要素内の要素に関連するものをできるだけ少なくするように、できるだけ注意を払っています。フロントエンドはこれらの API を使用し、Spring Boot API に依存する API パッケージは必要ありません。

backend-impl では、実際のビジネス ロジックを記述し、フル スプリング ブート スタックに自由に依存できます。ルールは、誰もこの依存関係の磁石を決して指さないようにすることです。特に、gwt コンポーネントに springboot ライブラリの存在の匂いさえさせないでください。絶対に参照しないでください。

myproject-frontend では、api コンポーネントで行ったように、別のサブモジュールに分岐しません。ここでは、gwt コード用のモノリシック コンポーネントを作成して、ホット コードの再コンパイルを実行するために gwt maven プラグインをより簡単に機能させることができるようにします。このコンポーネントでは、myproject-api に依存するだけでなく、gwt-user、gwt が必要とする古いバージョンの hibernate バリデーターなどの関連する gwt ライブラリにも依存します。myproject-frontend のルールは次のように宣言します。コンポーネント内のすべての依存関係をオプションとして。コンポーネントに推移的な依存関係を取りたくない場合。本番環境で必要なのは、myproject-frontend.jar/META-INF/resources/MyProjectModule.html... と、springboot が検出して提供する必要があるすべての静的リソースだけです。ただし、開発モードにいる間は、

<noServer>true</noServer>

ポイントは、この jetty サーバーを実行する場合、クラスパスにあるのはフロントエンド コードと API だけであり、間違いなく impl コードではないということです。次に、gwt 桟橋を使用したくない場合は、springboot tomcat または springboot 桟橋のいずれかを使用します。適切な websocket ライブラリなどで springboot の組み込みコンテナーを使用する方がはるかに優れています。

(b) springboot を使用して、META-INF/resources/ または public フォルダーから静的リソースをサーバーに提供します。通常は JSF コンポーネントも配置する場所になるので、リソースの方が好きです。いずれにせよ、静的リソースが来る場所は特別なので、gwt プラグインを調整して Java ソースを書き込みフォルダーにコンパイルする必要があります。

<webappDirectory>${project.build.directory}/classes/META-INF/resources</webappDirectory>

上のようなものです。

最後に、これが私の主な間違いでした。フロントエンド コードを記述した場所からコードを実行しません。これは間違っています。これは、フロントエンド コードに springboot の依存関係が必要になるためです。これにより、競合するライブラリが原因で極度の苦痛が生じます。

したがって、この問題を回避するために、myproject-runner コンポーネントを作成します。非常に詳細にしたい場合は、それを pom 親コンポーネントにして、パッケージを jar または war にフォークできるようにします。個人的には、war オプションよりも、実行可能な jar の方がはるかに好きです。重い weblogic のようなものに sprinboot アプリケーションをデプロイしたくはありませんが、あなたのボートを揺るがすものは何でも。

いずれにせよ、スプリング ブート ランナーは究極の依存マグネットです。このコンポーネントは、あなたが持っているすべてのモジュールとそれらの推移的な依存関係に依存します。しかし、ランナーコンポーネントをフロントエンドコードから分離し、フロントエンドコードのすべての依存関係をオプションにするため...基本的には、springboot と gwt 静的リソースのみをバンドルします。

あなたが開発している間、あなたがすることは....一度それを知ったら...簡単です。(A) メインファイルをトリガーして、Spring Boot jar アプリケーションを開始します。本当に war ファイルをデプロイしたい場合は、war ファイルをビルドして tomcat などにデプロイすることもできます...

(b) フロントエンド コンポーネントに移動し、それを右クリックして、Maven ビルドとして実行を選択し、gwt:run を選択します。gwt を実行すると、gwt コード サーバーが起動します。バックエンド コードは完全に見えなくなります。目の前にあるのは、フロントエンド コンポーネントにあるコードと、すべての gwt 依存関係だけです。オプションとして追加しました。

springboot dev を使用している場合は、最終的にバックエンドでコードをホットスワップできます。gwt プラグインを開始すると、モノリシックなフロントエンド コンポーネントのコードを最終的にホット スワップできます。

結論、それは可能ですが、それはめちゃくちゃです。この問題が解決されてよかったです。

于 2016-05-21T19:51:32.827 に答える
2

GWT コードをコンパイルするときに除外したい推移的な依存関係がどこにあるかを把握します。

    <dependency>
        <groupId>spring-dependency-with-hibernate</groupId>
        <artifactId>some-spring-boot-starter</artifactId>
        <exclusions>
            <exclusion>
               <groupId>org.hibernate</groupId>
               <artifactId>hibernate-validator</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

このようにして、GWT が提供するhibernateバージョンのみが実行時に利用可能になります。

于 2016-05-18T12:25:03.027 に答える