After updating to Yosemite, which updated Safari to version 8, autofill stopped working for localhost. After some searching, it appears that this is due new security rules for Safari and OS X. Of course, that didn’t stop me from trying to get this working again as it made developing on localhost very cumbersome. The fix is pretty simple.

All you need to do is edit your /etc/hosts file and add a fully-qualified domain name alias for 127.0.0.1. Here’s how mine looks:

127.0.0.1	localhost
255.255.255.255	broadcasthost
::1             localhost
127.0.0.1       cleanspeak.inversoft.com

I added the cleanspeak.inversoft.com entry. Now I can access localhost using this alias and Safari nicely does autofill on form fields.

A cool bit of CLI trickery that James Humphrey shared with me. This allows you to use IDEA for diffing and merging via git’s mergetool and difftool commands.

First, add IDEA to your path (everything is in Mac-speak here):

Bash

export INTELLIJ_HOME /Applications/IntelliJ IDEA 12.app/Contents/MacOS
PATH=$IDEA_HOME $PATH

Fish

set INTELLIJ_HOME /Applications/IntelliJ IDEA 12.app/Contents/MacOS
set PATH $INTELLIJ_HOME $PATH

Next, add these lines to your ~/.gitconfig file:

[merge]
   tool = intellij
[mergetool "intellij"]
   cmd = idea merge $(cd $(dirname "$LOCAL") && pwd)/$(basename "$LOCAL") $(cd $(dirname "$REMOTE") && pwd)/$(basename "$REMOTE") $(cd $(dirname "$BASE") && pwd)/$(basename "$BASE") $(cd $(dirname "$MERGED") && pwd)/$(basename "$MERGED")
   trustExitCode = true
[diff]
   tool = intellij
[difftool "intellij"]
   cmd = idea diff $(cd $(dirname "$LOCAL") && pwd)/$(basename "$LOCAL") $(cd $(dirname "$REMOTE") && pwd)/$(basename "$REMOTE")

That’s it. Now you can use IDEA to diff and merge from git CLI like this:

$ git mergetool
$ git difftool

I’ve found another annoyance with MyBatis (there are many so be on the lookout for a long blog post that covers everything). This one has to do with how MyBatis handles missing TypeHandlers and required a bit of time stepping through their code.

If you have an object that contains a field whose type is not registered with the TypeHandler registry, MyBatis does not always produce a nice exception for you. Instead, it sometimes decides to return null instead of creating your object.

Here is an example:

 // The domain object
 public class MyDateTimeHolder {
   public DateTime someJodaDateTime;
 }

I’m using Joda’s DateTime object here. If you don’t register this with MyBatis, it can cause this code to fail:

MyDateTimeHolder holder = holderMapper.retrieve();
// holder is null here!!!

The fix is to register the TypeHandler like this:

TransactionFactory transactionFactory = new JdbcTransactionFactory();
Environment environment = new Environment("development", transactionFactory, ds);
Configuration configuration = new Configuration(environment);
configuration.getTypeHandlerRegistry().register(DateTime.class, DateTimeTypeHandler.class);

If you are using MyBatis TypeHandlers in your Configuration, you need to register them BEFORE you add your Mapper instances. As it turns out, MyBatis proactively parses your XML and completely configures each mapper when it is registered. If you mapper XML uses results that need a TypeHandler, you must register those before hand.

Here’s some quick code:

configuration.getTypeHandlerRegistry().register(Locale.class, LocaleTypeHandler.class);
configuration.addMapper(SomeLocalMapper.class);

This works because the TypeHandler is registered before the mapper that requires it. This won’t work:

configuration.addMapper(SomeLocalMapper.class);
configuration.getTypeHandlerRegistry().register(Locale.class, LocaleTypeHandler.class); // FAIL!

Inversoft is hiring an outside software sales person. You can read the job description here: http://www.inversoft.com/jobs/outside-sales/. Email your resume to jobs@inversoft.com. Be sure to include key phrase #6 in your email: “IS + CS = happy customers”.

Inversoft has recently switched from Savant to Gradle until Savant 2.0 is finalized and can effectively rolled out (if this ever happens). Gradle is a decent temporary solution, but as a build tool junkie, it rubs me the wrong way. Here are some things that we encountered during the switch that Savant addresses.

Maven Central

We started by attempting to use Maven Central for our dependencies, but quickly realized that Maven Central is a complete mess. We also realized that it suffers from the “most surprise” pattern as well as “GPL” infestation. During our transition, we started to realize that using Maven Central actually caused our number of JARs to dramatically increase and for a couple of GPL JARs to sneak into our classpath.

In the end, we had to rever to managing our own repository and manage all of the ivy.xml dependency files by hand to ensure that everything was correct.

Transitive Mess

Gradle appears to suffer from the “let’s make it simple” methodology of Maven. In order to actually make life simple and avoid actual work, Maven pulls in the entire universe of your project dependencies for compiling and runtime. This means that even if you never import a class from a transitive dependency, Maven puts it in the classpath. This allows you to use classes from transitive dependencies. If you do this though, you’ll never actually know what JAR file a class comes from since it could come from some deeply nested dependency. It also tightly couples your project to your dependencies and those dependencies transitives. We prefer loose coupling rather than tight, so this is generally bad. We also like fewer dependencies at compile time rather than more. Again, bad news all around.

Flat Structure

Gradle plugins and domain are entirely flat. This makes it difficult to separate concerns and distinguish between Java compiling, testing and runtime. Maven actually got this right by cleaning separating concerns and separating plugins.

Configuration vs. tasks

Gradle build files can quickly become large and complex. It is often hard to distinguish between what is configuration and what are tasks.

Order matters

Order matters in Gradle build files unless you always use the String syntax for all configurations and tasks. If you have one task that depends on another task, the order of declaration matters. This is quite painful to debug and I thought we had finally grown out of single pass compiling. Apparently not.

No Versions

There are many pieces of Gradle that don’t like versions, e.g. plugins. These don’t have versions and just use the latest available. This is usually a bad idea because historical builds can break and you’ll never know what version you’ll be using when you execute a build.

MD5 and SHA1?

Why both?

Hashes not always used

The MD5 and SHA1 hashes aren’t always used. For example, the ivy.xml files don’t appear to use the hashes associated with that file. It really should use the hashes for everything.

UploadArchives doesn’t run the tests

WHAT?!?!?

Summary

Overall, I’m not a big fan of Gradle. It seems to be overly complex and sorta punts on dependency management. Having used Maven, Savant, Ant and Ivy, I would say that Savant 2.0 is still the best build system out there, even though it still isn’t finished.