Drop jhipster-dependencies dependency.

[mshima]

Overview of the feature request

Drop jhipster-dependencies dependency and use spring-boot's dependency management.
jhipster-framework will be kept.

Motivation for or Use Case

The idea of jhispter-dependencies is to add a centralized dependency management for jhipster project to unify and simplify dependencies.
Currently we have a mixed of jhispter-dependencies and generator-jhipster managed dependencies, so the purpose is only partially met.

Removing jhispter-dependencies will provide:

• less maintenance burden.
• easier release process (generator-jhipster only, jhipster-framework when needed).
• unified repository for dependency versions.
• better CI due to selective built-in generator-jhipster managed dependencies.
• spring-boot standard built tool implementation.

Related issues or PR

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

[mshima]

What do you think @mraible @DanielFran @deepu105?

[mraible]

Does this mean we can use spring-boot-starter-parent as a parent in generated projects? I remember talking to Josh Long a few years ago and he was appalled that JHipster managed its own dependencies rather than relying on Spring Boot's parent.

[mshima]

Does this mean we can use spring-boot-starter-parent as a parent in generated projects?

We probably can use spring-boot-dependencies only.
I think the benefit of spring-boot-starter-parent is to avoid dependency conflicts outside <dependencies>.

I remember talking to Josh Long a few years ago and he was appalled that JHipster managed its own dependencies rather than relying on Spring Boot's parent.

We will be still managing our own dependencies, but at generator-jhipster side only.

[mshima]

We are managing on generator-jhipster side:

• every node dependency.
• 37 dependencies at pom.xml file https://github.com/mshima/generator-jhipster/blob/f16e1b3020e045d4027d2cabb4065e57cb1a8d4c/generators/server/resources/pom.xml#L11-L49
• 9 dependencies at libs.version.toml file https://github.com/mshima/generator-jhipster/blob/f16e1b3020e045d4027d2cabb4065e57cb1a8d4c/generators/server/resources/gradle/libs.versions.toml#L2-L18

And at jhipster-dependencies side:

• 19 dependencies https://github.com/jhipster/jhipster-bom/blob/ab6f9aa1b079a4ae30c3bcaf4602b7778b124cf9/jhipster-dependencies/pom.xml#L42-L63.

Only springdoc-openapi dependency in jhipster-dependencies is used by the application jhipster --defaults.

[DanielFran]

I am in favour too!
Since we found a different behaviour with the bom in last maven release, it is better to manage the dependencies in the generator.

[mshima]

Indeed we define a custom testcontainers version.
But the version from spring-boot-dependencies is used anyway

[atomfrede]

Less overhead for releases and being closes to upstream boot would be a beneficial imho. So lets do it.

[deepu105]

Sounds good.

…

On Wed, 20 Mar 2024, 8:59 pm Frederik Hahne, ***@***.***> wrote: Less overhead for releases and being closes to upstream boot would be a beneficial imho. So lets do it. — Reply to this email directly, view it on GitHub <#25565 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIOKF6MGMN3TWRDHKVXWULYZHTD5AVCNFSM6AAAAABE777EQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJQGUYTKNZQHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>