Re: [hudson-dev] [Hudson-Dev] Re: Specifying the sections where your plugin should appear in the update center
On 1/5/12 12:57 PM, Henrik Lynggaard Hansen wrote:
2012/1/4 Winston Prakash<winston.prakash@xxxxxxxxx>:
One thing that is not documented is the values which can be used in that
Yes, we should document it. Unfortunately no solid list was ever
Let us work on that.
sure, let me start by making the initial suggestion
- scm: for all scm plugins (as today)
- scm-related: for scm helper plugins (as today except git,label column)
- trigger: for buils triggers (as today)
- builder/buildstep: for plugins that extend Builder. As today except
a few to clean out like project health, build pipeline, post build
task and the such
- slave: anything related to managing slaves (as today except system load avg)
- notification: for plugins that notify after (as today except copy to
- report: build reports
- publish/upload: any artifact uploader/publisher
- security: for security and user management
- fun: for none serious plugins such as cigame etc.
I know I am missing some categories, but since many of them are
changes from the current topic list
- suggest slaves and cloud plugins are one category
- drop the maven category
- add a library category for things like static-analysis-core, token-macro etc.
- drop the misc category and just use uncategorised
Sounds like a good list. Could you start a wiki page to list the Plugin
Categories, so that others can chime in.
Maybe we should build an alternative topic page while we figure this out ?
If you mean fixing the Public/private key issue to unscramble the
collected data, if so I fixed it in 2.2.0.
also should we specify the tier in the pom ?
I'm not sure if it should be part of the POM. The tier is decided based on
popularity of the plugin (number of downloads etc)
Speaking of which, did we ever get the download/install stats for
It has a unique server key, so the collected data will be more accurate/
The download data prior to 2.2.0 could be interpreted in terms of unique
IP. But may not be accurate.
The data is collected as part of apache log rotation. I have to parse
and create the statistics
and is the data publically available ?
What I think for the long run is to build an application that receives
the download request which saves the stat directly in a database. The
advantage of this approach would be; direct display of download stats by
that application on demand.
hudson-dev mailing list