Generator-jhipster: 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

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

• [ ] 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 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:

• 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[bot]]

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