Because the parent POM is shared by so many projects, it is common for it to be left alone when patch releases of some but not all our projects have to be issued. This is also because when multiple versions of the parent POM are referenced by different projects in a build, Maven can’t rely on a single version of the parent when it computes the dependency tree, causing mismatches and even producing the wrong results. As an example if we need to issue an IdP patch and update a third party dependency, changing the parent will not work reliably because opensaml, spring-extensions, and java-support may still reference the older parent.
As a rule, the parent tends to be left alone through the lifecycle of a minor version of a product and so cannot be the method by which a third party dependency version is updated. This has implications because of how Maven parses and handles properties. Overriding a property macro referring to the version of a third party dependency does not cause Maven to retrospectively update its definition of the managed dependency in the parent POM, and so in turn will not cause the right updated version to appear in a distribution.
Instead, though unfortunate, the procedure below needs to be followed when a component needs to be updated in between parent POM releases.
The managed dependency declarations for the third party component must be duplicated in the project’s own POM (or parent POM, in the case of a multi-module project like the IdP or OpenSAML). We have also found that the use of BOMs doesn’t work properly when multiple versions of a BOM are in the overall dependency tree, and so the entire contents of a BOM used as a managed dependency in the “root” parent POM have to be expanded into the updated projects’s POM or parent POM. (This is perhaps a bug in Maven and might be something to monitor and check periodically for a fix.)
As an example, consider a self-contained component such as Guava. To “patch” the version of Guava so that an IdP patch will include the updated version, idp-parent/pom.xml must be updated:
<!-- Note the change for posterity with a TODO to remove when the parent POM is updated. -->
<version>(updated Guava version)</version>
If the original managed dependency contained exclusions, these must be copied from the parent POM to fully duplicate the original dependency.
In the case of a more complex dependency like Spring, the process is the same, but because the original dependency is based on the BOM, the set of duplicated dependencies is very long since the entire list of potential Spring dependencies has to be spelled out.