it only fires when the dist project is run as part of the top level project . Running it on it own is silent
It is not true, the top level project doesn’t contribute compile dependencies, rather these seem to come from the modules.
It doesn’t stop the build but it is bogus and I dislike that, But even more do I dislike the whole mess that is the pom parsing. 10 out of 10 for effort but minus several hundred points for supportability. (I gave up chasing the above after an hour based on the “life is too short” premise). Just because you can do something doesn’t mean you should,
The value the enforcer brings to our lives is signature checking, not dependency checking and I would like us to have a conversation about removing all the dependency checking.
When the Enforcer was originally conceived it was to stop some avoidable situations, like distributions going out with the “wrong” contents,
The whole thing is horribly complex, with recursive constructors and the like and all it is is a guestimate at what we think maven might do,
While I was prepping the java-scripting plugin of The java 17 release I spotted a warning
[ERROR Project parent contributes compile dependenciesduring the rhino and nashorn dist check.
The oddities being that
it only fires when the dist project is run as part of the top level project . Running it on it own is silent
It is not true, the top level project doesn’t contribute compile dependencies, rather these seem to come from the modules.
It doesn’t stop the build but it is bogus and I dislike that, But even more do I dislike the whole mess that is the pom parsing. 10 out of 10 for effort but minus several hundred points for supportability. (I gave up chasing the above after an hour based on the “life is too short” premise). Just because you can do something doesn’t mean you should,
The value the enforcer brings to our lives is signature checking, not dependency checking and I would like us to have a conversation about removing all the dependency checking.
After the J17 stack is out