search

jhipster / generator-jhipster

JHipster is a development platform to quickly generate, develop, & deploy modern web applications & microservice architectures.
https://www.jhipster.tech
Apache License 2.0
21.54k stars 4.02k forks source link

Introduce the side by side option #12497

Closed Tcharl closed 1 year ago

Tcharl commented 4 years ago
Overview of the feature request

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

  1. 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

cbornet commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Any updates @Tcharl?

Tcharl commented 4 years ago

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 commented 4 years ago

@Tcharl do you want to merge https://github.com/jhipster/generator-jhipster/pull/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:

Tcharl commented 4 years ago

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

What about simplifying the usage:

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

mshima commented 4 years ago

@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[bot] commented 3 years ago

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 :smiley:. Comment or this will be closed in 7 days

github-actions[bot] commented 3 years ago

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 :smiley:. Comment or this will be closed in 7 days

joro88 commented 3 years ago

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

Tcharl commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

ntpthinh commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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

ksilz commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@gmarziou I stick with JHipster.

gmarziou commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

gmarziou commented 3 years ago

Only those who tried recently, please contribute.

joro88 commented 3 years ago

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

Tcharl commented 2 years ago

Tips page created and review pending: https://github.com/jhipster/jhipster.github.io/pull/1171

DanielFran commented 1 year ago

Closing since documentation has been added as a tip