Ensure that actual dependencies are compared rather than listed

[gary-rowe]

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

[ST-DDT]

Could you please fix this?

[gary-rowe]

I've added it to my list. I should visit it in the next week or so.

[gary-rowe]

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.

[ST-DDT]

Testresults for commit 9e073e4:

• Build success
• Missing dependencies - Build failure => not fixed
• Missing plugin - Build failure => not fixed
• Wrong dependency version - Build failure
• Wrong plugin version - Build failure
• Wrong dependency hash - Build failure
• Wrong plugin hash - Build failure
• Wrong dependency scope - Info/Warning shown
• Wrong plugin scope - Info/Warning shown
• Detect dependencies
• Detect transitive dependencies
• Detect plugins
• Detect additional dependencies for plugins (ex: this plugin itself)

[gary-rowe]

This is a great test report :-)

I'll do some more commits to cover the missing items.

[gary-rowe]

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?

[gary-rowe]

Wrong dependency/plugin scope is now covered.

[gary-rowe]

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]

@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.