Blog

Vorsicht beim Filtern von Ressourcen mit Maven

Boudewijn van Klingeren

Aktualisiert Oktober 23, 2025
3 Minuten

In meinem aktuellen Projekt verwenden wir Maven 1.1 für die Erstellung von Build-Artefakten. Obwohl es heutzutage ein wenig veraltet ist, funktioniert es immer noch gut. Wie Maven 2 verfügt auch diese Version über die Möglichkeit, Ressourcen zu filtern (z.B. XML- oder Eigenschaftsdateien), um bestimmte Schlüsselwörter durch Werte zu ersetzen, die in Eigenschaftsdateien und/oder der Befehlszeile angegeben sind. Wir verwenden es aus verschiedenen Gründen und es funktioniert perfekt... wenn es richtig eingesetzt wird, versteht sich.

Nach einer normalen Aktualisierung aus SVN habe ich neulich versucht, das Projekt zu bauen. Alles lief gut, bis einer der Unit-Tests unerwartet mit der Meldung fehlschlug: "Ungültiges Byte 3 einer 3-Byte-UTF-8-Sequenz" beim Lesen einer XSD-Datei zur Validierung. Zur gleichen Zeit untersuchten ein paar Kollegen von mir einen seltsamen Bamboo-Build-Fehler bei einer Schriftartdatei, die wir in einer GUI-Komponente verwenden. Da ich nicht wusste, dass dies auf die gleiche Situation zurückzuführen sein könnte, begann ich, meinen UTF-Fehler zu untersuchen. Nach einigem Herumgoogeln fand ich heraus, dass es etwas mit der Kodierung der XSD-Datei zu tun haben könnte. Wir verwenden den Standard-XML-Parser des Systems, Apache Xerces, und wenn er eine XSD-Datei liest, liest er sie mit der im XML-Header angegebenen Kodierung. Die Kodierung war als UTF-8 angegeben und die normale Quelldatei war tatsächlich eine UTF-8-Datei. Also habe ich die Kodierung der Version, die in das Maven-Zielverzeichnis kopiert wurde, überprüft und sie war ANSI. Hmm, seltsam...Um es für den Zweck dieses Blogs kurz zu machen: Es schien, dass die Filterung der Ressourcen vor kurzem geändert wurde. Die folgende Ressourcenkonfiguration wurde für den fehlgeschlagenen Build verwendet:

        

  src/resources
  true

  **/*.properties
  **/*.xml

  src/resources
  true

  **/*.properties
  **/*.xml

  src/java

  **/*.properties

Diese Konfiguration bewirkt, dass die folgenden Aktionen durchgeführt werden. Zunächst werden alle Ressourcen mit den Erweiterungen '.properties' und '.xml' im Verzeichnis 'src/resources' in die Zielverzeichnisstruktur kopiert und gefiltert (der Inhalt wird überprüft und bei Bedarf ersetzt). Zweitens werden alle Ressourcen im Verzeichnis 'src/resources', die nicht die Erweiterungen '.properties' und '.xml' haben, in die Zielverzeichnisstruktur kopiert und gefiltert. Drittens werden alle '.properties'-Dateien im Verzeichnis 'src/java' kopiert.Der Fehler liegt hier in der zweiten Ressourcenkonfiguration. Die Filteroption hätte hier nicht vorhanden sein dürfen, da die Kombination aus der ersten und zweiten Ressourcenkonfiguration tatsächlich dazu führt, dass alle Ressourcen gefiltert werden, was nicht der Fall sein sollte. Nachdem Sie die Filteroption in der zweiten Ressourcenkonfiguration entfernt hatten, wurde der Build wieder einwandfrei ausgeführt. Das Lustige daran ist, dass nach dem Einchecken der Änderung auch der Bamboo-Build korrekt war. Meine Kollegen, die immer noch versuchten, den Fehler mit der Schriftart zu beheben, waren ebenso wie ich ziemlich erstaunt. Aus irgendeinem Grund hatte Maven die Dateien beim Filtern und Kopieren durcheinander gebracht. Ziemlich bizarr, wenn man bedenkt, dass die XSD-Datei, die meinen Fehler verursachte, kein Schlüsselwort enthielt, das ersetzt werden sollte, und dass die Schriftdatei, die den Bamboo-Fehler verursachte, binär war... Der Vollständigkeit halber hier die Lösung, die funktioniert hat (mit der notwendigen Dokumentation):

        
            

  src/resources
  true

  **/*.properties
  **/*.xml

            

  src/resources

  **/*.properties
  **/*.xml

  src/java

  **/*.properties

Verfasst von

Boudewijn van Klingeren

Contact

Let’s discuss how we can support your journey.