Update center

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

Update center

Erik Ramfelt
Hi Kohsuke

Excellent work with the update center, it makes the plugin handling so
much easier.

Whats in the road map for it? I have a few suggestions:
* A group mode similar to the one in the Plugin wiki page, group
plugins according to type (SCM, builders, etc). It would also be nice
to be able to group the plugins by platform (.NET, Java, etc)

* Is there any dependency solving implemented? ie, can we create
library plugins that are downloaded automatically? (Should there be a
difference between library plugins and normal plugins?)

* Somehow show the optional/mandatory plugin dependencies for a plugin.

* Popularity listing, showing how many installations for each plugin.
May need an accept from the administrator and webservice to publish
stats to.

* Send an email when Hudson has found a new version of a plugin to the
administrator. Uses the email admin address.


BTW how is the update-center.json file updated? The ci-game is missing
the wiki link and the tasks plugins is titled Rake, which I could fix
but Im not sure how the file is generated.


Cheers
//Erik

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

Reply | Threaded
Open this post in threaded view
|

Re: Update center

Kohsuke Kawaguchi
Administrator
Erik Ramfelt wrote:
> Hi Kohsuke
>
> Excellent work with the update center, it makes the plugin handling so
> much easier.
>
> Whats in the road map for it? I have a few suggestions:
> * A group mode similar to the one in the Plugin wiki page, group
> plugins according to type (SCM, builders, etc). It would also be nice
> to be able to group the plugins by platform (.NET, Java, etc)

Yes. I should be able to read information from Wiki to do this. I also
wanted to capture excerpt from Wiki.

> * Is there any dependency solving implemented? ie, can we create
> library plugins that are downloaded automatically? (Should there be a
> difference between library plugins and normal plugins?)

Yes, this is in the plan, too. We also need to check the Hudson core
version that a plugin requires.

> * Somehow show the optional/mandatory plugin dependencies for a plugin.

I think the debian package approach is useful --- a plugin could
nominate "recommended" plugins, and the user would be prompted to
install them, too.


> * Popularity listing, showing how many installations for each plugin.
> May need an accept from the administrator and webservice to publish
> stats to.

Actually, all the downloads come from the java.net server, so we
actually have full stats access.

Looking at IntelliJ, it doesn't ask for any opt-in permissions for
obtaining download stats, so I'm thinking doing this doesn't require the
user to opt-in.


> * Send an email when Hudson has found a new version of a plugin to the
> administrator. Uses the email admin address.

Ah, good suggestion.


> BTW how is the update-center.json file updated? The ci-game is missing
> the wiki link and the tasks plugins is titled Rake, which I could fix
> but Im not sure how the file is generated.

A program tries to infer the Wiki page for a plugin by the following means:

   1. if POM has <url> that points to Wiki, that would be used. This is
      the recommended way.
   2. Similarity between the page name and the plugin artifact Id is
      considered and the best match is chosen if it's really close.
      This is how many plugins get their Wiki pages today.

ci-game plugin failed 1. above and 2. didn't match because the name was
too different.

And I need to set up a continuous execution of this tool.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update center

Erik Ramfelt
On Tue, Jun 10, 2008 at 6:22 PM, Kohsuke Kawaguchi
<[hidden email]> wrote:

> Erik Ramfelt wrote:
>>
>> Hi Kohsuke
>>
>> Excellent work with the update center, it makes the plugin handling so
>> much easier.
>>
>> Whats in the road map for it? I have a few suggestions:
>> * A group mode similar to the one in the Plugin wiki page, group
>> plugins according to type (SCM, builders, etc). It would also be nice
>> to be able to group the plugins by platform (.NET, Java, etc)
>
> Yes. I should be able to read information from Wiki to do this. I also
> wanted to capture excerpt from Wiki.

That would solve it. https://hudson.dev.java.net/issues/show_bug.cgi?id=1836
Perhaps there is a need for a "Update center" component in the issue tracker.

>> * Is there any dependency solving implemented? ie, can we create
>> library plugins that are downloaded automatically? (Should there be a
>> difference between library plugins and normal plugins?)
>
> Yes, this is in the plan, too. We also need to check the Hudson core version
> that a plugin requires.

Does this mean that the plugins in trunk will no longer be
automatically updated with dependency to the latest hudson.war?
Because most of the times, the plugins do not require the latest
version of Hudson at the time the plugin was released.


>> * Somehow show the optional/mandatory plugin dependencies for a plugin.
>
> I think the debian package approach is useful --- a plugin could nominate
> "recommended" plugins, and the user would be prompted to install them, too.

Sounds good, but how about mandatory plugins? ie, im thinking of a
library plugin that contains the logic for parsing incoming IM
messages to start/query builds (ie copy logic from existing IM
plugins). To add a new IM protocol, then I would only have to handle
the connection parts, as the library plugin would handle the message
parsing.


>> * Popularity listing, showing how many installations for each plugin.
>> May need an accept from the administrator and webservice to publish
>> stats to.
>
> Actually, all the downloads come from the java.net server, so we actually
> have full stats access.

But that is only counting the number of downloads? Im interested in
what plugins people actually use and not only downloaded. A plugin can
be downloaded many times, but uninstalled because it doesnt work.


> Looking at IntelliJ, it doesn't ask for any opt-in permissions for obtaining
> download stats, so I'm thinking doing this doesn't require the user to
> opt-in.

Ok, that works for me. The reason I asked is that debian popularity
package is not default installed.


>> * Send an email when Hudson has found a new version of a plugin to the
>> administrator. Uses the email admin address.
>
> Ah, good suggestion.

Ok, https://hudson.dev.java.net/issues/show_bug.cgi?id=1834


>> BTW how is the update-center.json file updated? The ci-game is missing
>> the wiki link and the tasks plugins is titled Rake, which I could fix
>> but Im not sure how the file is generated.
>
> A program tries to infer the Wiki page for a plugin by the following means:
>
>  1. if POM has <url> that points to Wiki, that would be used. This is
>     the recommended way.
>  2. Similarity between the page name and the plugin artifact Id is
>     considered and the best match is chosen if it's really close.
>     This is how many plugins get their Wiki pages today.
>
> ci-game plugin failed 1. above and 2. didn't match because the name was too
> different.

Strange because the ci-game plugin pom has the <url>
(http://shorl.com/jurijygidrybry).

> And I need to set up a continuous execution of this tool.

If only we had a CI tool ;)


//Erik

>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

RE: Update center

Adam Purkiss
In reply to this post by Kohsuke Kawaguchi
Just a quick request but could the available tab have the installed plugins highlighted somehow so you dont need to flick between available and installed to see what is installed.
 
Otherwise it is good.
 
Oh and could reload config from disk also reload plugins?






> Date: Tue, 10 Jun 2008 09:22:53 -0700

> From: [hidden email]
> To: [hidden email]
> Subject: Re: Update center
>
> Erik Ramfelt wrote:
> > Hi Kohsuke
> >
> > Excellent work with the update center, it makes the plugin handling so
> > much easier.
> >
> > Whats in the road map for it? I have a few suggestions:
> > * A group mode similar to the one in the Plugin wiki page, group
> > plugins according to type (SCM, builders, etc). It would also be nice
> > to be able to group the plugins by platform (.NET, Java, etc)
>
> Yes. I should be able to read information from Wiki to do this. I also
> wanted to capture excerpt from Wiki.
>
> > * Is there any dependency solving implemented? ie, can we create
> > library plugins that are downloaded automatically? (Should there be a
> > difference between library plugins and normal plugins?)
>
> Yes, this is in the plan, too. We also need to check the Hudson core
> version that a plugin requires.
>
> > * Somehow show the optional/mandatory plugin dependencies for a plugin.
>
> I think the debian package approach is useful --- a plugin could
> nominate "recommended" plugins, and the user would be prompted to
> install them, too.
>
>
> > * Popularity listing, showing how many installations for each plugin.
> > May need an accept from the administrator and webservice to publish
> > stats to.
>
> Actually, all the downloads come from the java.net server, so we
> actually have full stats access.
>
> Looking at IntelliJ, it doesn't ask for any opt-in permissions for
> obtaining download stats, so I'm thinking doing this doesn't require the
> user to opt-in.
>
>
> > * Send an email when Hudson has found a new version of a plugin to the
> > administrator. Uses the email admin address.
>
> Ah, good suggestion.
>
>
> > BTW how is the update-center.json file updated? The ci-game is missing
> > the wiki link and the tasks plugins is titled Rake, which I could fix
> > but Im not sure how the file is generated.
>
> A program tries to infer the Wiki page for a plugin by the following means:
>
> 1. if POM has <url> that points to Wiki, that would be used. This is
> the recommended way.
> 2. Similarity between the page name and the plugin artifact Id is
> considered and the best match is chosen if it's really close.
> This is how many plugins get their Wiki pages today.
>
> ci-game plugin failed 1. above and 2. didn't match because the name was
> too different.
>
> And I need to set up a continuous execution of this tool.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems [hidden email]



Reply | Threaded
Open this post in threaded view
|

RE: RE: Update center

mezlight
I think I prefer not to show the install plugins @ all in the available tab (netbeans way)


From: Adam Purkiss [mailto:[hidden email]]
Sent: Tuesday, June 10, 2008 1:10 PM
To: [hidden email]
Subject: RE: Update center

Just a quick request but could the available tab have the installed plugins highlighted somehow so you dont need to flick between available and installed to see what is installed.
 
Otherwise it is good.
 
Oh and could reload config from disk also reload plugins?






> Date: Tue, 10 Jun 2008 09:22:53 -0700
> From: [hidden email]
> To: [hidden email]
> Subject: Re: Update center
>
> Erik Ramfelt wrote:
> > Hi Kohsuke
> >
> > Excellent work with the update center, it makes the plugin handling so
> > much easier.
> >
> > Whats in the road map for it? I have a few suggestions:
> > * A group mode similar to the one in the Plugin wiki page, group
> > plugins according to type (SCM, builders, etc). It would also be nice
> > to be able to group the plugins by platform (.NET, Java, etc)
>
> Yes. I should be able to read information from Wiki to do this. I also
> wanted to capture excerpt from Wiki.
>
> > * Is there any dependency solving implemented? ie, can we create
> > library plugins that are downloaded automatically? (Should there be a
> > difference between library plugins and normal plugins?)
>
> Yes, this is in the plan, too. We also need to check the Hudson core
> version that a plugin requires.
>
> > * Somehow show the optional/mandatory plugin dependencies for a plugin.
>
> I think the debian package approach is useful --- a plugin could
> nominate "recommended" plugins, and the user would be prompted to
> install them, too.
>
>
> > * Popularity listing, showing how many installations for each plugin.
> > May need an accept from the administrator and webservice to publish
> > stats to.
>
> Actually, all the downloads come from the java.net server, so we
> actually have full stats access.
>
> Looking at IntelliJ, it doesn't ask for any opt-in permissions for
> obtaining download stats, so I'm thinking doing this doesn't require the
> user to opt-in.
>
>
> > * Send an email when Hudson has found a new version of a plugin to the
> > administrator. Uses the email admin address.
>
> Ah, good suggestion.
>
>
> > BTW how is the update-center.json file updated? The ci-game is missing
> > the wiki link and the tasks plugins is titled Rake, which I could fix
> > but Im not sure how the file is generated.
>
> A program tries to infer the Wiki page for a plugin by the following means:
>
> 1. if POM has <url> that points to Wiki, that would be used. This is
> the recommended way.
> 2. Similarity between the page name and the plugin artifact Id is
> considered and the best match is chosen if it's really close.
> This is how many plugins get their Wiki pages today.
>
> ci-game plugin failed 1. above and 2. didn't match because the name was
> too different.
>
> And I need to set up a continuous execution of this tool.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems [hidden email]



Reply | Threaded
Open this post in threaded view
|

RE: RE: Update center

ruel loehr

+1

 


From: Messmer, Jason [mailto:[hidden email]]
Sent: Tuesday, June 10, 2008 12:40 PM
To: [hidden email]
Subject: RE: RE: Update center

 

I think I prefer not to show the install plugins @ all in the available tab (netbeans way)

 


From: Adam Purkiss [mailto:[hidden email]]
Sent: Tuesday, June 10, 2008 1:10 PM
To: [hidden email]
Subject: RE: Update center

Just a quick request but could the available tab have the installed plugins highlighted somehow so you dont need to flick between available and installed to see what is installed.
 
Otherwise it is good.
 
Oh and could reload config from disk also reload plugins?





> Date: Tue, 10 Jun 2008 09:22:53 -0700
> From: [hidden email]
> To: [hidden email]
> Subject: Re: Update center
>
> Erik Ramfelt wrote:
> > Hi Kohsuke
> >
> > Excellent work with the update center, it makes the plugin handling so
> > much easier.
> >
> > Whats in the road map for it? I have a few suggestions:
> > * A group mode similar to the one in the Plugin wiki page, group
> > plugins according to type (SCM, builders, etc). It would also be nice
> > to be able to group the plugins by platform (.NET, Java, etc)
>
> Yes. I should be able to read information from Wiki to do this. I also
> wanted to capture excerpt from Wiki.
>
> > * Is there any dependency solving implemented? ie, can we create
> > library plugins that are downloaded automatically? (Should there be a
> > difference between library plugins and normal plugins?)
>
> Yes, this is in the plan, too. We also need to check the Hudson core
> version that a plugin requires.
>
> > * Somehow show the optional/mandatory plugin dependencies for a plugin.
>
> I think the debian package approach is useful --- a plugin could
> nominate "recommended" plugins, and the user would be prompted to
> install them, too.
>
>
> > * Popularity listing, showing how many installations for each plugin.
> > May need an accept from the administrator and webservice to publish
> > stats to.
>
> Actually, all the downloads come from the java.net server, so we
> actually have full stats access.
>
> Looking at IntelliJ, it doesn't ask for any opt-in permissions for
> obtaining download stats, so I'm thinking doing this doesn't require the
> user to opt-in.
>
>
> > * Send an email when Hudson has found a new version of a plugin to the
> > administrator. Uses the email admin address.
>
> Ah, good suggestion.
>
>
> > BTW how is the update-center.json file updated? The ci-game is missing
> > the wiki link and the tasks plugins is titled Rake, which I could fix
> > but Im not sure how the file is generated.
>
> A program tries to infer the Wiki page for a plugin by the following means:
>
> 1. if POM has <url> that points to Wiki, that would be used. This is
> the recommended way.
> 2. Similarity between the page name and the plugin artifact Id is
> considered and the best match is chosen if it's really close.
> This is how many plugins get their Wiki pages today.
>
> ci-game plugin failed 1. above and 2. didn't match because the name was
> too different.
>
> And I need to set up a continuous execution of this tool.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems [hidden email]


Reply | Threaded
Open this post in threaded view
|

RE: Update center

Adam Purkiss
that works to... anyway that means I am not going to accidently go.. "oh that looks interesting" and install it when it is already installed.




From: [hidden email]
To: [hidden email]
Date: Tue, 10 Jun 2008 12:42:09 -0500
Subject: RE: RE: Update center

+1

 


From: Messmer, Jason [mailto:[hidden email]]
Sent: Tuesday, June 10, 2008 12:40 PM
To: [hidden email]
Subject: RE: RE: Update center

 

I think I prefer not to show the install plugins @ all in the available tab (netbeans way)

 


From: Adam Purkiss [mailto:[hidden email]]
Sent: Tuesday, June 10, 2008 1:10 PM
To: [hidden email]
Subject: RE: Update center

Just a quick request but could the available tab have the installed plugins highlighted somehow so you dont need to flick between available and installed to see what is installed.
 
Otherwise it is good.
 
Oh and could reload config from disk also reload plugins?





> Date: Tue, 10 Jun 2008 09:22:53 -0700
> From: [hidden email]
> To: [hidden email]
> Subject: Re: Update center
>
> Erik Ramfelt wrote:
> > Hi Kohsuke
> >
> > Excellent work with the update center, it makes the plugin handling so
> > much easier.
> >
> > Whats in the road map for it? I have a few suggestions:
> > * A group mode similar to the one in the Plugin wiki page, group
> > plugins according to type (SCM, builders, etc). It would also be nice
> > to be able to group the plugins by platform (.NET, Java, etc)
>
> Yes. I should be able to read information from Wiki to do this. I also
> wanted to capture excerpt from Wiki.
>
> > * Is there any dependency solving implemented? ie, can we create
> > library plugins that are downloaded automatically? (Should there be a
> > difference between library plugins and normal plugins?)
>
> Yes, this is in the plan, too. We also need to check the Hudson core
> version that a plugin requires.
>
> > * Somehow show the optional/mandatory plugin dependencies for a plugin.
>
> I think the debian package approach is useful --- a plugin could
> nominate "recommended" plugins, and the user would be prompted to
> install them, too.
>
>
> > * Popularity listing, showing how many installations for each plugin.
> > May need an accept from the administrator and webservice to publish
> > stats to.
>
> Actually, all the downloads come from the java.net server, so we
> actually have full stats access.
>
> Looking at IntelliJ, it doesn't ask for any opt-in permissions for
> obtaining download stats, so I'm thinking doing this doesn't require the
> user to opt-in.
>
>
> > * Send an email when Hudson has found a new version of a plugin to the
> > administrator. Uses the email admin address.
>
> Ah, good suggestion.
>
>
> > BTW how is the update-center.json file updated? The ci-game is missing
> > the wiki link and the tasks plugins is titled Rake, which I could fix
> > but Im not sure how the file is generated.
>
> A program tries to infer the Wiki page for a plugin by the following means:
>
> 1. if POM has <url> that points to Wiki, that would be used. This is
> the recommended way.
> 2. Similarity between the page name and the plugin artifact Id is
> considered and the best match is chosen if it's really close.
> This is how many plugins get their Wiki pages today.
>
> ci-game plugin failed 1. above and 2. didn't match because the name was
> too different.
>
> And I need to set up a continuous execution of this tool.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: Update center

Kohsuke Kawaguchi
Administrator
In reply to this post by mezlight
Messmer, Jason wrote:
> I think I prefer not to show the install plugins @ all in the available
> tab (netbeans way)

That seems like a reasonable thing to do.

I stole the whole UI design from NetBeans anyway.

>
> ________________________________
>
> From: Adam Purkiss [mailto:[hidden email]]
> Sent: Tuesday, June 10, 2008 1:10 PM
> To: [hidden email]
> Subject: RE: Update center
>
>
> Just a quick request but could the available tab have the installed
> plugins highlighted somehow so you dont need to flick between available
> and installed to see what is installed.
>  
> Otherwise it is good.
>  
> Oh and could reload config from disk also reload plugins?

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update center

Kohsuke Kawaguchi
Administrator
In reply to this post by Adam Purkiss
Adam Purkiss wrote:
> Oh and could reload config from disk also reload plugins?

Actually, it doesn't. This is bit tricky to do for various reasons.

I really need to figure out how to restart a webapp from within a
webapp. This would be also necessary to provide the in-place update
capability of Hudson itself.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Update center

Adam Purkiss
whats the bet this is different for every single container.......




> Date: Tue, 10 Jun 2008 10:59:03 -0700

> From: [hidden email]
> To: [hidden email]
> Subject: Re: Update center
>
> Adam Purkiss wrote:
> > Oh and could reload config from disk also reload plugins?
>
> Actually, it doesn't. This is bit tricky to do for various reasons.
>
> I really need to figure out how to restart a webapp from within a
> webapp. This would be also necessary to provide the in-place update
> capability of Hudson itself.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems [hidden email]


Reply | Threaded
Open this post in threaded view
|

RE: Update center

ruel loehr

A winning one.  Prabhat might be able to weigh in on to do it for jboss.

 


From: Adam Purkiss [mailto:[hidden email]]
Sent: Tuesday, June 10, 2008 1:00 PM
To: [hidden email]
Subject: RE: Update center

 

whats the bet this is different for every single container.......



> Date: Tue, 10 Jun 2008 10:59:03 -0700
> From: [hidden email]
> To: [hidden email]
> Subject: Re: Update center
>
> Adam Purkiss wrote:
> > Oh and could reload config from disk also reload plugins?
>
> Actually, it doesn't. This is bit tricky to do for various reasons.
>
> I really need to figure out how to restart a webapp from within a
> webapp. This would be also necessary to provide the in-place update
> capability of Hudson itself.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Update center

Kohsuke Kawaguchi
Administrator
In reply to this post by Erik Ramfelt
Erik Ramfelt wrote:

> On Tue, Jun 10, 2008 at 6:22 PM, Kohsuke Kawaguchi
> <[hidden email]> wrote:
>> Erik Ramfelt wrote:
>>>
>>> Hi Kohsuke
>>>
>>> Excellent work with the update center, it makes the plugin handling so
>>> much easier.
>>>
>>> Whats in the road map for it? I have a few suggestions:
>>> * A group mode similar to the one in the Plugin wiki page, group
>>> plugins according to type (SCM, builders, etc). It would also be nice
>>> to be able to group the plugins by platform (.NET, Java, etc)
>>
>> Yes. I should be able to read information from Wiki to do this. I also
>> wanted to capture excerpt from Wiki.
>
> That would solve it. https://hudson.dev.java.net/issues/show_bug.cgi?id=1836
> Perhaps there is a need for a "Update center" component in the issue tracker.
Thanks for filing an issue.


>>> * Is there any dependency solving implemented? ie, can we create
>>> library plugins that are downloaded automatically? (Should there be a
>>> difference between library plugins and normal plugins?)
>>
>> Yes, this is in the plan, too. We also need to check the Hudson core version
>> that a plugin requires.
>
> Does this mean that the plugins in trunk will no longer be
> automatically updated with dependency to the latest hudson.war?
> Because most of the times, the plugins do not require the latest
> version of Hudson at the time the plugin was released.
Yeah, I'm not sure what the best versioning strategy would be.

The current structure of keeping the Hudson version number in
plugins/pom.xml helped keep plugins/*/pom.xml simple, but OTOH it has
the problem of what you describe.

Should we encourage each plugin to list <dependency> to hudson core and
war explicitly?


>>> * Somehow show the optional/mandatory plugin dependencies for a plugin.
>>
>> I think the debian package approach is useful --- a plugin could nominate
>> "recommended" plugins, and the user would be prompted to install them, too.
>
> Sounds good, but how about mandatory plugins? ie, im thinking of a
> library plugin that contains the logic for parsing incoming IM
> messages to start/query builds (ie copy logic from existing IM
> plugins). To add a new IM protocol, then I would only have to handle
> the connection parts, as the library plugin would handle the message
> parsing.
Right, I should be able to handle those accordingly, as well. Indeed the
library plugin was one of the motivations for the update center work.


>>> * Popularity listing, showing how many installations for each plugin.
>>> May need an accept from the administrator and webservice to publish
>>> stats to.
>>
>> Actually, all the downloads come from the java.net server, so we actually
>> have full stats access.
>
> But that is only counting the number of downloads? Im interested in
> what plugins people actually use and not only downloaded. A plugin can
> be downloaded many times, but uninstalled because it doesnt work.
I see.

I think there's a lot of ways to take advantage of improved
connectivity. Jesse had an idea of having Hudson collect exceptions and
ask the user for the permission to send it back to us.

Along the line of what you are thinking, perhaps we can ask the user for
a permission to send us a ping when they uninstall a plugin.


>> Looking at IntelliJ, it doesn't ask for any opt-in permissions for obtaining
>> download stats, so I'm thinking doing this doesn't require the user to
>> opt-in.
>
> Ok, that works for me. The reason I asked is that debian popularity
> package is not default installed.

Ah, interesting. I didn't know about this package, but it seems like
something we should be doing.

I wonder if we could provide some incentive for people to sign up to
send us the stats information, like linking this to the automatic error
stack trace submissions.

Hmm...

>>> * Send an email when Hudson has found a new version of a plugin to the
>>> administrator. Uses the email admin address.
>>
>> Ah, good suggestion.
>
> Ok, https://hudson.dev.java.net/issues/show_bug.cgi?id=1834
>
>
>>> BTW how is the update-center.json file updated? The ci-game is missing
>>> the wiki link and the tasks plugins is titled Rake, which I could fix
>>> but Im not sure how the file is generated.
>>
>> A program tries to infer the Wiki page for a plugin by the following means:
>>
>>  1. if POM has <url> that points to Wiki, that would be used. This is
>>     the recommended way.
>>  2. Similarity between the page name and the plugin artifact Id is
>>     considered and the best match is chosen if it's really close.
>>     This is how many plugins get their Wiki pages today.
>>
>> ci-game plugin failed 1. above and 2. didn't match because the name was too
>> different.
>
> Strange because the ci-game plugin pom has the <url>
> (http://shorl.com/jurijygidrybry).
Ah, indeed. Hmm. I suspect it's a case sensitivity issue.  I noticed
that URL has "game" but the real page has "Game".


>> And I need to set up a continuous execution of this tool.
>
> If only we had a CI tool ;)

Exactly!

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update center

Kohsuke Kawaguchi
Administrator
In reply to this post by ruel loehr
Loehr, Ruel wrote:
> A winning one.  Prabhat might be able to weigh in on to do it for jboss.
>
> ________________________________
> From: Adam Purkiss [mailto:[hidden email]]
> Sent: Tuesday, June 10, 2008 1:00 PM
> To: [hidden email]
> Subject: RE: Update center
>
> whats the bet this is different for every single container.......

I think if we cover several major ones, that's still useful.

Another possibility is to use JSR-88 or JSR-77 (I forgot which is
which.) JavaEE containers are supposed to have JMX interface for basic
operation, and I believe this includes deployment.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Update center

Adam Purkiss
well as long as you do winstone ;) The way I currently run it, and tomcat which is the way I used to run it until I saw that winstone did a good enough job for the load I put it under. No one uses anything else anyway,.... hehehe




> Date: Tue, 10 Jun 2008 11:19:11 -0700

> From: [hidden email]
> To: [hidden email]
> Subject: Re: Update center
>
> Loehr, Ruel wrote:
> > A winning one. Prabhat might be able to weigh in on to do it for jboss.
> >
> > ________________________________
> > From: Adam Purkiss [mailto:[hidden email]]
> > Sent: Tuesday, June 10, 2008 1:00 PM
> > To: [hidden email]
> > Subject: RE: Update center
> >
> > whats the bet this is different for every single container.......
>
> I think if we cover several major ones, that's still useful.
>
> Another possibility is to use JSR-88 or JSR-77 (I forgot which is
> which.) JavaEE containers are supposed to have JMX interface for basic
> operation, and I believe this includes deployment.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Update center

Brendt
In reply to this post by Kohsuke Kawaguchi
kohsuke wrote
I really need to figure out how to restart a webapp from within a
webapp. This would be also necessary to provide the in-place update
capability of Hudson itself.

--
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi@sun.com
Doesn't tomcat do something similar with its /manager webapp ?  Or is that just for deploy/undeploy X webapp?
Reply | Threaded
Open this post in threaded view
|

Re: Update center

stephenconnolly
In reply to this post by Kohsuke Kawaguchi
another issue is that restarting a web container runs the risk of  
classloader leaks. this could cause problems unless we have a shutdown  
listener for all the plugins ESP when the vm slaves are added. I'm  
already seeing a ssh connection leak every restart of hpi:run


Sent from my iPod

On 10 Jun 2008, at 19:19, Kohsuke Kawaguchi  
<[hidden email]> wrote:

> Loehr, Ruel wrote:
>> A winning one.  Prabhat might be able to weigh in on to do it for  
>> jboss.
>> ________________________________
>> From: Adam Purkiss [mailto:[hidden email]]
>> Sent: Tuesday, June 10, 2008 1:00 PM
>> To: [hidden email]
>> Subject: RE: Update center
>> whats the bet this is different for every single container.......
>
> I think if we cover several major ones, that's still useful.
>
> Another possibility is to use JSR-88 or JSR-77 (I forgot which is  
> which.) JavaEE containers are supposed to have JMX interface for  
> basic operation, and I believe this includes deployment.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]

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

Reply | Threaded
Open this post in threaded view
|

Re: Update center

Erik Ramfelt
In reply to this post by Kohsuke Kawaguchi
On Tue, Jun 10, 2008 at 8:07 PM, Kohsuke Kawaguchi
<[hidden email]> wrote:

> Erik Ramfelt wrote:
>>
>> On Tue, Jun 10, 2008 at 6:22 PM, Kohsuke Kawaguchi
>> <[hidden email]> wrote:
>>>
>>> Erik Ramfelt wrote:
>>>>
>>>> Hi Kohsuke
>>>>
>>>> Excellent work with the update center, it makes the plugin handling so
>>>> much easier.
>>>>
>>>> Whats in the road map for it? I have a few suggestions:
>>>> * A group mode similar to the one in the Plugin wiki page, group
>>>> plugins according to type (SCM, builders, etc). It would also be nice
>>>> to be able to group the plugins by platform (.NET, Java, etc)
>>>
>>> Yes. I should be able to read information from Wiki to do this. I also
>>> wanted to capture excerpt from Wiki.
>>
>> That would solve it.
>> https://hudson.dev.java.net/issues/show_bug.cgi?id=1836
>> Perhaps there is a need for a "Update center" component in the issue
>> tracker.
>
> Thanks for filing an issue.
>
>
>>>> * Is there any dependency solving implemented? ie, can we create
>>>> library plugins that are downloaded automatically? (Should there be a
>>>> difference between library plugins and normal plugins?)
>>>
>>> Yes, this is in the plan, too. We also need to check the Hudson core
>>> version
>>> that a plugin requires.
>>
>> Does this mean that the plugins in trunk will no longer be
>> automatically updated with dependency to the latest hudson.war?
>> Because most of the times, the plugins do not require the latest
>> version of Hudson at the time the plugin was released.
>
> Yeah, I'm not sure what the best versioning strategy would be.
>
> The current structure of keeping the Hudson version number in
> plugins/pom.xml helped keep plugins/*/pom.xml simple, but OTOH it has the
> problem of what you describe.
>
> Should we encourage each plugin to list <dependency> to hudson core and war
> explicitly?

I thought it already did, but now I see that its for the
org.jvnet.hudson.plugins.plugin. One problem for the plugin author is
to know when they should update the dependency to a newer hudson. I
dont really have a good answer for this.


>>>> * Somehow show the optional/mandatory plugin dependencies for a plugin.
>>>
>>> I think the debian package approach is useful --- a plugin could nominate
>>> "recommended" plugins, and the user would be prompted to install them,
>>> too.
>>
>> Sounds good, but how about mandatory plugins? ie, im thinking of a
>> library plugin that contains the logic for parsing incoming IM
>> messages to start/query builds (ie copy logic from existing IM
>> plugins). To add a new IM protocol, then I would only have to handle
>> the connection parts, as the library plugin would handle the message
>> parsing.
>
> Right, I should be able to handle those accordingly, as well. Indeed the
> library plugin was one of the motivations for the update center work.
>
>
>>>> * Popularity listing, showing how many installations for each plugin.
>>>> May need an accept from the administrator and webservice to publish
>>>> stats to.
>>>
>>> Actually, all the downloads come from the java.net server, so we actually
>>> have full stats access.
>>
>> But that is only counting the number of downloads? Im interested in
>> what plugins people actually use and not only downloaded. A plugin can
>> be downloaded many times, but uninstalled because it doesnt work.
>
> I see.
>
> I think there's a lot of ways to take advantage of improved connectivity.
> Jesse had an idea of having Hudson collect exceptions and ask the user for
> the permission to send it back to us.

Yes its a good idea (although Im a little afraid of the exception
flooding ;). I guess that the exceptions would be sent to a mailing
list? And then later a mail monitor could create issues for every new
unique exception.


> Along the line of what you are thinking, perhaps we can ask the user for a
> permission to send us a ping when they uninstall a plugin.

Well, theres more than one way to uninstall a plugin, the user can
delete the files. So we would get incorrect stats. Check out the stats
from the debian pkg, http://popcon.debian.org/ and an example
http://popcon.debian.org/main/text/by_inst.

Im seeing the following data to be sent in:
* Hudson version - we could see what versions of Hudson that people
tend to stick with. It would be very interesting to see how old Hudson
installations people are using; and if they are upgrading for every
new release.
* Plugin versions - same reason as above, but include data if the
plugin is in installed but not actually used
* Plattform - why not
* JDK version - why not
Of course, all data would be anonymized; as we are only interested in
the usage stats.

If the data is sent every week, we would get trend graphs on how many
Hudson installations there are, and if the Hudson base is growing or
shrinking (!?).

Perhaps this is a little to big to be included in the update manager
as this information could easily be gathered by a plugin. So why not
do as debian, and put the stats gathering as a plugin and asking users
to install it.

All this requires a place to collect the data. Does anyone have any
suggstions, this is a little far of but could Google Spreadsheet be
used for this?


>>> Looking at IntelliJ, it doesn't ask for any opt-in permissions for
>>> obtaining
>>> download stats, so I'm thinking doing this doesn't require the user to
>>> opt-in.
>>
>> Ok, that works for me. The reason I asked is that debian popularity
>> package is not default installed.
>
> Ah, interesting. I didn't know about this package, but it seems like
> something we should be doing.
>
> I wonder if we could provide some incentive for people to sign up to send us
> the stats information, like linking this to the automatic error stack trace
> submissions.
>
> Hmm...
>
>>>> * Send an email when Hudson has found a new version of a plugin to the
>>>> administrator. Uses the email admin address.
>>>
>>> Ah, good suggestion.
>>
>> Ok, https://hudson.dev.java.net/issues/show_bug.cgi?id=1834
>>
>>
>>>> BTW how is the update-center.json file updated? The ci-game is missing
>>>> the wiki link and the tasks plugins is titled Rake, which I could fix
>>>> but Im not sure how the file is generated.
>>>
>>> A program tries to infer the Wiki page for a plugin by the following
>>> means:
>>>
>>>  1. if POM has <url> that points to Wiki, that would be used. This is
>>>    the recommended way.
>>>  2. Similarity between the page name and the plugin artifact Id is
>>>    considered and the best match is chosen if it's really close.
>>>    This is how many plugins get their Wiki pages today.
>>>
>>> ci-game plugin failed 1. above and 2. didn't match because the name was
>>> too
>>> different.
>>
>> Strange because the ci-game plugin pom has the <url>
>> (http://shorl.com/jurijygidrybry).
>
> Ah, indeed. Hmm. I suspect it's a case sensitivity issue.  I noticed that
> URL has "game" but the real page has "Game".

Upps, thanks for fixing it. BTW the Open tasks plugin has the wrong
title and wiki link.


>>> And I need to set up a continuous execution of this tool.
>>
>> If only we had a CI tool ;)
>
> Exactly!
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Update center

Kohsuke Kawaguchi
Administrator
In reply to this post by mezlight

Done in 1.223.

Messmer, Jason wrote:

> I think I prefer not to show the install plugins @ all in the available
> tab (netbeans way)
>
> ________________________________
>
> From: Adam Purkiss [mailto:[hidden email]]
> Sent: Tuesday, June 10, 2008 1:10 PM
> To: [hidden email]
> Subject: RE: Update center
>
>
> Just a quick request but could the available tab have the installed
> plugins highlighted somehow so you dont need to flick between available
> and installed to see what is installed.
>  
> Otherwise it is good.
>  
> Oh and could reload config from disk also reload plugins?
>
>
>
>
>
> ________________________________
>
>
>> Date: Tue, 10 Jun 2008 09:22:53 -0700
>> From: [hidden email]
>> To: [hidden email]
>> Subject: Re: Update center
>>
>> Erik Ramfelt wrote:
>> > Hi Kohsuke
>> >
>> > Excellent work with the update center, it makes the plugin handling
> so
>> > much easier.
>> >
>> > Whats in the road map for it? I have a few suggestions:
>> > * A group mode similar to the one in the Plugin wiki page, group
>> > plugins according to type (SCM, builders, etc). It would also be
> nice
>> > to be able to group the plugins by platform (.NET, Java, etc)
>>
>> Yes. I should be able to read information from Wiki to do this. I also
>
>> wanted to capture excerpt from Wiki.
>>
>> > * Is there any dependency solving implemented? ie, can we create
>> > library plugins that are downloaded automatically? (Should there be
> a
>> > difference between library plugins and normal plugins?)
>>
>> Yes, this is in the plan, too. We also need to check the Hudson core
>> version that a plugin requires.
>>
>> > * Somehow show the optional/mandatory plugin dependencies for a
> plugin.
>>
>> I think the debian package approach is useful --- a plugin could
>> nominate "recommended" plugins, and the user would be prompted to
>> install them, too.
>>
>>
>> > * Popularity listing, showing how many installations for each
> plugin.
>> > May need an accept from the administrator and webservice to publish
>> > stats to.
>>
>> Actually, all the downloads come from the java.net server, so we
>> actually have full stats access.
>>
>> Looking at IntelliJ, it doesn't ask for any opt-in permissions for
>> obtaining download stats, so I'm thinking doing this doesn't require
> the
>> user to opt-in.
>>
>>
>> > * Send an email when Hudson has found a new version of a plugin to
> the
>> > administrator. Uses the email admin address.
>>
>> Ah, good suggestion.
>>
>>
>> > BTW how is the update-center.json file updated? The ci-game is
> missing
>> > the wiki link and the tasks plugins is titled Rake, which I could
> fix
>> > but Im not sure how the file is generated.
>>
>> A program tries to infer the Wiki page for a plugin by the following
> means:
>>
>> 1. if POM has <url> that points to Wiki, that would be used. This is
>> the recommended way.
>> 2. Similarity between the page name and the plugin artifact Id is
>> considered and the best match is chosen if it's really close.
>> This is how many plugins get their Wiki pages today.
>>
>> ci-game plugin failed 1. above and 2. didn't match because the name
> was
>> too different.
>>
>> And I need to set up a continuous execution of this tool.
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems [hidden email]
>
>
>
> ________________________________
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update center

Kohsuke Kawaguchi
Administrator
In reply to this post by Brendt

Yep. Different containers offer different means to do it.

Manager app is probably not a very desirable option, however, because
it's optional.

Being in the same VM, I think there's an easier way to do it for Tomcat.

blucas wrote:

>
> kohsuke wrote:
>>
>> I really need to figure out how to restart a webapp from within a
>> webapp. This would be also necessary to provide the in-place update
>> capability of Hudson itself.
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems                   [hidden email]
>>
> Doesn't tomcat do something similar with its /manager webapp ?  Or is that
> just for deploy/undeploy X webapp?

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update center

Kohsuke Kawaguchi
Administrator
In reply to this post by Erik Ramfelt
Erik Ramfelt wrote:
>> I think there's a lot of ways to take advantage of improved connectivity.
>> Jesse had an idea of having Hudson collect exceptions and ask the user for
>> the permission to send it back to us.
>
> Yes its a good idea (although Im a little afraid of the exception
> flooding ;). I guess that the exceptions would be sent to a mailing
> list? And then later a mail monitor could create issues for every new
> unique exception.

I think we can have a smarter server app that builds a list little more
intelligently. Then it can file bugs automatically --- that part is
pretty easy by using javanettasks.

Something like this could be useful for the GlassFish project itself, so
that's an extra incentive for me.



>> Along the line of what you are thinking, perhaps we can ask the user for a
>> permission to send us a ping when they uninstall a plugin.
>
> Well, theres more than one way to uninstall a plugin, the user can
> delete the files. So we would get incorrect stats. Check out the stats
> from the debian pkg, http://popcon.debian.org/ and an example
> http://popcon.debian.org/main/text/by_inst.
>
> Im seeing the following data to be sent in:
> * Hudson version - we could see what versions of Hudson that people
> tend to stick with. It would be very interesting to see how old Hudson
> installations people are using; and if they are upgrading for every
> new release.
Knowing the update cycle is interesting indeed. I seriously doubt if
anyone updates every release, but knowing a typical cycle is good. It
helps us determine when to remove some deprecated features.


> * Plugin versions - same reason as above, but include data if the
> plugin is in installed but not actually used
> * Plattform - why not
> * JDK version - why not
> Of course, all data would be anonymized; as we are only interested in
> the usage stats.
>
> If the data is sent every week, we would get trend graphs on how many
> Hudson installations there are, and if the Hudson base is growing or
> shrinking (!?).
>
> Perhaps this is a little to big to be included in the update manager
> as this information could easily be gathered by a plugin. So why not
> do as debian, and put the stats gathering as a plugin and asking users
> to install it.
Sounds good.


> All this requires a place to collect the data. Does anyone have any
> suggstions, this is a little far of but could Google Spreadsheet be
> used for this?

I can host the webapp to receive submissions. The data could be exported
  as CSV or something, then you can feed that into your favorite tools
for aggregation.



>> Ah, indeed. Hmm. I suspect it's a case sensitivity issue.  I noticed that
>> URL has "game" but the real page has "Game".
>
> Upps, thanks for fixing it. BTW the Open tasks plugin has the wrong
> title and wiki link.

I can't spot the open tasks plugin in Subversion repository. Where is
this plugin!?

>
>>>> And I need to set up a continuous execution of this tool.
>>>
>>> If only we had a CI tool ;)
>>
>> Exactly!
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems                   [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment