jhipster / jhipster-core

JHipster Domain Language, used by JHipster UML and JDL-Studio to generate entities

Warning

This repository is being discontinued. Its source code is being merged in the generator's repo (jhipster/generator-jhipster#11694). New PRs in this repo won't be merged.

---

---

Welcome to the official repository of everything common to JHipster and its projects, like the JDL (JHipster Domain Language).

Please read our guidelines before submitting an issue. If your issue is a bug, please use the bug template pre-populated here. For feature requests and queries you can use this template.

Contributing to JHipster-Core

For more details about the project structure and detailed examples on how to update JDL please refer our documentation pages.

Releasing

1. Commit any changes done, to ensure working directory is clean
2. Run the release script - You need to be logged into NPM
   • To release a patch version, simply run npm run release-patch
   • To release a minor version, simply run npm run release-minor
   • To release a major version, simply run npm run release-major

jhipster-core's Issues

Extra User Warning

When I import the below JDL, I get a warning about User even though User was not referenced. This is with master version of jhipster which links to v1.1.7 of jhipster-core

The jdl is being parsed.
Warning:  An Entity name 'User' was used: 'User' is an entity created by default by JHipster. All relationships toward it will be kept but any attributes and relationships from it will be disregarded.
Writing entity JSON files.
Generating entities.

JDL from Microservice section of documentation:

entity A
entity B
entity C

microservice * with mysuperjhipsterapp except C
microservice C with myotherjhipsterapp

On a side note, the line search * with ElasticSearch except C from the Microservice section of the documentation is considered invalid JDL.

relationships not generated

The following does not fill in the relationship fields for any entities in the .json files that are generated.

entity Organization {
name String required,
description String,
createdDate ZonedDateTime,
lastModifiedDate ZonedDateTime
}

entity Region {
name String required,
description String,
createdDate ZonedDateTime,
lastModifiedDate ZonedDateTime
}

entity Location {
name String required,
description String,
latitude Float,
longitude Float,
altitude Float,
createdDate ZonedDateTime,
lastModifiedDate ZonedDateTime,
markerIcon String
}

entity FormOutline {
title String required,
description String,
createdDate ZonedDateTime,
lastModifiedDate ZonedDateTime
}

entity FormComplete {
createdDate ZonedDateTime,
lastModifiedDate ZonedDateTime
}

entity FormOutlineString {
label String required
}

entity FormOutlineFloat {
label String required
}

entity FormOutlineDatetime {
label String required
}

entity FormCompleteString {
value String required
}

entity FormCompleteFloat {
value Float required
}
entity FormCompleteDatetime {
value ZonedDateTime required
}

relationship OneToMany {
FormOutline{formoutlinestring(label)} to FormOutlineString{formoutline(title)},
FormOutline{formoutlinefloat(label)} to FormOutlineFloat{formoutline(title)},
FormOutline{formoutlinedatetime(label)} to FormOutlineDatetime{formoutline(title)},
FormOutline{formcomplete} to FormComplete{formoutline(title)},
FormComplete{formcompletestring(value)} to FormCompleteString{formcomplete},
FormComplete{formcompletefloat(value)} to FormCompleteFloat{formcomplete},
FormComplete{formcompletedatetime(value)} to FormCompleteDatetime{formcomplete},
FormOutlineDatetime{formcompletedatetime} to FormCompleteDateTime{formoutlinedatetime(label)},
FormOutlineString{formcompletestring} to FormCompleteString{formoutlinestring(label)},
FormOutlineFloat{formcompletefloat} to FormCompleteFloat{formoutlinefloat(label)}
}

relationship ManyToMany {
Region{location(name)} to Location{region(name)}
}

Import a jdl definition which uses User entity

Overview of the issue

(from jhipster/generator-jhipster#3977)

I wish to use the User entity in order to associate each User with a Customer.

JDL-Importing such a definition generates an error

$ yo jhipster:import-jdl jhipster-jdl.jh
The jdl is being parsed.
Error jhipster:import-jdl jhipster-jdl.jh 

ERROR! Error while parsing entities from JDL
[object Object]

further inspecting the error is In the relationship between User and Customer, User is not declared.

Reproduce the error

1. yo jhipster to produce a basic project
2. Create jhipster-jdl.jh

    relationship OneToMany{
        User{customer} to Customer
     } 
    entity Customer {

        legalName String required
        birthDate LocalDate
        vatid String
        business Boolean required
    }

1. Import
   $ yo jhipster:import-jdl jhipster-jdl.jh

JHipster Version(s)

BTW I'm quite sure it is a regression bug.

[email protected] /home/lrkwz/generator-jhipster-extend-user
└── [email protected] 

JHipster configuration, a .yo-rc.json file generated in the root folder

{
  "generator-jhipster": {
    "jhipsterVersion": "3.5.1",
    "baseName": "test_customer",
    "packageName": "com.mycompany.myapp",
    "packageFolder": "com/mycompany/myapp",
    "serverPort": "8080",
    "authenticationType": "jwt",
    "hibernateCache": "ehcache",
    "clusteredHttpSession": "no",
    "websocket": "no",
    "databaseType": "sql",
    "devDatabaseType": "h2Disk",
    "prodDatabaseType": "mysql",
    "searchEngine": "no",
    "buildTool": "maven",
    "enableSocialSignIn": false,
    "jwtSecretKey": "308c83521a7f64cc27d75631dc2d1844913fe224",
    "useSass": false,
    "applicationType": "monolith",
    "testFrameworks": [
      "gatling"
    ],
    "jhiPrefix": "jhi",
    "enableTranslation": true,
    "nativeLanguage": "en",
    "languages": [
      "en",
      "it"
    ]
  }
}

Entity configuration(s) entityName.json files generated in the .jhipster directory

Browsers and Operating System

java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

git version 1.9.1

node: v4.2.1

npm: 3.10.5

bower: 1.7.9

gulp:
[14:40:57] CLI version 1.2.2
[14:40:57] Local version 3.9.1

yeoman: 1.7.1

Docker version 1.11.2, build b9f10c9

docker-compose version 1.7.1, build 0a9ab35

Inheritance, and 'extends'

I didn’t find any way to do inheritance. It would nice to do it as java does it:

entity Job {
    jobId Long,
    jobTitle String,
    minSalary Long,
    maxSalary Long
}
entity Barmaid extends Job
entity ProjectManager extends Job

I may do it after september if you want but it may take time!

Replace "angularSuffixes" by "angularSuffix"

In the grammar, the pegjs parser must be built again.
This must be replaced as well, and this must only take two args because name = key.
cc @deepu105 (by the way, great work man!)

Wrong names

Names only have unique letters in it. For instance, Employee will be returned as "Employe".

Maxbytes and minbytes validation issue

These two constraints are passed as minlength and maxlength.
Posted here.

Negative integers not supported by jhipster-uml and JDL online editor

This entity declaration

entity Location {
    longitude Double min(-180) max(180)
}

generates the following error message in jhipster-uml and in the JDL online editor:
Expected a space or integer but "-" found. -> line: 2

Of course a negative integer is as much an integer number as a positive one ...

Expose more methods

These methods have to be exposed (the following list is not complete):

• JDLReader#checkFileIsJDLFile.

Add the searchEngine option

Create bulk and fine grained relationships

when creating complex models it would be nice to have features to create relationships more efficiently

I would like to propose 2 new ways for this

1. create an alternate syntax to add relationships naturally to entity which java devs would be familiar to, we do this already for enum why not have same support for relationship as well
   We can continue to create the other side automatically as we do now and people who want the current syntax can continue using that

entity Region {
    regionId Long,
    regionName String
    @OneToOne
    country Country required
}

entity Country {
    countryId Long,
    countryName String
}

2. another convenience would be to do multiple declaration like below which would make more sense for our current relationship syntax

relationship OneToOne {
    Country{region} to Region
    Location{country} to Country
}

relationship OneToMany {
    Employee{job} to Job
    Location{country} to Country
}

@jhipster/developers opinions please

Roadmap for initial release

Below is the skeleton that should be supported at the minimum IMO for this to be reusable in all places

var self = {
  parse: parse, // this should accept a JDL string data and output a parsed object same as today required for JHUML
  parseIntermediate: parseIntermediate, // this should be called inside the above method but needs to be exposed as well, this accepts a JDL string and outputs the current pegjs parsed json, this could be used by JDL studio etc
  parseToJson: parseToJson // this could parse the JDL and output an array of Jhipster compatible json entities 
};

@MathieuAA what is your idea?

Genarating DTOs with MapStruct gives compiler error for complex model

Generating entities including DTOs with jhipster-uml from this JDL file:

entity Beacon {
    id Long,  // UUIDs aren't supported
    name String required minlength(2) maxlength(100),
}

entity Application {
    id Long,
    name String required minlength(2) maxlength(100),
}

entity Campaign {
    id Long,
    name String required minlength(2) maxlength(100),
}

entity Company {
    id Long,
    name String required minlength(2) maxlength(100),
}


relationship ManyToOne {
    Beacon{owner(name)} to Company,
    Application{owner(name)} to Company,
    Campaign{owner(name)} to Company
}

relationship ManyToMany {
    Campaign{beacons(name)} to Beacon{campaigns},
    Campaign{applications(name)} to Application{campaigns},
    Company{users(login)} to User{companies}
}

dto all with mapstruct

Gives the following Java compilation error when compiling the generated code:

:compileJava
/Users/ole/work/misc/mappingBug/src/main/java/io/github/jhipster/mappingbug/web/rest/mapper/CampaignMapper.java:22: error: Ambiguous mapping methods found for mapping property "java.lang.Long ownerId" to io.github.jhipster.mappingbug.domain.Company: io.github.jhipster.mappingbug.domain.Company companyFromId(java.lang.Long id), io.github.jhipster.mappingbug.domain.Company io.github.jhipster.mappingbug.web.rest.mapper.BeaconMapper.companyFromId(java.lang.Long id), io.github.jhipster.mappingbug.domain.Company io.github.jhipster.mappingbug.web.rest.mapper.ApplicationMapper.companyFromId(java.lang.Long id).
    Campaign campaignDTOToCampaign(CampaignDTO campaignDTO);
             ^
1 error
:compileJava FAILED

FAILURE: Build failed with an exception.

The full example code can be viewed at:
github.com/sensorberg-dev/mappingBug

Add required relationships

Correctly handle unary options

Doesn't handle correctly unary options (fluent methods, client code generation skipping, etc.).

Remove chalk?

We should remove chalk as I'd rather let the package calling the JDL project use colors or not use them at all.

Microservice Entities

When generating entities for a microservice, the correct attribute in the entity JSON is microserviceName. Currently the generator outputs microservice instead.

This issue prevents gateways from generating entities from a microservice

Support for microserviceName

For JHipster 3 we added a new field (microserviceName) to the entities JSON for micro-services entities.

microservice1/.jhipster/Foo.json :

{
    "relationships": [],
    "fields": [
        {
            "fieldName": "name",
            "fieldType": "String"
        }
    ],
    "changelogDate": "20160322132123",
    "dto": "no",
    "service": "no",
    "entityTableName": "foo",
    "pagination": "no",
    "microserviceName": "microservice1",
    "searchEngine": "no"
}

On the micro-service, this file is used to generate only the back-end of the entity. Then the same Foo.json is reused to generate the front-end on the gateway. And thanks to the microserviceName property, it can prefix the API endpoint with the correct route to use the microservice as a back-end.

It would be great to have support for this in the JDL.

In JDL this could be something like that:
setMicroserviceName Foo with microservice1

how to generate unidirectional associationto

I have a problem,I want use unidirectional associationto relationship to entity,but I can't use jdl to generate it

Add support for the table name

It was added in JHipster some time ago, just added in JHipster UML for UML editors.
Currently we can write:

entity A

A proposed syntax for the table name:

entityA(table_name)

Or even

entityA as table_name {
  ...
}

I'd rather have the first as it is the currently supported way of specifying a table for classes from XMI files.

If the user doesn't specify a table name, then the entity name will be used as table name (underscored first, then lowercased).

A way to bypass the entity filtering.

As proposed here d9785e9.

More tests for the JSON exporter

Valid JSON files have to be checked against what the service returns:

• 01c7715

Add the 'noFluentMethod for'

So that when the JDL is:

entity A
entity B
...
entity Z

noFluentMethod for A

Only A won't have fluent methods.

Add support for Blob Type Text

With JHipster we currently support Type TEXT for blob along with image and any we can add this to JDL as well

Replace every last occurrence of exists(Sync) by access(Sync) or stat(Sync)

service/dto/pagination options for entity not fully processed

This is a rather weird issue with parser in JHUML so it might or might not be present here as well

When there are say 4 instructions for serviceClass or serviceImpl only the last 2 are applied

eg:

service Region with serviceClass
service Task with serviceImpl

service Employee with serviceClass
service Department with serviceImpl

In the generated json files only Employee and Department had the option set, If I change the order again whichever entity comes last gets the option

Adding commands for unique constraints

I just love expressing the domain data model in JDL. However, whenever there is a change, I find myself manually editing the server code plus regenerating the client and test code with jhipster-uml, because there is manual changes necessary in the domain code like unique constraints, advanced validation constraints etc.

Wouldn't it be nice to have the ability to generate unique constraints by expressing them via JDL? Or am I missing something?

for example:
unique { <entity>{<column_list>} }

example:
unique { A{columnA, columnB} }

to define a unique constraint on entity A with columns columnA and columnB.

JDL studio does not take multiple entries at relationships definition as valid

I am using JDL in my app:

relationship OneToMany {
    User{hasChore} to Chore{isDoneBy}
    User{hasBadge} to Badge{ownedBy}
}

which is valid when I run the yo jhipster:import-jdl yourFileName.jh (and specified at JDL docs) but is not accepted as valid in the online JDL studio (reports Expected "//", "}" or a space but "U" found. -> line: 3.

import-jdl json generation issue with microservice

Using jhipster 3.5.1.

I'm seeing a problem with the JDL config line used to define the microservice for a table.

Docs say do it like this

entity foo
microservice foo with jhipsterapp

In the entity json file this comes through as

{
    "relationships": [],
    "fields": [],
    "changelogDate": "20160815122017",
    "entityTableName": "foo",
    "dto": "no",
    "pagination": "no",
    "service": "no",
    "microservice": "jhipsterapp"
}

I think this is incorrect and should actually be "microserviceName": "jhipsterapp"

If not on the gateway all the entities are created on the gateway rather than just the frontend.

JDLBinaryOption (pagination) toString isn't 'paginate'

It's pagination.

Creating a required OneToMany in the "Many" part.

If I create the example:

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

Jhipster creates Entities for Owner and Car, and I can create Cars without owner.
Is it possible to specify that the owner is required with JDL?

In the Entities annotations, I see that a ManyToOne is created for the Car Entity. I guess I would like that this relationship has (optional=false) next to the declaration, and that Jhipster automatically cares of the front-end code validation.

Add support for fluent setters

This follows the merge of jhipster/generator-jhipster#3751

As of JHipster 3.6.0 (unreleased at the time of this writing), we will have fluent setters by default.

This means a few changes in JHipster Core (and maybe the JDL, but I'm not an expert here):

• All entities must have a "fluentMethods": true attribute, see this test entity for example
• For many-to-many relationships, both sides of the relationship must have a otherEntityRelationshipName attribute, which is the name of the relationship on the other entity. As you can see also here, this name is by default the name of the current entity

Here is an example, with a many-to-many relationship between Car and Driver, where on purpose I named the relationships with their French names:

Car

{
    "fluentMethods": true,
    "relationships": [
        {
            "relationshipName": "conducteur",
            "otherEntityName": "driver",
            "relationshipType": "many-to-many",
            "otherEntityField": "name",
            "ownerSide": true,
            "otherEntityRelationshipName": "voiture"
        }
    ],
    "fields": [
        {
            "fieldName": "name",
            "fieldType": "String"
        }
    ],
    "changelogDate": "20160811114329",
    "dto": "no",
    "service": "serviceClass",
    "entityTableName": "car",
    "pagination": "no"
}

Driver

{
    "fluentMethods": true,
    "relationships": [
        {
            "relationshipName": "voiture",
            "otherEntityName": "car",
            "relationshipType": "many-to-many",
            "ownerSide": false,
            "otherEntityRelationshipName": "conducteur"
        }
    ],
    "fields": [
        {
            "fieldName": "name",
            "fieldType": "String"
        }
    ],
    "changelogDate": "20160811114249",
    "dto": "no",
    "service": "no",
    "entityTableName": "driver",
    "pagination": "no"
}

Add skipServer, skipClient and angularSuffix

Everything's in the title.

import JDL subgenerator overwrites changelogdate even for not unaltered tables while regenerating entity

Overview of the issue

import JDL subgenerator updates changelogdate in .json files for all the entities (while regenerating entity) instead of only the modified entity. Because of which conflict occurs and overwrite question is asked for all the .json and .java files. This also impact the audit module where again all the .json, .java and .xml file are overwritten again for all the entities.

The expected behaviour is only the files for the modified or newly added entities to be overwritten.

Though we use a new jh file for regeneration removing the unaltered tables, the regeneration fails due to the dependency in these tables. As a result we have to add all the dependency tables.
Since we have lot of custom logics written in these generated files the code maintenance is getting complicated.

Motivation for or Use Case

Maintenance is becoming complex as when the number of table increases, the number of overwrite questions are also increasing. Currently I have around 10 tables in my development. If I change one table and regenerate entity using import JDL subgenerator around 60 overwrite questions are asked even for the unaltered tables. This includes the audit overwrite question as well. ChangeLogDate field in the .json file is getting updated irrespective of the new or modified tables due to which all the .json and .java files are updated

JHipster Version(s)

3.4.0

JHipster configuration, a .yo-rc.json file generated in the root folder

{
"generator-jhipster": {
"jhipsterVersion": "3.4.0",
"baseName": "TEGTracker_v4",
"packageName": "com.tcs.tegtracker",
"packageFolder": "com/tcs/tegtracker",
"serverPort": "8080",
"authenticationType": "session",
"hibernateCache": "no",
"clusteredHttpSession": "no",
"websocket": "no",
"databaseType": "sql",
"devDatabaseType": "mysql",
"prodDatabaseType": "mysql",
"searchEngine": "no",
"buildTool": "maven",
"enableSocialSignIn": false,
"rememberMeKey": "8af9a4f2db413e9d3629564b71520896c96e6956",
"useSass": true,
"applicationType": "monolith",
"testFrameworks": [
"gatling"
],
"jhiPrefix": "jhi",
"enableTranslation": true,
"nativeLanguage": "en",
"languages": [
"en"
]
},
"generator-jhipster-entity-audit": {
"auditFramework": "custom"
}
}

Check keywords

From here.

Ability to use sub-objects as view

Not sure if this is an issue with JDL or JHipster.

relationship OneToOne {
    Tree{size(moon.size)} to Planet
}

Sorry for the bad example...

JDL won't allow the view to be a child object. (Planet has a child object 'moon' which has a size)
I've tried plenty of variations to try to get this to propogate to the Angular JS side to no avail.

Is this view used anywhere else besides on the frontend?

Core objects, and after that

The work in the "coreobjects" branch is almost done, save the last object that should encapsulate every other object.
This is a pseudo-roadmap of what needs to be done afterwards:

• Migrate the JDL parser here;
• Test it;
• Migrate the EntityCreator here and adapt it to be able to generate JSON from JDL;
• Test it and fix some bugs;
• Expose the generation;
• Update every other project that depend on this project.

@deepu105 As I said, it's almost done. I think I might be able to merge the branch and migrate the entity creator by the end of the week at worst... I don't have as much time as planned, and tests take a lot of time...

JDL ManyToMany is imported as OneToOne

The following sample JDL is imported as a OneToOne relationship in the class files with jhipster 3.5.1. The json files are created with the correct relationship. To reproduce start with a fresh jhipster project and import the below JDL. See that both Car and Driver classes are generated with OneToOne relationships.

entity Driver
entity Car

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

The entity(table_name) of JDL can't work well --"entity B (the_best_entity) // the_best_entity is the table's name"

https://jhipster.github.io/jdl/

entity B (the_best_entity) // the_best_entity is the table's name

my code:

entity Activity (cs_activity) {
activityId Integer required ,
activityTitle String required maxlength(255),
activityType String ,
activityBanner String required maxlength(255),
activityStyle String required maxlength(255),
activityDesc String required maxlength(1000),
activityStartDate Integer required ,
activityEndDate Integer required ,
activitySort Integer required ,
activityState Integer required
}

yo jhipster:import-jdl yourfile.jh

Attribute on relationship

Add support for adding relationships with User

Since Release 2.5.0 JHipster supports adding ManyToOne relationships to the User entity.
We should be able to do this using JDL as well...

Override default id name feature request

Hi,

This is just a minor feature request. Currently, all the id will be generated
automatically, i.e.

entity Locale {}

This will generate a Locale table with Primary key 'id' automatically. Can it be enhanced such that the name of this id field is customized by adding some syntax? E.g.

entity Locale {
localeId Long id_override;
}

So in above example the keyword id_override will indicate the name of id will be localeId.

Thanks,
Sam

Add option to make Entity extend AbstractAuditingEntity

Entities created from JDL never extend AbstractAuditingEntity. this should be an option as the DTO, pageable, etc.

Refactor reserved keyword check

As discussed here

Its in progress

Generate application from JDL

This is a big thing, as the 2nd level cache is specified during the application's generation, and not during entity generation... But this has a direct impact on how the entity is to be generated (with or without the annotation in the Java class file).
@jdubois If I'm not mistaken, if I call yo jhipster after modifying my app, it will add some new files (from hibernateCache with the no value, to the hazelcast value), but it won't remove any file if I do the opposite (could it be possible?).
Do you think it's a good idea to extend the JDL to be a kind of input during app and entity generation? For instance, if I write something like:

entity A
entity B
...
entity Z
relationship OneToOne {
   ...
}

dto * with mapstruct except J, H, I, P, S, T, E, R
hibernateCache with hazelcast

Some code, somewhere (like here) could parse it, write a yo file, and call yo jhipster to generate the app, then generate the entities.
I've seriously thought about that for a while, and I think the idea of having a JDL-driven application generation is kind of nice.

Of course, @jhipster/developers, I'd like your input too! It wouldn't happen for v1.0.2, of course =)

A second way to declare options

Currently (Before and for v1.0.0), options were/are declared like this:

entity A
entity B
entity C

paginate * with Something except A
paginate A with SomethingElse

The second way consists in copying the way the relationships are declared so that this syntax is added:

entity A
entity B
entity C

paginate {
    * with Something except A,
    A with SomethingElse
}

We wouldn't have to write the option's type every time we want to add an option to an entity.

How to add an attribute to a relation ?

For example if I want a relation between a "user" entity and a "forum" entity with a role attribute what is the good way to do with the jdl language ?

entity Forum {  
    name String required
}

entity User{    
    login String required
}

/** each user can have an unique role in several forums  
* How do that ?
*/
relationship ManyToMany {
    User{forums} to Forum{users}
}

Required relationships in the JSON creator

To add: relationshipValidateRules.

Move common code to JDL

Move some of the common code to JDL so that we can use it in JHUML and the sub generator
This would make JDL act like a parent library kind of thing for all Jhipster projects that requires these info. Another option would be to move all the common reusable code to a new project called jhipster-core what do you think @MathieuAA ?

This can address @MathieuAA request to have some reusable code from JHipster in a module. Though may not be the most intuitive way this could be a viable solution

1. database attribute types: this can be moved from JHUML to here so that this becomes the reference point for different types used in the generator, JHUML, JDL studio and JDL and if @jdubois and @jhipster/developers are ok then I can refactor the entity sub generator to get the types from JDL while constructing the questions. only downside of this would be that if we need to add a new type we have to add it here rather than adding it directly in the generator, but then it saves us the trouble of updating all different projects to handle the new type
2. dsl_parser: IMO this can be moved to JDL project, it has dependency on parser_helperand jhipster_option_helper but those are minor util methods which can be either duplicated or moved to this project and referenced in JHUML since it will have JDL as a dependency anyway
3. ClassScheduler: with the current way of liquibase not being order dependent is this required? if so can it be moved here and referenced from JHUML
4. EntitiesCreator: can this be moved here as well

@Pattern(regexp = "undefined") in Java code when generate entity using JDL

Duplicate from: jhipster/generator-jhipster#3421 (comment)

Overview of the issue

Generate entity with pattern validation
ex:
entity E{
test String pattern("$\d+^")
}
Result:
class E{
....
@pattern(regexp = "undefined")
String test;
....
}

Motivation for or Use Case

JHipster Version(s)

JHipster 3.0

JHipster configuration, a .yo-rc.json file generated in the root folder

Entity configuration(s) entityName.json files generated in the .jhipster directory

Browsers and Operating System

Reproduce the error

Related issues

Suggest a Fix

Edit generators/entity/templates/src/main/java/package/domain/field_validators.ejs
40: -validators.push('@pattern(regexp = "' + field.fieldValidateRulesPatternJava + '")');
40: +validators.push('@pattern(regexp = "' + (field.fieldValidateRulesPattern ? field.fieldValidateRulesPattern.replace(//g, '\') : field.fieldValidateRulesPattern) + '")');