Please, note that these documentation pages are frozen for Intellij IDEA Contest.
You will find updated reVu site on


What is it ?

reVu is a plugin for Intellij IDEA which helps to perform team code reviews or simply annotate your code. Intellij IDEA is great for automatic code inspections, but not at the point to make team code reviews useless (smile)

There's much literature about peer code review process, I'll just mention main advantages for me:

Some tools already exist, but they are either commercial (see Crucible from Atlassian) or are not tied to IDEA (GoogleCode provides a review process, Eclipse and Netbeans have their code review plugin, ...) whereas IDE integration is a key feature.

Key features


IntellijIDEA provides a plugin manager which allows user to download plugins from IDE. Plugin manager is available from Settings dialog. No further step is required.

Review process

Creating review

You create reviews from reVu project settings (which may be accessed directly from reVu tool window). A review is identified by its unique name. This name is used to create XML file which stores review definition.

When you create a new review, you have to choose if this review will be shared with others or will be local for you. A shared review is referenced from project settings file, whereas a local review is referenced from workspace settings file. But you will be able to change this setting using Share checkbox at any time.

A review definition is composed of:

Users, priorities and tags are defined in a referential. You'll probably use similar referentials between your reviews. In this case, you should create a review template with your custom referential and copy or extend it for your you reviews. Extend a template means that changes performed upon template will be replicated for reviews extending it, whereas copy makes the review independant from template.

Status combo defines current status of review. Administrator is in charge of changing this status according to current phase of your review:

Adding issues

Just point on reviewed code and invoke Add Issue action (Alt I shortcut by default). Issue is attached to selected ccde: if code is changed, issue is marked as desynchronized but is still available (and you'll still be able to preview initial code at any time).

Write a summary for this item. Optionally, you may add information such as priority, or tags.

Tags allow you to categorize issues according your needs. Usually, you'll use tags to set type of issue: coding standard, optimization, i18n, doc, ... But you can use them for additional classification: related business layer, resolution complexity, ...

Managing existing issues

The browsing tool window allows to navigate and update existing issues. There's one tab for each active review (i.e. reviewing or fixing) plus a tab gathering all issues.

Depending on your role, you are able to update issue information and change issue status : resolved, closed, reopened.

You can also configure issue recipients, i.e. author(s) which should fix issues, adding free notes and preview reviewed code. When no recipient is specified, it means all authors defined for review are concerned.

Issue table

Issue table is searchable through 2 ways:

Issue table is also sortable and you can choose visible columns using column selector button next to search field.


reVu adds also a scope for each active review. Theses scopes contain files which have at least one issue.

In future release, there could be scopes containing all files to review.

VCS integration

Issues are attached to the VCS revision of reviewed file. This allows later to retrieve original code when it has been changed between reviewing phase and fixing phase. The Preview tab in issue form shows the current preview and the original preview (when available).

NB: one key feature which is planned for future releases is to provide a mechanism for reviewers to work on diff between a reference VCS revision and a current revision so they may concentrate on changes.


Review definitions are stored in XML files. These files should be saved in your project tree for 2 reasons:

If you store shared reviews outside from project, others will have to access them using same file paths (e.g. a shared directory).

When a review is shared and several users work at the same on this review, usually its XML file must be merged. Most of time, there won't be any conflict, but sometimes you'll have to perform merge. It's the price to pay for having a such simple mechanism (smile) A custom merge resolution mechanism might be added in future releases.

If you find this issue critical, you should consider using a server based tool such as Crucible from Atlassian, see I don't know it, but Atlassian usually makes great products.


Each review has its own user list (but remember you should create a review template with your default users). User roles are specific to reviews: a user may be defined as reviewer in a review and author in another one.

Users are identified by a login and shown in UI through a display name. User must define their login using reVu application settings so they can be identified in reviews. Otherwise, an alert is shown and user can't use reVu.

reVu does not manage passwords. Since user information are stored in XML files, each one could alter easily these passwords, even if they are crypted. Or it would required some protection which would degrade usability

Future plan

Some features I'd like to implement in future releases :

Found a bug, want new feature ?

Please use Issue tracker.

More information is available on reVu site:

Icons come from famous FAMFAMFAM Silk icon library: