Hudson Required Feature

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Hudson Required Feature

Jean-Marc Taillant
Hi All,

It could be very interesting for plugins management to get list of
available/updated plugins based on User's installed Hudson version. I
had problem when hudson told me that there was an update for Build
Publisher plugin (and I downloaded it), but the Hudson Version was not
compatible with this plugin. It required the latest one (1.313). I had
to check logs to find that there was an API difference.

So the step are:
1) Get the Current Hudson version
2) Check for this version the list of available plugin
3) Display the list of plugins,

Any comments?

Jean-Marc

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hudson Required Feature

Jean-Marc Taillant
Or maybe just a new column, indicating the mininal Hudson Version to get!

Jean-Marc Taillant wrote:

> Hi All,
>
> It could be very interesting for plugins management to get list of
> available/updated plugins based on User's installed Hudson version. I
> had problem when hudson told me that there was an update for Build
> Publisher plugin (and I downloaded it), but the Hudson Version was not
> compatible with this plugin. It required the latest one (1.313). I had
> to check logs to find that there was an API difference.
>
> So the step are:
> 1) Get the Current Hudson version
> 2) Check for this version the list of available plugin
> 3) Display the list of plugins,
>
> Any comments?
>
> Jean-Marc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hudson Required Feature

Andrew Bayer
We probably need a better way of defining what Hudson version a plugin needs to run - as of now, the Hudson core version is updated for each plugin when a new release of Hudson core comes out, so there's no systematic way to know if plugin X actually depends on changes in Hudson core 1.xxx, or if it just happened to be built against that version of Hudson.

A.

On Wed, Jul 1, 2009 at 8:03 AM, Jean-Marc Taillant <[hidden email]> wrote:
Or maybe just a new column, indicating the mininal Hudson Version to get!


Jean-Marc Taillant wrote:
Hi All,

It could be very interesting for plugins management to get list of available/updated plugins based on User's installed Hudson version. I had problem when hudson told me that there was an update for Build Publisher plugin (and I downloaded it), but the Hudson Version was not compatible with this plugin. It required the latest one (1.313). I had to check logs to find that there was an API difference.

So the step are:
1) Get the Current Hudson version
2) Check for this version the list of available plugin
3) Display the list of plugins,

Any comments?

Jean-Marc

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

RE: Re: Hudson Required Feature

justinedelson
This shouldn't be too complicated. Just need to define a maven property like hudson.version and then change the parent plugin pom to use this property for inclusion of dependencies. The parent should set this property to the current version (i.e. ${project.version}) for backwards compatibility reasons.
 
This property could also be used to generate some metadata used by Hudson to filter compatible plugins.
 
Justin


From: Andrew Bayer [mailto:[hidden email]]
Sent: Wednesday, July 01, 2009 11:17 AM
To: [hidden email]
Subject: Re: Hudson Required Feature

We probably need a better way of defining what Hudson version a plugin needs to run - as of now, the Hudson core version is updated for each plugin when a new release of Hudson core comes out, so there's no systematic way to know if plugin X actually depends on changes in Hudson core 1.xxx, or if it just happened to be built against that version of Hudson.

A.

On Wed, Jul 1, 2009 at 8:03 AM, Jean-Marc Taillant <[hidden email]> wrote:
Or maybe just a new column, indicating the mininal Hudson Version to get!


Jean-Marc Taillant wrote:
Hi All,

It could be very interesting for plugins management to get list of available/updated plugins based on User's installed Hudson version. I had problem when hudson told me that there was an update for Build Publisher plugin (and I downloaded it), but the Hudson Version was not compatible with this plugin. It required the latest one (1.313). I had to check logs to find that there was an API difference.

So the step are:
1) Get the Current Hudson version
2) Check for this version the list of available plugin
3) Display the list of plugins,

Any comments?

Jean-Marc

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Re: Hudson Required Feature

stephenconnolly
The problem with this is that it will seriously break builds for anyone building from source.

At present, by forcing all plugins to sync on a hudson version, running mvn clean install from /trunk/hudson will:

build hudson version 1.(N+1)-SNAPSHOT
download hudson version 1.N

if we switch plugins to be built against previous versions, then a full build may have to download M versions of hudson (where M is the number of plugins).

In reality, AFAIK there are three possible solutions:

1. stop the current practice of having plugins/pom.xml in SCM with a non-SNAPSHOT version.

2. use ranges

3. take plugins out of the build

none are optimal, but any will provide a faster local clean full build, at the expense of making those builds less predictable.

with #1, when running a release, you will have to provide the non-SNAPSHOT parent version prior to running the release, and then restore it afterwards.  Also, unless you pull your local pom back to a hudson release, the version of hudson you are developing against is bleeding edge.

the versions-maven-plugin can help here, e.g.

cd trunk/hudson/hudson/plugins/myplugin
mvn versions:update-parent
# this will have updated the parent version to the latest release
mvn versions:commit
# this will remove the vesionsBackup file

# do my development

svn ci -m "prepare for release"
mvn release:prepare release:perform -B
# this will have done the release
mvn versions:child-modules -N -f ../pom.xml
# this will have updated the parent version to the latest -SNAPSHOT version
# I can add a goal to versions to make this a tad easier
mvn versions:commit
# keep changes to our pom
mvn versions:revert -f ../pom.xml
# roll back changes to any other plugin poms
svn ci -m "returning to developement"

With #2, we have a very unpredictable build and depend on the maven metadata being correct... but we can exactly define what versions of hudson each plugin works with, e.g.

 <version>[1.309,2-!)</version>

when doing a local full clean build from head, this should use the 1.(N+1)-SNAPSHOT versions that is built as part of the build... however I've said should... it could be any version in that range.... but the good news is that we could then indicate the minimum version required in the update centre

With #3, we no longer have a complete full build.

There are other solutions, but I see these as being essentially variations on each of these 3 in conjunction with variations on the current scheme.

Note the current scheme is not the recommended way to use maven (i.e. plugins/pom.xml should be in SCM with a -SNAPSHOT version) The reason for this is to do with the fact that hudson is not deployed to central.....

Kohsuke is by now getting rather familiar with my moans w.r.t. sun artifacts not being in central...

-Stephen

2009/7/1 Edelson, Justin <[hidden email]>:
> This shouldn't be too complicated. Just need to define a maven property like
> hudson.version and then change the parent plugin pom to use this property
> for inclusion of dependencies. The parent should set this property to the
> current version (i.e. ${project.version}) for backwards compatibility
> reasons.
>  
> This property could also be used to generate some metadata used by Hudson to
> filter compatible plugins.
>  
> Justin
> ________________________________
> From: Andrew Bayer [mailto:[hidden email]]
> Sent: Wednesday, July 01, 2009 11:17 AM
> To: [hidden email]
> Subject: Re: Hudson Required Feature
>
> We probably need a better way of defining what Hudson version a plugin needs
> to run - as of now, the Hudson core version is updated for each plugin when
> a new release of Hudson core comes out, so there's no systematic way to know
> if plugin X actually depends on changes in Hudson core 1.xxx, or if it just
> happened to be built against that version of Hudson.
>
> A.
>
> On Wed, Jul 1, 2009 at 8:03 AM, Jean-Marc Taillant
> <[hidden email]> wrote:
>>
>> Or maybe just a new column, indicating the mininal Hudson Version to get!
>>
>> Jean-Marc Taillant wrote:
>>>
>>> Hi All,
>>>
>>> It could be very interesting for plugins management to get list of
>>> available/updated plugins based on User's installed Hudson version. I had
>>> problem when hudson told me that there was an update for Build Publisher
>>> plugin (and I downloaded it), but the Hudson Version was not compatible with
>>> this plugin. It required the latest one (1.313). I had to check logs to find
>>> that there was an API difference.
>>>
>>> So the step are:
>>> 1) Get the Current Hudson version
>>> 2) Check for this version the list of available plugin
>>> 3) Display the list of plugins,
>>>
>>> Any comments?
>>>
>>> Jean-Marc
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>