Skip to content

Conversation

ppkarwasz
Copy link
Contributor

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.
@ppkarwasz ppkarwasz requested a review from vy January 6, 2025 14:21
@vy
Copy link
Member

vy commented Jan 6, 2025 via email

@ppkarwasz
Copy link
Contributor Author

(KO’ed by flu. Responding from bed.)

Get better soon!

Changes LGTM. I think we should later move the site from root to a leaf module. This might help us to implement “site should run after all modules”, which is a manual practice currently.

I am glad you agree. Having a dedicated site module can solve many problems, e.g., we could build the website with a simple ./mvnw site without a compulsory ./mvnw verify first.

@ppkarwasz ppkarwasz merged commit 8908092 into 2.x Jan 6, 2025
9 checks passed
@ppkarwasz ppkarwasz deleted the fix/2.x/dependabot branch January 6, 2025 19:31
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

Successfully merging this pull request may close these issues.

2 participants