2022.06

Migration MyCoRe LTS 2021.06 nach 2022.06

Diese Seite fasst Systemanforderungen für die Nutzung des MyCoRe LTS 2022.06 und die Migration von Version 2021.06 zu 2022.06 zusammen.

Systemanforderungen MyCoRe LTS 2022.06

Für den Betrieb einer MyCoRe-Anwendung unter LTS 2022.06 sind folgende Voraussetzungen zu erfüllen:

Betriebssystem

MyCoRe LTS 2022 ist auf diesen Betriebsystemen im Einsatz. Höhere Versionen sollten kein Problem darstellen.

Open SuSE Leap 15.4 oder höher
SuSE SLES 15.4 oder höher
Ubuntu 20.04 LTS
CentOS 8
RHEL 8
Windows 10 für Test- und Entwicklungssysteme

Standardsoftware

Zur Arbeit mit MyCoRe LTS 2022 sind folgende Softwarekomponenten erforderlich bzw. empfohlen. Diese sind alle von Drittanbietern und im Normalfall in den Distributionen enthalten.

Java 17 (OpenJDK) (muss ggf. extern nachinstalliert werden)
Tomcat 10.0.x bzw. Jetty 11.x (alternativ ein System mit Unterstützung von Servlet-5.0 und JakartaEE)
SOLR 8.11.2 oder höher
eine hibernate-fähige relationale Datenbank wie PostgreSQL 10 oder höher , MySQL/Maria-DB 10 oder höher, DB2; für Testzwecke genügt auch die integrierte Datenbank H2
Git 2.26 oder höher
Apache Maven 3.6.3 oder höher

Neuerungen

Java17-Kompatibilität / JakartaEE – Umstellung
MyCoRe BOM
RESTAPIv2: ObjectListing
Update-Kommando für Datenbank-Konfiguration
Stabile Sortierung von Klassifikationslabeln
Erweiterung der Service-Metadaten
Standard XSLT-Prozessor ist konfigurierbar / XSLT3 ist Standard
Neue MODS Version 3.8
Erweiterung des Factbased Access Systems
CSL Verbesserungen (Citation Style Language)
Datenimport via pica2MODS
Integration von OCFL
Support für einen S3-Store als Backend
RestAPI v2: Bearbeiten von Derivaten
SKOS (Linked Data) für Klassifikationen
Für Alto-Dateien sind nun auch Attribute im Volltextindex enthalten.
MyCoRe-PI unterstützt die ePIC-API
Kommando um Zyklen zu finden und zu beheben

aus dem Code entfernt

IFS1
MCRTraceListener

Migrationsschritte

Aktuelle Versionsnummer

Viel Anwender nutzen nicht die über Maven Central bereitgestellten Releases sondern möchten von den eingearbeiteten Bugfixes der Entwickler profitieren. Hierfür muss das Nexus Repository mit den bereitgestellten SNAPSHOTS eingebunden werden. Für Release 2022 kann folgende Version genutzt werden:

1
2
3
4
5


 <dependency>
   <groupId>org.mycore</groupId>
   <artifactId>...</artifactId>
   <version>2022.06.1-SNAPSHOT</version>
 </dependency>

Umbenenung J2EE -> Jakarta EE

In den eigenen Java-Klassen muss die Import-Definition von javax.** zu jakarta.* wegen der Nutzung von Java 17 LTS /Jakarta EE umgestellt werden.

Jakarta EE 9 implementiert den Servlet 5.0 Standard. Somit ist Tomcat 10.0.x bzw. Jetty 11.x einzusetzen. Achtung Tomcat 10.1.x nutzt Servlet 6.0 und ist für MyCoRe 2022.06 nicht getestet!

Ggf. muss die Dependency in den pom.xml-Dateien aktualisiert werden.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


 <dependency>
  <groupId>jakarta.servlet</groupId>
  <artifactId>jakarta.servlet-api</artifactId>
  <version>5.0.0</version>
  <scope>provided</scope>
</dependency>
<dependency>
  <groupId>jakarta.xml.bind</groupId>
  <artifactId>jakarta.xml.bind-api</artifactId>
  <version>3.0.1</version>
</dependency>

In den Files web.xml bzw. web-fragment.xml muss ggf. auf jakarta umgestellt werden.

1
2
3


<web-fragment version="5.0" xmlns="https://jakarta.ee/xml/ns/jakartaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-fragment_5_0.xsd"
    metadata-complete="true" >

MyCoRe BOM

MyCoRe liefert jetzt auch ein BOM Bill of Material aus, die in MyCoRe-Anwendungen /-Bibliotheken für das Dependency-Management nachgenutzt werden kann. Damit wird die Parent-pom.xml auf gesplittet in einen Teil, welcher nur noch die Versionsnummern enthält. Die folgende Dependeny kann in den eigenen Anwendungen nachgenutzt werden.

1
2
3
4
5
6
7


<dependency>
  <groupId>org.mycore</groupId>
  <artifactId>mycore-bom</artifactId>
  <version>2022.06.1-SNAPSHOT</version>
  <type>pom</type>
  <scope>import</scope>
</dependency>

`persistence.xml` Konfiguration anpassen

Werden MyCoRe-Module nicht genutzt (z. B. mycore-pi), so müssen die entsprechenden Konfigurationen mapping-file aus der persistence.xml entfernt werden, da es sonst zu einer Ausnahme kommt. Gleiches gilt für das Paket mycore-ifs. Mit dem CLI-Kommando reload mappings in jpa configuration file kann ein Update der Konfiguration online erfolgen.

XSLT3

Mit LTS 2022 ist XSLT3 jetzt die Standardeinstellung für die Transformer. Soll komplett auf XSLT1 zurück geschaltet werden, so geht dies über das folgende Property. Details zur Migration von XSLT1 zu XSLT3 und entsprechende Anpassungsschritte sind in der Migrationsanleitung für XSLT3 zu finden.

  MCR.LayoutService.TransformerFactoryClass=org.apache.xalan.processor.TransformerFactoryImpl

Neue Tabelle für Objekt-Historie (REST-API v2)

Damit ein performantes Objekt-Listing via REST-API v2 umgesetzt werden kann, wurde eine neue Tabelle eingeführt. Diese wird automatisch beim Start von MyCoRe mit der neuen Version angelegt, wenn in der persistence.xml ein Update der Datenbank erlaubt ist

  <property name="hibernate.hbm2ddl.auto" value="update" />

Damit die Datenbank nun auch befüllt wird, muss das folgende (Web-)CLI-Kommando aus der neuen CLI-Kommandogruppe "Object Info Commands" einmalig aufgerufen werden:

  create all objectinfo

Weitere Anpassungen

Soll mit dem Umstieg OCFL genutz werden, so ist die Anleitung für den Umstieg zu beachten.
Mit Java 17 funktioniert die Ant XMLTask nicht mehr. Ggf. könnten die Teile im Ant-build.xml durch die Funktion replace ersetzt werden.

Details zur Migration von MIR-Anwendungen und entsprechende Anpassungsschritte sind in der Migrationsanleitung für MIR zu finden.

Export-Kommandos

Es wurden Export-Kommandos für Objekte mit Content-Transformern hinzugefügt. In diesem Zusammenhang wurden die bestehenden Kommandos angepasst.

Bisher gab es die folgenden Export-Komandos:

1
2
3
4
5
6
7
8


export object {0} to directory {1} with {2}
export object from {0} to {1} to directory {2} with {3}
export all objects of type {0} to directory {1} with {2}
export all objects of base {0} to directory {1} with {2}
export derivate {0} to directory {1} with {2}
export derivate from {0} to {1} to directory {2} with {3}
export all derivates to directory {0} with {1}
export all derivates of project {0} to directory {1} with {2}

Nun gibt es die folgenden Export-Komandos:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


export object {0} to directory {1} with stylesheet {2}
export object {0} to directory {1} with transformer {2}
export objects from {0} to {1} to directory {2} with stylesheet {3}
export objects from {0} to {1} to directory {2} with transformer {3}
export all objects of type {0} to directory {1} with stylesheet {2}
export all objects of base {0} to directory {1} with stylesheet {2}
export derivate {0} to directory {1} with stylesheet {2}
export derivates from {0} to {1} to directory {2} with stylesheet {3}
export all derivates to directory {0} with stylesheet {1}
export all derivates of project {0} to directory {1} with stylesheet {2}

Für die Auswahl eines Stylesheets wurde die folgenden Angleichungen vorgenommen:

Bisher:

Bei Objekt-Kommandos wurde die Angabe in der Klausel with {x} zu {x}-object.xsl erweitert. Der Standardwert war xsl/save.
Bei Derivat-Kommandos wurde die Angabe in der Klausel with {x} zu {x}-derivate.xsl erweitert. Der Standardwert war xsl/save.

Nun:

Bei Objekt-Kommandos wird die Angabe in der Klausel with stylesheet {x} der Pfad zum Stylesheet angegeben. Der Standardwert ist xsl/save-object.xsl.
Bei Derivat-Kommandos wird die Angabe in der Klausel with stylesheet {x} der Pfad zum Stylesheet angegeben. Der Standardwert ist xsl/save-derivate.xsl.