JHipster Conf 2019 : JHipster side-by-side in practice by David Steiman

What people said

Recommends Jochen Haßfurter · 2019-09 · Stack Overflow · on “Problem with JHipster Upgrade from 6.1.2 to 6.2.0”

At least David Steiman ("Xetys", Stream Lead JHipster UAA) knows about the problems with upgrading a jhipster generated application with jhipster upgrade , talked about "the dark side of jhipster" on his speech at JHipster Conf 2019 and presented a solution in a demo: [this video] . I try to follow his advices and not to touch the generated classes and configs - which is even more interesting, if someone tries to connect to two databases and stay upgradeable. But that may only answer your last question, not the ones to the in-depth bugfix you had to do in this particular upgrade from 6.1.2 to 6.2.0.

Recommends Jochen Haßfurter · 2019-12 · Stack Overflow · on “Theme Bootstrap and Jhipster”

JHipster (e.g. v6.5.1) already comes with Bootstrap, as you can find in package.json : "@ng-bootstrap/ng-bootstrap": "5.1.0", "bootstrap": "4.3.1" And all a bootstrap-theme ought to need are the bootstrap libraries (css/js), but it depends on your external theme, if there are some other libraries to load. Therefore you can integrate the code into the Angular components in src/main/webapp/[...] . Perhaps you can build your own JHipster blueprint as mentioned in [this video] (JHipster Conf 2019 : JHipster side-by-side in practice by David Steiman). Also - beside all of the documentation that can be found on [LINK] - this video [LINK] ("The new Voxxed websites using JHipster, Angular and GitLab by S

Recommends vicpermir · 2020-02 · Stack Overflow · on “Preventing JHipster import-jdl from overwriting changes when updating entities”

I faced this problem in one of my projects and I'm afraid there is no easy way to tell JHipster not to overwrite your changes. The good news is you have two ways of mitigating this and both will make your life much easier. Update your entities in a separate branch The idea is to update your entities (execute the import-jdl command) in a different branch and then, once the whole process is finished merge the changes back to master. This requires no extra changes to your code. The problem I had with this approach is that sometimes the merges were not trivial and I still had to go through a lot of code just to be sure that everything was still in place and working properly. Do not change the ge

Recommends Jochen Haßfurter · 2020-02 · Stack Overflow · on “JHipster inheritance”

As Gaël Marziou commented, you have to implement it manually. I just want to repeat it to see an answer on your question on stackoverflow - by no means to take his credits (he's undoubtedly great!!). For coding the generated source further, I just want to point at Side-by-Side-coding to be able to update your code with jhipster in the future. There is a good practice example and detailed explanation [this video] from David Steiman (xetys) on youtube, along with inheritance.

Recommends Jochen Haßfurter · 2020-02 · Stack Overflow · on “Problems when Upgrading to the newest version of JHipster”

Yes, after following xetys talk on [this video] and reprogramming its example, I followed a side-by-side practice in my own code.

Recommends Gaël Marziou · 2020-04 · Stack Overflow · on “How to update entities in JHipster without losing previous logic work?”

In JHipster community, this is known as side-by-side approach. Have you seen these presentations? [this video] and [LINK]

Recommends Gaël Marziou · 2021-04 · Stack Overflow · on “What are the best practices to prevent code loss while regenerating application with JHipster”

There is an approach named as side-by-side (see [this video] ) that requires discipline from developers. Also --incremental-changelog new feature of JHipster 7 can help to manage incremental changes to SQL database, even though it's currently poorly documented. Another useful feature is to generate your project with @GeneratedByJHipster annotation in your Java classes by using jhipster --with-generated-flag If a team of 5 to 10 devs works on same app, it will be hard anyway without JHipster but even harder with JHipster. I see several alternatives: Use a microservice architecture to help isolating from others changes. For a monolith, I would recommend using JHipster only for bootstrapping the app

Recommends jelharou · 2023-09 · Stack Overflow · on “What is the best practice of JHispter consumization?”

Not sure who closed it but this must have come up a lot in the past... Did you look at the talks on Youtube? Here are the ones I had in mind. They may be old but give you some perspective: * [LINK] * [this video]

Cites Amir T · 2019-10 · Stack Overflow · on “jhipster side by side generator (once)”

I like the idea of the side-by-side development in JHipster to support easy upgrading, etc as demonstrated in [this video] So instead of manually creating the BandExtendedResource and the BandExtendedRepository, etc, is there already, or could there be either: a JDL option to indicate side-by-side is going to be used or a yeoman generator for these files? I understand this could be a bit circular, in that, the point of the extended classes is that we don't overwrite them, but these could/would be excluded (one way or another) from subsequent generator runs.

Cites Jochen Haßfurter · 2020-01 · Stack Overflow · on “JHipster nested component”

An Angular application can have one Router-Object. You create a router module and a service in the app root module. The SPA can have one or more router-outlets, where linked components will be rendered. These components can be loaded with the root app or lazily to keep the initial size minimized. Lazy-loaded components can be preloaded. And the Router can be passed with or without data to its child. The child component can add its routes-configuration to the Object. The Router is also dispatching events, which can be intercepted. And the routes can be guarded (e.g. "only allow logged in users to render the linked component"). JHipster generates a best practice "template" Angular frontend (if