JHIPSTER JDL のバックアップ(No.2)

既存のプロジェクト（コマンドラインを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サンプル †

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

にそのためのリポジトリがあります。

↑

どうやって使うのですか †

↑

JDLファイルのインポート †

その後、JDLファイルを使用してエンティティを生成できます。

拡張子が「.jh」または「.jdl」のファイルを作成するだけです。
アプリケーション、デプロイメント、エンティティ、および関係を宣言するか、JDL-Studio

https://start.jhipster.tech/jdl-studio/

またはJHipster IDE

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ファイルへのエクスポート †

アプリケーションに既にエンティティがあり、JDLファイルを取得したい場合は、そうしないでください。あなたのためにそれをするサブジェネレータがあるので、あなたは最初からそれを書く必要はありません。

jhipster export-jdl <FILE_NAME>アプリのルートフォルダで実行するだけで、すべてのエンティティ、関係、およびオプションのエクスポートが1つのJDLファイルにまとめられます。注：サブ世代にファイル名を指定することもできません。デフォルトのものが選択されます。

↑

言語 †

私たちは開発者にとってできるだけフレンドリーな構文を保つようにしました。あなたはそれでこれらのことをすることができます：

アプリケーションをそのオプションとエンティティで宣言します。
エンティティをその属性で宣言します。
それらの間の関係を宣言する、
そしてJHipster特有のオプションをいくつか宣言します。

JDLの文法を見たいのであれば、ここ

https://github.com/jhipster/jhipster-core/blob/master/lib/dsl/gen/grammar.html

に HTMLファイルがあります。

↑

アプリケーション宣言 †

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でもまったく同じことができます。

↑

エンティティ宣言 †

エンティティ宣言は次のように行われます。

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フィールドを追加しているので、心配する必要はありません。

↑

関係宣言 †

関係の宣言は次のように行われます。

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名前ではなく、ユーザに示すことができるように、フロントエンドに連結されたエンティティのを。

↑

列挙型 †

JDLを使ってEnumを作るには、次のようにします。

ファイル内の任意の場所にEnumを宣言します。

 enum Language {
   FRENCH, ENGLISH, SPANISH
 }

エンティティで、Enumを型として持つフィールドを追加します。

 entity Book {
   title String required,
   description String,
   language Language
 }

↑

ブロブ（byte []） †

JHipsterは、イメージタイプと任意のバイナリタイプの間で選択できるので、素晴らしい選択をします。JDLを使えば同じことができます。エディタを使ってカスタムタイプ（DataType?を参照）を作成し、次の規約に従って名前を付けます。

AnyBlob?または単にBlob「任意」のバイナリ型のフィールドを作成すること。
ImageBlob? イメージであることを意味するフィールドを作成すること。
TextBlob? CLOB（テキスト（長））のフィールドを作成します。

そして、あなたは好きなだけデータ型を作成することができます。

↑

オプション宣言 †

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ファイルを破損しないように無視します。

↑

サービスオプション †

指定されたサービスは、リポジトリインタフェースを直接呼び出すリソースクラスを作成しません。これはデフォルトで最も単純なオプションです。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

↑

マイクロサービス関連のオプション †

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番目のオプションはあなたのエンティティをどのようにそしてあなたが検索したいかを指定します。

↑

アノテーション †

注釈は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ファイルを使用する場合（マイクロサービスなど）には実際には便利です。

↑

デプロイメント宣言 †

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 †

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の名前にはコメントがありません。

↑

すべての関係 †

JDLとの関係を作成する方法についての説明。

↑

一対一 †

車に運転手がいて、運転手に車がある双方向の関係。

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
}

↑

一対多 †

所有者に1つ以上のCarオブジェクトがなく、Carがその所有者を知っている双方向の関係。

entity Owner
entity Car
relationship OneToMany {
  Owner{car} to Car{owner}
}

この関係の単方向バージョンはJHipsterではサポートされていませんが、次のようになります。

entity Owner
entity Car
relationship OneToMany {
  Owner to Car
}

↑

多対一 †

一対多の関係の相互バージョンは、以前と同じです。車がその所有者を知っている単方向バージョン：

entity Owner
entity Car
relationship ManyToOne {
  Car to Owner
}

↑

多対多 †

最後に、この例では、ドライバを知っているCarがあり、Driverオブジェクトはそのcarにアクセスできます。

entity Driver
entity Car
relationship ManyToMany {
  Car{driver} to Driver{car}
}

関係の所有側は左側になければならないことに注意してください

↑

定数 †

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)
}

↑

ワークフロー †

↑

モノリスワークフロー †

ここに特別なワークフローはありません。

アプリケーションを作成する
JDLファイルを作成します
インポートする

↑

マイクロサービスのワークフロー †

マイクロサービスを扱うのは少し面倒ですが、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

を参照してください。

↑

附属書 †

↑

利用可能なアプリケーションオプション †

JDLでサポートされているアプリケーションオプションは次のとおりです。

JDLオプション名

デフォルト値

可能な値

アプリケーションタイプモノリスモノリス、マイクロサービス、ゲートウェイ、UAA baseName ジップスターパッケージ名 com.mycompany.myapp packageFolderオプションを設定します authenticationType jwtまたはuaa jwt、session、uaa、oauth2 UAAアプリの場合はuaa、それ以外の場合はjwt uaaBaseName? 認証タイプがuaaの場合、ゲートウェイおよびマイクロサービスには必須です。二重引用符で囲む必要があります。 buildTool メイヴンメイヴン、グラドル databaseType SQL sql、mongodb、cassandra、couchbase、いいえ devDatabaseType? h2ディスク h2ディスク、h2メモリ、* * + prodデータベースの種類 prodDatabaseType? MySQL mysql、mariadb、mssql、postgresql、oracle、いいえ cacheProvider ehcacheまたはhazelcast ehcache、ヘーゼルキャスト、不定詞、no モノリスおよびゲートウェイ用のehcache、それ以外の場合はhazelcast enableHibernateCache? 本当の clientFramework 角度X angularX、反応する useSass 偽 clientPackageManager? 午後 npm、糸 entitySuffix エンティティのサフィックス。空の文字列の場合はfalseです。 dtoSuffix DTO DTOのサフィックス。空の文字列の場合はfalseです。 jhiPrefix チ enableTranslation 本当の母国語 en JHipsterでサポートされている任意の言語言語 [en、fr] JHipsterで利用可能な言語中括弧は必須です enableSwaggerCodegen? 偽 serviceDiscoveryType? 偽ユーレカ、領事、いいえ messageBroker 偽カフカ、偽検索エンジン偽 elasticsearch、false サーバポート 8080、8081または9999 アプリの種類によりますウェブソケット偽 spring-websocket、false testFrameworks [] 分度器、きゅうり、ガトリングブレース必須 skipClient 偽 skipServer 偽 skipUserManagement? 本当の

↑

利用可能な展開オプション †

JDLでサポートされているアプリケーションオプションは次のとおりです。

JDLオプション名

デフォルト値

可能な値

deploymentType docker-compose docker-compose、kubernetes、openshift directoryPath 「../」相対パス二重引用符で囲む必要があります appsフォルダ [] アプリケーションのディレクトリ名をカンマで区切って指定します。リストでなければなりません。例[foo、bar] clusteredDbApps? [] クラスタDBを含むアプリケーションのディレクトリ名をカンマで区切って指定します。リストでなければなりません。例[foo、bar] gatewayType ズールーズールー、traefik serviceDiscoveryType?が `no`の場合、値は無視されますモニタリングいいえいいえ、ヘラジカ、プロメテウス consoleOptions [] [学芸員、ジップキン] リストでなければなりません serviceDiscoveryType? ユーレカユーレカ、領事、いいえ dockerRepositoryName? dockerリポジトリの名前またはURL。二重引用符で囲む必要があります dockerPushCommand? 「ドッカープッシュ」使用するdocker pushコマンド。二重引用符で囲む必要があります kubernetesNamespace デフォルト deploymentTypeがkubernetesの場合にのみ適用可能 kubernetesServiceType? ロードバランサロードバランサ、NodePort?、入力 deploymentTypeがkubernetesの場合にのみ適用可能 ingressDomain kubernetesServiceType?が `Ingress`の場合のIngressのドメイン二重引用符で囲む必要があります。deploymentTypeがkubernetesの場合にのみ適用可能 istio いいえいいえ、manualInjection、autoInjection deploymentTypeがkubernetesの場合にのみ適用可能 openshiftNamespace デフォルト deploymentTypeがopenshiftの場合にのみ適用されます。 storageType はかないはかない、しつこい deploymentTypeがopenshiftの場合にのみ適用されます。

↑

利用可能なフィールドタイプと制約 †

JDLでサポートされている型は次のとおりです。

↑

共通データベース †

PostgreSQL
MySQL
MariaDB
オラクル
MsSQL
MongoDB
カウチベース

共通データベース

カサンドラ

検証

ひもひも必須、最小長、最大長、パターン、固有整数整数必須、最小、最大、ユニーク長いです長いです必須、最小、最大、ユニーク BigDecimal? BigDecimal? 必須、最小、最大、ユニーク浮く浮く必須、最小、最大、ユニークダブルダブル必須、最小、最大、ユニーク列挙型必須、ユニークブール値ブール値必須、ユニーク LocalDate? 必須、ユニーク日付必須、ユニーク ZonedDateTime? 必須、ユニーク期間必須、ユニーク UUID UUID 必須、ユニークブロブ必須、最小バイト数、最大バイト数、固有 AnyBlob? 必須、最小バイト数、最大バイト数、固有 ImageBlob? 必須、最小バイト数、最大バイト数、固有 TextBlob? 必須、ユニークインスタントインスタント必須、ユニーク