From discussion with Kohsuke:
[19:00:13] <drulli> kohsuke: can I change the scope @requiresDependencyResolution in the HPI mojo from 'runtime' to 'test'? Otherwise the dependency to Hudson core is not correctly resolved? See
JENKINS-8509:Hudson does not warn when a plug-in is build for a more recent version of Hudson (then the installed one) (Reopened) http://hudson-labs.org/issue/8509
[19:01:14] <kohsuke> This sounds more like a bug in the hpi mojo
[19:01:19] *** awb has joined #hudson
[19:01:26] <kohsuke> How does changing the scope to test fix it?
[19:01:53] <drulli> When scope is test the 'provided' dependencies are added. In runtime not.
[19:02:22] <drulli> And hudson-core is a provided dependency in many plug-ins.
[19:02:37] <kohsuke> Does that mean we never correctly calculated the value?
[19:03:30] <drulli> I didn't check, but this should work only if the dependency does not use provided, see http://maven.apache.org/developers/mojo-api-specification.html
[19:03:51] <kohsuke> If we set it to test, we now need to make sure test scope dependencies don't show up as dependencies
[19:03:52] <drulli> At least for my plug-ins it does not work.
[19:04:50] <drulli> I see. This will require some extra work. I'll have a look at it.
[19:05:56] <kohsuke> Maybe we are better off resolving dependencies on our own.
[19:06:26] <kohsuke> I had a very similar situation back in GlassFish, and in the end I felt more comfortable doing that
[19:06:53] <kohsuke> Build the dependency graph, and cut the edges with the criteria of my choice, instead of one of four pre-built choices.
[19:07:21] <kohsuke> The code is at http://java.net/projects/maven-antrun-extended-plugin
[19:08:17] <drulli> Ok, I'll have a look at it...
[19:10:36] <kohsuke> (for example when your plugin depends on another plugin in a compile dependency, and when that in turn depends on a version of Hudson core, you want to make sure that's ignored)