Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hudson-dev] [Hudson-Dev] Re: Aligment of plugin names

Currently we have no Tier 4 - although I know what you mean, all those that are currently un-categorized

But I would question whether Tier 3 is based on 'popularity'. It is split into 4 categories:
  • Hudson - plugins developed and maintained for the Hudson community 
  • Compatible -  tested by their owners for compatibility between Hudson and Jenkins
  • Install Tested - those that, on release of a new plugin version, are tested by the Hudson community that they at least install correctly. But there is no stated compatibility from Jenkins
  • Other - plugins that have not been identified as belonging to any of the above categories

I would say that all new plugins become Tier 3 - Hudson or Compatible. Isn't that the case?


On 27/01/2012 16:36, Winston Prakash wrote:
I didn't mean plugin author would abuse the the system. I meant there are many open ended questions

How do they know which tier their plugin belongs to?.
Should all new plugins starts with "tier4"?.
When do they move up the ladder tier4 -> tier3 -> tier2 -> tier1?.
Who will inform them now their plugin has moved from tier4 to tier3?

- Winston

On 1/27/12 8:14 AM, SUSAN DUNCAN wrote:
I guess I want to believe that plugin authors would not abuse the system, surely this is a good starting point?



On 27/01/2012 16:00, Winston Prakash wrote:

As I mentioned to Henrik earlier, tier information can not be in the POM file. If it is in the POM file, plugin authors can put their plugin to any tier1 they wish. But It has to be determined based on popularity of the plugin. So the information need to come from external list, not from POM.

- Winston

On 1/27/12 7:50 AM, SUSAN DUNCAN wrote:
While we are talking about new properties for POM files

- could we introduce one to denote the Tier of a plugin. then we could use this to add a field on the Plugin Information box on the plugin's page  (with a link to the tier list).  We could ask plugin owners to add it - fine for tier1/2 and some tier 3 - but if they do not, then an optional field and no harm done.

I have added a tag to those tiered plugins - on each plugin wiki page - but it would be good to show the tier info more prominently when someone browses the wiki for potential plugins to use


On 26/01/2012 23:04, Winston Prakash wrote:
The plugin is identified with a JSON attribute "name" and display name comes from the JSON attribute "title".
When the update center generator generates the JSON, from the  plugin POM it uses the tag <artifactId> for the "name" and <name>  for  "title".

I like the <name> "Hudson BIRT Charts Plugin", because this will be used as project name in the IDE. This makes it easy to find the project in the list of so many other projects. Also the name "Hudson :: Maven 3 :: Plugin", tells me "Maven3" is a "Plugin" available as module inside the main project "Hudson".

However, I agree with you that  the display name "Hudson BIRT Charts Plugin" in the update center has redundant prefix "Hudson" and suffix "Plugin".

To solve this problem we could introduce a POM property called "displayName". Ex

    <displayName>Birt Chart</displayName>
The update center generator would use this property, if available" to fill the JSON attribute "title" or revert to <name> tag.

- Winston

On 1/26/12 12:40 PM, Henrik Lynggaard Hansen wrote:

I raised an eclipse defect about aligning plugin names
( but I think it
warrants wider discussion.

As written in the bug report
Currently the our naming of plugins (even just within the core) seems
a bit "random".Not only is this randomness a bit ugly, it also breaks
the natural

Hudson BIRT Charts Plugin
JCaptcha Plugin
Hudson :: Maven 3 :: Plugin

I think we should agree on a preferred naming convention and re-align
our own plugins. This convention should be posted on the wiki, so
others have a chance to follow it.

I suggest we remove both "Hudson" and "plugin" from the name as that
information is redundant in the context of the update centre. which
would lead to names such as
* BIRT Charting
* JCaptcha
* Maven 3
* Windows slaves

I am not sure if this should be done at the source level or in the update
centre .

I know that sometimes the name is seen outside the context of plugin
centre, and there might be useful to have both "Hudson" and "plugin"
in the name, so perhaps an idea was to support reading a property like
"hudson.hint.displayname" (same style as the netbeans hints) from the
pom.xml and if present use that instead of the normal project name.

Best regards
hudson-dev mailing list

Back to the top