Generator-jhipster: Roadmap to v7

[deepu105]

@jhipster/developers please update this ticket to add what you would like to see in v7

[gmarziou]

What would be the default serviceDiscovery?

[deepu105]

@gmarziou I think it should still be no as a simple project shouldn't need service discovery

[begbegin]

New features
Add ng material
Add Flutter

[xetys]

I suggest a thing called side-by-side sub-generator. I'll give more details soon

[begbegin]

Thanks

Le lun. 16 déc. 2019 à 14:47, David Steiman [e-mail] a
écrit :

I suggest a thing called side-by-side sub-generator. I'll give more
details soon

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/10958?email_source=notifications&email_token=AARETXOU2YQ5KDTC7QENCEDQY6IH3A5CNFSM4J3H7UM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG66CXI#issuecomment-566092125,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AARETXLZRABR4SVUWLO3ROTQY6IH3ANCNFSM4J3H7UMQ
.

[wmarques]

@begbegin anything else ? ☕️

[deepu105]

@begbegin sorry but we won't be adding those as its not in our roadmap

[xetys]

I opened a discussion on SBS on our group. As soon there is consensus, there should be an RFC to the SBS-sub-gen (or the removal of my taks above)

Another topic I see is some development on our UAA support, such as:

• moving most generated UAA code to the JHipster library, as it uncommonly changed in code, in detail:
  
  
  
  • the @AuthorizedXXXFeignClient annotation with their configurations
  
  
  • the abstract classes / interfaces under package.security.oauth2 for UAA microservices and gateways, maybe even the concrete implementations
  
  
• standardizing name conventions for the feign clients
  
  
  
  • @AuthorizedUserFeignClient for token forwarding clients
  
  
  • @AuthorizedServiceFeignCleint for service-to-service calls using the internal OAuth2 client
  
  
• offer analog implementations for RestTemplate, as there are use-cases where RestTemplates give more options than feign cleints
• migrate to spring-security-oauth

If this list is okay, I'll update the roadmap

[pascalgrimaud]

I think we have a lot of ideas here, but we should focus on:

• if it's a breaking change, it should go to v7
• if it's a big feature without breaking change, it could be done during v6 or v7
• there is no ETA but we tried to do a major release each year, so we can try to publish a release between february to june 2020

And if a feature can go into module, I'd prefer this solution, instead of integrating the feature directly to JHipster, unless it is totally mandatory
Less features inside JHipster, less tickets, less work to maintain it...

[deepu105]

Agree 100% with Pascal

Thanks & Regards,
Deepu

On Mon, Dec 16, 2019 at 4:49 PM Pascal Grimaud [e-mail]
wrote:

I think we have a lot of ideas here, but we should focus on:

• if it's a breaking change, it should go to v7
• if it's a big feature without breaking change, it could be done
  during v6 or v7
• there is no ETA but we tried to do a major release each year, so we
  can try to publish a release between february to june 2020

And if a feature can go into module, I'd prefer this solution, instead of
integrating the feature directly to JHipster, unless it is totally
mandatory
Less features inside JHipster, less tickets, less work to maintain it...

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/10958?email_source=notifications&email_token=AAIOKFZ2GCHBL6BLZSUDNWDQY6PQ7A5CNFSM4J3H7UM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG7ER3A#issuecomment-566118636,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIOKF3FTDY57TCEKQJ3KJDQY6PQ7ANCNFSM4J3H7UMQ
.

[begbegin]

Making elasticsearch as primary database

[atomfrede]

Making elasticsearch as primary database

I would not do that. Elastic is a searchengine and therefore not suited to be primary datastore imho.

My points I would like to see:

• Neo4j support (which can be done in the 6.x release when we have boot 2.2 support)
• Having a modular package structure in the backend which follows modulith approach
• Using debezium for writing into multiple datastore (e.g. when using elasticsearch) but that might be a module too
• havin at least the micronaut blueprint ready to use

[gmarziou]

Having a modular package structure in the backend which follows modulith approach

+1

havin at least the micronaut blueprint ready to use

+1

[PierreBesson]

I have added modulith and "server side packaging by feature" to the list.

[PierreBesson]

@atomfrede Maybe we could also introduce more arch-unit tests ?

[atomfrede]

@pascalgrimaud Maybe some more would be nice, but when we have full moduliths support we will have automated tests for the package structure out of box (based in arch unit rules under the hood).

[begbegin]

• Using debezium for writing into multiple datastore (e.g. when using elasticsearch) but that might be a module too

Thanks

[atomfrede]

And of course we should decide and maybe implement a microfrontend solution which helps to scale teams building a Microservice environment such that the teams stay as independent as possible

[jdubois]

I believe it's important to simplify what we generate, both for our users and ourselves:

• +1 for having just one type of application (no more microservice/monoliths), and having a clearer front/back separation (to me it's already good, but this is where we have the more complaints)
• I would like to remove a lot of our generated code in the "initial generation" and push it to our lib and Spring Boot Starter. This will make upgrading easier, and the initial generation will be less frightening
• The "side car" is part of my two previous points: let's simplify what we generate
• We should also remove less-used options. Session-based authentication should be removed: it costs a lot, and I don't think anybody uses this anymore. We need to do some stats from start.jhipster.tech, we have all the data there.
• We need Vue badly, and we should vote on which should be the default front end framework. Because I'm liking Vue the way I liked AngularJS... much better than Angular and React!

[deepu105]

Since this is roadmap discussion I'm locking this to contributors

[jdubois]

It's a simple one, but a breaking one: we should rename our package from "io.github.jhispter" to "tech.jhipster"

[PierreBesson]

+1 @jdubois, also rename the jhipster.github.io repo to jhipster.tech

[gmarziou]

Session-based authentication should be removed: it costs a lot, and I don't think anybody uses this anymore.

What do you mean by "it costs a lot"?

From a security standpoint, session-based authentication has some advantages over our JWT implementation for monoliths: secured cookies, revocation. It also consumes less network bandwidth.

[pascalgrimaud]

I'd like to have prettier for java, and I know a lot of people want it too :)

But I'm not sure if it's a breaking change or a feature ?

[deepu105]

I would consider it a feature

On Wed, 18 Dec 2019, 7:14 am Pascal Grimaud, [e-mail]
wrote:

I'd like to have prettier for java, and I know a lot of people want it too
:)

But I'm not sure if it's a breaking change or a feature ?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/10958?email_source=notifications&email_token=AAIOKF6AIYHW5PSEL2RAVSDQZG5TBA5CNFSM4J3H7UM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHE7NLI#issuecomment-566884013,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIOKF4Z3NEBY3EDHVMNHH3QZG5TBANCNFSM4J3H7UMQ
.

[vishal423]

I would like to provide an out of box solution with spring cloud gateway as the default gateway over zuul, and an initial support of svelte (I still need to look deeply into this, but, it looks promising).

In addition, it would be good to integrate with angular cli build ecosystem (I know there is a PR in progress) and create custom builders to abstract JHipster specific webpack customization.

[wmarques]

Yep I agree with @vishal423 on the angular part. We can easily integrate Angular CLI and build a custom builder on top of it to fit our needs.
I struggle to find time currently but I think it should be ok for v7

[vishal423]

@wmarques let me know if you need help here.

Cheers,
Vishal

On Thu, Dec 19, 2019 at 7:22 PM William Marques [e-mail]
wrote:

Yep I agree with @vishal423 https://github.com/vishal423 on the angular
part. We can easily integrate Angular CLI and build a custom builder on top
of it to fit our needs.
I struggle to find time currently but I think it should be ok for v7

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/10958?email_source=notifications&email_token=AD2BV4I5UWTVXZLSVNJ63B3QZN4CDA5CNFSM4J3H7UM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHJVLTI#issuecomment-567498189,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD2BV4KZYTUCBT2SP6T5J4TQZN4CDANCNFSM4J3H7UMQ
.

--
Thanks & Regards,

[PierreBesson]

I have a feature request on my mind for some time which would be best for an internship. It would be to implement two factor authentication for our JWT option.

[vishal423]

Starting keycloak v8, WebAuthn support is available. It would be
interesting to enable this in JHipster.

On Thu, Dec 19, 2019 at 11:22 PM Pierre Besson [e-mail]
wrote:

I have a feature request on my mind for some time which would be best for
an internship. It would be to implement two factor authentication for our
JWT option.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/10958?email_source=notifications&email_token=AD2BV4PAVPWH63THWL2TSWLQZOYHBA5CNFSM4J3H7UM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHKM5EI#issuecomment-567594641,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD2BV4LGRZDTRFUY5XLDGJTQZOYHBANCNFSM4J3H7UMQ
.

--
Thanks & Regards,

[pascalgrimaud]

Unless you disagree, I'm adding:

• remove Java8 support

[cbornet]

:+1: let's put var everywhere !

[DanielFran]

Migrate from springfox to springdoc (https://github.com/springdoc/springdoc-openapi/issues/292)

[atomfrede]

What about making psql the default SQL database? And maybe remove h2 for unit tests when selecting same db for production and leverage testcontainers for that?

[pascalgrimaud]

+1 for psql by default

About testcontainer, I'm not sure. You can have some issue for CI, which uses build inside Docker. It means you need to config DinD service (Docker in Docker), which is for avdanced users

[atomfrede]

Yes not sure about testcontainers but maybe make it an option.

[pascalgrimaud]

If I remember well, @cbornet you wanted to switch back to Tomcat, instead of staying with Undertow. Am I correct ? If yes, we could add it to the list.

[deepu105]

Any specific reason to switch from Undertow?

[jdubois]

Concerning Tomcat vs Undertow, it's initially my decision so let me recap:

• Undertow starts a bit faster and we never had any issue with it. I didn't check, but I also guess it's lighter.
• BUT it looks like nobody uses it outside of us. This means we need to configure it specifically, and that we sometime loose monitoring data (on Azure Spring Cloud, you get automatic monitoring of Tomcat, but not Undertow). Also, it looks like activity on GitHub is low ( https://github.com/undertow-io/undertow/pulse/monthly ) and that Red Hat doesn't use it on Quarkus (it's an extension that can be used for supporting Servlets), which doesn't look good for the future of the project.

[mraible]

I thought we used Undertow because it has HTTP/2 support.

On Jan 14, 2020, at 12:32 PM, Julien Dubois [e-mail] wrote:

Concerning Tomcat vs Undertow, it's initially my decision so let me recap:

Undertow starts a bit faster and we never had any issue with it. I didn't check, but I also guess it's lighter.
BUT it looks like nobody uses it outside of us. This means we need to configure it specifically, and that we sometime loose monitoring data (on Azure Spring Cloud, you get automatic monitoring of Tomcat, but not Undertow). Also, it looks like activity on GitHub is low ( https://github.com/undertow-io/undertow/pulse/monthly https://github.com/undertow-io/undertow/pulse/monthly ) and that Red Hat doesn't use it on Quarkus (it's an extension that can be used for supporting Servlets), which doesn't look good for the future of the project.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/10958?email_source=notifications&email_token=AAAELZDBPX6N6Y5GVSIII7DQ5YHLRA5CNFSM4J3H7UM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI52SSY#issuecomment-574335307, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAELZACC3K5EFUEWRPRSULQ5YHLRANCNFSM4J3H7UMQ.

[jdubois]

@mraible I had no idea about this, so if this was an argument then it didn't come from me! Anyway, Spring Boot should support Tomcat with HTTP2 now.

[pmverma]

While this is not a feature but can't we just replace all the string literals used everywhere with constants?
For eg,

if (authenticationType === 'oauth2') -> if (authenticationType === AuthType.OAuth)
if (prodDatabaseType === 'mssql') -> if (prodDatabaseType === DB.Mssql) 
and many others

There are so many of them everywhere!

[deepu105]

Hi Mohan,

yes, we could, but would require some considerable refactoring. Feel free
to attempt if you have the time

Thanks & Regards,
Deepu

On Thu, Jan 23, 2020 at 2:00 PM P. Mohan [e-mail] wrote:

While this is not a feature but can't we just replace all the string
literals used everywhere with constants?
For eg,

if (authenticationType === 'oauth2') -> === if (authenticationType === AuthType.OAuth)
if (prodDatabaseType === 'mssql') -> if (prodDatabaseType === DB.Mssql)
and many others

There are so many of them everywhere!

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/10958?email_source=notifications&email_token=AAIOKF7BFHNSQQRVD3JKOVDQ7GIHLA5CNFSM4J3H7UM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJXJDEA#issuecomment-577671568,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIOKFYWFSSFYAA6MXNFOU3Q7GIHLANCNFSM4J3H7UMQ
.

[pmverma]

Thanks @deepu105 , I will give a try as soon as I have some free time.

[gmarziou]

Could we remove dependency on DropWizard ?

[PierreBesson]

I think the dependency on dropwizard is only to output the metrics in the logs so yes it can be removed.

[PierreBesson]

I would like to deprecate the JHipster Console for JHipster 7. It can be replaced by documentation on how to integrate with ELK and Prometheus.

[pmverma]

Do we have any available statistics for npm vs yarn?
I think it is better to remove yarn if its usage is very less.

[gmarziou]

@PierreBesson yes exporting metrics through logback/logstash is no longer relevant with Prometheus Let's drop JHipster Console. This way we can also drop DropWizard metrics dependency.

I think documentation could be light because most likely users looking for a production ready centralized logging and metrics may opt for dedicated cloud solutions or for solutions integrated in their cloud provider offer.

For those who may want to manage their own infrastructure (for instance for regulation compliance like PCI-DSS) they will probably not use jhipster-console;

[atomfrede]

I would like to have a look at changed package structure for the backend. So package by feature and not by layer along with integrating modulith to enforce these constraints or did someone else already started something?

[mshima]

Added jdl centric to needs discussion.
Reason:
.yo-rc.json is a crucial part of yeoman-generator, it provides inter generator config synchronisation.
JDL centric can be implemented by creating a custom Storage once the config workflow is improved.

[Tcharl]

For side-by-side, there's a dedicated ticket: #12497