Configuring checkstyle in eclipse via the maven-eclipse-plugin

I like to keep my eclipse configuration files in a central place, so that I can change them more easily. Currently, I tend to have a build-resources Maven project around. Inside this, amongst other things, lies the checkstyle configuration for use during the Maven build. The build-resources project is then added as a build extension, so that the files are accessibly during the build.

For projects using this way of configuration, it is desirable to have the eventually created Eclipse project to be able to use the same configuration file. The following steps allow me to access the checkstyle configuration file, create a configuration for the Eclipse Checkstyle plugin, and have that set up automatically whenever i call mvn eclipse:eclipse.

Create a template configuration file for the Eclipse Checkstyle Plugin

Head over to the project's configuration in Eclipse. In the "Checkstyle" menu entry, switch to "Local Check Configurations". Here, create a "New" configuration with the following data:

Type:	Remote Configuration
Location:	jar:file:///[your local maven repo]/[path-to-build-resources-project]/build-resources-1.1.5.jar!/checkstyle/checkstyle-maven-config.xml

This configuration will access the build-resources project's jar file and select the proper file inside it. It uses Java's built-in jar-Protocol to access this file.

Use this configuration set with your Eclipse project. Configure any inclusions/exclusions or such as you like.

Configure eclipse:eclipse to use your configuration template

Now that we have our template, we must make sure it will be used whenever eclipse:eclipse is called. To do so, first copy the Eclipse Checkstyle configuration file (".checkstyle" in your project directory inside the Eclipse workspace) over into your build-resources project. I saved it to eclipse/checkstyle-config.xml. Now you can tell the maven-eclipse-plugin to copy over that file during the creation by addin this to your global maven parent pom:

<pluginManagement>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-eclipse-plugin</artifactId>
            <version>2.8</version>
            <configuration>
                <additionalConfig>
                    <file>
                        <name>.checkstyle</name>
                        <location>eclipse/checkstyle-config.xml</location>
                    </file>
                </additionalConfig> 
                <additionalProjectnatures>
                    <projectnature>
                        net.sf.eclipsecs.core.CheckstyleNature
                    </projectnature>
                </additionalProjectnatures>       
            </configuration>
        </plugin>
    </plugins>
</pluginManagement>

Since you have added the build-resources project as a build extension, its contents will be on the classpath. Hence, the location "eclipse/checkstyle-config.xml" will be copied to [project base dir]/.checkstyle and picked up by the Checkstyle Plugin. So from now on, every time you release a new version of your build-resources, all eclipse projects will automatically be updates to these changes as soon as the new build-resources version makes it to your local repository (i.e.: on the next run of maven).

All that's left to do is run mvn eclipse:eclipse and refresh/import the Eclipse project.

Note: I have not checked if the m2eclipse plugin will pick up the configuration too. I do not use it much for bigger projects, in my experience it slows down the builds, especially on projects with many modules. The eclipse:eclipse way gives me the best of two worlds: a clean eclipse projects without any Maven magic - and a console in which I can use Maven without eclipse getting confused.

Generating a Google Maps API Key for a Chrome Extension

Usage of the Google Maps JavaScript API requires you to generate a key for the domain you want to show maps in. This in itself is an easy process and no problem. But what to do when you use a chrome plugin and want to show a map in a page that is contained inside the plugin (for example the popup)?

The solution: you have to provide your chrome extension ID to the generator at and prepend http://, else it will be rejected for being an invalid URL.

For a chrome extension, the id can be seen by navigating to chrome://extensions with chrome. If in doubt outside of a chrome extension, a good way to decide what to enter is to follow google's advice and look at the host id by using JavaScript along the lines of

alert("url: "+window.location.host)

This gives you the host name to enter.

Upon entering a valid url, you will be shown several ways to include the Google Maps api into your web page.

Configuring Maven for Wicket 1.4.x

Note to self:

when using Wicket 1.4 and up together with Maven, the maven-compiler plugin must be configured to use source and target JDK 1.5 or higher. This is because of the Method MarkupContainer.add(Component...), which in JDK 1.4 (the maven-compiler plugin's standard) gets translated into MarkupContainer.add(Component[]).

To configure the plugin, add this to the project's pom.xml:

<build>
 <plugins>
  <plugin>
   <groupId>org.mortbay.jetty</groupId>
   <artifactId>maven-jetty-plugin</artifactId>
  </plugin>
  <plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-compiler-plugin</artifactId>
   <version>2.1</version>
   <configuration>
    <source>1.6</source>
    <target>1.6</target>
   </configuration>
  </plugin>
 </plugins>
</build>

Local configuration sets for Eclipse-based projects

Sometimes I find myself in the situation that I want to modify the configuration of a project that is connected to a revision control system, but don't want to commit those changes. A frequent example is wanting to run a wicket application in debug mode. This is something you don't want to check in, because the project should be kept in a deployment-ready condition inside the repository. On the other hand, I don't want my IDE to remind me constantly of that uncommitted change, since this obscures other changes. While there are RCSs that support this kind of local changes, SVN does not so readily. There is, however, a little method to hide the changes using the IDE, in this case, Eclipse:

Let's assume that the project uses a file called application.properties, which is found at the root level of the classpath at runtime. This is a fairly common setup. Using Eclipse, you can simply override these settings and hide the changes from svn. To do that, first add a new folder, called local-config. Inside, add a copy of application.properties. Edit as necessary.

To have Eclipse use this folder when running the software, insert it into the classpath as a class folder. Insert it before the original classpath:

This way, you can easily spot the difference of this folder to a normal source folder:

Using normal Java classpath behavior, the files in local-config will now be found earlier than the original properties file and be used instead.

To keep SVN from nagging you about checking it in, you can just add local-config to the svn:ignore property of the project's root folder. From now on you can change the configuration as you like and not have to check it in, while being able to spot any other changes with a quick glance at the project. Nothing magical, but useful when you don't want to start your software using Maven/Ant and resource filtering. Works for other kinds of resources too. Even for classes, although I wouldn't recommend using that too often - it tends to confuse.