Generator-jhipster: Reimporting a JDL file is handled as a new project

[amatosg]

Overview of the issue

When importing a JDL file, it doesn't ask for confirmation on conflict files where changes have been made and it simply overrides them. It also commits the changes with the message Initial application generated by JHipster-5.7.0

Motivation for or Use Case

When importing a JDL file, it should as for confirmations prior overriding changed files and it shouldn't automatically commit those changes.

Reproduce the error

Create a project and import a JDL. It shouls, at least, ask for confirmation when overriding the narbar file.

Related issues

none found

Suggest a Fix

implement the confirmation before overriding the files changed by the user and don't auto-commit the changes.

JHipster Version(s)

[email protected] /Users/alejandro/IdeaProjects/test_comment
└── [email protected]

Environment and Tools

java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

git version 2.16.2

node: v8.11.3

npm: 6.4.1

yeoman: 2.0.5

Docker version 18.09.0, build 4d60db4

docker-compose version 1.23.1, build b02f1306

INFO! Congratulations, JHipster execution is complete!

JHipster Version(s)

5.7.0

JHipster configuration

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

Browsers and Operating System

• [x] Checking this box is mandatory (this is just to show you read everything)

[deepu105]

Please use the --interactive flag for that behaviour

On Mon, 26 Nov 2018, 1:11 am Alejandro Matos <[email protected]
wrote:

Overview of the issue

When importing a JDL file, it doesn't ask for confirmation on conflict
files where changes have been made and it simply overrides them. It also
commits the changes with the message Initial application generated by
JHipster-5.7.0
Motivation for or Use Case

When importing a JDL file, it should as for confirmations prior overriding
changed files and it shouldn't automatically commit those changes.
Reproduce the error

Create a project and import a JDL. It shouls, at least, ask for
confirmation when overriding the narbar file.
Related issues

none found
Suggest a Fix

implement the confirmation before overriding the files changed by the user
and don't auto-commit the changes.
JHipster Version(s)

[email protected] /Users/alejandro/IdeaProjects/test_comment
└── [email protected]

Environment and Tools

java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

git version 2.16.2

node: v8.11.3

npm: 6.4.1

yeoman: 2.0.5

Docker version 18.09.0, build 4d60db4

docker-compose version 1.23.1, build b02f1306

INFO! Congratulations, JHipster execution is complete!
JHipster Version(s)

5.7.0
JHipster configuration Entity configuration(s) entityName.json files
generated in the .jhipster directory Browsers and Operating System

• Checking this box is mandatory (this is just to show you read
  everything)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/8880, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ABDlF50eoIt7UgGvwT6G8a8aCsxAtTNaks5uyz_QgaJpZM4YyLCl
.

[amatosg]

this is counterintuitive, the previous behavior was to ask before overriding files. Now it behaves the other way around: it will override all your files unless you use a flag. I was using the import feature very often as I made changes to my jdl file and I was really surprised to realize that I wasn't asked to override my changes, it just did it and it committed those changes so all the work I did had to be made again.

I know I'm not in the position to demand anything, I just want to understand. So, could you please explain to me why was this change made? maybe I'm missing something?

[deepu105]

@amatosg sorry it was a surprise, and I understand the pain, let me see what can be done, the change was made to speed up multi-application import so that things are done in parallel, and when running in parallel you won't be able to interact with it. Maybe I can skip the behavior for cases where you are only generating entities. Can you confirm, did you generate app and entities or just entities?

[amatosg]

I was generating a monolithic app with entities. Whenever I make changes to the JDL file (new fields, change the values of other fields), I reimport it and it would ask to override some files. I then check which files are being affected and accept or reject the generation.

IMO, the user should still be prompted to choose the action and leave a flag like --unattended for generating without asking the override as that was the original flow.

[ruddell]

In my opinion, the application shouldn't regenerate by default if it already exists in that directory, that's what is causing the issue.

It's fine if you use --ignore-application but it isn't clear to the end-user that they have to add a special flag to re-import an updated JDL file.

JDL file showing this issue (import it, then import it again):

application {
    entities *
}

entity Foo {
   name String
}

[jbadeau]

Is there some way to disable auto git commit?

[ruddell]

@jbadeau --skip-git, to see all options, jhipster app --help

[makania]

this is counterintuitive, the previous behavior was to ask before overriding files. Now it behaves the other way around: it will override all your files unless you use a flag. I was using the import feature very often as I made changes to my jdl file and I was really surprised to realize that I wasn't asked to override my changes, it just did it and it committed those changes so all the work I did had to be made again.

I know I'm not in the position to demand anything, I just want to understand. So, could you please explain to me why was this change made? maybe I'm missing something?

Same here. Used it basically for datamodelling and was surprised to see it "resetting" my pom.xml (database configuration), .yo-rc.json (language settings, client-framework) and api.yml (swagger) and then autocommitting everything.

[jdubois]

I'm adding a bug bounty on this, as this is important for JHipster 6

[vishal423]

I suspect this issue is also causing the manual upgrade to auto commit

[deepu105]

@amatosg please claim the bounty. @mraible fyi

[vishal423]

@deepu105, do above change also fixes the auto commit behavior on manual upgrade?

[pascalgrimaud]

@deepu105 : the PR was opened by @Shaolans, not by @amatosg
It was @Shaolans who worked on this, and tried to find the fix

[deepu105]

Oh sorry @Shaolans, plz do claim the bounty

[deepu105]

@vishal423 no this only addresses the interactive behaviour. If there is an issue with commit it needs to be looked into

[Shaolans]

Bounty claimed https://opencollective.com/generator-jhipster/expenses/8417
If someone who participated wants a share of the bounty I will be glad to do so.

[pascalgrimaud]

Don't share, @deepu105 you should claim one, as you worked on this too. We have money and should use it.

[steffanolesen]

In my opinion, the application shouldn't regenerate by default if it already exists in that directory, that's what is causing the issue.

It's fine if you use --ignore-application but it isn't clear to the end-user that they have to add a special flag to re-import an updated JDL file.

JDL file showing this issue (import it, then import it again):

application {
    entities *
}

entity Foo {
   name String
}

With version 6.1.0 re-importing (using --ignore-application) still always regenerates a new 20190621083439_added_entity_Foo.xml and updates master.xml