For a Great Time, Try These IDEA Project Tips

Most of these are IDEA specific, but a few concepts in here translate well to other IDEs, I suppose. A basic IntelliJ IDEA project consists of three files:

• myproj.ipr - this is the project file
• myproj.iml - a module file, you might have a bunch of these
• myproj.iws - a workspace file

Here are a handful of tips for managing these files.

New IDEA, New Format

People generally store their IDEA project and module files in the root directory of their project. Take a look at the Guice trunk directory. See the .iml and .ipr files?

As IDEA evolves from release to release, the project file format changes. So if you use the exact same version of IDEA as the Guice authors, you can use their project file. But if you happen to use an older version of IDEA, you probably won’t be able to use their project file. Or, if you open the files with a new (or beta) version of IDEA, the file might get upgraded to the new format.

I always store my project and module files in version-specific directories:

trunk
 |
 +--idea5
 |      .iml, .ipr files for IDEA 5
 +--idea6
 |      .iml, .ipr files for IDEA 6
 +--idea7
        .iml, .ipr files for IDEA 7

Easy, right? This lets different programmers collaborate on the same project without trampling each other’s project and module files.

Relative Paths

IDEA uses relative or absolute paths in both the project file and the module file(s). Modules default to relative paths, the project file defaults to absolute paths.

If you plan to share your project and module files, be sure to set BOTH the project AND module settings to relative paths. This is particularly critical in the directory structure shown above, because all of the paths need to include “../” due to the idea5, idea6, or idea7 directories.

Relative paths are important because different programmers use different directory structures on their computers. Furthermore, if you use Subversion (or other version control tools), your branches will be checked out to different directories. Having all relative paths in your IDEA project and module files means you can do a fresh checkout to any path and get to work right away.

CRLF Woes

I work on a team where some programmers use Linux, others use Windows. We found if a Linux user changes the project or module in any way, IDEA stores using “\n” line endings. If a Windows user modifies the files, IDEA stores the files using “\r\n”. Sigh. I wish IDEA would just store “\n” always.

To avoid this problem, configure your version control tool (CVS, Subversion, whatever) to always store these files using a particular line ending style. In Subversion, you simply set an attribute called

svn:eol-style

on these files. This avoids bogus diffs if your teammates use different operating systems.

Do Not Share *.iws

The .iws file is a workspace file. This contains programmer-specific preferences. Do not share this with other programmers, and DO NOT check this in to a version control repository. If you do, every programmer who opens the file in IDEA will modify it, and you’ll constantly be updating, merging, and resolving conflicts.

If the .iws file is not found, IDEA silently creates a new one for you, so there is no reason to share .iws files.

Avoid Ant Conflicts

I always configure my Ant buildfiles to produce output in a “build” directory. I configure IDEA to put its output in a different directory. It seems to cause problems when two different build systems compete for the same directory.

Ignores

Be sure to tell IDEA to exclude directories that are unrelated to compilation or runtime settings. If your Ant buildfile drops .class files in a directory independent of IDEA’s build directory, be sure to configure your module to exclude the Ant output directory. Otherwise every time you compile in Ant, IDEA will re-scan all of those Ant build artifacts. You should also exclude things like documentation directories, again for performance reasons.

Source Paths

Put your source code in a ’src’ directory of some sort. Configure that as a source path in IDEA. I’ve seen many programmers list OTHER directories as “source” directories as well. I don’t know why so many people do this, but it is not a good idea. For example, we generally have a resources directory that contains images and properties files that should be added to the CLASSPATH at runtime. The resources directory SHOULD be added to the CLASSPATH, but it SHOULD NOT be added as a “source” directory.

Adding non-source code as a source directory slows things down as IDEA scans those files, copies them to cache folders, etc.

I generally like several parallel source paths. I’ll have at least one for application code, and another for unit test sources. I like keeping XML, .properties, and image files in a separate resources folder.

Many people like to put these collateral files right in there with application source code, which I believe is a mistake. They must then add a source directory to the CLASSPATH (which is weird), or they must rely on Maven or Ant to COPY these collateral files to a build directory during the application build. Yuk, yuk, yuk! Having to copy these files around just leads to problems that are completely avoidable.

Be Careful with Plugins

Unfortunately, some plugins store programmer-specific settings in the .ipr file instead of the .iws file. This means if one programmer installs some plugin and commits the project file to the version control repository, other programmers on the team now see what are essentially bogus diffs (and potential conflicts) in the files.

I simply stopped using one plugin because of this behavior. Just something to look out for.

This entry was posted on Saturday, October 20th, 2007 at 4:44 pm and is filed under Java, Software Development. You can skip to the end and leave a response.