[Feature] [nx-spring-boot] Support for non-standard parents and for a parent pom.xml

[vanbujm]

I'd like to first thank you for this plugin! I am really excited to be using it to create a monorepo that can do both js/ts AND java-spring. 🥳

Is your feature request related to a problem? Please describe

My individual spring applications/libraries must separately state their dependencies even if they have common deps.

Describe the idea you'd like

I would like to be able to have a pom.xml at the root level of the monorepo that can state common things like:

• groupId
• common dependencies
• distributionManagement

Additional context

So I kind of found a hack for this solution already. You can add <!-- <artifactId>spring-boot-starter-parent</artifactId>--> to each application/library to get the plugin to recognise it as a Nx project, then implement your own <parent> block that points to a pom.xml at the root. This hack has the drawback of having to repeat the groupId for each application/lib to get the affected plugin to work.

What I would like to do is implement the following:

• change the plugin's logic for finding the groupId to first check the application/lib pom, then if empty, use the parents groupId
• change the plugin's logic to check for <artifactId>spring-boot-starter-parent</artifactId> and if it doesn't exist check for it in the root pom

I am happy to submit a PR

[vanbujm]

PR is up

[mtivi]

Any chance the pr can be looked at @tinesoft ? Without the ability to define a parent POM (other than spring boot directly), we cannot define common behavior.

I would like to extend the spring boot parent, defining my own distributionManagement, repositories, and pluginManagement

[mlschechter]

I've tried using the existing released nx-spring-boot plugin to create an application with libraries, and it creates the build wrapper (in my case, Maven Wrapper) in each of the directories of the monorepo.

@mtivi - Could you please update the documentation in your pull request to indicate what structure is created by the new functionality? It would be very helpful to understand how the various modifications work to generate a structure.

Is there any support for separating the inheritance (dependency/plugin management, etc.) from build aggregation? Projects like Spring Boot and Dropwizard separate these into a parent build in a subdirectory.

Also, does this support Gradle builds and the buildSrc reusability model?

[mtivi]

I do not have a PR @mlschechter. @vanbujm created a PR that I'd like to make use of.

[tinesoft]

Hi folks!

Thank you for the interest in the plugin, I'm glad it's being useful to other devs out there ^^

@vanbujm Thanks for your PR🙏🏾. and sorry for the late answer... I can't remember why I haven't looked at it sooner or why I closed it... 😳

@mtivi @mlschechter you'll be happy to know that I have since implemented a proper multi-module support for both Maven and Gradle! in PR#179

This is the very first attempt to multi-modules support, following some guidelines from Spring Boot docs. Based on your feedbacks, I will certainly improve it further.

I plan to release it next week. I'll ping back here once done.

Stay tuned!

[tinesoft]

I've just released https://github.com/tinesoft/nxrocks/releases/tag/nx-spring-boot%2Fv8.1.0 with the above features!

Have fun with the new multi-modules support and feel free to share any issue/improvement ☺️