Skip to content
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

Closed
evenh opened this issue Jan 15, 2018 · 8 comments
Closed

Support multi-module Maven projects #222

evenh opened this issue Jan 15, 2018 · 8 comments

Comments

@evenh
Copy link
Contributor

evenh commented Jan 15, 2018

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.

@evenh evenh changed the title [WIP] Support multi-module Maven projects Support multi-module Maven projects Feb 7, 2018
@evenh
Copy link
Contributor Author

evenh commented Feb 7, 2018

I've updated this issue with a better description :-)

@greysteil
Copy link
Contributor

Thanks for creating this @evenh. Here's my plan for implementing - am I missing anything?

File fetching

  • Dependabot fetches the root pom.xml (i.e., the one that is in the directory specified by the user, which by default is the root directory of the git repo)
  • Dependabot reads the <modules> from that pom.xml and looks in each of those directories for a pom.xml
    • If any directory specified as a module doesn't have a pom.xml Dependabot errors
  • Dependabot reads each of the module pm.xml files looking for more modules, and recursively downloads them, too.

File parsing

  • Dependabot parses each of the downloaded files as it normally would
    • Question: Will Dependabot ever encounter the same dependency being required twice, with incompatible versions? Is that allowed? As I understand it only a single version of a dependency is used by Maven.

Update checking / file updating

  • Happen as usual

@evenh
Copy link
Contributor Author

evenh commented Apr 19, 2018

Your proposal looks sane to me. Regarding your question, yes - that's a possibility (unfortunately)

@greysteil
Copy link
Contributor

Cool. FYI, the PR tracking this is #354. Should have it done tomorrow. 🎉

@greysteil
Copy link
Contributor

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!

@evenh
Copy link
Contributor Author

evenh commented Apr 22, 2018

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.

@greysteil
Copy link
Contributor

Ah, Dependabot won't create that because it remembers that it's previously created a PR to 24.1-jre. I can make it "forget" it from console though - one moment...

@greysteil
Copy link
Contributor

And in other news, I've just added support for custom repositories 🎉

melegiul added a commit to netzbegruenung/keycloak-mfa-plugins that referenced this issue Jul 26, 2024
Dependabot already supports maven multi modules.
So just one block should be fine.

dependabot/dependabot-core#222
ppkarwasz added a commit to apache/logging-log4j2 that referenced this issue Jan 6, 2025
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.
ppkarwasz added a commit to apache/logging-log4j2 that referenced this issue Jan 6, 2025
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants