Java-Bibliothek für den Zugriff auf die MediaWiki-API

Bibliotheken um die MediaWiki-API anzusteuern gibt es wie Sand am Meer. Bei soviel Auswahl fällt es natürlich schwer eine passende und funktionale Bibliothek zu finden. Für Java habe ich mittlerweile die Bibliothek JWBF (kurz für Java Wiki Bot Framework) für mich entdeckt. Die Bibliothek kann einfach per Maven eingebunden werden:

<dependency>
	<groupId>net.sourceforge</groupId>
	<artifactId>jwbf</artifactId>
	<version>3.1.1</version>
</dependency>

Anschließend kann eine MediaWiki-Seite ohne Probleme bezogen werden:

MediaWikiBot wikiBot = new MediaWikiBot("https://wiki.example.org/");
Article article = wikiBot.getArticle("Artikelname");
System.out.println(article.getText());

Auch das Anlegen von Artikeln ist kein Problem:

MediaWikiBot wikiBot = new MediaWikiBot("https://wiki.example.org/");

Article article = new Article(wikiBot, "Test");
article.addText("Lorem ipsum dolor sit amet.");

wikiBot.login("Nutzername", "Passwort");
article.save();

Der Quelltext der Bibliothek ist auf GitHub zu finden. Lizenziert ist die Bibliothek unter der Apache License in der Version 2.0 und damit freie Software.

Maven-Repository in Eigenregie hosten

Wenn mittels Maven eine Abhängigkeit zur pom.xml-Datei, wie in folgendem Beispiel, hinzugefügt wird:

<dependency>
	<groupId>org.slf4j</groupId>
	<artifactId>slf4j-api</artifactId>
	<version>1.7.26</version>
</dependency>

versucht Maven diese Abhängigkeit von Maven Central, dem zentralen Repository, zu beziehen. Es ist allerdings möglich Abhängigkeiten aus anderen Repositories zu beziehen. Dazu muss der repositories-Block zur pom.xml hinzugefügt werden.

<repositories>
	<repository>
		<id>example</id>
		<url>https://repository.example.org</url>
	</repository>
</repositories>

Aus Nutzersicht ist die Konfiguration von Maven damit erledigt. Soll ein solches Maven-Reposity aufgesetzt werden, ist dies relativ einfach möglich. Dazu wird ein Verzeichnis per HTTP über den Webserver Nginx ausgeliefert. Innerhalb dieses Verzeichnisses wird ein gesicherter Ordner erstellt, welcher über WebDAV erreicht werden kann. Die entsprechende Nginx-Konfiguration sieht für diesen Fall wie folgt aus:

server {
        listen   443 ssl;
        listen [::]:443 ssl;

        ssl_certificate /etc/letsencrypt/live/repository.example.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/repository.example.org/privkey.pem;

        root /var/www/example/repository;

        server_name repository.example.org;

        location / {
                autoindex     on;
        }

        location /upload {
                dav_methods     PUT DELETE MKCOL COPY MOVE;
                dav_ext_methods   PROPFIND OPTIONS;

                dav_access    user:rw group:rw all:rw;

                create_full_put_path  on;

                autoindex     on;

                auth_basic "restricted";
                auth_basic_user_file /var/www/example/repository/upload/.htpasswd;
        }
}

Die .htpasswd-Datei, welche für die Authentifizierung benötigt wird, kann mit dem Tool htpasswd erstellt werden:

htpasswd -c .htpasswd nutzer1

Bei der Nutzung wird das gewünschte Passwort erfragt. Soll ein weiterer Nutzer hinzugefügt werden, so muss der Parameter -c entfernt werden:

htpasswd .htpasswd nutzer2

Anschließend wird die Konfiguration von Nginx mittels:

service nginx reload

aktualisiert. Danach kann WebDAV für die Ressource verwendet werden. In der pom.xml-Datei für das Projekt, welches ein Artefakt für das Repository erzeugt, wird der build-Bereich erweitert und der distributionManagment-Bereich hinzugefügt:

            </plugin>
        </plugins>
        <extensions>
            <extension>
                <groupId>org.apache.maven.wagon</groupId>
                <artifactId>wagon-webdav-jackrabbit</artifactId>
                <version>3.2.0</version>
            </extension>
        </extensions>
    </build>
    <distributionManagement>
        <repository>
            <id>example</id>
            <url>dav:https://repository.example.org/upload/</url>
            <layout>default</layout>
        </repository>
    </distributionManagement>
</project>

Im Extension-Bereich wird das Wagon-Plugin für WebDAV aktiviert. Dieses sorgt dafür das die Artefakte per WebDAV zum Repository hochgeladen werden. In dem distributionManagment-Bereich wird die WebDAV-URL definiert. Wenn nun ein:

mvn deploy

durchgeführt wird, wird dies allerdings nicht funktionieren. Hintergrund ist das der upload-Ordner per Basic authentication geschützt ist. Die Zugangsdaten für diese Authentifikation müssen noch hinterlegt werden. Natürlich werden diese nicht in der pom.xml hinterlegt, da dies aus Gründen der Sicherheit keine gute Idee wäre. Stattdessen werden die Daten in der settings.xml hinterlegt. Diese befindet sich im Pfad:

~/.m2/settings.xml

In dieser Datei wird eine server-Sektion mit den Zugangsdaten hinzugefügt:

<settings>
	<servers>
		<server>
			<id>example</id>
			<username>example</username>
			<password>password</password>
		</server>
	</servers>
</settings>

Anschließend kann das Artefakt erfolgreich mittels:

mvn deploy

in das Repository hochgeladen werden. Problematisch ist das sich die Daten nur im upload-Verzeichnis und nicht im eigentlichen Verzeichnis des Repository liegen. Zur Lösung hierfür wird ein Cronjob, im Kontext des Nutzers www-data, angelegt:

sudo -u www-data crontab -e

Ziel des Cronjobs ist es die Daten aus dem upload-Verzeichnis regelmäßig in das eigentliche Verzeichnis des Repository zu kopieren:

*/5  *    * * *   cp /var/www/example/repository/upload/* /var/www/example/repository/ -r

Damit wird alle 5 Minuten der Inhalt des uploadVerzeichnisses in das Repository kopiert. Ein Verschieben kann leider nicht durchgeführt werden, da die Metadaten beim jeden Deployment von Maven eingelesen werden und erweitert werden. Hier könnten Optimierungen durchgeführt werden, so das alle Dateien bis auf die Metadaten verschoben werden. Soll ein nicht öffentliches Repository erstellt werden, kann auf den zusätzlichen upload-Ordner verzeichnet werden und das Hauptverzeichnis selber per WebDAV befüllt werden. So lange die Zugangsdaten für den Server in der settings.xml-Datei hinterlegt sind, können seitens Maven die entsprechenden Artefakte bezogen werden.

Ausführbare jar-Datei mittels Maven generieren

Für bestimmte Java-Projekte ist es durchaus praktisch als Ergebnis eine jar-Datei inklusive der benötigten Abhängigkeiten zu generieren. So kann das Projekt in Form einer einzelnen Datei unkompliziert ausgeliefert werden. Mittels Maven lässt sich dies relativ einfach bewerkstelligen. Dabei wird eine Basis-POM (pom.xml) benötigt, in welcher das Plugin maven-assembly-plugin konfiguriert wird:

<plugin>
	<artifactId>maven-assembly-plugin</artifactId>
	<version>3.1.0</version>
	<configuration>
		<archive>
			<manifest>
				<mainClass>com.example.webservice.Webservice</mainClass>
			</manifest>
		</archive>
		<descriptorRefs>
			<descriptorRef>jar-with-dependencies</descriptorRef>
		</descriptorRefs>
	</configuration>
</plugin>

Soll nach erfolgter Entwicklung die jar-Datei mit den Abhängigkeiten erzeugt werden, muss das Kommando:

mvn clean compile assembly:single

genutzt werden. Damit das Ganze auch beim gewöhnlichen:

mvn package

funktioniert, muss die pom.xml angepasst werden. Dabei wird zur Plugin-Definition ein executions-Block hinzugefügt, welcher dafür sorgt das dass Ziel single auch während der Phase package ausgeführt wird. Die komplette pom.xml sieht dann wie folgt aus:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>webservice</artifactId>
    <version>1.0.0</version>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    </properties>

    <dependencies>
        <dependency>
            <groupId>com.google.code.gson</groupId>
            <artifactId>gson</artifactId>
            <version>2.8.5</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.7.0</version>
                <configuration>
                    <source>8</source>
                    <target>8</target>
                </configuration>
            </plugin>
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <version>3.1.0</version>
                <configuration>
                    <archive>
                        <manifest>
                            <mainClass>com.example.webservice.Webservice</mainClass>
                        </manifest>
                    </archive>
                    <descriptorRefs>
                        <descriptorRef>jar-with-dependencies</descriptorRef>
                    </descriptorRefs>
                </configuration>
                <executions>
                    <execution>
                        <id>make-assembly</id>
                        <phase>package</phase>
                        <goals>
                            <goal>single</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

Alle im dependencies-Block verwendeten Abhängigkeiten, werden somit in die jar-Datei übernommen.

LoadingCache der Guava-Bibliothek nutzen

Für Java existiert eine Bibliothek mit dem Namen Guava. Diese, von Google entwickelte, Bibliothek bietet gewisse Basisfunktionalitäten, welche vom Java-Framework nicht abgedeckt werden. Eine dieser Funktionalitäten ist der LoadingCache. Bei diesem handelt es sich um einen Cache, welcher dazu genutzt werden kann die Ergebnisse zeitintensiver Operationen zwischenzuspeichern. Daneben verfügt er über die Informationen wie er die entsprechenden Daten bezogen werden. Um Guava zu nutzen muss die Bibliothek z.B. mittels Maven eingebunden werden. Dazu muss die pom.xml-Datei um eine Abhängigkeit erweitert werden:

<dependency>
	<groupId>com.google.guava</groupId>
	<artifactId>guava</artifactId>
	<version>27.0-jre</version>
</dependency>

Anschließend kann Guava in dem betreffenden Projekt genutzt werden. In diesem Beispiel soll der Cache dazu dienen Anfragen an einen Webservice zu cachen. Der Webservice liefert Daten zurück, welche in einem Objekt vom Typ BookData gespeichert werden:

class BookData {

	public final String title;
	public final String description;
	public final double price;

	public BookData(String title, String description, double price) {
		this.title = title;
		this.description = description;
		this.price = price;
	}
}

Innerhalb der Anwendung übernimmt die Methode getBookData die Aufgabe, diese Daten vom Webservice zu beziehen:

public BookData getBookData(String isbn) {
	return bookdataService.getData(isbn);
}

Der LoadingCache von Guava ist technisch betrachtet eine Map. Bei der Initialisierung ist dies ersichtlich:

LoadingCache<String, BookData> books = CacheBuilder.newBuilder()
		.maximumSize(1000)
		.expireAfterWrite(7, TimeUnit.DAYS)
		.build(
				new CacheLoader<String, BookData>() {
					public BookData load(String isbn) {
						return getBookData(isbn);
					}
				});

Beim Anlegen des Cache können unterschiedliche Parameter wie die maximale Größe, die Zeit ab der ein Eintrag erneuert wird und der CacheLoader definiert werden. Der CacheLoader implementiert die Methode load, welche die entsprechenden Daten vom Webservice bezieht. Nachdem der LoadingCache definiert ist, kann die Map normal genutzt werden:

BookData bookData = books.get("9783736889842");

Im Hintergrund wird der Wert, wenn vorhanden, aus dem Cache bezogen. Ist dies nicht der Fall wird stattdessen der CacheLoader genutzt, welcher in diesem Beispiel einen Request an den Webservice sendet und das Ergebnis wieder im Cache hinterlegt. Der LoadingCache selber beschränkt sich auf die Laufzeit der Applikation und wird nicht persistiert.

Tests bei Maven überspringen

Wenn man unter Maven mittels:

mvn package

mal schnell ein Paket bauen möchte ohne das dabei die komplette Testsuite eines Paketes ausgeführt wird, kann dies durch den Parameter:

-Dmaven.test.skip=true

erreichen. Alternativ kann der Parameter gekürzt werden:

-Dmaven.test.skip

Komplett würde das ganze dann so aussehen:

mvn package -Dmaven.test.skip