Hmm.. looks like my understanding that the proposal of plugins tier
is based on popularity, seems to be wrong. If there is a fixed
criteria to determine to which tier the plugin belongs, then I
think POM property can be used.
- Winston
On 1/27/12 8:42 AM, SUSAN DUNCAN wrote:
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?
s
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?
rgds
susan
On 27/01/2012 16:00, Winston Prakash wrote:
Susan,
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
susan
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
<properties>
<displayName>Birt Chart</displayName>
</properties>
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:
Hi
I raised an eclipse defect about aligning plugin names
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=369713) 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
sorting.
examples:
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
Henrik
_______________________________________________
hudson-dev mailing list
hudson-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hudson-dev
|
