Ensure that actual dependencies are compared rather than listed
Spotted by Andreas Shildbach:
At present if dependencies are changed without a fresh snapshot being taken then the enforcer rules will only be applied against the whitelist.
The enforcer needs to be stricter to avoid a false sense of security
Could you please fix this?
I've added it to my list. I should visit it in the next week or so.
OK, done a first draft on the develop branch. Apologies for the extreme delay on this.
Can I ask @ST-DDT to take a look at this and verify that it does detect a stale/incorrect URN whitelist by modifying the values in the rule-tester module pom.xml.
Testresults for commit 9e073e4ff86f1578904506ee9b9b252a5bce3708:
- [x] Build success
- [ ] Missing dependencies - Build failure => not fixed
- [ ] Missing plugin - Build failure => not fixed
- [x] Wrong dependency version - Build failure
- [x] Wrong plugin version - Build failure
- [x] Wrong dependency hash - Build failure
- [x] Wrong plugin hash - Build failure
- [x] Wrong dependency scope - Info/Warning shown
- [x] Wrong plugin scope - Info/Warning shown
- [x] Detect dependencies
- [x] Detect transitive dependencies
- [x] Detect plugins
- [ ] Detect additional dependencies for plugins (ex: this plugin itself)
This is a great test report :-)
I'll do some more commits to cover the missing items.
Missing dependencies - Build failure => not fixed
This is confusing. Commenting out the Bouncy Castle test dependency from the rule-tester module and rebuilding leads to a failure due to missing dependency. Removing the antlr dependency either causes a correct download, or if sneakily removed just before SHA1 testing, results in a build failure due to an exception.
@ST-DDT could you clarify this situation?
Wrong dependency/plugin scope is now covered.
Exploring the Maven tree to locate the enforcer/digest rules is proving unreliable and possibly unnecessarily complex. I'm going to leave this out from this version.
@ST-DDT could you clarify this situation?
Well I just build/installed your plugin and added it in one of my test projects and tested those cases.
Maybe I can write a JUnit like test for this.
Wrong dependency/plugin scope is now covered.
Nice
Exploring the Maven tree to locate the enforcer/digest rules is proving unreliable and possibly unnecessarily complex. I'm going to leave this out from this version.
Okay. I will have a look at this too. Maybe I can find a solution for this. But not today.