Home/ Questions/Q 9280397
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-18T17:51:42+00:00

We have a multi-module POM, which also serves as a parent POM for all

  • 0

We have a multi-module POM, which also serves as a parent POM for all sub-modules involved. Call it MultiModulePOM. We have about 70 modules, say numbered Module1 to Module70.

Now: The first 30 of these modules require a set of JAR files at compile-time only. That is – scope=provided. Since we’re talking about a set of JAR files, it is quite tedious to keep those 30 modules in sync and in general, I am not a huge fan of copying definitions around.

So, I fell into the pitfall of dependency grouping. Seemed like a good idea, however it doesn’t work for provided dependencies. In other words: if I group the dependent JARs in a module called ExtDependencies, and make Module1 depend on ExtDependencies, the JARs referred-to by ExtDependencies won’t be transitively-added to Module1, because their scope is provided.

(If the last paragraph is not true, please let me know as it could really get me out of a jam)

The only other option that I could see was to create a parent POM called (for example) IntermediaryPOM. IntermediaryPOM extends MultiModulePOM and enlists the set of dependent JAR files with scope=provided. Modules Module1–Module30 then extend IntermediaryPOM.

That seemed to do the trick but I have three problems with it:

  1. It adds another layer of POM that I’m not sure is really needed.
  2. Later, during distribution time, I find myself having to install/deploy the intermediary POM’s as well.
  3. Consider the general case: the intermediary POM may have other siblings used for other sets of JARs (for modules 31-50). Therefore, this solution doesn’t seem to scale well.

So my question is – according to your experience, what is the best way to approach this? any known best practices for such a use case?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’m afraid there is no easy solution here.

    You’re right saying that if you declare common dependencies in ExtDependencies as provided they won’t be added to the classpath of any other module that is dependent on ExtDependencies. That’s how provided works.

    But you could declare these common dependencies without scope (e.g. with default compile scope) and add provided dependency on ExtDependencies. In this case all of the ExtDependencies dependencies will be added to classpath. God, that’s a lot of “dependencies” 🙂

    You’ve also mentioned other possible option — introduce another level of abstraction (which, as you might know, is a way to solve almost any problem). But such multi-level hierarchy is less elegant and more difficult to maintain (I have it in our projects, so I’ve been there).

    In general, I haven’t come across this problem in such a scale but if I were to solve it I’d go with the first option taking into account scoping suggestion.

    • 0