JetBrains IntelliJ IDEA Blog

Maven integration in a Java IDE might not be a surprise for you, but let me show you just one thing, that makes IntelliJ IDEA Maven support prominent and noteworthy.

If you have any Maven project, you do not need to perform routine steps while importing it to IntelliJ IDEA and you do not need to be anxious about dependencies and artifacts in it, nor would you need to worry about technologies used in project. Just open the project as you do with usual IntelliJ IDEA projects, sit back and relax. IntelliJ IDEA will automatically recognize everything.

Here is an example. To open our Maven project, we just go to File | Open Project (Alt + F + O) and specify the path to pom.xml (the Maven project descriptor file).



IntelliJ IDEA creates a project based on the Maven Project descriptor file.
When done, all maven goals can be found in the Maven projects tool window. We can simply run/debug arbitrary Maven goals; execute them before/after make or run/debug, or by invoking an assigned keyboard shortcut. Select any Maven goal in the tree and right-click it to view options.



Now, let’s view our project structure. Go to Settings (Ctrl + Alt + S) | Project Structure and click Modules. As you can see, IntelliJ IDEA recognized modules and web facets. Moreover, all dependencies and deployment settings were detected and stored.



That’s all, nothing but a single click and you can enjoy complete support for Maven builder, including smart coding assistance for editing Maven pom.xml, intelligent code completion, inspections and quick-fixes, refactorings and other IntelliJ IDEA productivity-boosting features, which we are going to cover in the next posts.

It is sometimes the case, you can create plugins you want to preserve for internal use only. With
IntelliJ IDEA you can maintain your own enterprise repository to share your plugins with team members solely.

To create a repository, we need a Web server, where our plugins will reside, and a descriptor of available plugins (updatePlugins.xml), so IntelliJ IDEA could find them. This file can be located at the same Web server, for instance. By the time we decide to use plugins from the enterprise repository, we’ll only need to specify where this descriptor resides. To do so, open the Settings dialog (Ctrl + Alt + S) and go to Updates. In the Plugin Hosts section click Add and specify path to the updatePlugins.xml.

When creating updatePlugins.xml file for your repository, follow this DTD:
http://plugins.intellij.net/dtd/idea/updatePlugins1.0.dtd, so IntelliJ IDEA would be able to recognize available plugins.
Each plugin entry in this file should contain plugin identifier and URL of the plugin repository. Additionally, we can specify here plugin version. Though, if it is not pointed out in updatePlugins.xml, IntelliJ IDEA will fish it out from the plugin *.jar.

For example, we upload MyPlugin to the Web server where the repository resides. Then we open the updatePlugins.xml and add new plugin entry, like this one:

<plugins>
  <plugin id="MyPlugin" url="http://unit:8080/myPlugin.jar" version="1.0"/>
</plugins>

And that’s all we need to do to add the plugin to our repository.

If the whole team uses customized IntelliJ IDEA, you can add the whole list of plugin hosts to the bin/idea.properties under IntelliJ IDEA installation folder. Just open this file and add the following line: -D idea.plugin.hosts=[URL1],[URL2],…[URLn] where [URL1],[URL2],…[URLn] is a comma-delimited list of the URLs to the enterprise repositories.

Once hosts are specified, plugins are automatically updated according to the schedule defined in the Check for updates field of the Updates dialog. Yet, you can update them manually any time you need it. Just open the Updates dialog and click Check now. Update Info dialog box opens showing the list of plugins from all the available enterprise repositories. You can unselect those of them you don’t want to update for some reason.
Don’t forget that updates will take effect after IntelliJ IDEA restart.

If you had worked with IntelliJ IDEA for a while, you’re most likely aware of @Nullable, @NotNull annotations which allow you to formally specify method contracts and validate whether these contracts are met, and @NonNls annotation which is helpful when you want to exclude strings from the internationalization process.

However, there’re several cases when direct annotating code is not advisable: for example, project is shared between team members that use different IDEs, or you work with library classes. That does not mean you can’t make use of these annotations, though — with IntelliJ IDEA you can store annotations outside of the source code.

Let’s have a look at how it works. First, we need to open the Settings dialog (Ctrl + Alt + S) and go to Code Style (F), then check the option Use external annotations at the Code Generation tab. Now, add the annotations.jar library to either module or project. You can find it under INTELLIJ_IDEA_HOME/lib folder.


After that, open your current inspection profile and make sure Constant conditions& exceptions inspection is enabled and Suggest @Nullable annotation for methods that may possibly return null option is selected.

At this moment we can enjoy externally annotating methods, fields, parameters, etc. For example, we work on a module that contains a method that might return null.



Let’s add annotation — just click the light bulb. IntelliJ IDEA asks whether we want to add annotation in code directly, or store it externally. Select the second option and specify the external annotation root for the current module.

Note: You only select the location for external annotations once, so each next external annotation within this module will be stored in the same folder. Alternatively, you can specify annotations root at any time: open Project Settings dialog and go to the Modules page, then select the needed module and open its Paths tab. There you can find External annotations area, where you can manage external annotations attached to the module.

Now, this method is annotated without placing anything to the source code directly. You can press Ctrl + Q to view the attached annotation.



With external annotations you can even annotate methods within JDK classes.



Just like when you add external annotation on the module level, you can specify the storage location right when you add the annotation, or using Project Settings dialog. In the latter case, open Project Settings dialog, go to JDKs and specify the path in the Annotations tab.

DSM stands for Dependency Structure Matrix - a method for exploring dependencies between program parts (modules, classes, etc.), and provides a compact matrix representation of a project. It helps you visualize the dependencies between the parts of a project and highlights the information flow within a project.

When working on complex software projects it’s especially important to track dependencies between project parts. You might encounter too complicated relationships, or cyclic dependencies, that may seriously affect application performance and behavior, or even impede further project development. IntelliJ IDEA has adopted the DSM technology to provide easy reviewing and resolving of potential problems in project structure.

Let’s take a closer look at the DSM. To view the dependency matrix of your project, select Analyze | Analyze Dependency Matrix from the main menu and specify the desired analysis scope. If your project class files are out-of-date, IntelliJ IDEA will ask you whether you want to compile a project before continuing the DSM analysis. It is recommended to compile the project to avoid the analysis resulting in incomplete or incorrect data.

When ready, the DSM View is opened in a new window, enabling to examine dependencies. Let’s discover what we can learn from the DSM view.



In our example there is a typical DSM view with one of the rows selected. The row headers represent program structure. Everything is collapsed now and only modules are shown. When expanded, the header is tree-like, allowing you to dig into program packages. The column headers are the same as the corresponding row headers. Thus they are not shown in order to save space. Instead, different visual aids are used on the row headers.

Here we can learn the following:

1. The selected row and corresponding column are highlighted to visualize row dependencies.
2. The ellipsis in the cell means that the maven-core module has many (more than 99) dependencies on maven-project module.
3. The column shows the dependencies of the selected row.
4. The row shows the dependencies on the selected row.
5. This means that the maven-project module has 16 dependencies on maven-settings module.
6. Various shades correspond to the number of dependencies. The more dependencies there are the bluer the corresponding cell is.

And what about dashes and color annotations? This is quite obvious also.

1. Color annotations help to visualize row dependencies at a glance.
2. This green annotation means that maven-core depends on maven-project.
3. This yellow annotation means that maven-project depends on maven-profile.
4. The dashes on the diagonal correspond to self dependencies which are not shown.

Thus, when we select a row, green annotations show dependent modules, while the yellow ones show modules on which the selected module depends.
Dependency matrix becomes more convenient, if you remember one simple mnemonic rule – all dependencies always “flow” from Green to Yellow.
At this moment we’ve only selected one of the rows. Let’s select some cell to explore the dependencies indicated in it.



For example, cell #1 is one of interest. We’ve selected it, and again, we can see some color annotations. They mean that maven-project has 16 dependencies on maven-settings. The symmetrical cell (cell #2) shows dependencies in the other direction - in this case zero.

You might notice that instead of alphabetically sorting rows, DSM view sorts dependencies in a special way: classes, which are used most, are moved to the bottom. In a project with good structure this creates a triangular shape in the lower left half of the matrix.

Let’s drill down a little bit and expand some cell. For example, we want to take a closer look at dependencies between maven-core and maven-error-diagnostics. Corresponding cell is shown below.



We double click it to view the expanded dependencies.



If the project contains mutual dependencies, called cycles, we’ll simply detect them while exploring the DSM view.



Cyclic dependencies are shown in red. In our example, this means that the lifecycle and * are both dependent on each other, as well as plugin and usability.
Such dependencies require much more attention, and you may need to investigate them narrowly. Integrated advanced code navigation will help you to jump directly to the code which requires your attention. Just right-click the dependency and choose Find Usages for Dependencies on the context menu.



All usages will be shown in the corresponding tool window.

While exploring dependencies you may find that some part of your project deserves more attention and should be discovered in detail while the rest of the project is not of interest at the moment. In such case, you can limit the scope of your DSM to the selected rows, or dependencies.

Now, structure of any complex project, with thousands of Java classes, spreads out before your eyes.

Once again we’re happy to let you know that our productivity-focused IDE for Java Developers, IntelliJ IDEA has been listed as a 18th Annual Jolt Product Excellence Award finalist, in two categories: Web Development Tools and Development Environments.

We hope our efforts on creating the most productive and intelligent Java IDE will be appreciated, and IntelliJ IDEA will be one of the winners honored at a gala ceremony on March 5, 2008 in Santa Clara, California.

In forthcoming IntelliJ IDEA 6.0 release a new tool will be available. It aims to measure the code coverage for your unit tests or tests written as simple applications with the main() method. The engine that performs code coverage in IntelliJ IDEA is based on the EMMA open-source toolkit.

The feature as implemented by IntelliJ IDEA brings several technical innovations to the Java code coverage field.
The most important of them are:

1. On-the-fly code coverage execution with no classes pre scanning phase
   IntelliJ IDEA has no need in static classes instrumentation making use of instrumentation concept introduced in Java 5.0. Moreover, IntelliJ IDEA already knows the structure of your project, so it can calculate the package coverage statistics based not only on those classes that have been instrumented, but taking into account all compiled classes for the package. Essentially this brings lazy coverage calculation concept into action and ensures low run time overhead.
2. Correct coverage information displayed for files edited after coverage statistics has been gathered
   How is it possible? Well, again this is a result of a tight integration of coverage support with the rest of IntelliJ IDEA infrastructure. Here the result is obtained by collecting the information on the difference between the current file version and the one created at the moment coverage was run (taken from the local VCS).

To get the feeling of the code coverage, you just need to configure this feature and run your tests or applications. You can access this feature by selecting Run | Edit Configurations (or by pressing Shift + Alt + F10). The Run/Debug Configurations dialog appears where you can enable and configure the feature.



To run the coverage measuring, simply run or debug the configuration.
Whereupon, the statistics on the lines covered can be displayed in the Project View by selecting View-> Show Coverage Information or pressing Ctrl+Alt+F6 in the default keymap.



Also right in the editor you’ll see whether the lines were covered or not (they are marked green and red, respectively). The yellow mark indicates that the line was executed “partially”, for example, if only one condition from the if statement was checked.



The feature is already available in the latest EAP version. Join EAP now!