Generator-jhipster: Update entity using yo

[ilopezluna]

I don't know if this feature already exists, but every time that I add a field to an existing entity I'm recreating all the entity, because yo jhipster:entity replaces my sources. I think will be great if yo jhipster:entity check if the entity is already created, then add the new fields and update tests and views. What do you think?

[jdubois]

The idea is that you generate your file with JHipster, and then you work on it by yourself... But I understand what you do, in fact I do it myself all the time :-)

BTW, you have another issue: the liquibase changelog is getting also generated again, so you need to remove it, which is painful

Anyway, this really can't be done: we can only generate new files, not update existing ones. You have, however, some tools to help you:

• Yeoman gives you a menu when a file is getting overwritten. You can do a diff, for example
• Personally I always overwrite it, and use Git to do the merging. This works quite well.

[fabiosato]

Hi, if possible, could you elaborate on the git workflow that you are using for managing the updates to entities?
I think this would be usefull for a lot of your users.

[jdubois]

@fabiosato I just updated the documentation (yesterday I think!) and added a "generating an entity a second time": http://jhipster.github.io/creating_an_entity.html

Can you have a look at it?

Then all I do is using either the Yeoman questions, or use Git, to do diffs against the old and the new file.

[fabiosato]

Yes, thanks. This is good information. So basically, the best approach would be to not modify directly the JPA Entities, but apply changes to the JSON files and run jhipster to generate the backend (Java) files again, is that correct?

In our team we are discussing the best approach on how to handle the situation where we already did customizations to the frontend but want jhipster to re-generate the code based on modifications on the backend. Besides a workflow with git to restore previous modifications to that files, we are considering that maybe it's better to extend the angular 'classes' generated by jhipster so we can isolate our modifications on files that will not be touched by jhipster.

[jdubois]

I meant it mostly if you want to upgrade your JHipster version.
Otherwise, just modify your model files normally, in Java, and use "mvn liquibase:diff" to generate the Liquibase changelog.
That might do more merging next time you do a "yo jhipster:entity", but with Git that shouldn't be too hard. Of course, it depends on what brings the next version of JHipster!

[vancourse]

So, if I am trying to create microservices - in which I want one "mother ship" to have the full jhipster generated spring-boot project; and other microservices to have just the appropriate parts ( ex. a Comment MicroService should have the comment entity, along with the REST calls and DB and UI). The main css and js ( navbar etc. ) should all be defined in the "mothership"... What is the best way to go about doing this?

[heppa]

Maybe it might help others to explain how I do this most of the time, as I'm working agile and the data model needs updates quite often during the first few development sprints. I try to create and envision the data model up front as good as I can, but it is not always possible.

So, what I do is to create a file with JDL Studio first and store it in my project's resources. Then I run yo jhipster:import-jdl src/main/resources/data-model-file.jh. When everything works as expected, I commit to my git repo.

Now, when there are changes to my data model, I directly modify the data-model-file.jh and re-run the command above (answer a for the first conflict). This also overwrites everything and then I use the diff and merge to bring back my other changes to the overwritten files. For me this is somewhat easier than updating the entities in the .jhipster/*.json files and run the entity generator for each of them.