Description

There is no warning for this plugin in the update center that this plugin requires a newer Hudson version than at least 1.362 which we are using!

I updated the plugin from 1.14 to 1.15 version and after that our metrics job failed to finish, the graphs of the metrics job were lost, configuration page of any job in Hudson failed to load completely and it wasn't possible to trigger some jobs - so the warning about update should always be there if there is a need for it!

Ulli Hafner
added a comment - 2011-01-14 06:40 Attached a screenshot showing a Hudson 1.392 instance.
Hudson reports that some plug-ins require Hudson 1.393. However, the latest version of the static analysis plug-ins are also build against Hudson 1.393. There is no such warning for these plugins.

[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.[19:00:14] <hudson-admin> 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)

Ulli Hafner
added a comment - 2011-01-25 10:30 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 .
[19:00:14] <hudson-admin> 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)