Generator-jhipster: Move all non-essential classes/utils to the server-side and client-side libs.

[deepu105]

Enabling the possibility of overriding them if needed. This makes generated code lighter

[deepu105]

I would actually propose to make this a high priority task for JH7. What do you think @jdubois @pascalgrimaud @jhipster/developers ?

[deepu105]

@avdev4j this could be a nice task for you if everyone & you agree as this needs some focused work IMO

[avdev4j]

If you think it's something with high priority so I could focus on it. I already had this discussion with @jdubois and reduce the number of generated files seems to be a good way to go.

however, we need to define which classes are non essentials. Have you already any idea about that?

[gmarziou]

Moving everything to libs makes it harder to update users projects unless they continuously follow JHipster updates which is very difficult as soon as users add custom code.

JHipster team maintains only current major version which means roughly one year while major libs like Spring, Hibernate often support older versions for many years.

So basically, it means that after one year, it's much harder to update a JHipster project and if you want to fix some vulnerabilities from Spring or Jackson, you'd better manage these dependencies yourself and don't depend on JHipster for it.

Also, the jhipster libs version naming does not follow the generator's version naming which makes it even harder to know which one works for which generator version.

All this for me translates into "more generated code means project easier to maintain on mid to long term".

[jdubois]

@gmarziou I totally agree we should have the same major.minor versions for the generator and the lib (maybe not get down to the patch level). We have an issue about this somewhere.

But for the rest I have the exact opposite feedback : it’s much easier to update a lib (also: you have tools like dependabot which do it automatically) than re-generating and merging everything.

[gmarziou]

@jdubois I knew you'd disagree because I had same position when team initially decided to move more classes to libs but it's OK :)

I think that using the lib approach is easier for the JHipster team but not for JHipster users.
Also, I was not speaking of re-generating, for me after few months of a project generated by JHipster, it does not make any sense to run jhipster upgrade

My team is working on 3 JHipster apps that are under PCI-DSS requirements, to be compliant we must monitor all vulnerabilities announced by external libs. So, for us, it's a serious business and yes we have tools for doing so.

For the 2 first apps, keeping them up to date with security fixes was more complex due to using jhipster BOM from a 2 years old version. You would think that it's just a matter of incrementing some versions in pom.xml but it's not because of dependency transitivity and one level of indirection added by JHipster. One of my team mates had to document how to do it because it was difficult.

So, for the most recent one, after 3 months of dev I cut the dependencies with jhipster BOM to rely as much as possible on spring boot starters which will be maintained longer and now things are simpler.

In frontend code, it's even more difficult at least for Angular because ng-jhipster depends on ng-bootstrap for few things like the alert popups. So, if you decided to use a richer UI lib like PrimeNG or Angular Material, you'll spend some time to remove this dependency and as this code is not generated, it's more difficult to do it.

Another difficulty that is currently being addressed is the poor compatibility with Angular CLI, updating your app which ng cli is so much easier.

[sendilkumarn]

I agree with @gmarziou here.It adds another layer of abstraction and this will make it difficult for the users (especially those who would like to customise).

In fact I guess I was a biggest fan for moving into library before. But lately realised how problematic it will be when we wanted to customise the solution.

For the lite version of JHipster, IMO we should construct it from scratch rather than retro-fitting a solution into the existing product.

[jdubois]

OK, then it would be good to have more feedback here.

For me you have 3 different issues here:

• The BOM: it indeeds add a layer on top of the Spring BOM, but it does not radically change things (as there is still the Spring BOM), and we're supposed to only add JHipster-specific dependencies here (for example, we should usually keep the Hibernate version coming from the Spring BOM, unless there is a bug in it)
• The Java code: a lot of it is never customized, and maybe even shouldn't be (=the JWT code, which is just too complex for most people). Updating it or having it compliant is just like any other Java libraries, and there are already a lot of them.
• The TypeScript code: this one is clearly more complex, and managing dependencies there is really hard. I mostly want to reduce code so that build time are smaller, and also because many things are never modified there. Then, with the JHipster Control Center, we are already in the process of removing all the admin screens anyway, which is a huge step forward.

[gmarziou]

• The BOM approach is OK in itself, the only problem that makes it difficult to use is that it is supported only for one year per major version. Imagine that it was the same for Spring Boot starters, would you keep on using them or rather drop them?
• The Java code: the server-side lib is not like other libraries because it's monolithic, aggregating many dependencies that are not required by many projects.

When you generate code, at least you generate only what's required by a user's project in pom.xml and in code. This is what was so attracting to me in JHipster before it started to add its own runtime dependencies and turned into a framework. I preferred when JHipster was Spring Initializr on steroids.

[pascalgrimaud]

+1 with @gmarziou
I use JHipster in real project for my customers and what I like is the fact I can customize all classes I want.
Because of jhipster lib, sometimes, I had to copy paste exactly the same classes from jhipster lib, change package, and customize these classes.

I absolutely don't care about people who complain about 'JHipster generates too much classes'. They don't understand why these classes are here.

Another important point for me.
We wanted to split into little projects, into librairies because we consider these classes won't change a lot. In fact, for each new release of JHipster, we need to release: ng-jhipster, react-jhipster, jhipster lib, jhipster core etc
So in the end, it's more work as the generator-jhipster depends on all these libs.

That's the reason why we are moving JHipster Core into generator-jhipster

[DanielFran]

+1 with @gmarziou.
Would prefer that generated project contains all classes, so I can customize easily.

[murdos]

+1 with @gmarziou https://github.com/gmarziou and Pascal

Le sam. 4 juil. 2020 à 12:53, Daniel Franco [e-mail] a
écrit :

+1 with @gmarziou https://github.com/gmarziou.
Would prefer that generated project contains all classes, so I can
customize easily.

—
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/12019#issuecomment-653751038,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABGBNDQUKJEUPEOS6DUGLLRZ4C2PANCNFSM4ONMAYPA
.

[jdubois]

I thought we had a consensus here, but in fact we do not.
Let’s block this for the moment, and gather more feedback and ideas.

[PierreBesson]

I volunteer to work on this during this summer to the best of my capacity
for the server side. I think I can propose something...

Le sam. 4 juil. 2020 à 20:24, Julien Dubois [e-mail] a
écrit :

I thought we had a consensus here, but in fact we do not.
Let’s block this for the moment, and gather more feedback and ideas.

—
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/12019#issuecomment-653797070,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAD5LP4MTCCZI4RE4YTKBPLRZ5XUZANCNFSM4ONMAYPA
.

[PierreBesson]

I think we can find a solution similar to spring boot where you can easily
surcharge the defaults provided by the lib. This is what would satisfy most
people. Maybe it can be an option to have explicit vs implicit
configuration.

Le sam. 4 juil. 2020 à 22:22, Pierre Besson [e-mail] a
écrit :

I volunteer to work on this during this summer to the best of my capacity
for the server side. I think I can propose something...

Le sam. 4 juil. 2020 à 20:24, Julien Dubois [e-mail] a
écrit :

I thought we had a consensus here, but in fact we do not.
Let’s block this for the moment, and gather more feedback and ideas.

—
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/12019#issuecomment-653797070,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAD5LP4MTCCZI4RE4YTKBPLRZ5XUZANCNFSM4ONMAYPA
.

[atomfrede]

I think having more stuff in a library makes it easier for us, but necessarily for our users. In case there is a bug/problem most of the times we are able to provide a workaround like change following lines in that class/file, which would not be possible that easily with having more stuff inside a library.

[deepu105]

I think @gmarziou and @pascalgrimaud has some really valuable feedback here becoz unlike many of us they are actually maintaining applications built with JHipster, so instead of just adding my hypothetical opinion (which is just that and doesn't have a lot of Exp with actually maintaining a JHipster app for many years) I'll propose to look at their feedback and see if we can do something about it. Should we look at the way we maintain and support the libs? should we support previous versions of the BOM?

[jdubois]

This is indeed very surprising to me:

• Originally I wanted to generate everything, but I had a ton of negative feedback against it. That's why I pushed for the BOM and the libraries, and I believe those were good choices as they simplify the usage of JHipster and the upgrades.
• Now I see all the experienced JHipster users (and it seems unanimous) are against using the libraries (I'm less sure about the BOM).

Of course we need to discuss this on a case-by-case basis. For instance, I believe putting our JWT code in a library would be a good thing: nobody should touch this (and if you do, you'll probably mess things up).

As always, I'm going to try to gather feedback from other communities like NodeJS, Rails or Symphony. I believe they already had that kind of issue, and it's important to learn from them. I will post here my findings.

Then, this is definitely a good discussion to have at our upcoming JHipster Code conference.

[mraible]

My proposal: Do the work to make this happen, in a separate repo than we have now. Make it so you can generate a JHipster app with no code. Give users the ability to opt-in. For example:

jhipster jdl oauth2-blog --no-code

Personally, I hate the "no code" and "low code" marketing terms that are floating around. But.... maybe we should embrace them and make it as an option?

[deepu105]

TBH I hate those terms as well and I like the way JHipster is but unfortunately lot of people (especially more experienced devs) keep complaining that we create too much code so any solution to reduce the amount of code we generate by default would be nice. Libs are obviously one way and so far no body complained when we moved stuff to libs, so may be we can move more to libs. Another way probably is with the hexagonal stuff

[pascalgrimaud]

I think we are fine today, I don't see what additional stuff we could put in jhipster lib
Should we keep this ticket opened ?
Or can we move on, to be closer to v7 @deepu105 ?

[jdubois]

Can I move the JWT code to the lib? I don’t believe it’s good to customize it, and it would make security issues easier to handle

[pascalgrimaud]

indeed, the JWT part should be moved
@jdubois : don't forget it's the new project, jhipster-bom, with the new package name: tech.jhipster :)

[deepu105]

Ya lets close it. There isn't too much interest here anyway

On Fri, 6 Nov 2020, 11:19 pm Pascal Grimaud, [e-mail]
wrote:

indeed, the JWT part should be moved
@jdubois https://github.com/jdubois : don't forget it's the new
project, jhipster-bom, with the new package name: tech.jhipster :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/12019#issuecomment-723325287,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIOKFZWU6KBKKOYIKDTES3SORY6VANCNFSM4ONMAYPA
.