Introduce the side by side option

[Tcharl]

Overview of the feature request

We propose to add a jhipster 'side by side' application binary option (sidebyside * exept D) generating code differently

0. sample jdl

let's take that jdl as an example:

dto A
service A with ServiceImpl
application app {
    packageName p
    applicationType monolith
    entities E
}
entity E {
    f String notnull
}

1. entity code

// entity/EGen.java
@MappedSuperClass
abstract class EGen {
    private f String
    public void setF(String f) { this.f =f;}
   @NotNull
    public String getF() { return f;}
}
// entity/E.java
@Entity
public class E extends EGen { // This file won't be erased neither modified by a regeneration
/**    custom code written by the end user if he wants to 
 @MyAnnotation
   public String getF() { return f;} 
*/
}

// repository/EGenRepository.java
@NoRepositoryBean
public interface EGenRepository extends ERepository<ApplicationView, Long> {}
@Repository
public interface ERepository extends EGenRepository {}

// dto/EGenDTO.java
abstract class EGenDTO {
    private f String
    public void setF(String f) { this.f =f;}
   @NotNull
    public String getF() { return f;}
}

// dto/EDTO.java
public class EDTO extends EGenDTO {}

// mapper/EGenMapper.java
public interface EGenMapper extends EntityMapper<EDTO, E> {}

// mapper/EMapper.java
@Mapper(componentModel = "spring", uses = {OtherE.class})
public interface EMapper extends EGenMapper {}

// service/EServiceGen.java
interface EServiceGen {
EDTO save(EDTO) {}
...
}

// service/EService.java
interface EService extends EServiceGen {
}

// service/impl/EServiceImplGen.java
abstract class EServiceImplGen implements EService {
private EMapper eMapper;
...
}
// service/impl/EServiceImpl.java
public class EServiceImpl extends EServiceImplGen {}

// tests/EITGen.java contains actual EIT code
// tests/EIT.java

public class EIT {}

//webapp/app/entity/e/e-gen.service.ts
export abstract class EGenService {
...
}

//webapp/app/entity/e/e.service.ts
@Injectable({ providedIn: 'root' })
export class EService extends EGenService {
}

//webapp/app/entity/e/e.comonent.ts
@Component({
  selector: 'jhi-e-domain',
  templateUrl: './e.component.html',
})
export class EComponent {
...
}

Motivation for or Use Case

Jhipster is generating classes that are directly used and that cannot be customized easily: any regeneration will lead to either a merge step or custom code erase. Thus, upgrading or generating is a dangerous step to achieve, leading to project stop using the platform.

Related issues or PR

Antonio Goncalves presentation @ jhipster conf 2018

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

[cbornet]

For the repository and service, I believe it's easier to do side-by-side by extending the repository generated by JHipster and setting @Primary on the child classes. It achieves the same goal without modifying the current generated code and without making things more complex.

[Tcharl]

Hi @cbornet ,

Tried this, but spring doesn't like it: it forces to have only one repository by entity... So @norepositorybean is mandatory for the actual generated repository.

For service I forgot the annotation: @Primary works well!

[mraible]

Any updates @Tcharl?

[Tcharl]

Should we include this in the main generator?
I think this deserves a specific branch done collaboratively: I won't be able to implement everything by myself (for example, I don't know the vue and the react part at all).
On my backlog, I've planned to achieve #12080 first because it covers the major painpoint, then this one

[mshima]

@Tcharl do you want to merge #12521?
We can merge it, it's only missing to add dependencies, and revert when I release yeoman-environment 3.0.
About yeoman-environment 3.0:

• jhipster 7 is more than 1 month away. I don't have hurry to release it.
• I have a proposal for npm 7, if accepted, I plan to integrate before releasing.
• .yo-resolve will happen for environment 3.0
• If we add .jhipsterignore we will have 2 ignore files .jhipsterignore and .yo-resolve.

[Tcharl]

@mshima yes please I would be very glad to see it in the current patch release.

What about simplifying the usage:

• jhipsterignore will just skip
• yo-resolve will let the user choose between erase, merge or skip.

So that both files will stay relevant even after the yeoman upgrade

[mshima]

@mshima yes please I would be very glad to see it in the current patch release.

What about simplifying the usage:

• jhipsterignore will just skip
• yo-resolve will let the user choose between erase, merge or skip.

So that both files will stay relevant even after the yeoman upgrade

I am against jhipsterignore, because of the reasons I explained in the issue, like this will not work for modules.

[github-actions]

This issue is stale because it has been open 30 days with no activity.
Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted.
We are accepting PRs 😃.
Comment or this will be closed in 7 days

[github-actions]

This issue is stale because it has been open 30 days with no activity.
Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted.
We are accepting PRs 😃.
Comment or this will be closed in 7 days

[joro88]

Hi. Any progress on Side-by-side generator?
Any new ETA?

[Tcharl]

Hi @joro88 ,

Not really: I'm on the constants part for now, because I think that simplifying the generator will help to introduce new options...
For now, if you want to kinda side-by-side, you can:
Use totally uncorrelated classes (I personnally use ddd paradigm for my custom code in addition to jhipster generated stuff)
Use the fantastic .yo-resolve file at the root or your repo to list what to exclude from regen erase.
And it's pretty efficient in the end.

After that constant and some refactor of some weird generator stuff, I plan to go for #14363 then this one.
So if you want to have it quick, feel free to contribute!

[gmarziou]

Use the fantastic .yo-resolve file at the root or your repo to list what to exclude from regen erase.

Wow this is a hidden gem, I could not find a doc about it and expected format.
Do you have a link?

[Tcharl]

It's as simple as that.
Example content:

src/main/docker/realm-config/jhipster-realm.json skip
src/main/java/com/corp/config/SecurityConfiguration.java skip
src/main/java/com/corp/security/SecurityUtils.java skip
src/main/java/com/corp/service/UserService.java skip
src/main/resources/config/liquibase/changelog/00000000000000_initial_schema.xml skip
src/main/resources/config/liquibase/changelog/20210113165745_added_entity_Member.xml skip

I just don't know where to add the doc

[gmarziou]

For JHipster, it could be in tips section.
For Yeoman's docs, maybe @mshima would know

[ntpthinh]

It's as simple as that.
Example content:

src/main/docker/realm-config/jhipster-realm.json skip
src/main/java/com/corp/config/SecurityConfiguration.java skip
src/main/java/com/corp/security/SecurityUtils.java skip
src/main/java/com/corp/service/UserService.java skip
src/main/resources/config/liquibase/changelog/00000000000000_initial_schema.xml skip
src/main/resources/config/liquibase/changelog/20210113165745_added_entity_Member.xml skip

I just don't know where to add the doc

Thank you for pointing out. This sounds convenient.
However, I cannot see it's working on my side. I created .yo-resolve file with similar content in JHipster 7.0.0.
Hope to see your document on this. Thank you

[ksilz]

@gmarziou I have my own base classes for both the entities and DTOs that JHipster generates. I wrote a shell script that adds them/patches them back into the source code after JHipster updated my entities.

The same applies to the Spring Data repository interfaces: For some, I created my own repository interface. My shell script then appends these to the existing extends statement of the JHipster-generated repository interface.

[gmarziou]

@ksilz interesting, and for how long did you update your project with the generator since initial generation?

[ksilz]

@gmarziou Since Feb 2020. JHipster updates (like 6.x going to 7.x) are still a royal freakin' pain the butt. But I can update my entities effortlessly.

What also helps is that I don't use the default Angular UI. I built my own, so no conflicts there. And I got my own business layer on top of JHipster.

[gmarziou]

Major upgrades are painful and I consider it's not worth.

On my team's projects, we never used JHipster more than few weeks, I prefer to cut all dependencies from JHipster as soon as possible so that I can upgrade dependencies more easily and feel free to refactor our code.

[ksilz]

@gmarziou I stick with JHipster.

• I can update dependencies on the front-end just fine. I can't change the build process (like JHipster 7 did for Angular) or switch out the test framework easily. But then I didn't need to until now.
• The biggest pain on the back-end is the hard-coded Spring Boot dependency on the back-end. 2020 and 2021 were really bad as I was shipping a Spring Boot 2.2.x version in my app that was 5 minor releases behind in the 2.2 branch and two major releases behind 2.4. And it's starting again - JHipster 7.1 shipped with Spring Boot 2.4.x again, which is behind the current 2.5 branch.

[gmarziou]

@ksilz Upgrading Spring Boot for JHipster is a major effort each time for the team because it has to work on so many project configurations. It is much simpler for your own projects that have a narrower scope, this is why I don't use JHipster BOM as I must be more reactive to update deps to be compliant with PCI-DSS requirements.

[ksilz]

@gmarziou I understand that it's a major effort. I'm not asking to get major versions faster (like 2.5 right now and 3.0 in the fall). What I do want is faster security fixes.

An example: We were stuck with Spring Boot 2.2.7, I think, before JHipster 7.0 was out. Now at that time, the 2.2 branch was at 2.2.12 or something, 5 patches ahead. That's a lot of bug fixes and security updates we were missing in Spring Boot, plus all the related projects (Spring Security, Spring Data, ...).

So how can we speed this up? From what I can see on the outside, there's no "patch branch in parallel to next major version" going on at JHipster. I think that's one of the reasons why people stop using JHipster quickly and switch to manual mode. At the very least, I'd like to have documentation for a "manual Spring Boot override": Let me, in my own little project here, switch from "JHipster Spring Boot 2.2.7" to "My own Spring Boot 2.2.12", for instance.

[gmarziou]

Even Spring Boot team lags behind sometimes in terms of security updates, I had recently the case with Undertow.

In the end, security updates are the responsibility of the app dev team.

I like your proposal to have documentation for a "manual Spring Boot override", I did it once for one of my projects and I found it not that easy but I can't remember the details, this was the trigger for me to depend directly on Spring Boot rather than through JHipster's indirection.

[ksilz]

@gmarziou Who would know how to do a "manual Spring Boot override"?

[gmarziou]

Only those who tried recently, please contribute.

[joro88]

Hi,
What is the progress on side-by-side generator?

[Tcharl]

Tips page created and review pending: jhipster/jhipster.github.io#1171

[DanielFran]

Closing since documentation has been added as a tip