Project setup

I find it good to work in an environment where standard tasks are sufficiently automated. Having a good development environment from the start keeps your head free for the important work.

IDE

My IDE does a lot of the tasks that I do frequently during development: building, testing, running, debugging, profiling, documenting, that is integrated all pretty well. There are a number of good IDE’s for Java, the most popular ones seem to be Eclipse, NetBeans and IntelliJ IDEA. While I used to work mostly with Eclipse, I find myself working with NetBeans more and more. They are both pretty good, but for my personal needs, the overall quality and integration of the available plugins is simply higher on NetBeans.

Version control

Managing the project without a version control system is one of the things I would not even think doing anymore. It serves as a repository to store all changes to the files, and when working in a team, it provides mechanisms to keep the team members work in sync.

A few years back, when I was a consultant, I found some places who had a “human concurrent version system” or H-CVS. It supported a very simple locking mechanism that prevented two users to work at the same time. One developer simply told the other one that he was working on a particular file. Versioning was done by creating archives of the state every day. This of course only worked when the developers worked in the same office. Looking back at it, it sounds like editing source code with Microsoft Notepad. Well, I know several people who even do their editing with Notepad today, so I it is very likely that some form of “human version control system” still exists today.

I practically store all kinds of documents I create in a Subversion repository, it simply makes me sleep better: I can keep track of my changes and I have a central point for backups.

Maven

Once the project has grown to a certain size it becomes more and more difficult to keep an overview. In my opinion, it is a good idea to include code measurements from the start. I usually include these tools

  • Cobertura
  • PMD
  • JDepend
  • Checkstyle

Cobertura is a code coverage tool which measures which parts of your code are covered by test cases. While even a hundred percent coverage is often not desired, reasonable and even does not guarantee a bug-free system, it helps me finding the holes in my test cases. It should be mentioned that Maven includes a standard plugin for another coverage name Cenqua Clover. It seems like a good tool, but it locks you into a 30 day trial period. I don’t like this kind of things, to be fair, they seem to let OpenSource projects use their tool for free. For my purposes, Cobertura is great, I wished it had a project overview (LOC, NCLOC, number of files, packages, classes, methods) that EMMA or Clover do, though.

PMD is a tool for measuring “good coding practices”, in general it helps me spotting potential problems in the code, Checkstyle is similar, but has a focus on code formatting. They both complement each other pretty well.

JDepend measures dependencies between classes and packages and calculates some fancy numbers that are related to these inter-dependencies. This tool supports the developer to create highly cohesive and loosely coupled systems. One of the measurements I find most useful is the detection of cycles between packages.

It is of course possible to include these tools in an Ant build file, but it takes quite a bit of effort to integrate them and creating a consistent output report at the same time.

This is all covered by another great Java build tool: Maven 2. Given a minimal description of the project, it automates the build process and creates a consistent overview in form of a web site. In the past, I had used Maven 1. I hated it. Even though I could clearly see its usefulness, it simply felt clunky and patched together. When Maven 2 came out, I was even more disappointed at first – many of the plugins that I was used to on Maven 1 did not exist for quite a while. The situation has improved a lot since that time, working with Maven 2 “feels” a lot better.

Once the setup is in place, building is as simple as typing in a command or invoking it from within the IDE.

Some notes: While setting up my projects I found some issues with the Maven plugins that I resolved like this:

1. There seems to be a bug in the Cobertura-Reporting plugin, which is used from Maven by default. For some reason, it can not find the instrumention file. However, there is a workaround, simply specify an explicit version number

...
<reporting>
<plugins>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<!-- There is a bug in version 1.8, specify 2.0 -->
<version>2.0</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<configuration>
<targetJdk>1.5</targetJdk>
</configuration>
</plugin>
</plugins>
</reporting>

I use JDK 1.5/1.6 as my default development, Maven’s and its plugins default assume 1.4, so there need to be changes made to the pom.

For the Java compiler :

...
<build>
...
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
</plugins>
</build>

For the PMD plugin:

...
<reporting>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<configuration>
<targetJdk>1.5</targetJdk>
</configuration>
</plugin>
</plugins>
</reporting>

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: