Oh right! I missed the second half of our pom.deps file:
blacklisted org.hibernate:hibernate-ehcache:4.2.19.Final from
smx3:smx3.bill-of-materials:2.1.1;
deprecated org.hibernate:hibernate-search-engine:4.4.0.Final from
smx3:smx3.bill-of-materials:2.1.1;
resolved org.hibernate:hibernate-search-orm:4.4.0.Final from
smx3:smx3.bill-of-materials:2.1.1;
locked org.hibernate:hibernate-validator:4.3.1.Final from
smx3:smx3.upstream.bill-of-materials:1.0.16;
I provide 4 types of resolution, deprecated/blacklisted means the build
will fail, unless you specifically opt-in to deprecated/blacklisted
dependencies.
On resolve, anything that's changed moves from `locked` to either
resolved/deprecated/blacklisted, and on release anything resolved goes
to locked.
In the end user projects, we "import" the bill of materials .deps
artifact which pulls in any locked version, but I also have support for
adding:
allow unlocked /^.*someregex.*$/;
which will trigger a re-resolve, which we use for our own internal
artifacts, so we pick up the latest internal releases IF we re-resolve.
The whole process seems to work well, it does cause some annoying round
trip releases or quirks now and then, but for the most part - it's
really solved a heap of issues where we've needed to back a quick
backport fix in a production environment.
Since we publish the pom.deps file for each artifact, when doing the
backports, we simply import the deps used in the distribution version
we're patching, and manually allow any updated deps that we need to fix.
Tomo Suzuki wrote:
For reproducible builds, I expected the lock file contains specific
versions, rather than ranges. Would you share the background why your tool
records the ranges?
