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.