web-dev-qa-db-ja.com

Mavenモジュールとスプリングプロファイルの整理

異なるクライアント向けにカスタマイズできるアプリケーションとしてのWebとして、Springのプロファイルと、製品を作成するためのMavenマルチモジュールプロジェクトの設計上の問題に直面しています。このために、コードをかなり整理する必要があります。これが、コードを中心にプロファイルを整理する方法についてアドバイスしている理由です。

現在、私は2つのプロファイルのみを使用しています。アプリケーション全体に対してdev/prodです。これらのプロファイルは、MavenプロファイルとSpringプロファイルの両方です。 Springプロファイルは、Mavenフィルタリングからの私のWebアーカイブのweb.xmlにあります。

一部の外部ハードウェアに依存する他のモジュールからいくつかのクラスを簡単に切り替えたい場合、これだけでは少し面倒です。もちろん、この問題を解決するためだけに、どこからでも新しいプロファイルを追加できます。

しかし、私はそれを処理するためのより一般的な方法を探しています。「そのときに必要なので」作成しただけのプロファイルのスープで終わりたくありません。モジュールごとにdev-xxx/prod-xxxプロファイルを作成する必要がありますか、それともベストプラクティスがありますか？

これが私のプロジェクトが現在どのように構成されているかに関する情報です。これは私が現在持っているものについてのアイデアをあなたに与えます。しかし、あなたの答えでこれを考慮する必要はありません

サーバーの私の完全なスタック：PostgreSQL、Hibernate、JPA、Spring + Spring-Security、CXF（JAX-RS実装とFIQL検索エンジンとしての多くの機能を提供）、WebSockets、Jackson（jsonシリアライザー）

これが私のモジュールが現在どのように編成されているかです、私は必ずしも私が持っているものと正確に一致する答えを探す必要はありませんが、それはあなたにアイデアを与えます：

  • コア：現在、すべてのエンティティ、ビジネスサービス、および権利管理が含まれています。私はDTOオブジェクトを使用しないので、JPA/Jacksonからのすべての注釈はエンティティ（データベース内の36テーブル）にあります。
  • Rest-Common：デフォルト構成がいくつか含まれています（jackson mapper、jackson jax-rs provider）。
  • RestCore：すべてのサービスをWebの世界に公開し、CXF JAX-RS検索モジュールに依存する検索サービスを提供します。 URLは単純な権利に従ってスプリングセキュリティで保護されており、ビジネスサービスでさらにチェックが行われます。
  • RestReader：モバイルリーダーと同期するために、一連の貴様URLを公開します。それらはブラウザで使用するように作られていません。
  • 技術的な部分のみを実装する他の2つの独立したモジュール。

注：私は統合環境の中間プロファイルなどを持っている可能性があることを知っています、それらは計画されていますが、事前に実際に指定または設計されていない機能ごとに2週間から3週間実行しているので、現在、完全なビルドプロセスをクリーンアップしたり、完全な分析や設計を行ったりする時間はほとんどありません。したがって、現時点では実装できない将来のいくつかの回答に興味があるかもしれません。

designbuildsspringmaven
5
Walfrat

単一のMavenプロジェクトに複数のビルドターゲットを配置し、Springプロファイルを介してビルド中にアプリのカスタマイズを実行することはお勧めしません。このソリューションは、特定のアプリケーション/実行コンテキストに属する機能の可視性が低下しているため、サポートが困難です。

プラグインアーキテクチャは、一般的なコードと顧客の仕様を明確に区別するため、ここではより良い選択です。どうやってそれができる？

プロジェクト構造

  project
    core
      pom.xml
    feature1
      pom.xml
    feature2
      pom.xml
    app1
      pom.xml
    app2
      pom.xml

ここでは、コアモジュールに共通の機能があり、コアといくつかの機能を依存関係として含む、異なる顧客向けの2つのアプリがあります。ルートプロジェクトの「mvn integration-test」は、アプリのコア、機能、ソースコードをコンパイルしてテストを実行しますが、アプリのアセンブリは行いません。モジュールを構築することで、特定のアプリを組み立てることができます。

アプリケーションアーキテクチャ

コアモジュールは、それ自体を実行できるアプリです。必要なインフラストラクチャと最小限の機能がすべて含まれています。プラグインと構成APIのオプションのインターフェースを提供し、顧客ごとにカスタマイズできるようにします。

上記の例のすべての機能モジュールは、コアインターフェイスの一部を拡張するプラグインです。 OSGiを使用することもできますが、最も簡単な解決策は、Springアプリケーションコンテキスト構成のランタイム検出を使用することです（サーブレット3.0のWebフラグメントを使用するか、デフォルトの構成に、たとえば '/ META-INF /にあるクラスパスのすべてのファイルを含めることができますmy-spring-plugins '）。ここで、すべての追加構成を配置し、プラグインBeanを定義できます。一部の顧客が、あるエンティティのアクションとしてREST APIを介してアクセスできる機能Aを必要としているとします。IActionProviderインターフェイスを実装するBeanからアクションのリストを収集するコンポーネントを定義できます。このインターフェースを実装し、この機能のアクション定義を返すプラグイン。

アプリモジュールもプラグインです。アプリケーションのブランド化、データベース構成、エンタープライズ統合構成などを制御するインターフェースを拡張できます。

2
Ivan Gammel

可能であれば、両方の間にリンクされたプロファイルを作成し、devとprodの両方でファイルを即座に編集/比較/制御できるようにします。それが私の提案ですが、もし誰かが私よりも優れた経験を持っているなら、私は彼らからそれをとります。

1
Tyler Yates