Generator-jhipster: Create a JHipster library

[jdubois]

This has already been discussed many times, and I think it's time to act, before we release JHipster 4.

The goal is to create our own JHipster Java library:

• JHipster wouldn't be "just" a generator, it would evolve into a real framework
• We would have the same library on the front end, now we have migrated to Angular 2 and have modules, but that will be done in a second time

We'll do this to simplify some parts of JHipster, as:

• Some of the generated files are never changed by users, and so they add complexity for nothing
• Those files add trouble when doing upgrades

It's also better for us, it's easier to code directly the library, than doing templates.

My proposal is to start with something very small and very simple, and then we'll see how we can evolve:

• Some of the Security stuff like the Ajax*Handler files
• Some utilities, like AngularCookieLocaleResolver, LoggingAspect, ExceptionHandlingAsyncTaskExecutor(is this still relevant?), FixedH2Dialect
• This will force us to have a specific JHipsterProperties config, so I will need to rename the existing JHipsterProperties into something else, probably <<MyAppName>>Properties

For me this is a must-have feature, and I could lead this pretty quickly, while the Angular 2 version is being lead by @deepu105 , so this can be done in time for JHipster 4.

This is of course open for comments: please vote on this ticket if you like it or not, and please add comments if you have strong opinions against this, as this will impact everyone.

[deepu105]

I completely agree for the plan :+1:
Lets start with the stuff you mentioned those are hardly modified by people.

I would also like to remove the jhi-prefix option as it adds unwanted complexity. It can be used for stuff like route url etc but not on the actual code. I reallly dont care about people who want to generate something with jhipster and then call it their own.Majority of our users wouldnt mind having internal class/files names with Jhi as prefix. This will save us lot of maintanance headache in future. There are lot of classes in our NG2 code which has the prefix on class names

[mraible]

I'm against this based on past experience with AppFuse. However, you guys do most of the development and maintenance, so I'll leave this decision up to you. ;)

[jdubois]

@mraible sorry I remember your discussion on this, and I forgot about it when I did the ticket!
But yes we have a lot of demand for this, and I'm not totally sure it's the best decision, that's why we would start small, with a few obvious classes. So if that's an issue, it wouldn't be too bad.

@deepu105 for this I need to merge #4660 -> is this OK with you? It might add a few bugs as that's really a hard part to test, but the classic use cases are covered.

[jdubois]

I'm creating a jhipster/jhipster project (incredibly we didn't use the name yet!!) and I'll give write access to the JHipster dev team, like we have with the current jhipster/generator-jhipster page. I'll disable wiki and tickets for the moment, and forward people to jhipster/generator-jhipster, so we still have one central place.

[sendilkumarn]

A big +1 from me..

On 12 Dec 2016 11:04 PM, "Julien Dubois" [e-mail] wrote:

I'm creating a jhipster/jhipster project (incredibly we didn't use the
name yet!!) and I'll give write access to the JHipster dev team, like we
have with the current jhipster/generator-jhipster page. I'll disable wiki
and tickets for the moment, and forward people to
jhipster/generator-jhipster, so we still have one central place.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/4662#issuecomment-266453492,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AL5LUlRZAw_qhk_1YrFmkVrJU1zfeR5_ks5rHWJ_gaJpZM4LKjwa
.

[deepu105]

Yes please merge we are doing a beta release anyway :smiling_imp:

[jdubois]

First code is pushed at https://github.com/jhipster/jhipster !!

[gzsombor]

I've used previously Trails which was a similar CRUD generation app, with an embedded library. Initially it was fun, but it was very hard to fix even simple things - so I don't think it could be a good solution generally.
Lot's of times, I had to customize the generated code - for example to add the user id to the Spring Security UserDetails implementation, or to the auditing stuff, which is currently a not so difficult - even a bit boring - stuff, which I had to do every time, when I want to upgrade. But if it's turned into a library, this could be a big PITA.
At least, try to limit to stuff, which can be easily customized later : so no static variables, no final/private variables, just plain simple DTOs and services, etc ...

[PierreBesson]

I'm OK with this. Totally agree with having two separate configuration properties class, one for JHipster and one for the user.

[deepu105]

@gzsombor yes that is the primary concern and for that we should make sure that everything in the library can be locally overridden similar to spring boot so that if you have to do something you can extend the class and do that easily but that means more work for us to make it extendable

[jdubois]

@gzsombor @deepu105 yes at the moment I'm only doing very basic stuff: utility classes, that nobody modifies (at least nobody that I know of!). Those are not Spring beans, so you can use them or not, without any issue.
Next step would be "some" Spring beans, doing the same mechanism as Spring Boot, so they are easy to disable or override if needed.
This will not include any entity code, it's only for some parts of the main generator, that nobody changes because they contain specific optimizations or tunings.

[jdubois]

And a first version is released on Maven Central!

See:

https://issues.sonatype.org/browse/OSSRH-25366
https://github.com/jhipster/jhipster

[gmarziou]

Looks good. How do you plan to manage dependencies version between apps and lib?

[jdubois]

The app will have a dependency in its pom.xml, and that's all :-)