Uncategorized

Introducing: molindo-mysql-collations-lib

Let me introduce one of our numerous unknown Open Source Java libraries on GitHubmolindo-mysql-collations-lib. It really is small with a single public Java class: a Comparator for Strings with the behavior of (most) MySQL collations.

The JDK already provids a decent collation library with java.text.Collator and an even better one is available with icu4j, so why bother? Well, sometimes you simply want your application and your database (a MySQL database that is) to have consistent sort order and equality. If you write heavily database-centric applications like our very own molindo-dbcopy, it’s mandatory.

As there is no Java collation 100% consistent with MySQL, we’ve decided to go for JNI. No, really. My C programming is pretty rusted, but somehow I’ve got it done. Basically, we use libmysqlclient.so and the method strnncollsp(..) defined in m_ctype.h (documentation can be found in string/CHARSET_INFO.txt of MySQL’s source distribution). Basically, it’s the trailing space ignoring equivalent of strnncoll(..) which “compares two strings according to the given collation”. As simple as that. Why no trailing spaces? Well, “all MySQL collations are of type PADSPACE. This means that all CHAR, VARCHAR, and TEXT values in MySQL are compared without regard to any trailing spaces” (see docs).

The library performs fairly well but requires some more testing. It’s available from Maven Central and comes with a pre-compiled library for Ubuntu amd64 that requires libmysqlclient. You can however tweak build.sh to your needs if you are on another operating system.

<dependency>
<groupId>at.molindo</groupId>
<artifactId>molindo-mysql-collations-lib</artifactId>
<version>0.1.0</version>
</dependency>


Upgrade from Maven 2 to Maven 3 and property substitutions

I just ran across a problem after upgrading from Maven 2 to Maven 3. It seemed as if one of our properties, which we defined like this in the pom.xml of the parent project

1
<foobar.prop>barfoo.value</foobar.prop>

wouldn’t be replaced in the child pom. Our directory lineout was:

Screen Shot 2013-07-16 at 11.44.01

The resulting error message was:

1
'dependencyManagement.dependencies.dependency.groupId' for ${foobar.prop}:foobar:jar with value '${foobar.prop}' does not match a valid id pattern.

The problem lies in the way Maven 3 handles the path to the parent pom. The file child-of-child/pom.xml referenced its parent like this:

<parent>
	<groupId>at.molindo.pom</groupId>
	<artifactId>child-of-parent</artifactId>
	<version>1.0</version>	
</parent>

There’s the new behaviour that Maven 3 brought into place. Maven 2 tried to look for the pom.xml of child-of-parent in the reactor of currently building processes first. Whereas Maven 3 doesn’t look there at all, but relies on an explicit path first, before looking into the local repository.

Therefore the solution was to add the path:

<parent>
	<groupId>at.molindo.pom</groupId>
	<artifactId>child-of-parent</artifactId>
	<version>1.0</version>
	<relativePath>../child-of-parent/pom.xml</relativePath>
</parent>

There you go.