Hibernate 4 schema generation with Maven

Sunday, August 31, 2014 11:23:44 PM

While upgrading my blog software Cilla to Java 8 and Hibernate 4, I found out that the old hibernate3-maven-plugin refused to create schema.sql files. Well, it wasn’t really surprising. The name of the plugin already implied that the plugin won’t play with the next major release of Hibernate.

I could not spot an official update of the plugin. Instead, I found Kai Moritz new Hibernate 4 maven plugin, which turned out to be very useful.

One key feature is to set up and initialize a local database for unit testing. I don’t need this feature for Cilla (yet ;-)). All I need is a hbm2ddl style generation of a SQL schema file for setting up new instances of my blog software from scratch. It turned out that the plugin was easily configured that way, and so it got almost a drop-in replacement for the old plugin.

This is what the section of the project’s pom file looks like:

<plugin>
    <groupId>de.juplo</groupId>
    <artifactId>hibernate4-maven-plugin</artifactId>
    <version>1.0.4</version>
    <executions>
        <execution>
            <goals>
                <goal>export</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <hibernateDialect>org.hibernate.dialect.PostgreSQL82Dialect</hibernateDialect>
        <target>NONE</target>
        <type>CREATE</type>
    </configuration>
</plugin>

With the target set to NONE, the schema.sql file is quietly generated while building the project. If set to SCRIPT, a copy will be dumped to stdout.

A CREATE type only generates create statements of the database. The default is BOTH, which creates drop and create statements.

Since no actual database is created, there is no need to add user, password and url parameters.

A list of all configuration options can be found here. The plugin is available at Maven Central.

Written by Shred in Javano comments

Tags: English, Hibernate, Maven

Little Java Regex Cookbook

Saturday, August 30, 2014 12:23:47 PM

Regular expressions, or short “Regex”, are a pattern of characters and metacharacters that can be used for matching strings. For example, the pattern “gr[ae]y” matches both the strings “gray” and “grey”.

While regular expressions are an integral part of other popular languages, they have been introduced to the Java world quite late in 2002, with the release of Java 1.4. Perl, certainly the mother language of modern regexes, already turned 15 that year.

Regexes are sometimes hard to understand, but once you got the hang of them, they will soon become your weapon of choice when you have to deal with texts.

In this article, I focus on Java code patterns for common scenarios. If you have never heard of regular expressions before, the Wikipedia article and the Pattern JavaDoc are good starting points. The Regex Crossword site is a great place to practice your regex skills.

F20: SANE und trotzdem keinen Scanner?

Friday, January 31, 2014 12:02:43 AM

Falls sich mal jemand wundert, warum unter Fedora 20 der Scanner auf einmal nicht mehr gefunden wird:

sudo yum install sane-backends-drivers-scanners

löst das Problem. Das Paket wird aus irgendeinem Grund nicht automatisch mitinstalliert.

Written by Shred in Fedoradono comments

Tags: F20, SANE

How to feed DDMS with gpsbabel

Sunday, June 9, 2013 1:44:40 PM

The Android Device Monitor is not just an aid for debugging applications, but also allows to simulate GPS positions, so you won’t need to actually run around in the countryside for testing your GPS app. But where to get test data from?

I have recorded some of my hiking trips with my Garmin GPS 60, and saved them in Garmin’s proprietary gdb file format. These files contain waypoints, routes and also recorded tracks.

The Swiss Army Knife for GPS files, gpsbabel, comes in handy for converting a gdb file into the GPX file format that can be read by DDMS. This is the line I used for conversion:

gpsbabel -i gdb -f hike-track.gdb -o gpx,gpxver=1.1 -F hike-track.gpx

Note the gpxver=1.1 option, as DDMS is unable to read GPX 1.0 files.

After converting and loading the GPX file into DDMS, I can now send single waypoints as GPS events to the emulated device. But beyond that, I can also play back a recorded track, and simulate that I carry around the emulated device on that track. This is very useful for testing GPS apps.

Written by Shred in Androidno comments

Tags: English, GPS, debugging

Validating the Android 4.2.2 RSA fingerprint

Sunday, May 26, 2013 3:45:17 PM

Android 4.2.2 comes with a new security feature. If you try to connect to your smartphone via adb and USB debugging, you will note that your device is marked as “offline”. Additionally, a dialog shows up on your device, presenting an RSA fingerprint of your computer and asking for confirmation to accept a connection.

The rationale is that if your device is lost or stolen, there is no way to read its content even if USB debugging was enabled.

Now, presenting an RSA fingerprint surely is a nice idea to avoid man-in-the-middle attacks. But how do you get that fingerprint in order to compare it with the one shown on the device? At first I thought there must be a command (or an adb option) that prints out the fingerprint, but I wasn’t able to locate one. After spending some time with my favourite search engine, I finally dug up a rather more than less complicated command line that prints out the footprint:

awk '{print $1}' < adbkey.pub | openssl base64 -A -d -a | openssl md5 -c | \
awk '{print $2}' | tr '[:lower:]' '[:upper:]'

The command must be executed in the directory where adb stores the adb key, which usually is ~/.android (or /root/.android if adb runs as root).

If you are somewhat security paranoid, you surely wonder why, on the one hand, Google shows a footprint on the device, but on the other hand makes it difficult to find out if that footprint actually belongs to your computer.

Written by Shred in Android, Sicherheit1 comment

Tags: English, adb

maven-release-plugin and git fix

Thursday, May 2, 2013 11:57:34 PM

After hours of trying and wondering why my release scripts suddenly stopped working, I found out that maven-release-plugin seems to have an issue with git on recent systems. If you invoke mvn release:prepare and find out that the release process just runs against the current SNAPSHOT instead of the release version, you likely stumbled upon bug MRELEASE-812.

The reason for this issue seems to be that mvn release:prepare parses the output of git status. However the status is localized in recent versions of git, and maven-release-plugin fails to parse the localized output.

The coming fix will probably use git status --porcelain, which returns a machine-readable output. However, for the time being

LANG='en_US.UTF-8'
mvn release:prepare

is a valid workaround.

Written by Shred in Softwaretechnikno comments

Tags: English, git, maven

Fedora: SSD kurz und schmerzlos

Sunday, April 28, 2013 11:42:07 AM

Es gibt schon viele Artikel, wie man SSD-Festplatten richtig in Linux einbindet. Aber entweder sind sie unvollständig oder recht lange. Also, hier eine tl;dr-Fassung – SSD mit Fedora, kurz und schmerzlos.

Trimming

Wenn die SSD trimming kann (was mittlerweile bei allen SSDs auf dem Markt der Fall sein sollte), sollte es natürlich auch verwendet werden. Dadurch ermöglicht man wear levelling, gibt also der SSD die Möglichkeit, den Verschleiß der Speicherzellen zu verteilen.

In der /etc/fstab wird bei jedem Mountpoint, der auf eine SSD-Partition verweist, die Parameter discard angehängt. Eine gute Idee ist es außerdem, noatime hinzuzufügen, um die Schreibzugriffe auf die Platte zu reduzieren. Das sieht dann zum Beispiel so aus:

UUID=939446e3-9bb9-40a6-bf03-2d87bb8f5837 /                       ext4    discard,noatime        1 1
UUID=4f75261d-2e40-4e39-bf63-2a9c517fc73d /home                   ext4    discard,noatime        1 2
UUID=05db751b-5c2b-47da-8577-89ee30d90e56 swap                    swap    defaults        0 0

Das funktioniert mit reinen ext4-Partitionen, aber auch mit LVM- und RAID-Partitionen, jedoch nicht mit Partitionen, die mit LUKS verschlüsselt sind. Swap-Partitionen trimmen immer, ein discard-Parameter ist nicht erforderlich.

Nach einem Neustart sollte man einmalig alle SSD-Partitionen von Hand trimmen:

sudo fstrim -v /
sudo fstrim -v /home

I/O-Scheduler

Was bei mechanischen Festplatten wirklich Zeit kostet, ist das Positionieren des Schreib-Lesekopfes, weshalb Linux versucht, die Daten möglichst zu sammeln und zu gruppieren. Bei SSDs spielt es dagegen keine Rolle, wie fragmentiert die Daten sind. Aus dem Grund kann man das Gruppieren wegfallen lassen und sich über die gewonnene Performance freuen.

Dazu wird eine Datei /etc/udev/rules.d/40-ssd.rules mit folgendem Inhalt angelegt:

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

Beim nächsten Neustart verwenden SSD-Platten den noop-Scheduler, mechanische Festplatten weiterhin den für sie optimalen cfq.

Swappiness

SSDs können beliebig oft und schnell gelesen werden, verschleißen aber bei Schreibzugriffen. Swapping auf eine SSD-Partition ist zwar möglich, aber der Lebensdauer nicht sehr zuträglich. Folgende Zeilen in der /etc/sysctl.conf reduzieren das Auslagern auf die Swap-Partition auf ein Minimum.

vm.swappiness=1
vm.vfs_cache_pressure=50

Bei den heutigen Preisen selbst für üppige RAM-Ausstattung wäre es zumindest bei Desktop-Rechnern eine Überlegung wert, ob eine Swap-Partition überhaupt notwendig ist. Nachträglich kann eine Swap-Partition durch Auskommentieren der entsprechenden Zeile in der /etc/fstab deaktiviert werden.

Firefox-Cache

Firefox lagert seinen Cache in das Home-Verzeichnis aus, was eine zusätzliche Belastung für die SSD darstellt. Wer einen Rechner sein Eigen nennt, der mit üppig viel RAM gesegnet ist, kann auf das /tmp-Verzeichnis ausweichen, welches bei Fedora 18 im Arbeitsspeicher statt auf der Festplatte liegt. Das geht leider nur über einen Eingriff in die Eingeweide des Browsers über die URL about:config.

Nach einer Bestätigung, dass man sich benehmen wird, wird mit der rechten Maustaste über Neu - String ein neuer String-Eintrag angelegt. Der Eigenschaftsname lautet browser.cache.disk.parent_directory, der String-Wert /tmp.

Danach muss der Firefox noch neu gestartet werden.

Written by Shred in Fedoradono comments

Tags: Pimp My Fedora, SSD

Mausparameter verstellen, Gnome 3 Style

Thursday, April 25, 2013 12:38:45 AM


Da fehlt doch was!

Ist es ein Bug, oder ist es ein Feature des für Gnome-Entwickler typischen Aufräumwahns? Ich weiß es nicht. Aber ich war erstaunt, als ich in Gnome 3.6 die Mausbeschleunigung verstellen wollte und mich dort ein fast leerer Dialog angähnte.

Die Mausparameter können über das mittlerweile zum wohl wichtigsten (und wenig komfortablen) Gnome-Konfigurationstool dconf-editor eingestellt werden. Falls noch nicht geschehen, wird es über

sudo yum install dconf-editor

installiert. Nach dem Start klicken wir uns durch den Pfad org - gnome - settings-daemon - peripherals - mouse durch. Dort kann die Mausbeschleunigung über die Paramerer motion-acceleration (Standardwert “-1.0”) und motion-treshold (Standardwert -1) eingestellt werden.

Um die Mausbeschleunigung ganz auszuschalten, wird motion-acceleration auf 0 gestellt.

Written by Shred in Fedoradono comments

Tags: Gnome 3, dconf

Gnome 3 findet Nemo

Friday, April 19, 2013 12:59:00 AM

Weiter geht es mit Gnome 3. Die Gnome-Entwickler schreckten nicht davor zurück, dem Dateimananger Nautilus eine ordentliche Feature-Diät zu verpassen. Das Ergebnis ist eigentlich nur noch ein besserer Datei-Dialog. Weggefallen sind Features wie die Baumansicht eines Verzeichnisses oder die Verfügbarkeit einer zusätzlichen Leiste (Taste F3). Für Anfänger verzichtbar sicherlich, und auch zu schwer zu bedienen für die fast schon zwanghafte Fixiertheit der Gnome-Entwickler auf Touchscreens. Für intensivere Anwender sind die Features jedoch unverzichtbar. Das Durchsuchen stark verschachtelter Verzeichnisbäume ist nun zum Beispiel nicht mehr möglich, ohne in einer Flut von Nautilus-Fenstern zu ersaufen.

Die Änderungen wurden von der Community stark kritisiert. Die Cinnamon-Entwickler veröffentlichten als Reaktion darauf den Nautilus-Fork Nemo, der die Features weiterhin enthält. Mit folgendem Dreizeiler lässt sich Nemo auch unter Gnome 3 als Standard-Dateimanager einsetzen:

sudo yum install nemo
sudo mv /usr/bin/nautilus /usr/bin/nautilus.bak
sudo ln -s /usr/bin/nemo /usr/bin/nautilus

Die Lösung ist zwar nicht sehr elegant, aber arbeitet zuverlässig. Einen weniger invasiven Eingriff beschreibt Oliver Foster in einem Bug-Eintrag, allerdings führte das bei mir während der Arbeit zu einem bunten Nebeneinander von Nautilus- und Nemo-Fenstern auf dem Bildschirm.

Wenigstens dieses Mal hatten die Gnome-Entwickler übrigens teilweise ein Einsehen und haben die Baumansicht für Gnome 3.8 wieder eingebaut. Es besteht also die Aussicht, dass der hier beschriebene Workaround in Fedora 19 nicht mehr notwendig sein wird.

Written by Shred in Fedoradono comments

Tags: Cinnamon, F18, Gnome 3, Nautilus, Nemo

Fedora 18: Google Earth installieren

Wednesday, April 17, 2013 11:57:00 PM

Willkommen zurück zu neuen Fedora-Artikeln. Nach einem Ausflug zu Linux Mint bin ich wieder zu Fedora zurückgekehrt und beginne gleich mit einem Klassiker: der Installation von Google Earth auf Fedora 18. Der guten Tradition folgend hat sich Google auch diesmal eine Raffinesse ausgedacht, um uns die Installation nicht allzu leicht zu machen. Aber dazu gleich mehr...

Fangen wir erst einmal mit der obligatorischen Installation eines ganzen Magazins an 32 bit-Paketen an, die unbedingt benötigt werden:

sudo yum install redhat-lsb.i686 gtk2.i686 mesa-libGL.i686 libSM.i686

Besitzer einer Nvidia-Grafikkarte mit proprietärem Treiber benötigen außerdem noch die 32 bit-Version ebendieses Treibers:

sudo yum install xorg-x11-drv-nvidia-libs.i686

Als nächstes können wir das rpm-Paket von Google Earth herunterladen und installieren. Das Paket möchte das Verzeichnis /usr/bin anlegen, was rpm mit einer Fehlermeldung quittiert, da das Verzeichnis natürlich schon existiert. Also brauchen wir ein wenig Gewalt...

sudo rpm -ivh --force google-earth-stable_current_x86_64.rpm

Update: Der folgende Teil ist mit der aktuellen Version von Google Earth nicht mehr notwendig.

Und das war’s schon? Nein, jetzt kommt die eingangs erwähnte Raffinesse, denn an diesem Punkt stürzt Google Earth beim Starten sofort ab. Ohne den Artikel von ioncube wäre ich nie darauf gekommen, dass die Ursache an einer veralteten Library und einem Font liegt. Folgende Zeilen lösen das Problem auf recht pragmatische, aber wirksame Weise:

sudo rm /etc/fonts/conf.d/65-fonts-persian.conf
cd /opt/google/earth/free/
sudo mv libGLU.so.1 libGLU.so.1.bak
sudo ln -s /usr/lib/libGLU.so.1

Dann endlich startet Google Earth auch auf Fedora 18. War ja gar nicht so schwer, oder? ;-)