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
|
