Comments (12)
Thanks for your Input @datencia
I like the idea of using the :artifactId
:-)
I thought about it at the beginning, don't remember why I discarded the idea at the time... but it seems the best solution.
I will dig a little more and gather knowledge for Gradle as well, to provide the most unified and simple solution for users.
Don't hesitate to continue sharing your feedback, much appreciated 👍🏾
from nxrocks.
Hi @mklueh
I'm currently improving the support for multi-modules projects to accommodate this use case( Initial PR is here: #210)
It should be fixed very shortly.
So stay tuned! ;-)
from nxrocks.
Thanks for using the plugin and for your kudos! Don't hesitate to star ⭐ the project on GitHub ;-)
Regarding the issue, it looks indeed like a bug, as when the runFromParentModule
is set to true
, the executor is already supposed to search the child module folder hierarchy, until the parent pom.xml
(or build.gradle
) that does contain the child module is found...
I'll have a look into it, stay tune!
from nxrocks.
🤟 Great!
Yes, I've been digging through the code and I've seen the loop causing this that tries to locate the parent pom.xml.
Thank you for your quick response ⭐ ⭐ ⭐
from nxrocks.
🎉 This issue has been resolved in version 9.0.2 🎉
The release is available on:
Your semantic-release bot 📦🚀
from nxrocks.
Thank you 🤟
I've been testing the new release but it is still not working because it is not taking into consideration the path of the submodule when looking for it in the parent pom.xml
file. I've created a PR fixing it.
from nxrocks.
Hi @datencia, thanks for trying out the multi-module feature and for your PR
But unfortunately, I think your proposed implementation is not correct either...
There is a misconception on how the structure of a true nested multi-modules project should look like.
As the result, my initial implementation was "limited" in that regard, and your is not really solving the problem.
I looked at Spring Boot own project on Github, which is imho, a very good example of how a truly nested multi-modules project should be structured.
This is what I learned:
For Maven
(Until 2.2.x, Spring Boot project was using Maven as build system)
https://github.com/spring-projects/spring-boot/tree/2.2.x
├── spring-boot-tests/
│ ├── spring-boot-deployment-tests
│ ├── spring-boot-integration-tests
│ ├── spring-boot-smoke-tests-invoker
│ ├── spring-boot-smoke-tests
│ └── pom.xml (intermediary pom.xml listing direct children modules in this folder)
│
├── spring-boot-project/
│ ├── spring-boot-actuator
│ ├── spring-boot-devtools
│ ├── spring-boot-starters/
│ │ ├── spring-boot-starter-activemq
│ │ ├── spring-boot-starter-actuator
│ │ ├── spring-boot-starter-jpa
│ │ └── pom.xml (intermediary pom.xml listing direct children modules in this folder)
│ │
│ └── pom.xml
│
└── pom.xml (THE root module)
Main Takeaways
- one additional
pom.xml
at each intermediary level - the intermediary
pom.xml
lists direct children modules in the folder
For Gradle
(Since 2.3.x, Spring Boot project now uses Gradle as build system)
https://github.com/spring-projects/spring-boot/tree/main
├── spring-boot-tests/
│ ├── spring-boot-deployment-tests
│ ├── spring-boot-integration-tests
│ ├── spring-boot-smoke-tests-invoker
│ └── spring-boot-smoke-tests
│
├── spring-boot-project/
│ ├── spring-boot-actuator
│ ├── spring-boot-devtools
│ └── spring-boot-starters/
│ ├── spring-boot-starter-activemq
│ ├── spring-boot-starter-actuator
│ └── spring-boot-starter-jpa
├── build.gradle
└── settings.gradle (THE root module listing all modules using their full path , with ":" as separator)
Main Takeaways
- no need for additional
settings.gradle
at each intermediary level - the root module
settings.gradle
lists all modules using their full path , with ":" as separator
So based on that, I will rework/improve and better document the nested mutli-module support, following the best practices from Spring Boot project, as described above.
Stay tuned!
from nxrocks.
mmm I see, but imho it is merely a way of organizing the modules and not a good practice itself.
This organization may make sense within the scope of a project that requires it, but other projects do not need to create an intermediate pom.xml.
I'm going to try to use this workaround of an intermediate pom.xml but I guess I'll have to add another maven wrapper there for it to work, right?
from nxrocks.
Suggestion: make the root module path configurable at the plugin level to avoid these problems by locating the Maven wrapper so you don't have to search by code for its location.
from nxrocks.
Hi @datencia
This organization may make sense within the scope of a project that requires it, but other projects do not need to create an intermediate pom.xml.
OK, granted that the intermediary pom.xml
might not be always necessary (depending on if there is an actual need to gather common configuration, dependencies or plugins at that level).
But, I'm curious... in your case:
- why would you have an intermediary
apps
folder (demo-parent/apps/demo/
) to begin with? - how does your
demo-parent/**pom.xml**
look like? do you refer to the demo child module from there (using the relative path<module>./apps/demo</module>
?
I'm going to try to use this workaround of an intermediate pom.xml but I guess I'll have to add another maven wrapper there for it to work, right?
Yes that right, The current code expect the parent module to declare the child module as a direct module (i.e <module>child-module</module>
and also to contain the Maven Wrapper files.
Regarding the issue, it looks indeed like a bug, as when the runFromParentModule is set to true, the executor is already supposed to search the child module folder hierarchy, until the parent pom.xml (or build.gradle) that does contain the child module is found...
I would like the plugin to ease/automate that as much as possible, to avoid yet another config to manage for end-users. Not sure if most of them will ever need such detail of customization...
from nxrocks.
But, I'm curious... in your case:
In my case, I have an structure like this (reduced for simplicity, the names are for guidance only) managing 3 independent apps, e.g. 2 spring boot applications and one angular/react app:
.
├── mvnw
├── mvnw.cmd
├── nx.json
├── package.json
├── package-lock.json
├── apps
│ ├── backend
│ │ ├── pom.xml
│ │ ├── project.json
│ │ └── src
│ ├── api-rest
│ │ ├── pom.xml
│ │ ├── project.json
│ │ └── src
│ └── frontend
│ ├── package.json
│ └── src
├── pom.xml
└── README.md
The parent pom.xml
file (at the project root folder, note also the Maven wrapper there) manages the common properties/dependencies for the 2 spring boot applications and declares them as modules:
<modules>
<module>apps/backend</module>
<module>apps/rest-api</module>
</modules>
I would like the plugin to ease/automate that as much as possible, to avoid yet another config to manage for end-users. Not sure if most of them will ever need such detail of customization...
I have thinking about it, reading the Maven docs (I have not been able to look at gradle) I think that if the plugin offered a way to indicate the path to the maven wrapper (or by default use the root folder of the project as it usually happens) you could avoid having to locate it manually, and combining it with the use of the ArtifactId instead of using the path would avoid having to calculate/locate the module that contains it.
Inspecting the Maven help mvn --help
I read this
-pl,--projects <arg> Comma-delimited list of specified
reactor projects to build instead
of all projects. A project can be
specified by [groupId]:artifactId
or by its relative path
Note the point A project can be specified by [groupId]:artifactId or by its relative path
.
I have been testing a while this approach (to be honest, I didn't know about it) and works, e.g.
./mvnw clean -pl :backend`
Where backend
(in this example) is the artifactId for the apps/backend
application as declared in apps/backend/pom.xml
.
By using the artifactId I don't need to know the path of the module.
from nxrocks.
Running into the same issue after wondering why my CI timeouted after 40 minutes.
I'm using Gradle and @nxrocks/nx-quarkus.
Is there any progress on this issue so far?
from nxrocks.
Related Issues (20)
- Adopting Nx to SpringBoot MonoRepo's HOT 1
- Run arguments on project level are not pass to ./mvnw spring-boot:run only the ones that are coded to the project.json HOT 5
- [Feature] Configuration Variants HOT 1
- [Feature] (nx-spring-boot) Add Support for Java 21 HOT 2
- [chore] Reduce code smells reported by Sonarcloud
- [Feature] Make sure e2e + smoke tests pass on all OS
- Linking is failing with nx-spring-boot link command [Bug] HOT 1
- [bug] Spring packages are not cached HOT 1
- [Feature] Update plugins to support Nx 17 HOT 14
- [Bug] Support for nx v17.x.x HOT 6
- [Feature] : support java 21 HOT 5
- [Question] Maven dependency management for monorepo libs HOT 16
- [Feature] Run custom Maven commands by nx-spring-boot HOT 2
- [Bug] create-nx-spring-boot fails to run HOT 3
- [Bug] createNodesFor is not a function since @nxrocks/nx-spring-boot 9.3.0 HOT 8
- Cached projects are only restored the "target" folder but not the ~/.m2/repository folder HOT 10
- [Bug] Cannot run any nx command after creating micronaut project HOT 10
- [Bug] Spring boot multi-modules project doesn't work HOT 11
- [Bug] nx-flutter: inferred tasks aren't working HOT 26
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nxrocks.