[[JHIPSTER一覧]]
*** 目次 [#n96aa4b5]
#contents
* JHipsterドメイン言語（JDL） [#z4f90135]
** JDLの概要 [#hbdeb56a]
JDLはJHipster固有のドメイン言語です。すべてのアプリケーション、デプロイメント、エンティティ、およびそれらの関係を単一のファイル（または複数のファイル）にシンプルでユーザーフレンドリーな構文で記述できます。
** このページの原文(英語) [#r07a176c]
https://www.jhipster.tech/jdl/
このページは、上記原文の、googleの日本語訳を手直（googleの翻訳そのまま＋pukiwiki用に、ちょっと整形）したものになります。
どなたでも、編集可能です。気に入らない方は、どうぞ、修正をお願いします。
** JDL Studio [#i86b2ec6]
https://start.jhipster.tech/jdl-studio/
** プレビュー機能 [#r8ac8106]
JDLファイルとそのUMLビジュアライゼーションを作成するには、Eclipse、VS Code、Atom用のオンラインJDL-StudioまたはJHipster IDEプラグイン/拡張機能のいずれかを使用できます。JDLモデルのURLを作成してエクスポートまたは共有することもできます。
実行することで、import-jdlサブジェネレータを使用してJDLファイルからアプリケーション、デプロイメント、およびエンティティを生成できますjhipster import-jdl your-jdl-file.jdl。
既存のプロジェクト（コマンドラインをjhipster import-jdl使用して作成または生成さjhipsterれたプロジェクト）がある場合は、runningを実行してプロジェクトのエンティティを生成できますjhipster import-jdl your-jdl-file.jdl。このコマンドは必ずJHipsterプロジェクトの下で実行してください。
生成したJHipsterアプリケーションのルートから実行することで、JHipster UMLを使用してアプリケーションやエンティティを生成し、それらをJDLファイルとしてエクスポートすることもできjhipster-uml your-xmi-file.xmi --to-jdlます。JHipster UMLについてさらに学び、それをインストールするには、JHipster UMLの資料を参照してください。
これはエンティティサブジェネレータを使用する代わりに使用でき、推奨されるアプローチです。考え方は、古典的なYeomanの質問と回答よりも、ビジュアルツールを使用して関係を管理する方がはるかに簡単であるということです。
JDLプロジェクトはGitHubで利用可能です、それはJHipster（Apache 2.0ライセンス）のようなオープンソースプロジェクトです。JDL構文解析を行うためのノードライブラリとしても使用できます。
あなたがJHipsterドメイン言語のJDLを気に入ってくれたら、GitHubに、スターの評価を投票してくださいね。
* JDLサンプル [#ba008a05]
Oracleの「Human Resources」サンプルアプリケーションはJDLに翻訳されており、ここから
https://github.com/jhipster/jdl-samples/blob/master/Oracle-Human-Resources-sample.jdl
入手できます。同じアプリケーションがJDL-StudioとJHipster IDEにもデフォルトでロードされます。
もっとサンプルを探しているのなら、ここ
https://github.com/jhipster/jdl-samples
にそのためのリポジトリがあります。
** どうやって使うのですか [#f4753b46]
*** JDLファイルのインポート [#a32e46e4]
その後、JDLファイルを使用してエンティティを生成できます。
- 拡張子が「.jh」または「.jdl」のファイルを作成するだけです。
- アプリケーション、デプロイメント、エンティティ、および関係を宣言するか、JDL-Studio
実際に使えるやつ
https://start.jhipster.tech/jdl-studio/
またはJHipster IDE（Eclipse VSCode Atomでのインストール動画あり)
https://www.jhipster.tech/jhipster-ide/
でファイルを作成してダウンロードします。
- エンティティのみを作成している場合jhipster import-jdl my_file.jdlは、JHipsterアプリケーションのルートフォルダで実行してください。
- アプリケーションを作成している場合jhipster import-jdl my_file.jdlは、フォルダ内で実行するだけです。
チームで作業している場合は、おそらく1つではなく複数のファイルを使用したいと思うでしょう。このオプションを追加したので、手動ですべてのファイルを1つに連結するのではなく、実行するだけで済みます。
jhipster import-jdl my_file1.jdl my_file2.jdl
JDLのインポート中にエンティティを再生成したくない場合は、--json-onlyフラグを使用してエンティティ作成部分をスキップし、.jhipsterフォルダ内にjsonファイルのみを作成できます。
jhipster import-jdl ./my-jdl-file.jdl --json-only
デフォルトimport-jdlでは、変更されたエンティティだけが再生成されます。すべてのエンティティを再生成する場合は、--force フラグを渡します。これにより、エンティティファイルに対するローカルの変更がすべて上書きされます。
jhipster import-jdl ./my-jdl-file.jdl --force
あなたがあなたのプロジェクトでそれを使いたいならば、あなたはそうすることによってそうすることを加えることができます：
- NPM： npm install jhipster-core --save
- 糸： yarn add jhipster-core
ローカルにインストールしてpackage.jsonファイルに保存します。
** JDLファイルへのエクスポート [#l64c423a]
アプリケーションに既にエンティティがあり、JDLファイルを取得したい場合は、そうしないでください。あなたのためにそれをするサブジェネレータがあるので、あなたは最初からそれを書く必要はありません。
jhipster export-jdl <FILE_NAME>アプリのルートフォルダで実行するだけで、すべてのエンティティ、関係、およびオプションのエクスポートが1つのJDLファイルにまとめられます。注：サブ世代にファイル名を指定することもできません。デフォルトのものが選択されます。
* 言語 [#e9612a06]
私たちは開発者にとってできるだけフレンドリーな構文を保つようにしました。あなたはそれでこれらのことをすることができます：
- アプリケーションをそのオプションとエンティティで宣言します。
- エンティティをその属性で宣言します。
- それらの間の関係を宣言する、
- そしてJHipster特有のオプションをいくつか宣言します。
JDLの文法を見たいのであれば、ここ
https://github.com/jhipster/jhipster-core/blob/master/lib/dsl/gen/grammar.html
に HTMLファイルがあり ます。
** アプリケーション宣言 [#r1dec1e8]
v2.0.0以降、アプリケーションの宣言は可能です（JHipster v5と互換性があります）。
1つまたは複数のアプリケーションをインポートするために、JHipsterアプリケーションフォルダにいる必要はありません。
最も基本的な宣言は次のように行われます。
application {
config {}
}
JHipsterアプリケーションにはデフォルト値の設定があり、前の構文を使用すると、アプリケーションがデフォルト値を使用するようになります（特に選択しなかった場合と同じ）。結果のアプリケーションは以下のようになります。
- baseName： jhipster
- アプリケーションタイプ： monolith
- databaseType： sql
- 等
今、あなたはいくつかのカスタムオプションが必要な場合：
application {
config {
baseName myapp
applicationType microservice
prodDatabaseType postgresql
buildTool gradle
}
}
これらのオプションは、JDLで利用可能なもののほんの一例です。オプションの完全なリストは、ここの付録にあります。
複数のアプリケーションが必要な場合は、次のようにします。
application { // will be generated under the 'myFirstApp' folder
config {
baseName myFirstApp
}
}
application { // will be generated under the 'mySecondApp' folder
config {
baseName mySecondApp
applicationType microservice
}
}
あなたはあなたが望むだけ多くのファイルにあなたが望むだけの数のアプリケーションを持つことができます。制限はありません。
エンティティの宣言は利用可能な最も基本的なものであり、今、あなたは欲しいアプリケーションでどのエンティティが生成されるべきかを設定することができます。
前の例を改良しましょう。
application {
config {
baseName myMonolith
applicationType monolith
}
entities * except C, D
}
application {
config {
baseName myGateway
applicationType gateway
serverPort 9042
}
entities * except A, B
}
application {
config {
baseName microserviceA
applicationType microservice
}
entities C
}
application {
config {
baseName microserviceB
applicationType microservice
serverPort 8082
}
entities D
}
entity A
entity B
entity C
entity D
dto * with mapstruct
service * with serviceClass
paginate D with pager
これらのアプリケーションとフォルダを生成すると、いくつかのことが起こります。
- 4つのアプリケーションが作成されます。
-- myMonolithの中./myMonolith、サーバーのポート番号8080
-- myGateway ./myGateway、サーバーポートあり9042
-- サーバー./microserviceAポートとともに、microserviceA in8081
--- サーバーポートを指定していなくても、JHipsterはデフォルトでポートを設定します。
--- マイクロサービスの場合、デフォルトのものは 8081
--- ゲートウェイとモノリスの場合、それは 8080
--- UAAアプリの場合、それは 9999
-- サーバー./microserviceBポートと一緒にmicroserviceB8082
- 4つのエンティティが生成されます
-- AそしてBモノリスの中で
-- CそしてDゲートウェイの両方
--- C 最初のマイクロサービスで
--- D 2番目のマイクロサービス
- このmicroserviceオプションはCand に対して暗黙的ですD
-- これらは2つのマイクロサービスで生成されるため、このオプションはデフォルトで設定されます。
- オプションは以前と同じように機能します
デフォルト値が存在しない場合、ジェネレータはデフォルト値を設定します（のようにdatabaseType）。JHipster Coreでもまったく同じことができます。
** エンティティ宣言 [#g41f40bd]
エンティティ宣言は次のように行われます。
entity <entity name> {
<field name> <type> [<validation>*]
}
- <entity name> エンティティの名前です。
- <field name> エンティティの1つのフィールドの名前
- <type> JHipsterがサポートしているフィールドの型
- オプションとして<validation>フィールドの検証。
可能なタイプと検証はここで説明されているものです、検証が値を必要とするならば、単に(<value>)検証の名前の直後に追加してください。
これがJDLコードの例です。
entity A
entity B
entity C
entity D {
name String required
address String required maxlength(100)
age Integer required min(18)
}
正規表現は（v1.3.6から）このように使われているのでちょっと特別です。
entity A {
myString String required minlength(1) maxlength(42) pattern(/[A-Z]+/)
}
v4.9.Xより前のジェネレータを使用している場合は、このようなパターンを使用する必要がありますpattern('[A-Z]+'。
JDLは使いやすく読みやすいように作られているので、もしあなたのエンティティが空（フィールドなし）なら、あなたはエンティティをentity Aorで宣言することができますentity A {}。
JHipsterはデフォルトのidフィールドを追加しているので、心配する必要はありません。
** 関係宣言 [#d6283bed]
関係の宣言は次のように行われます。
relationship (OneToMany | ManyToOne | OneToOne | ManyToMany) {
<from entity>[{<relationship name>[(<display field>)]}] to <to entity> [{<relationship name>[(<display field>)]}]
}
- (OneToMany | ManyToOne| OneToOne | ManyToMany) あなたの関係のタイプは
- <from entity> 関係のエンティティ所有者の名前です。ソース、
- <to entity> 関係が移動するエンティティの名前です。
- <relationship name> 型としてもう一方の端を持つフィールドの名前です。
- <display field>選択ボックスに表示すべきフィールドの名前です（デフォルトは：id）、
- required 注入されたフィールドが必要かどうか
- with jpaDerivedIdentifier@MapsId関連付けに使用されるかどうか（1対1にのみ適用可能）
これは簡単な例です：
entity Book
entity Author
relationship ManyToOne {
Book to Author
}
必要に応じてデフォルトで一方（または両方）が設定されるため、注入フィールドの宣言はオプションです。前の例はこれと同じです。
entity Book
entity Author
relationship ManyToOne {
Book{author} to Author
}
もっと複雑にしましょう。本には必要な著者が1人、著者には複数の本があります。
entity Book
entity Author {
name String required
}
relationship OneToMany {
Author{book} to Book{writer(name) required}
}
ここでは、Bookクラスはのフィールドを通してリンクされるという名前の必須フィールドを持ちます。writernameAuthor
もちろん、実際のケースでは、たくさんの関係があり、いつも同じ3行を書くのは面倒です。だからこそ、次のように宣言できるのです。
entity A
entity B
entity C
entity D
relationship OneToOne {
A{b} to B{a}
B{c} to C
}
relationship ManyToMany {
A{d} to D{a}
C{d} to D{c}
}
結合は常にidフロントエンドでリレーションを編集するときに表示されるデフォルトフィールドでもあるフィールドを使用して行われます。代わりに別のフィールドを表示する必要がある場合は、次のように指定できます。
entity A {
name String required
}
entity B
relationship OneToOne {
A{b} to B{a(name)}
}
JPA派生識別子 - @MapsIdは以下のように宣言することができます。現在のところ1対1でのみサポートされています。
entity A {
name String required
}
entity B
relationship OneToOne {
A{b} to B{a(name)} with jpaDerivedIdentifier
}
これはJHipster、両方返すRESTリソースを生成させるidとname名前ではなく、ユーザに示すことができるように、フロントエンドに連結されたエンティティのを。
** 列挙型 [#jdfaf91e]
JDLを使ってEnumを作るには、次のようにします。
- ファイル内の任意の場所にEnumを宣言します。
enum Language {
FRENCH, ENGLISH, SPANISH
}
- エンティティで、Enumを型として持つフィールドを追加します。
entity Book {
title String required,
description String,
language Language
}
** ブロブ（byte []） [#z5a08db9]
JHipsterは、イメージタイプと任意のバイナリタイプの間で選択できるので、素晴らしい選択をします。JDLを使えば同じことができます。エディタを使ってカスタムタイプ（DataTypeを参照）を作成し、次の規約に従って名前を付けます。
- AnyBlobまたは単にBlob「任意」のバイナリ型のフィールドを作成すること。
- ImageBlob イメージであることを意味するフィールドを作成すること。
- TextBlob CLOB（テキスト（長））のフィールドを作成します。
そして、あなたは好きなだけデータ型を作成することができます。
** オプション宣言 [#ccb29bdb]
JHipsterでは、ページネーションやDTOなどのエンティティのオプションを指定できます。JDLでも同じことができます。
entity A {
name String required
}
entity B
entity C
dto A, B with mapstruct
paginate A with infinite-scroll
paginate B with pagination
paginate C with pager // pager is only available in AngularJS
service A with serviceClass
service C with serviceImpl
キーワードはdto、paginate、serviceおよびwithこれらの変更をサポートするために、文法に追加されました。間違ったオプションが指定された場合、JDLはそれを素敵な赤いメッセージで知らせ、JHipsterのJSONファイルを破損しないように無視します。
*** サービスオプション [#kaec1a88]
指定されたサービスは、リポジトリインタフェースを直接呼び出すリソースクラスを作成しません。これはデフォルトで最も単純なオプションです。Aを参照してください。serviceClass（Bを参照）を使用したサービスでは、リソースがサービスクラスを呼び出し、リポジトリクラスが呼び出されます。serviceImpl（Cを参照）を使用したサービスは、リソースクラスによって使用されるサービスインタフェースを作成します。このインタフェースは、リポジトリインタフェースを呼び出す具象クラスによって実装されます。
確実でない限り、サービスを使用しないのが最も簡単な方法であり、CRUDに適しています。複数のリポジトリを使用することでサービスクラスに最適なビジネスロジックが多数ある場合は、Class with serviceを使用します。Jhipsterは不要なインターフェースのファンではありませんが、気に入った場合はimplでサービスを受けてください。
entity A
entity B
entity C
// no service for A
service B with serviceClass
service C with serviceImpl
JDLはマスオプション設定もサポートします。それはすることは可能です：
entity A
entity B
...
entity Z
dto * with mapstruct
service all with serviceImpl
paginate C with pagination
なお*とall同等です。最新バージョンでは除外されています（すべてのエンティティにオプションを設定する際に非常に強力なオプションです）。
entity A
entity B
...
entity Z
dto * with mapstruct except A
service all with serviceImpl except A, B, C
paginate C with pagination
JHipsterを使用すると、クライアントコードやサーバーコードが不要かどうかもわかります。Angular関連のファイルにサフィックスを追加したい場合でも、JHipsterでそれを実行できます。 フィルタオプションは、エンティティごとにアクティブにすることができます：フィルタ<entity name>またはすべてのエンティティに対してフィルタ：フィルタ*。あなたのJDLファイルに、同じことをするために単にこれらの行を追加してください：
entity A
entity B
entity C
skipClient A
skipServer B
angularSuffix * with mySuperEntities
filter C
最後に、テーブル名も指定できます（エンティティの名前がデフォルトで使用されます）。
entity A // A is the table's name here
entity B (the_best_entity) // the_best_entity is the table's name
** マイクロサービス関連のオプション [#n788a80a]
JHipster v3以降、マイクロサービスを作成できます。JDLでエンティティを生成するためのオプションをいくつか指定できます。マイクロサービスの名前と検索エンジンです。
マイクロサービスの名前（JHipsterアプリの名前）を指定する方法は次のとおりです。
entity A
entity B
entity C
microservice * with mysuperjhipsterapp except C
microservice C with myotherjhipsterapp
search * with elasticsearch except C
最初のオプションはJHipsterにあなたのマイクロサービスにあなたのエンティティを処理させたいことを伝えるために使われますが、2番目のオプションはあなたのエンティティをどのようにそしてあなたが検索したいかを指定します。
** アノテーション [#efc314c3]
注釈はJHipster v5以降で利用可能です。Javaで可能なことと同様に、アノテーションはアノテーションオプションであなたのエンティティにアノテーションを付けるように同じように働きます。
たとえば、このJDLコードを見てください。
entity A
entity B
entity C
dto C with mapstruct
paginate * with pager except C
search A with elasticsearch
これはアノテーションと同等です：
@paginate(pager)
@search(elasticsearch)
entity A
@paginate(pager)
entity B
@dto(mapstruct)
entity C
これにより、実際に削除されるよりも多くのコードが追加されますが、複数のJDLファイルを使用する場合（マイクロサービスなど）には実際には便利です。
** デプロイメント宣言 [#nc352c25]
v3.6.0以降では、デプロイメント宣言が可能です（JHipster v5.7以降と互換性があります）。
1つまたは複数のデプロイメントをインポートするために、JHipsterアプリケーションフォルダーにいる必要はありません。
最も基本的な宣言は次のように行われます。
deployment {
deploymentType docker-compose
appsFolders [foo, bar]
dockerRepositoryName "yourDockerLoginName"
}
JHipsterデプロイメントには他のすべてのプロパティのデフォルト値を含む設定があります。前の構文を使用すると、デプロイメントにデフォルト値が使用されるようになります（特に選択しなかった場合と同じ）。結果として得られるデプロイメントは以下のようになります。
- deploymentType： docker-compose
- appsFolders： foo, bar
- dockerRepositoryName： yourDockerLoginName
- serviceDiscoveryType： eureka
- gatewayType： zuul
- directoryPath： ../
- 等
今、あなたはいくつかのカスタムオプションが必要な場合：
deployment {
deploymentType kubernetes
appsFolders [store, invoice, notification, product]
dockerRepositoryName "yourDockerLoginName"
serviceDiscoveryType no
istio autoInjection
kubernetesServiceType Ingress
kubernetesNamespace jhipster
ingressDomain "jhipster.192.168.99.100.nip.io"
}
これらのオプションは、JDLで利用可能なもののほんの一例です。オプションの完全なリストは、ここの付録にあります。
複数の配置が必要な場合は、次のようにします。
// will be created under 'docker-compose' folder
deployment {
deploymentType docker-compose
appsFolders [foo, bar]
dockerRepositoryName "yourDockerLoginName"
}
// will be created under 'kubernetes' folder
deployment {
deploymentType kubernetes
appsFolders [foo, bar]
dockerRepositoryName "yourDockerLoginName"
}
deploymentTypeごとに1つのデプロイメントを持つことができます。で定義されているアプリケーションappsFoldersは、デプロイメントを作成しているのと同じフォルダー、またはで定義されているフォルダーになければなりませんdirectoryPath。たとえば上記の場合は、次のようなフォルダ構造が必要です。
.
├── yourJdlFile.jdl
├── foo
├── bar
├── kubernetes // will created by the JDL
└── docker-compose // will created by the JDL
* コメント＆Javadoc [#c9803216]
JavadocとコメントをJDLファイルに追加することは可能です。
Javaと同じように、この例ではJavadocコメントを追加する方法を示します。
/**
* Class comments.
* @author The JHipster team.
*/
entity MyEntity { // another form of comment
/** A required attribute */
myField String required
mySecondField String // another form of comment
}
/**
* Second entity.
*/
entity MySecondEntity {}
relationship OneToMany {
/** This is possible too! */
MyEntity{mySecondEntity}
to
/**
* And this too!
*/
MySecondEntity{myEntity}
}
これらのコメントは、後でJHipsterによってJavadocコメントとして追加されます。
JDLは独自のコメントを持っています。
// an ignored comment
/** not an ignored comment */
したがって、最初から始まるものはすべて//JDLの内部コメントと見なされ、Javadocとしてはカウントされません。
JDL Studioのディレクティブは#構文解析中に無視されます。
コメントの別の形式は以下のコメントです。
entity A {
name String /** My super field */
count Integer /** My other super field */
}
ここでAの名前はとMy super field、B はとコメントされMy other super fieldます。はい、コンマは必須ではありませんが、コードを間違えないようにするためにそれらを持つのが賢明です。カンマとそれに続くコメントを混在させる場合は、注意してください。
entity A {
name String, /** My comment */
count Integer
}
カウントがするので、Aの名前にはコメントがありません。
** すべての関係 [#rd873b27]
JDLとの関係を作成する方法についての説明。
*** 一対一 [#ob88e95f]
車に運転手がいて、運転手に車がある双方向の関係。
entity Driver
entity Car
relationship OneToOne {
Car{driver} to Driver{car}
}
市民がパスポートを持っているが、そのパスポートがその所有者だけにアクセスすることができない単方向の例。
entity Citizen
entity Passport
relationship OneToOne {
Citizen to Passport
}
// using @MapsId
relationship OneToOne {
Citizen to Passport with jpaDerivedIdentifier
}
*** 一対多 [#n2a26959]
所有者に1つ以上のCarオブジェクトがなく、Carがその所有者を知っている双方向の関係。
entity Owner
entity Car
relationship OneToMany {
Owner{car} to Car{owner}
}
この関係の単方向バージョンはJHipsterではサポートされていませんが、次のようになります。
entity Owner
entity Car
relationship OneToMany {
Owner to Car
}
*** 多対一 [#qbd0d4e1]
一対多の関係の相互バージョンは、以前と同じです。車がその所有者を知っている単方向バージョン：
entity Owner
entity Car
relationship ManyToOne {
Car to Owner
}
*** 多対多 [#f2db90e1]
最後に、この例では、ドライバを知っているCarがあり、Driverオブジェクトはそのcarにアクセスできます。
entity Driver
entity Car
relationship ManyToMany {
Car{driver} to Driver{car}
}
関係の所有側は左側になければならないことに注意してください
** 定数 [#sa8995c7]
JHipster Core v1.2.7以降、JDLは数値定数をサポートします。これが一例です。
DEFAULT_MIN_LENGTH = 1
DEFAULT_MAX_LENGTH = 42
DEFAULT_MIN_BYTES = 20
DEFAULT_MAX_BYTES = 40
DEFAULT_MIN = 0
DEFAULT_MAX = 41
entity A {
name String minlength(DEFAULT_MIN_LENGTH) maxlength(DEFAULT_MAX_LENGTH)
content TextBlob required
count Integer min(DEFAULT_MIN) max(DEFAULT_MAX)
}
* ワークフロー [#vfeb8300]
** モノリスワークフロー [#z7d7a43a]
ここに特別なワークフローはありません。
- アプリケーションを作成する
- JDLファイルを作成します
- インポートする
** マイクロサービスのワークフロー [#vfb0e38e]
マイクロサービスを扱うのは少し面倒ですが、JDLにはエンティティを適切に処理するためのオプションがいくつかあります。
ではmicroservice <ENTITIES> with <MICROSERVICE_APP_NAME>、あなたはどのmicroserviceに生成されますどのエンティティを指定することができます。例えばこの設定をしてください：
entity A
entity B
entity C
- microservice A with firstMS
- microservice B with secondMS
2つのJHipsterアプリケーション（「firstMS」と「secondMS」）があるとすると、2つのアプリケーションにJDLファイルをインポートすると、次のようになります。
- 'firstMS'では、エンティティAとCが生成されます。
- 「secondMS」では、エンティティBとCが生成されます。
Cなぜなら、このエンティティがどこで生成されるかを指定するマイクロサービスオプションがなければ、それはどこでも生成されるからです。このJDLをモノリスアプリケーションにインポートすることにした場合、すべてのエンティティが生成されます（モノリスにはJDLの制限オプションはありません）。
注：2つの異なるマイクロサービスで同じエンティティーを生成したい場合は、JDLファイルを更新する代わりに2つのJDLファイルを作成することができます。毎回。
前の例は、このように書かれたはずがありません。
entity A
entity B
entity C
microservice * except B with firstMS
microservice * except A with secondMS
これが結果です。
- 'firstMS'では、エンティティのみCが生成されます
- 「secondMS」では、エンティティBとCが生成されます。構文解析時に、あるオプションが別のオプションと重複する場合は、後者が優先されるためです。
JDLを使ってマイクロサービススタック全体を作成することもできます。例えば、このブログ記事
https://medium.com/jhipster/create-full-microservice-stack-using-jhipster-domain-language-under-30-minutes-ecc6e7fc3f77
を参照してください。
** 附属書 [#pa36af03]
*** 利用可能なアプリケーションオプション [#xc62a0d9]
JDLでサポートされているアプリケーションオプションは次のとおりです。
| JDLオプション名 | デフォルト値 | 可能な値 | コメント |
| applicationType | monolith | monolith, microservice, gateway | |
| authenticationType | jwt | jwt, session, oauth2 |jwt |
| baseName | jhipster | | |
| blueprint | | Name of an additional blueprint (see Marketplace) |DEPRECATED. String |
| blueprints | | Names of additional blueprints (see Marketplace) | |
| buildTool | maven | maven, gradle | |
| cacheProvider | ehcache or hazelcast | caffeine, ehcache, hazelcast, infinispan, memcached, redis, no |ehcache for monoliths and gateways, hazelcast otherwise |
| clientFramework | angularX | angularX, react | |
| clientPackageManager | npm | npm, yarn | |
| clientTheme | none | Something or none |うまくいくことがわかっていれば、好きな値を入れることができます (たとえばyeti). |
| clientThemeVariant | | Something or primary |うまくいくことがわかっていれば、好きな値を入れることができます (たとえば dark, もしくは light), 空にすることもできます |
| databaseType | sql | sql, mongodb, cassandra, couchbase, no | |
| devDatabaseType | h2Disk | h2Disk, h2Memory, * |* + prodデータベースタイプ |
| dtoSuffix | DTO | |DTO用のサフィックス.空の文字列の場合はfalse。 |
| enableHibernateCache | TRUE | | |
| enableSwaggerCodegen | FALSE | | |
| enableTranslation | TRUE | | |
| entitySuffix | | |エンティティ用のサフィックス.空の場合はfalse. |
| jhiPrefix | jhi | | |
| languages | [en, fr] | Languages available in JHipster |中括弧は必須です |
| messageBroker | FALSE | kafka, false | |
| nativeLanguage | en | Any language supported by JHipster | |
| packageName | com.mycompany.myapp | |packageのフォルダを設定します |
| prodDatabaseType | mysql | mysql, mariadb, mssql, postgresql, oracle, no | |
| reactive | FALSE | | |
| searchEngine | FALSE | elasticsearch, false | |
| serverPort | 8080, 8081 or 9999 | |アプリの種類によって異なります |
| serviceDiscoveryType | FALSE | eureka, consul, no | |
| skipClient | FALSE | | |
| skipServer | FALSE | | |
| skipUserManagement | FALSE | | |
| testFrameworks | [] | cypress, protractor, cucumber, gatling |中括弧は必須 |
| websocket | FALSE | spring-websocket, false | |
** 利用可能な展開オプション [#a86aefbd]
JDLでサポートされているアプリケーションオプションは次のとおりです。
|JDLオプション名 |デフォルト値 |可能な値 |コメント|
| JDL option name | Default value | Possible values | Comment |
| deploymentType | docker-compose | docker-compose, kubernetes, openshift | |
| directoryPath | "../" | | 相対パス。二重引用符で囲む必要があります |
| appsFolders | [] | | カンマで区切られたアプリケーションのディレクトリ名。リストである必要があります、例 [foo, bar] |
| clusteredDbApps | [] | | クラスター化されたDBがコンマで区切られているアプリケーションのディレクトリー名。リストである必要があります、例 [foo, bar] |
| gatewayType | SpringCloudGateway | serviceDiscoveryTypeが `no`の場合、値は無視されます | |
| monitoring | no | no, prometheus | |
| serviceDiscoveryType | eureka | eureka, consul, no | |
| dockerRepositoryName | | | Dockerリポジトリの名前またはURL。二重引用符で囲む必要があります |
| dockerPushCommand | "docker push" | | 使用するdockerpushコマンド。二重引用符で囲む必要があります |
| kubernetesNamespace | default | | DeploymentTypeがkubernetesの場合にのみ適用可能 |
| kubernetesUseDynamicStorage | FALSE | true, false | DeploymentTypeがkubernetesの場合にのみ適用可能で、kubernetesStorageClassNameオプションを有効にします |
| kubernetesStorageClassName | "" | | DeploymentTypeがkubernetesの場合にのみ適用可能で、空のままにすることができます（2つの二重引用符） |
| kubernetesServiceType | LoadBalancer | LoadBalancer, NodePort, Ingress | DeploymentTypeがkubernetesの場合にのみ適用可能 |
| ingressDomain | | | kubernetesServiceTypeが `Ingress`の場合のIngressのドメイン。二重引用符で囲む必要があります。 DeploymentTypeがkubernetesの場合にのみ適用可能 |
| ingressType | nginx | nginx, gke | kubernetes入力タイプ。`kubernetesServiceType`が入力に設定されている場合にのみ設定されます |
| istio | FALSE | true, false | DeploymentTypeがkubernetesの場合にのみ適用可能 |
| openshiftNamespace | default | | DeploymentTypeがopenshiftの場合にのみ適用可能 |
| storageType | ephemeral | ephemeral, persistent | DeploymentTypeがopenshiftの場合にのみ適用可能 |
| registryReplicas | 2 | | OpenShiftデプロイメントタイプを使用する場合のレプリカの数 |
** 利用可能なフィールドタイプと制約 [#k0f4973f]
JDLでサポートされている型は次のとおりです。
** 共通データベース [#o5302051]
- PostgreSQL
- MySQL
- MariaDB
- オラクル
- MsSQL
- MongoDB
- カウチベース
** フィールドタイプと検証 [#y8f9e138]
各フィールドタイプには、独自の検証リストがあります。 JDLでサポートされているタイプは次のとおりです。
| JDL type | Validations |
| String | required, minlength, maxlength, pattern, unique |
| Integer | required, min, max, unique |
| Long | required, min, max, unique |
| BigDecimal | required, min, max, unique |
| Float | required, min, max, unique |
| Double | required, min, max, unique |
| Enum | required, unique |
| Boolean | required, unique |
| LocalDate | required, unique |
| ZonedDateTime | required, unique |
| Instant | required, unique |
| Duration | required, unique |
| UUID | required, unique |
| Blob | required, minbytes, maxbytes, unique |
| AnyBlob | required, minbytes, maxbytes, unique |
| ImageBlob | required, minbytes, maxbytes, unique |
| TextBlob | required, unique |
** 利用可能なオプション [#b1ef7375]
*** 単項オプション [#g4c01a54]
これらのオプションには意味がありません。
- skipClient
- skipServer
- noFluentMethod
- filter
彼らはこのように使用することができます： <OPTION> <ENTITIES | * | all> except? <ENTITIES>
*** バイナリーオプション [#a63bd725]
これらのオプションは値を取ります。
- dto（mapstruct）
- service（serviceClass、serviceImpl）
- paginate（pager、pagination、infinite-scroll）
- search（elasticsearch）
- microservice （カスタム値）
- angularSuffix （カスタム値）
- clientRootFolder （カスタム値）
** トラブルシューティング [#t252e19f]
***JDLインポートは、MS baseNameと一致するときに1つのエンティティーのみを検出します [#h66ae45e]
これは構文解析システムに関する既知の問題であり、修正するのは難しいです。明らかな回避策は、マイクロサービスと内部のエンティティに異なる名前を使用することです。
詳細についてはJHipster Core issue＃308
https://github.com/jhipster/jhipster-core/issues/308
を参照してください。
* 問題とバグ [#vf22b48b]
JDLはGitHub
https://github.com/jhipster/jhipster-core
から入手でき、JHipsterと同じ 貢献ガイドライン
https://github.com/jhipster/generator-jhipster/blob/master/CONTRIBUTING.md
に従っています。
図書館自体に関する問題やプルリクエストを提出するために私たちのプロジェクトを使ってください。
- JDL課題追跡システム [#l70d7bf2]
https://github.com/jhipster/jhipster-core/issues
- JDLプルリクエスト
https://github.com/jhipster/jhipster-core/pulls
何かを送信するときは、できるだけ正確にする必要があります。
- 1つの投稿された号には1つの問題
- プルリクエストは歓迎されていますが、実際に理解できるようにするためにはコミットは 'アトミック'でなければなりません。
* 翻訳者注：さいごに [#ad5859bf]
このページは、だれでも、編集可能にしてあります。
googleの翻訳をベースに、作成してありますが、加筆修正など、
気づいたらお願いします。
* 練習してみる [#o76fd13c]
以下、訳者の練習ターンです。
さて、翻訳は、だいだいこの辺にしておいて、エンティティを作ってみようと思います。
JDLのサンプルって、HelloWorldにしては、ちょっと、おおきいじゃないですか。
まずは、小さく、やってみたら、どうなるか。実験してみましょうか。
https://start.jhipster.tech/jdl-studio/
を開いて、既存のコードをバッサリ消して、下記のコードをいれてみます。
// AEntityComment
entity AEntity {
// AEntityNameComment
aEntityName String
}
右上のダウンロードボタンを押すと、jhipster-jdl.jhがダウンロードされます。
自分のアプリのフォルダにこの、ダウンロードしてきたファイルをもってきて、
gradlew clean
jshipster import-jdl さっきダウンロードしたファイル名
で、--forceオプションつけとかなかったので、いろいろ上書き確認されてしまった。
*** 1個のエンティティ作成の結果はこんな感じ [#k0eff1f2]
Found the .jhipster/AEntity.json configuration file, entity can be automatically generated!
The entity AEntity is being updated.
info Using blueprint generator-jhipster-vuejs for entity-client subgenerator
create
src\main\resources\config\liquibase\changelog\20190719011806_added_entity_AEntity.xml
create src\main\resources\config\liquibase\data\a_entity.csv
create src\main\java\com\mycompany\myapp\domain\AEntity.java
create src\main\java\com\mycompany\myapp\repository\AEntityRepository.java
create src\main\java\com\mycompany\myapp\web\rest\AEntityResource.java
create src\test\java\com\mycompany\myapp\web\rest\AEntityResourceIT.java
conflict src\main\resources\config\liquibase\master.xml
? Overwrite src\main\resources\config\liquibase\master.xml? overwrite
force src\main\resources\config\liquibase\master.xml
conflict src\main\java\com\mycompany\myapp\config\CacheConfiguration.java
? Overwrite src\main\java\com\mycompany\myapp\config\CacheConfiguration.java?
overwrite
force src\main\java\com\mycompany\myapp\config\CacheConfiguration.java
create src\main\webapp\app\entities\a-entity\a-entity-details.vue
create src\main\webapp\app\entities\a-entity\a-entity-update.vue
create src\main\webapp\app\entities\a-entity\a-entity.vue
conflict src\main\webapp\app\core\jhi-navbar\jhi-navbar.vue
? Overwrite src\main\webapp\app\core\jhi-navbar\jhi-navbar.vue? overwrite
force src\main\webapp\app\core\jhi-navbar\jhi-navbar.vue
create src\main\webapp\app\entities\a-entity\a-entity-details.component.ts
create src\main\webapp\app\entities\a-entity\a-entity-update.component.ts
create src\main\webapp\app\entities\a-entity\a-entity.component.ts
create src\main\webapp\app\entities\a-entity\a-entity.service.ts
create src\main\webapp\app\shared\model\a-entity.model.ts
create src\test\javascript\spec\app\entities\a-entity\a-entity.component.spec.ts
create src\test\javascript\spec\app\entities\a-entity\a-entity-detail.component.spec.ts
create src\test\javascript\spec\app\entities\a-entity\a-entity- update.component.spec.ts
create src\test\javascript\spec\app\entities\a-entity\a-entity.service.spec.ts
conflict src\main\webapp\app\router\index.ts
? Overwrite src\main\webapp\app\router\index.ts? overwrite
force src\main\webapp\app\router\index.ts
conflict src\main\webapp\app\main.ts
? Overwrite src\main\webapp\app\main.ts? overwrite
force src\main\webapp\app\main.ts
create src\main\webapp\i18n\en\aEntity.json
conflict src\main\webapp\i18n\en\global.json
? Overwrite src\main\webapp\i18n\en\global.json? overwrite
force src\main\webapp\i18n\en\global.json
create src\main\webapp\i18n\ja\aEntity.json
conflict src\main\webapp\i18n\ja\global.json
? Overwrite src\main\webapp\i18n\ja\global.json? overwrite
force src\main\webapp\i18n\ja\global.json
Running `webpack:build` to update client app
Entity AEntity generated successfully.
1つのエンティティ追加だけで、これだけのファイルが修正されるのだね。
** 画面上でなにが変わるのか。 [#w5e51b5b]
えーっとですね。まずユーザで、ログインしてみたところ、メニューに、「エンティティ」のドロップダウンが追加されてました。
リストにダミーデータが入っている！
** JDLで書いたコメントはどうなったのだろうか。 [#q9d97d70]
上記のサンプルのjdlに、記入したコメントは、生成に反映されるのか確認
AEntityCommentは、どこに消えた？...
どこにも、反映されてないもよう。
AEntityNameCommentは、どこに消えた？...
これも、反映されてないもよう。
実験の結果、jdlのコメントは、生成時に、ないものとして、処理されてから、生成されていることがわかりました。
** 実験２ エンティティのカラムを１つ追加したらどうなるのか？ [#ca0c891c]
例えば、エンティティにメールアドレスを追加しとしたら、どうなるのでしょう。
entity AEntity {
aEntityName String
aMailAddress String
}
でやってみます。
jhipster import-jdl jhipster-jdl.jh
*** 結果 [#ldb41b26]
Found the .jhipster/AEntity.json configuration file, entity can be automatically generated!
The entity AEntity is being updated.
info Using blueprint generator-jhipster-vuejs for entity-client subgenerator
create src\main\resources\config\liquibase\changelog\20190719014642_added_entity_AEntity.xml
conflict src\main\resources\config\liquibase\data\a_entity.csv
? Overwrite src\main\resources\config\liquibase\data\a_entity.csv? overwrite
force src\main\resources\config\liquibase\data\a_entity.csv
conflict src\main\java\com\mycompany\myapp\domain\AEntity.java
? Overwrite src\main\java\com\mycompany\myapp\domain\AEntity.java? overwrite
force src\main\java\com\mycompany\myapp\domain\AEntity.java
identical src\main\java\com\mycompany\myapp\repository\AEntityRepository.java
identical src\main\java\com\mycompany\myapp\web\rest\AEntityResource.java
conflict src\test\java\com\mycompany\myapp\web\rest\AEntityResourceIT.java
? Overwrite src\test\java\com\mycompany\myapp\web\rest\AEntityResourceIT.java? overwrite
force src\test\java\com\mycompany\myapp\web\rest\AEntityResourceIT.java
conflict src\main\resources\config\liquibase\master.xml
? Overwrite src\main\resources\config\liquibase\master.xml? overwrite
force src\main\resources\config\liquibase\master.xml
identical src\main\java\com\mycompany\myapp\config\CacheConfiguration.java
conflict src\main\webapp\app\entities\a-entity\a-entity-details.vue
? Overwrite src\main\webapp\app\entities\a-entity\a-entity-details.vue? overwrite
force src\main\webapp\app\entities\a-entity\a-entity-details.vue
conflict src\main\webapp\app\entities\a-entity\a-entity-update.vue
? Overwrite src\main\webapp\app\entities\a-entity\a-entity-update.vue? overwrite
force src\main\webapp\app\entities\a-entity\a-entity-update.vue
conflict src\main\webapp\app\entities\a-entity\a-entity.vue
? Overwrite src\main\webapp\app\entities\a-entity\a-entity.vue? overwrite
force src\main\webapp\app\entities\a-entity\a-entity.vue
identical src\main\webapp\app\core\jhi-navbar\jhi-navbar.vue
identical src\main\webapp\app\entities\a-entity\a-entity-details.component.ts
conflict src\main\webapp\app\entities\a-entity\a-entity-update.component.ts
? Overwrite src\main\webapp\app\entities\a-entity\a-entity-update.component.ts? overwrite
force src\main\webapp\app\entities\a-entity\a-entity-update.component.ts
identical src\main\webapp\app\entities\a-entity\a-entity.component.ts
identical src\main\webapp\app\entities\a-entity\a-entity.service.ts
conflict src\main\webapp\app\shared\model\a-entity.model.ts
? Overwrite src\main\webapp\app\shared\model\a-entity.model.ts? overwrite
force src\main\webapp\app\shared\model\a-entity.model.ts
identical src\test\javascript\spec\app\entities\a-entity\a-entity.component.spec.ts
identical src\test\javascript\spec\app\entities\a-entity\a-entity-detail.component.spec.ts
identical src\test\javascript\spec\app\entities\a-entity\a-entity-update.component.spec.ts
conflict src\test\javascript\spec\app\entities\a-entity\a-entity.service.spec.ts
? Overwrite src\test\javascript\spec\app\entities\a-entity\a-entity.service.spec.ts? overwrite
force src\test\javascript\spec\app\entities\a-entity\a-entity.service.spec.ts
identical src\main\webapp\app\router\index.ts
identical src\main\webapp\app\main.ts
conflict src\main\webapp\i18n\en\aEntity.json
? Overwrite src\main\webapp\i18n\en\aEntity.json? overwrite
force src\main\webapp\i18n\en\aEntity.json
identical src\main\webapp\i18n\en\global.json
conflict src\main\webapp\i18n\ja\aEntity.json
? Overwrite src\main\webapp\i18n\ja\aEntity.json? overwrite
force src\main\webapp\i18n\ja\aEntity.json
identical src\main\webapp\i18n\ja\global.json
Running `webpack:build` to update client app
Entity AEntity generated successfully.
で、気になるエラーが
liquibase.exception.ValidationFailedException: Validation Failed:
1 change sets check sum
config/liquibase/changelog/20190719011806_added_entity_AEntity.xml::20190719011806-1-data::jhipster was: 8:a3c3a4caf7a78df32f18798fc9eb3fb7 but is now: 8:e7433bda47ea85d0868d7996ab6aeb15
*** ログファイルのありか [#ua9ab501]
config/liquibase/changelog
*** 画面で確認すると、次のエラーが [#z56c967a]
Caused by: org.h2.jdbc.JdbcSQLSyntaxErrorException: 列 "A_MAIL_ADDRESS" が見つかりません
カラムが更新されていないようだ。カラム追加には、何か、作法があるのだろう。
ググると、liquibaseチェックサムが働いて、勝手に変更できないようになってるみたい。
mavenの場合は、
mvn liquibase:clearCheckSums
ってやらないと、叱られちゃうみたい。
gradleの場合は、
./gradlew liquibaseClearChecksums --stacktrace
なんだけど、
Caused by: org.gradle.internal.resolve.ModuleVersionNotFoundException: Could not find mysql:mysql-connector-java:.
って怒られた
** もしかして、 エンティティのカラム追加にコマンドあるんじゃないか説 [#p098aec4]
jhipster entity 変更したいエンティティ
で、追加メニューがあることを確認しました。
修正したいエンティティが、今回たまたま、 AEntityだったとすると
jhipster entity AEntity
と書きます。
すると、次のコマンドラインの質問がきます。
The entity AEntity is being updated.
? Do you want to update the entity? This will replace the existing files for this entity, all your custom code will be o
verwritten (Use arrow keys)
> Yes, re generate the entity
Yes, add more fields and relationships
Yes, remove fields and relationships
No, exit
カーソルキーの上下で、選びます。
でも、このやり方も、一度、ダミーデータがはいってしまうと、データベースの変更チェックがはたらいてしまいました。
** どうやって、回避するの？ [#ndd4fb32]
いまのところ、うまくいくのは、
gradle clean
というありがちな方法でした。さいしょっから、やっておけばよかった。
