Use H2 for JBatch tests instead of Derby

so that we don't need to manage more dependencies

Author: marko-bekhta

.github/dependabot.yml

@@ -53,7 +53,6 @@ updates:
           - "com.puppycrawl.tools:*"
           # DB drivers:
           - "com.h2database:h2"
-          - "org.apache.derby:derby"
           - "org.postgresql:postgresql"
           - "org.mariadb.jdbc:mariadb-java-client"
           - "com.mysql:mysql-connector-j"
@@ -111,10 +110,6 @@ updates:
       # we don't want always want to get the latest Weld version:
       - dependency-name: "org.jboss.weld.se:*"
         update-types: ["version-update:semver-major"]
-      # Sticking to Derby 10.16 for now since later versions require JDK 21+, and we need to test with JDK 17.
-      # See https://db.apache.org/derby/derby_downloads.html
-      - dependency-name: "org.apache.derby:*"
-        update-types: [ "version-update:semver-major", "version-update:semver-minor" ]
       # Sticking to SLF4J 1.x for now since later versions require to upgrade providers
       # (Log4j, ... see https://www.slf4j.org/faq.html#changesInVersion200),
       # and also because we only need this dependency for AWS SDK,

build/parents/build/pom.xml

@@ -158,9 +158,6 @@
 
         <!-- >>> JDBC Drivers -->
         <version.com.h2database>2.3.232</version.com.h2database>
-        <!-- Sticking to Derby 10.16 for now since later versions require JDK 21+, and we need to test with JDK 17.
-             See https://db.apache.org/derby/derby_downloads.html -->
-        <version.org.apache.derby>10.16.1.1</version.org.apache.derby>
         <version.org.postgresql>42.7.7</version.org.postgresql>
         <version.org.mariadb.jdbc>3.5.3</version.org.mariadb.jdbc>
         <version.mysql.mysql-connector-j>9.3.0</version.mysql.mysql-connector-j>
@@ -879,11 +876,6 @@
                 <artifactId>h2</artifactId>
                 <version>${version.com.h2database}</version>
             </dependency>
-            <dependency>
-                <groupId>org.apache.derby</groupId>
-                <artifactId>derby</artifactId>
-                <version>${version.org.apache.derby}</version>
-            </dependency>
             <dependency>
                 <groupId>org.postgresql</groupId>
                 <artifactId>postgresql</artifactId>

pom.xml

@@ -209,7 +209,6 @@
         <!-- The lowest supported version of Java for applications using Hibernate Search -->
         <!-- Set statically, independently from the current JDK: we want our code to comply with this version -->
         <!-- Adjust the contributing guide when changing the release Java version -->
-        <!-- Once upgrading review the dependency list to see if any major versions can be updated e.g. Derby 10.17 requires JDK 21 (see dependabot config and comments in POMs). -->
         <java-version.main.release>17</java-version.main.release>
         <java-version.main.compiler.java_home>${java.home}</java-version.main.compiler.java_home>
         <java-version.main.compiler>${java-version.main.compiler.java_home}/bin/javac</java-version.main.compiler>

util/internal/integrationtest/jbatch-runtime/pom.xml

@@ -35,14 +35,14 @@
             <scope>compile</scope>
         </dependency>
         <!--
-            JBatch requires a database in order to work, and it seems it uses SQL that won't work with H2.
-            Anyway, it uses an embedded Derby instance by default, so we just put the Derby driver in the classpath
-            so it won't complain.
+            JBatch requires a database in order to work. Since we either need to use an embedded Derby or create the schema,
+            we want to keep the setup to a minimum and use only H2.
+            Derby is not used to keep the # of managed dependencies lower.
          -->
         <dependency>
-            <groupId>org.apache.derby</groupId>
-            <artifactId>derby</artifactId>
-            <version>${version.org.apache.derby}</version>
+            <groupId>com.h2database</groupId>
+            <artifactId>h2</artifactId>
+            <version>${version.com.h2database}</version>
             <scope>compile</scope>
         </dependency>
     </dependencies>

util/internal/integrationtest/jbatch-runtime/src/main/resources/META-INF/services/batch-config.properties

@@ -1,12 +1,16 @@
 # SPDX-License-Identifier: Apache-2.0
 # Copyright Red Hat Inc. and Hibernate Authors
 
-# Let JBatch use an embedded Derby database (the default),
-# since the SQL it generates doesn't seem to work on other DBs (H2 in particular)
+# Configure h2 in-memory database to be used with JBatch,
+# It requires the user and password to be passed via the following properties.
+# See com.ibm.jbatch.container.util.BatchContainerConstants for other property constants:
+DB_USER=sa
+DB_PWD=sa
 
-# However, we still customize the database location
-# (the default uses a "RUNTIMEDB" directory in the current working directory)
-JDBC_URL=jdbc:derby:memory:jbatch;create=true
+# Since we are not relying on the embedded Derby instance, we have to manually create the schema.
+# To do that, the init script is included in the JDBC url.
+# Schema scripts are adapted from the built-in Derby ones located in com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerSQLConstants
+# H2 Database Configuration
+JDBC_URL=jdbc:h2:mem:db1;INIT=RUNSCRIPT FROM 'classpath:/h2-batch-schema.sql';DB_CLOSE_DELAY=-1
 # Need to explicitly specify the driver class since the default ones points to `org.apache.derby.jdbc.EmbeddedDriver`
-# which is not there anymore since Derby 10.15
-JDBC_DRIVER=org.apache.derby.iapi.jdbc.AutoloadedDriver
+JDBC_DRIVER=org.h2.Driver

util/internal/integrationtest/jbatch-runtime/src/main/resources/h2-batch-schema.sql

@@ -0,0 +1,58 @@
+CREATE SCHEMA IF NOT EXISTS JBATCH;
+SET SCHEMA JBATCH;
+CREATE TABLE IF NOT EXISTS JOBINSTANCEDATA
+(
+    jobinstanceid BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1 INCREMENT BY 1) PRIMARY KEY,
+    name          VARCHAR(512),
+    apptag        VARCHAR(512)
+);
+CREATE TABLE IF NOT EXISTS EXECUTIONINSTANCEDATA
+(
+    jobexecid     BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1 INCREMENT BY 1) PRIMARY KEY,
+    jobinstanceid BIGINT,
+    createtime    TIMESTAMP,
+    starttime     TIMESTAMP,
+    endtime       TIMESTAMP,
+    updatetime    TIMESTAMP,
+    parameters    BLOB,
+    batchstatus   VARCHAR(512),
+    exitstatus    VARCHAR(512),
+    CONSTRAINT JOBINST_JOBEXEC_FK FOREIGN KEY (jobinstanceid) REFERENCES JOBINSTANCEDATA (jobinstanceid) ON DELETE CASCADE
+);
+CREATE TABLE IF NOT EXISTS STEPEXECUTIONINSTANCEDATA
+(
+    stepexecid       BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1 INCREMENT BY 1) PRIMARY KEY,
+    jobexecid        BIGINT,
+    batchstatus      VARCHAR(512),
+    exitstatus       VARCHAR(512),
+    stepname         VARCHAR(512),
+    readcount        INTEGER,
+    writecount       INTEGER,
+    commitcount      INTEGER,
+    rollbackcount    INTEGER,
+    readskipcount    INTEGER,
+    processskipcount INTEGER,
+    filtercount      INTEGER,
+    writeskipcount   INTEGER,
+    startTime        TIMESTAMP,
+    endTime          TIMESTAMP,
+    persistentData   BLOB,
+    CONSTRAINT JOBEXEC_STEPEXEC_FK FOREIGN KEY (jobexecid) REFERENCES EXECUTIONINSTANCEDATA (jobexecid) ON DELETE CASCADE
+);
+CREATE TABLE IF NOT EXISTS JOBSTATUS
+(
+    id  BIGINT PRIMARY KEY,
+    obj BLOB,
+    CONSTRAINT JOBSTATUS_JOBINST_FK FOREIGN KEY (id) REFERENCES JOBINSTANCEDATA (jobinstanceid) ON DELETE CASCADE
+);
+CREATE TABLE IF NOT EXISTS STEPSTATUS
+(
+    id  BIGINT PRIMARY KEY,
+    obj BLOB,
+    CONSTRAINT STEPSTATUS_STEPEXEC_FK FOREIGN KEY (id) REFERENCES STEPEXECUTIONINSTANCEDATA (stepexecid) ON DELETE CASCADE
+);
+CREATE TABLE IF NOT EXISTS CHECKPOINTDATA
+(
+    id  VARCHAR(512),
+    obj BLOB
+);