Maven parent POM: Circular dependencies

Question 1

Suggestion

For simplify dependency configuration use versions ranges.

For example artifact A needs artifact B with version 0.1.0. Configure dependency as range <version>[0.1.0, 0.2.0)</version>.

This mean that A requires B with version greater or equal than 0.1.0 and less than 0.2.0 (so all hotfixes are good for this artifact).

This helps, because when hotfix is released, there is no need to change artifact A dependencies. Just rebuild parent project and hotfixed B will be attached to project A

This technique requires releasing parent project when hotfix is released By parent project I mean somethink like WAR with libraries or EAR, or Distribution Archive with all artifacts inside.

More: 3.4.3. Dependency Version Ranges

Question 2

A major source of confusion in Maven is the fact that parent pom can actually encompasses 2 distinct types of relationships:

parent-child relationship:
- declared once per child inside its <parent> tag
- inherit plugins, dependencies, properties, versions, etc declared inside pom.xml
aggregator-submodule relationship:
- declared once at top-level pom via <modules> tag
- goals passed in via cmd line (eg mvn clean install) are passed along to submodules

This distinction is irrelevant if all modules remain on the same version (ie always perform releases from top-level). But as soon as the versions start to fragment (ie release one submodule but not the other) then it becomes necessary to create 2 separate poms for each task.

project/
  parent/
    parent_pom.xml      # declare dependency versions as ranges [0.1.0, 0.2.0)
  children/
    aggregator_pom.xml  # <modules> section lists api/dao/etc
    api/
      pom.xml           # declare parent_pom as parent
    dao/
      pom.xml           # declare parent_pom as parent

Why is this complex structure needed?

Why not just go with MariuszS suggestion of using ranges at top level parent?

Imagine one of the basic components, say the api, is extremely stable. You don't want to rebuild or re-release it if it's avoidable.

Meanwhile, let's say 2 other components that depend on each other like pdf-exporter and docs which you release and/or branch quite often so that you frequently change version ranges: 0.1.x -> 0.2.x -> 0.3.x etc.

Then you would would be forced to modify and release your parent pom to reflect the relationship between pdf-exporter and docs quite often, but you wouldn't necessarily want to release api since it doesn't care about these changes. Hence the need to put parent to the side and ensure releasing it doesn't trigger an unnecessary re-release of api submodule.

Question 3

If there is a common root module (the “parent”) that all the other modules (the “children”) depend on, none of the children should be depended upon by the parent.

This is because Maven works in quite a simple way: to build a module, you first build all of the modules on which it depends (using a transitive closure model) that are not already built. If you've got a circular dependency, you end up in the situation where in order to build A, you've got to first have A built. That's crazy and obviously won't work in a useful way.

However, you can also have a parent have its children be sub-modules. That's a different, non-inheritable relationship, and it causes the sub-modules to be built after the super-module. That works. It's also entirely reasonable to make the sub-modules of a super-module have no other relationship on the super-module than that simple containment.

In short, whatever way you're arranging the modules on disk and in your repository, do not introduce circular dependencies. (I've seen it argued that circular dependencies should logically turn a group of modules into a single module due to that being the only way to sanely define the operation of the proper-containment operator. I'm not sure I quite agree with that, but it is not entirely wrong…)