-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support multi-module Maven projects #222
Comments
I've updated this issue with a better description :-) |
Thanks for creating this @evenh. Here's my plan for implementing - am I missing anything? File fetching
File parsing
Update checking / file updating
|
Your proposal looks sane to me. Regarding your question, yes - that's a possibility (unfortunately) |
Cool. FYI, the PR tracking this is #354. Should have it done tomorrow. 🎉 |
https://github.com/greysteil/maven-multimodule-sample/pulls 🔥 🔥 🔥 I'll blog about this and release it on Monday. @evenh - if you have any repos you'd like to try it on before then I'd be much obliged. There are bound to be a few bugs hiding in there. Thanks so much for your advice and encouragement on this one! |
That's just awesome @greysteil - good (and quick) work 😀 I've just updated evenh/maven-multimodule-sample@4035b88 and was expecting two pull requests with 1 file each or one pull request with 2 files after pushing that last commit. |
Ah, Dependabot won't create that because it remembers that it's previously created a PR to |
And in other news, I've just added support for custom repositories 🎉 |
Dependabot already supports maven multi modules. So just one block should be fine. dependabot/dependabot-core#222
Since Dependabot cannot handle multiple versions of the same artifact at once, our Dependabot configuration for `2.x` is split into two runs: - One Dependabot run handles the dependency upgrades for the `log4j-slf4j-impl` (based on SLF4J 1.x) and `log4j-mongodb4` (based on MongoDB client 4.x). - A second Dependabot run handles the dependency upgrades for the remaining modules (which use SLF4J 2.x and MongoDB client 5.x). Unfortunately, due to the way Maven multi-module support is implemented in Dependabot (see dependabot/dependabot-core#222), the second Dependabot configuration also tries to upgrade the dependencies of `log4j-slf4j-impl` and `log4j-mongodb4`. This is due to the inclusion of the aggregator POM `/pom.xml`, which causes Dependabot to also include all the remaining Log4j modules. The easiest solution to this problem is to remove "/" from the second configuration. Pros: - 99% of our managed dependencies are in "/log4j-parent" or the individual modules, so we will not miss many upgrades. - No more duplicate PRs. Cons: - "pom.xml" contains some dummy managed dependencies to upgrade the version number of `commons-csv` and similar artifacts for **site-only** purposes. IMHO we should find a different way to upgrade these.
Since Dependabot cannot handle multiple versions of the same artifact at once, our Dependabot configuration for `2.x` is split into two runs: - One Dependabot run handles the dependency upgrades for the `log4j-slf4j-impl` (based on SLF4J 1.x) and `log4j-mongodb4` (based on MongoDB client 4.x). - A second Dependabot run handles the dependency upgrades for the remaining modules (which use SLF4J 2.x and MongoDB client 5.x). Unfortunately, due to the way Maven multi-module support is implemented in Dependabot (see dependabot/dependabot-core#222), the second Dependabot configuration also tries to upgrade the dependencies of `log4j-slf4j-impl` and `log4j-mongodb4`. This is due to the inclusion of the aggregator POM `/pom.xml`, which causes Dependabot to also include all the remaining Log4j modules. The easiest solution to this problem is to remove "/" from the second configuration. Pros: - 99% of our managed dependencies are in "/log4j-parent" or the individual modules, so we will not miss many upgrades. - No more duplicate PRs. Cons: - "pom.xml" contains some dummy managed dependencies to upgrade the version number of `commons-csv` and similar artifacts for **site-only** purposes. IMHO we should find a different way to upgrade these.
In a lot of (open source and enterprise) projects it is very common to create Maven multi-module projects. One can for example have a module for only domain classes, utils or interfaces meant for public consumption.
Dependencies (code dependencies, plugins etc) can be attached to any module, optionally overriding dependencies higher up in the hierarchy (often referred to as the build reactor in Maven terminology).
In order for dependabot to be useful to a lot of Java shops, this functionality must be implemented.
See this project for a sample.
The text was updated successfully, but these errors were encountered: