Dmitry Jemerov's Weblog

IntelliJ IDEA: OpenAPI documentation contributions

Arik Kfir asks whether we accept contributions to our OpenAPI documentations. In fact, the best way to contribute to the documentation is to write an overview article covering an area of the OpenAPI that you’re familiar with. The article does not need to be overly long and detailed – simply describe how to use a component, and how to accomplish the most common tasks using its API. We will be happy to review the articles, publish them on jetbrains.com (if you agree to this), and possibly include them in the Plugin Development Package.

JavaDoc contributions are also welcome. However, we can produce JavaDocs pretty fast internally, so it may be sufficient to file a JIRA request specifying the classes that you would like to see documented.

If you would like to write an article covering some part of the OpenAPI, please contact me (yole@jetbrains.com) in advance and let me know about the topics you’re going to cover, so that we can avoid work duplication. Also, a new introductory plugin development tutorial will be published with the 5.1 release, so articles covering the very basics of plugin development are not in the highest demand now.

And thanks for your offer to contribute, Arik!

IntelliJ IDEA 6.0 "Demetra": Per-project and per-scope inspection profiles

This feature is in fact something I promised to blog about quite a long time ago, but after the initial implementation was nearly complete, we decided that we don’t really like the way it turned out, and ended up redoing the feature completely. This post describes the second, reworked implementation – and who knows what changes we will need to do with it based on feedback from users?..

In previous versions of IntelliJ IDEA, the inspection profile was a user’s personal setting; it was possible to export and import inspection profiles, but having a single inspection profile shared between all developers working on the project was quite cumbersome. There was no simple way to propagate the inspection profile changes to all users if the profile was changed after initial configuration. Also, the only way to have different inspection settings in different files of the project was to disable inspections on per-file basis using an icon in the status bar. (In fact, the name for the icon – “Hector the Inspector” – was initially suggested by one of our EAP members, but we liked it so much that we started using it even in the names of classes related to implementing its functionality.)

IntelliJ IDEA 6.0 makes this much more flexible: it is now possible to store inspection profiles in the project file, and the custom scopes mechanism can be used to associate different inspection profiles with different parts of the project.

As you can see, we have a separate inspection profile for test sources (where the error strictness is much less important), another for the OpenAPI (where JavaDoc errors are highlighted), and yet another for runtime classes which need to be compatible with JDK 1.3 (so all Java 5 features and API methods are forbidden). The scope definition language is very flexible: for example, the OpenAPI profile is defined as “all modules which have openapi as part of the name”.

We have also made a number of extensions to the scope definition language. For example, it can now apply to files of any type and not only to Java classes, and it supports module groups (so you can define a scope as “all modules in this module group”).

When a new inspection profile is created, you can choose whether it should be saved as your personal profile (IDE profile), or as a shared profile in the .ipr file.

The status bar now shows the profile which is used to inspect the file currently open in the editor, and provides a quick way to access the profile settings. Note that we have dropped the old possibility to disable inspections on per-file basis: the scopes functionality is much more powerful, and if single-file suppressions are indeed what you need, you can create single-file scopes and associate empty inspection profiles with them.

IntelliJ IDEA Python plugin available in CVS

I’m happy to announce that Pythonid, the Python language plugin for IntelliJ IDEA, is now available as an incubator project at java.net. There are no public releases yet, but the entire source code is available in CVS and licensed under the Apache 2 license.

I started working on Pythonid as a spare time project before I joined the IDEA team, while I was still working on Omea. After I started working on IDEA, I no longer had much spare time – and, frankly speaking, had enough IDEA-related coding in the daytime. Because of that, the development of the plugin pretty much stalled. However, I did send the plugin sources to several developers who expressed interest in the plugin newsgroup, and one of them – Keith Lea – was sufficiently interested to pick up the project and adapt it for use in the company where he’s working. Keith was also the one who arranged the release of the plugin at java.net.

The main problem currently preventing the release of the plugin is lack of a formatter. Otherwise, the plugin has roughly achieved feature parity with the JavaScript plugin as of IntelliJ IDEA 5.0. The formatter implementation has been problematic because of the issues with the formatter core – the Python indentation and whitespace handling is quite different from that of Java, so the core sometimes needs to be extended in order to support Python well.

I expect to make a “real” release of the plugin (and upload it to the Plugin Manager) as soon as either the formatter reaches somewhat working state, or it becomes clear that it will not be possible to achieve a sufficiently working formatter with IntelliJ IDEA 5.1. In the latter case, the plugin will be released with the formatter disabled.

There is still lots and lots of work to do on the plugin, so if you’re interested in contributing, feel free to contact me.

Update: Chris Miller has kindly provided instructions for checking out and building the plugin.

IntelliJ IDEA: External contributors to standard plugins

The holiday season is long over by now, but there’s still not too much to tell regarding the main topic of my blog – new features of IntelliJ IDEA 6.0. As the release of IntelliJ IDEA 5.1 is quickly approaching, most of the team has been focused on bugfixing and wrap-up changes for the 5.1 release. So the 5.1 changes are what I’m going to talk about in the next few blog posts.

One change that has been quite exciting for me in particular is that we’ve got a new external contributor for the plugins included in the IntelliJ IDEA distribution. Previously we had three – Bas Leijdekkers is responsible for maintaining and improving InspectionGadgets and IntentionPowerPak plugins originally developed by Dave Griffith, Alexey Efimov is maintaining his Images plugin, and Alexander Kitaev does most of the work on the Subversion integration plugin. They have now been joined by Sascha Weinreuter, a long-time member of the IntelliJ IDEA and plugin development community and the author of the XPathView plugin. Sascha has contributed a number of new inspections (“Incorrect component/action registration” and “Component/Action not registered in plugin.xml”) and a number of smaller enhancements to DevKit, the IntelliJ IDEA plugin which supports development of other plugins. Recently Sascha has also started contributing fixes and improvements to InspectionGadgets. Thanks a lot for your contributions Sascha, and I’m looking forward to your future work. :-)

We are very much interested in getting more active contributors, so if you would like to see your code in the IntelliJ IDEA distribution, go grab the Plugin Development Package, study the source code of the standard plugins (available under the Apache 2 license), and start sending patches to us. We’ll give you commit access to the Subversion repository where the plugins are stored as soon as we decide that we’re satisfied with the quality of your contributions.