New sub generators for modularity

[pascalgrimaud]

Overview of the feature request

The discussion started here https://groups.google.com/g/jhipster-dev/c/y_sER_CM3Hc

Motivation for or Use Case

The goal will be to start to create some new sub generators. To resume quickly:

Pro:

• easier to maintain, no more if else in templates with too much combinations
• easier to add new options
• easier for new contributors

Cons:

• duplication of templates
• some options will be maintained better than others (but IMO, it's normal, if you compare an option used by 50% of projects, with an option used by less than 0.5%)

Then later, when the v8 will start, we'll migrate the existing sub generators into the new ones.
For now, no impact on existing projects as all these new sub generators are totally independent!

Roadmap

We can start to add these following sub generator:

• init : with default files, when you start a project
• maven
• gradle
• spring-boot

Then, we can think about:

• spring-boot-mvc

• spring-boot-reactive

• security-jwt

• security-oauth2

• database-postgresql

• database-mysql

• etc.

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

[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

[atomfrede]

Keep it open

[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

[mshima]

I have been thinking on how to better integrate entities.

Keeping same architecture that adds an entity-foo generator for each foo (eg sql, mongodb, cassandra, neo4j, couchbase, elasticsearch, angular, react, vue) generator, our generators will become too bloated.
And the workflow will not be as simple as a this.composeWith('entity-foo'), it would need some register to keep the entity-* generators order consistent.

So we should drop entity-* generators and replace with:

• new priorities called preparingEntities and another called configuringEntities.
• support methods at generator-base to be used in the priorities.
  • this.configureEachEntity(({entity, entityConfig}) => {}) at configuringEntities
  • this.prepareEachEntity(({entity, entityWithConfig}) => {}) at preparingEntities and configuringEntities
  • this.prepareEachField(({entity, entityWithConfig, field}) => {}) at preparingFields
  • this.prepareEachRelationship(({entity, entityWithConfig, relationship}) => {}) at preparingRelationships
  • this.writeEachEntity(({entity}) => {}) at writing
• entity generator should delegate to the project type generator (java, spring-boot, spring-boot-web, jhipster).

[Tcharl]

How will it do the trick when two generators will participate to one same file, e.g. elastic & sql? will elastic depend on sql?

[mshima]

We should implement as modular templates.

The fallback is to implement in the parent.
In this case spring-boot-elasticsearch and spring-boot-sql depends on spring-boot or spring-boot-data.

[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

[mshima]

Keep open.

[mraible]

I'm not sure this is the best place to add this comment. However, since this is the main issue targeting v8, I figured I'd add it here.

When hanging out with @joshlong a couple of weeks ago, he noticed how much XML a JHipster pom.xml has and how much Java code we generate by default. His reaction was along the lines of "these are problems that Spring Boot is supposed to solve!"

This made me wonder: can we do more to make this possible? If we extend spring-boot-starter-parent in pom.xml, does that reduce the amount of XML we generate by default? If so, why don't we change it? I'm sure there are reasons, that's why I ask.

Can we move more code into the jhipster-framework dependency too? I'm sure we can, but will it make folks wish they had "all code in the project" as we do now?

Back in the day, I modified AppFuse so it was modular and new projects had very little XML in pom.xml and hardly any Java. However, I found that most users wanted the full source. To help, I created a "full-source" Maven plugin that would pull in all the source code and update the dependencies. I'm not sure this would be necessary today, but it was back then to keep users happy.

[Tcharl]

Hi @mraible ,

Not extending the parent pom was a suggestion coming from @jdubois : usually, companies have their own company poms (for example to manage distributionManagement), that's why we moved back to standalone mode.

Regarding jhipster-framework and code, we could also provide our spring-boot-starter project suite.

[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

[pascalgrimaud]

Following this Tweet: https://twitter.com/juliendubois/status/1469225642122166274

Doing it in main generator-jhipster is not a good idea.
The idea will be there: https://github.com/jhipster/jhipster-lite

So this ticket can be closed.