Closed HerbertKoelman closed 1 year ago
Hello @HerbertKoelman. I believe this is one of those things that seems simple but might be complicated to implement. Mostly because when we generate a microservices architecture, all the apps created are in individual folders and are not related to each other. This allows you to put them in separate Git repos if you so desire.
If we generated an aggregator POM (which is similar to a parent POM), then the projects would require a layout like this:
pom.xml
- project1/pom.xml
- project2/pom.xml
- project3/pom.xml
We also kindof have a parent pom in jhipster-bom
. And, if we were doing things more of the Spring Boot Way, we'd use Spring Boot as our parent POM.
I don’t think it’s simple, I think it’s useful 😊A+HerbertLe 6 avr. 2023 à 17:33, Matt Raible @.***> a écrit : Hello @HerbertKoelman. I believe this is one of those things that seems simple but might be complicated to implement. Mostly because when we generate a microservices architecture, all the apps created are in individual folders and are not related to each other. This allows you to put them in separate Git repos if you so desire. If we generated an aggregator POM (which is similar to a parent POM), then the projects would require a layout like this: pom.xml
We also kindof have a parent pom in jhipster-bom. And, if we were doing things more of the Spring Boot Way, we'd use Spring Boot as our parent POM.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
This issue is stale because it has been open for too long without any activity. Due to the moving nature of jhipster generated application, bugs can become invalid. If this issue still applies please comment otherwise it will be closed in 7 days
Overview of the feature request
When implementing a distrubuted application all modules are based on the same software stack. Especially when implementing version 1 of the software.
So it might be a good thing to use a parent pom to reference all the common stuff like artefacts and plugins settings and versions.
If later some new modules are using different versions, thier pom file can always over ride artefacts versions or add a specific plugin taht will do something specific to the new module.
Motivation for or Use Case
As of now, we are spending a lot of time moving all the common things generated in each modules pom file into a parent pom.
Related issues or PR
Not that I know of.