JHipsterのカスタマイズ
組織向けにJHipsterをカスタマイズ/拡張することは可能ですか？
つまり、組織に固有の機能を備えたいくつかのプロジェクトを作成するローカルバージョンがあるということですか？たとえば、カスタム認証スキーム（Springセキュリティに引き続き依存）の使用、カスタムスタイル（色、フォント）の使用、特定のMaven依存関係の追加などです。
これが可能な場合、JHipsterの更新によってこれらの拡張機能が上書きされないように、JHipsterを更新する可能性を維持しながら実行できますか？
ありがとう。
一般的なアプローチは次のとおりです。
- まず、すべての標準JHipsterスタックを使用して空のプロジェクトを作成しました。使用されるDBMSはPostgresです。 jhipsterエンティティ生成ツールを使用した基本的なデータ構造の概要を説明し、最も重要な関係を作成しました。また、標準のJHipsterオプション内で基本的なユーザーロールと権限を定義しました。このフェーズでは、複雑な固有の制約、ビジネス制限、ユーザー管理、JPAエラー処理、プレゼンテーションなどの詳細にはあまり注意を払いませんでした。最初に一種のバックボーンを作成しただけです。 CRUDページはすべて標準です。
- ドメイン固有のビジネスロジックをいくつか導入しました。基本的なフロントエンドのカスタマイズが実行されました：ブランディング、スタイル、いくつかのカスタムビュー（まだ使用されているbootstrapクラス）など）。Jhipsterで生成されたフレームはそのまま維持されましたが、拡張されました。バックエンドとフロントエンドの両方で、特定のトークン検証ルールを備えたトークンベースです。ユーザーフレンドリーなエラー処理が導入され、ユーザーはさまざまな条件でどのようなビジネス制限が表示されるかを理解できるようになりました。実装されたビジネスロジックを満たすために、より複雑なユニットテストの作成を開始しました。最近。エンティティは、この段階でほとんど（〜80％）手動で作成されます。これは、JHipsterが提供するデータ構造に慣れており、CRUD RESTコントローラー、ページ、およびLiquibaseの変更ログはliquibase：diffを使用して生成され、手動で編集されました。このようなエンティティは.jhipsterフォルダーに追加されません。
- インターフェース設計に対する要求がますます厳しくなっているため、エンドユーザーとの対話用に別個のフロントエンドレイヤーを導入することが決定されました。 REST jhipsterで生成されたフロントエンドとのインターフェースを部分的に共有しますが、プロジェクト構造に関しては完全に独立しています。新しいフロントエンドレイヤーにもAngularを使用することにしました。実際、これは個別のindex.html、bower.json、Gruntfile.jsなどのサブフォルダーです。同時に、ビジネスロジックの改善、db構造の改良、コードカバレッジの拡大、新しいユーザーロールの導入などを続けました。
- .。
そのため、管理とデータ管理の目的で、「古い」JHipsterフロントエンドを少しカスタマイズしました。また、エンドユーザーに対応するカスタムデザインの独立した「新しい」フロントエンド。 注意してください：それはIS元のインターフェースを維持し、それをある程度カスタマイズし、エンティティを生成する可能性を維持することが可能であり、これまでのプロジェクトでうまく機能しましたそれが正当化されたように。
いくつかの注意：
- Pom.xmlのコンポーネントバージョンは常に手動で更新されていました。
- Mavenの依存関係は手動でpom.xmlに追加されました。
- JSの依存関係は手動でindex.html/bower.json/app.jsに追加されました。
- 複雑なフロントエンドスクリプトを使用している場合、本番プロファイルのJSの醜化に対処するのは難しいかもしれません。
- もう1つの難しいことは、Spring-bootで使用されるDBMSとテストで使用されるH2の両方でliquibaseスクリプトを機能させ続けることです。
- プロジェクトに固有のドメインロジックによっては、構成の調整で問題が発生する可能性があります。
お役に立てば幸いです。
リリース2.26.0（2015年12月中旬）で導入されたもう1つのアプローチは、独自のモジュールを構築することです。 ドキュメント を参照してください。