JetBrains support for 3rd-party plugins

[Patrick Wright]

Hi Dmitry

I've used NetBeans, jEdit, IntelliJ, Firefox, among other plugin-extensible tools. One problem these all have--including IntelliJ--is that apart from those officially supported, plugins are generally not tested, reviewed or recommended by the makers of the tool itself. In the worst case (true for all those tools) the plugin repository includes quite a few "junk" or incubator-quality plugins that don't deserve to be used in a serious development tool. What I periodically find is that plugins that aren't actively maintained throw exceptions, for example, and when this becomes enough of an annoyance I pull the plug and remove the plugin. The current system of tracking plugin quality via voting, and commenting via a discussion page (and unmaintained wiki) doesn't take us far enough.

I would love to see some sort of review system by IntelliJ for plugins. I see and appreciate the voting system, appreciate that JetBrains has lots of work on its hands, etc.--but I feel the current system includes too many unstable plugins and something in the process could be improved.

Here are some practical ideas:
1) if the plugin is open-source, plugin developers should be required to distribute it with (an) IntelliJ project file(s) so that one can easily retrieve, debug and improve the plugin.
1a) would be nice to have a dialog or feature to pull plugin source down with the plugin (jEdit supports this), optionally pulling in the plugin project or plugin module(s)
1b) some way to encourage collaboration would be useful. for example, if plugin developers were hosted on site X (sourceforge, google code, codehaus, java.net), it would nice neat if IntelliJ could take care of the grunt work of getting CVS/SVN set up so that source code could be downloaded, and patches could be submitted more easily

2) the JetBrains team could help by marking older plugins which have been superseded by features in newer releases of IntelliJ. currently there is no filtering on the plugin list, which includes very old plugins that are no longer useful past a certain version.

3) the plugin dialog could be extended
3a) to include links to the source (and maybe a checkbox to download it)
3b) to show the number of votes on a plugin

4) a quick tool to vote on plugins would be useful--for example, when disabling or removing a plugin, an option to vote and comment (to be posted to the plugins website)

5) some way to capture activity in plugin development would be helpful--e.g. plugins released just once would have a lower rating than those regularly updated

6) include vote categories for "stability", "configurability"

7) when a plugin throws an exception (or is suspected as the cause), it would be great to be able to
7a) disable the plugin immediately
7b) vote on it
7c) file an issue or
7d) submit a comment to the plugins site
7e) track the number of exceptions thrown per plugin, across users (optional, of course, as this info would be uploaded)

8) i get a very bad feeling from plugins distributed as binaries, with no email address, plugin home page, or developer home page provided.

9) nice to have--assuming the source was available, a PMD or Checkstyle configuration could verify (and warn) if the plugin performs IO, network operations, etc. (esp. for plugins with no email address or home page).

Sorry, that's a long list! But you have such a great start in the current plugin set that it's worth asking for it to be first-class.

If you think any of these are worthwhile, and might be implemented in the future, I'm glad to add any or all suggestions as feature requests in JIRA.

Thanks!
Patrick

[Dmitry Jemerov]

Hello Patrick,

Thanks a lot for your detailed feedback!

As for reviewing plugins, it's indeed mostly a matter of JetBrains resources. There is a small number of plugins that we're using ourselves and promoting in the forums and the blog, but we don't really have the resources to evaluate all submitted plugins in much detail.

Responses to specific items:

1) if the plugin is open-source, plugin developers should be required to distribute it with (an) IntelliJ project file(s) so that one can easily retrieve, debug and improve the plugin.

I don't think that *requiring* it would be either necessary or possible. The projects are usually available anyway, and if they aren't, they are easy to set up.

1a) would be nice to have a dialog or feature to pull plugin source down with the plugin (jEdit supports this), optionally pulling in the plugin project or plugin module(s)

Feel free to file a JIRA issue for this (although I'm not sure how many users would actually use this).

1b) some way to encourage collaboration would be useful. for example, if plugin developers were hosted on site X (sourceforge, google code, codehaus, java.net), it would nice neat if IntelliJ could take care of the grunt work of getting CVS/SVN set up so that source code could be downloaded, and patches could be submitted more easily

This request is not really specific to plugin development - this is a general issue of checking out code from a repository and creating a project for it. We've improved support for this scenario in version 7.0, and if you have specific suggestions how to improve it even further, feel free to post JIRA issues.

2) the JetBrains team could help by marking older plugins which have been superseded by features in newer releases of IntelliJ. currently there is no filtering on the plugin list, which includes very old plugins that are no longer useful past a certain version.

There's an "Obsolete" category in our plugin manager for this purpose. If you are aware of any plugins that should be there but are not, please let me know.

3) the plugin dialog could be extended
3b) to show the number of votes on a plugin

JIRA issue please?

4) a quick tool to vote on plugins would be useful--for example, when disabling or removing a plugin, an option to vote and comment (to be posted to the plugins website)

Hard to say - maybe this feature will be more annoying than useful.

5) some way to capture activity in plugin development would be helpful--e.g. plugins released just once would have a lower rating than those regularly updated

In my opinion, the release history is easy to view in the plugin manager as it is now.

6) include vote categories for "stability", "configurability"

Again, this looks like an overcomplication to me. Users can comment on this if they want to.

7) when a plugin throws an exception (or is suspected as the cause), it would be great to be able to
7a) disable the plugin immediately
7b) vote on it
7c) file an issue or
7d) submit a comment to the plugins site
7e) track the number of exceptions thrown per plugin, across users > (optional, of course, as this info would be uploaded)

Integrating exception reporting with our plugin repository site may be a good idea - we'll have to think about that.

9) nice to have--assuming the source was available, a PMD or Checkstyle configuration could verify (and warn) if the plugin performs IO, network operations, etc. (esp. for plugins with no email address or home page).

I don't think that it's a common case. Open-source plugins nearly always do have both a home page and author information.

[Patrick Wright]

Hi Dmitry

Thanks for your feedback. We don't agree on all points, but I'm pleased that you took the time to think it over and respond.

A couple of quick notes.

- My list of plugins has 366 entries--going back to 2004. I am sure a number of those are for features which are no longer useful (being in the newer versions of IDEA already).

This request is not really specific to plugin development - this is a general issue of checking out code from a repository and creating a project for it. We've improved support for this scenario in version 7.0, and if you have specific suggestions how to improve it even further, feel free to post JIRA issues.

Spend a few minutes on the plugins website, for example, category "Editor". How many of the first 10 have source code linked, even the ones listed as "free software"? I count 2 out of 10. In some cases, it may be available--great, go to the Wiki page, scroll down until you find it.

I'm sure we can do better.

I think the risk IntelliJ faces is that the plugin repository is a becoming a dumping ground. At least that's my experience of it. Many of the plugins I try out are unstable, incomplete, or throw exceptions (but keep running). That was my experience with jEdit plugins as well. Some strategy to encourage feedback, rating and involvement seems necessary.

But that's just my opinion--again, thanks for listening.

Regards
Patrick


I added the following issues to the tracker:
pull source with plugin
http://www.jetbrains.net/jira/browse/IDEA-16254

see votes in plugin dialog
http://www.jetbrains.net/jira/browse/IDEA-16255

comment/rate plugins
http://www.jetbrains.net/jira/browse/IDEA-16256

plugin exception reporting
http://www.jetbrains.net/jira/browse/IDEA-16257

obsolete plugins
http://www.jetbrains.net/jira/browse/IDEA-16258