Source code filtering with Maven

Today I searched for a Maven plugin that would filter some of my source files before compiling them. An equivalent to the resources plugin with filtering turned on, but for Java sources, that would replace occurences of, say, ${token.name} with somevalue wherever that string occurs in the source files.

I could not find such a plugin and I think I understand why. When the resources plugin processes the resources, it simply copies them from src/main/resources to target/classes, optionally filtering them. In the packaging phase, Maven simply zips up everything he finds in target/classes to the target jarfile.

But with source code you cannot simply copy the .java files to, say, target/generated after filtering them, and expect Maven to compile these filtered source files. You would have .java source files with the exact same name and same package declaration in src/main/java and in target/generated. So source file filtering cannot work in Maven unless you tell the compiler to change the directory from which to compile files. Well, I don’t have that much experience with Maven and I don’t know how to do that. I know the build-helper plugin can add a directory to the compile path, but I don’t know how to remove a directory from it.

On my project I needed to process only one single file. Let’s call it mypackage.Locator.java. I declared that class in a file named src/main/java/mypackage/_Locator.java (note the underscore). Then I configured an antrun task to copy that file over to target/generated/mypackage/Locator.java, a directory that build-helper had added to the compile path. I then told the compiler plugin to exclude all source files whose names begin with an underscore.

The most important parts of my pom.xml file look like this:

  <build>
    <plugins>

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <excludes>
            <exclude>**/_*.java</exclude>
          </excludes>
        </configuration>
      </plugin>

      <plugin>
        <artifactId>maven-antrun-plugin</artifactId>
        <executions>
          <execution>
            <id>generate-locator</id>
            <phase>process-sources</phase>
            <configuration>
              <tasks>
                <filter token="token.name" value="somevalue"/>
                <copy file="src/main/java/mypackage/_Locator.java"
                      tofile="target/generated/mypackage/Locator.java"
                      filtering="true"/>
              </tasks>
            </configuration>
            <goals>
              <goal>run</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

    </plugins>
  </build>

Note that you now let Ant filter the source files, so you must use Ant-like tokens (e.g. @token.name@). This works reasonably well, but if I can make some time for it I would really like to know how to remove the default source directory from the compile path.

Ubuntu fonts problem after reboot

My screen fonts under Ubuntu are occasionally completely screwed up. They show up in blue with overstrikes:

ubuntu-font
I think this happens when I reboot my machine without a second monitor being attached to it, which it usually has. I suppose X.org gets confused when it cannot find a monitor that used to be there.

To solve this problem you must reconfigure X.org. Just enter the following and log out and in again to your X session:

sudo dpkg-reconfigure xorg

Strongest chess program money can (not) buy

Kinda offtopic, but I’m also an avid chessplayer, so…

Crafty is recognized as one of the strongest open-source chess engines available, having once achieved a rating of 2792 on the internet chess server and having an estimated 2608 ELO rating. A default installation on Ubuntu 8.04 (e.g. aptitude install crafty and aptitude install crafty-books-medium) will pack firepower enough to plunge anyone of us mere mortals into despair as we see it effortlessly pondering the game 13 moves ahead. But it’s actually quite easy to push the envelope even more and take full advantage of your computer’s hardware. Here’s what I did to turn my Dell Latitude D830 into, basically, an unbeatable (by me) chess opponent that almost burned my lap.

There are three things we are going to give Crafty to make it stronger:

  • more memory for its transposition/refutation hash table
  • more memory for its pawn structure/king safety hash table
  • the second core of my Intel Centrino Duo processor.

My machine has about 2Gb RAM and we are going to use as much of that as we can for the transposition/refutation hash table, this being the most critical of the two. It can only be set to certain allowed values, and after some experimentation I found that the highest value I could give it before paging was 1536Mb. The pawn structure/king safety hash table gets the rest of my 2Gb RAM, or 128Mb.

Make sure you exit all (and I mean all) non-essential applications before you do this. I also had to stop my local MySQL and Apache servers to make this work without paging. You’ll also have to run the following command or Linux will not let you allocate that much memory:

sudo sh -c "echo 2000000000 > /proc/sys/kernel/shmmax"

How many threads to use on a multi-processor machine is set with the smpmt parameter, which I set to 2.

For reference, here is my complete .craftyrc file:

  hash=1536M
  hashp=128M
  smpmt=2
  exit

(And I’m not covering the almost 1Gb of openings database I have installed. I refer you to Crafty’s website on how to do that.)

You’re now all ready to start XBoard, and enjoy many fine chess games indeed. On the screenshot below you’ll see both crafty.bin processes share close to 1.6Gb RAM and how both cores jumped up to almost 100% usage. And just for fun, notice also how the CPU’s temperature climbed up to 64 celsius from an intial 44 celsius (it would later climb beyond 70 celsius). Don’t you just love it when a computer is used to its full potential instead of running screensavers?

crafty_pushed

Don’t unit test JavaBeans

Should unit tests cover JavaBeans just to get a higher code coverage?

These days I am working on a payment processing application that exposes its main interface as a SOAP web service. The API requires the client to build a wrapper object that packages the information needed for processing, for instance, a credit-card debit authorization: customer name and address, credit card number and so on.

I wrote the application code-first, and let the web service stack automatically generate the WSDL and other artefacts needed by the calling client software. From that WSDL and the generated XML schemas, the client can then generate the required Java supporting code to use the web service (almost) transparently.

This requires that I define those wrapper objects with a default no-args constructor, and that I define getters and setters for all its fields (the so-called JavaBean convention. Personally I dislike this kind of programming for a variety of reasons, but it was forced upon me by the web service stack.

When the time came to write unit tests, I actually had more time available than I had planned for, so I thought I should try to increase my test code coverage as much as possible. That led to several refactorings that overall helped the code’s testability, improved the test coverage, and probably improved the overall design.

But then I noticed that several of the wrapping objects’ get/setters had not been exercised by the test code. I first thought of writing unit tests for these classes, but then I realized how stupid that would be. Come one, writing unit tests for getters and setters?

A much better approach is to understand why the unit tests did not cover these methods in the first place. Upon investigating I discovered that I had not written unit tests that covered certain, very special logic branches&emdash;the very ones that needed those unexercised get/setters.

I duly wrote unit tests for these special cases, and after a few more minutes like this my test code coverage reached more than 80%, or twice what it was when I started out.

Lessons learned:

  • Write unit tests. Always.
  • Do not unit test JavaBeans. Unit test the methods that use the JavaBean methods instead.
  • Monitor your test code coverage. Tools such as Cobertura make this trivial.
  • Improve your test code coverage through relentless refactoring. Not only will your coverage improve, but so will probably your design.
Reblog this post [with Zemanta]

Trends in Smart Buildings Meeting, March 2009

Several home automation enthusiasts met again at LESO-PB to discuss recent developments in the field. There were four of us this time, Adil, Friedrich, David and yours truly.

20090323_3328

Friedrich openened the discussion by telling us about his ongoing work on the influence of light, especially its color, on human health. Early results suggest that proper daylighting control will not only help us save oodles of energy but will actually make us healthier. For more details we will, however, have to wait for his thesis to be complete.

Adil showed us his recent work on the large-scale physical modeling of cities. He showed us how, from publicly available data (including data from Google Earth) one could derive a fairly realistic model of a city’s impact on its environment.

He told us also that he was considering analyzing shadows on pictures from Google Earth to derive 3D models of entire cities. This idea has great potential, provided he finds a way around Google’s tendency to stitch together satellite images taken at different times of the day.

Google Escher

We also discussed the recently announced Google Powermeter project, whereby Google aggregates measurements remotely taken on your utility meters and presents the information to you. We were all amazed that Google managed to pull this one off (and frankly we have no idea how they do it) but some of us also expressed concern about privacy issues. How long will it be until we start getting email telling us that “People taking their baths while watching TV usually buy this-or-that book. Click here to buy it now” ?

20090323_3329

And finally the evening concluded with me asking the assembly for advice on some building simulation software issues I had been having lately. Friedrich, in particular, suggested I tried solving the problem in Fourier space instead of time space, something I would indeed never have thought about. I’ll definitely have a look and see if this could help for my open-source Heartbreak building simulation project.

Reblog this post [with Zemanta]