- We used "convert-junit-assertions-to-assertj.sh" script to launch the automatic conversion.
 - The auto conversion of  assertEquals(<List>, <List>) was wrong.
 - assertThat(result.get("REGISTRATIONTIME")).isEqualTo(new Date(20)) in HandlingEventRepositoryTest.java (in the testSave method) throw an exception, because equals call isn't symmetric between java.util.Date and java.sql.Timestamp. AssertJ and Junit equality assertion doesn't call equals method in the same way. One invoke expected.equals(actual) and the other actual.equals(expected).

Use Spring's RMI Registry

Remove duplicate try/catch block

Upgrade Apache Commons Collections to v3.2.2

This resolves #11.

Version 3.2.1 has a CVSS 10.0 vulnerability. That's the worst kind of
vulnerability that exists. By merely existing on the classpath, this
library causes the Java serialization parser for the entire JVM process
to go from being a state machine to a turing machine. A turing machine
with an exec() function!

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8103
https://commons.apache.org/proper/commons-collections/security-reports.html
http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/

I think this might be a leftover from when `CarrierMovement` used to have five constructor parameters, and the test was passing null into different positions. Once refactored the statements ended up looking quite the same instead.

This reverts commit 1bc9c9ac72b55f490b9628628d2dbc2179a86909.

Fix maven build warnings:

 - set plugin versions
 - specify resource encoding

Refactored code to remove warnings

Bump Hibernate from 3 to 4.

Replaced deprecated JDBCTemplate.queryForInt