JBeret is an implementation of Jakarta Batch. It is also included in WildFly, the new and improved JBoss Application Server to provide portable batch processing support in Jakarta EE environment.

Build JBeret

To build and run default set of tests:

mvn install

Some tests require additional steps and thus are not included in the default run. For instance, MongoDB-related tests need to start MongoDB first. To build and run all tests:

# start MongoDB database
mongod

# build JBeret, activate allTests maven profile to run all tests
mvn install -DallTests

Some tests involves very large data set (e.g., over 1 million rows of CSV or Excel data), and may cause memory errors in some machines:

OutOfMemoryError: unable to create new native thread

Increase ulimit to avoid such errors. For example,

ulimit -u 2048add

JBeret Modules:

• jberet-core: core batch runtime engine
• jberet-se: impl classes specific to Java SE runtime environment
• jberet-support: a collection of reusable batch readers and writers (e.g., CSV, fixed length, Excel, Json, XML, Mongo, JDBC, JMS, HornetQ, PDF, etc) for batch applications, and JNDI support
• jberet-rest-api: REST API for batch job management
• jberet-ui: front-end UI web app for batch job management
• jberet-se-bom: a maven BOM to encapsulate all the dependencies required by JBeret Java SE.
• test-apps: test applications
• tck-porting-impl: support running Jakarta Batch TCK with JBeret in Java SE
• wildfly-jberet-samples: Sample batch processing apps that can be deployed to WildFly or JBoss EAP 7
• quarkus-jberet: The Quarkus JBeret Extension adds support for Jakarta Batch applications

3rd-party & Community Extensions:

• JBoss Tools for Batch (Eclipse extensions, Wizards, Visual editing, etc)
• jberet-eap6
• jberetweb, job repository viewer

Project Resources:

• JBeret Issues & Bugs, Issues Awaiting Volunteers
• JBeret Documentation
• JBoss EAP Quickstarts for Batch Processing
• JBeret-dev Mailing List
• WildFly Forum
• JBeret Forum
• JBoss Batch API project
• Jakarta Batch Expert Group Discussion
• Download JBeret jars and distro zip from JBoss.org nexus

Batch sample & test applications:

• https://github.com/jberet/jberet-wildfly-samples, web apps that demonstrate the following:
  • JsonItemReader, JsonItemWriter
  • CsvItemReader, CsvItemWriter
  • XmlItemReader, XmlItemWriter
  • MongoItemReader, MongoItemWriter
  • JNDI lookup of Jackson JsonFactory, MappingJsonFactory & XmlFactory in WildFly for batch reader and writer
  • JNDI lookup of MongoClient in WildFly
  • job xml files showing the use of various reader/writer configuration properties
  • jberet-support module can be installed in WildFly and referenced by multiple apps via either MANIFEST.MF or jboss-deployment-structure.xml
• https://github.com/jberet/jsr352/tree/main/test-apps
  • test apps running in Java SE environment to verify core batch requirements
  • test apps running in Java SE environment to verify additional JBeret features (inheritance, scripting support, infinispan job repository, etc)

org.jberet artifacts may be retrieved from Maven Central or JBoss Public Repository

<repositories>
    <repository>
        <id>jboss-public-repository-group</id>
        <name>JBoss Public Repository Group</name>
        <url>https://repository.jboss.org/nexus/content/groups/public/</url>
    </repository>
</repositories>
...
<dependencies>
        <dependency>
            <groupId>jakarta.batch</groupId>
            <artifactId>jakarta.batch-api</artifactId>
            <version>${version.jakarta.batch.batch-api}</version>
            <scope>provided</scope>
        </dependency>

    <dependency>
        <groupId>org.jberet</groupId>
        <artifactId>jberet-core</artifactId>
        <version>1.0.2.Final</version> <!-- replace it with the desired version -->
    </dependency>
    <dependency>
        <groupId>org.jberet</groupId>
        <artifactId>jberet-support</artifactId>
        <version>1.0.2.Final</version> <!-- replace it with the desired version -->
    </dependency>

Batch application dependencies

Minimal application dependencies:

    <dependency>
            <groupId>jakarta.batch</groupId>
            <artifactId>jakarta.batch-api</artifactId>
        </dependency>
    <dependency>
        <groupId>javax.inject</groupId>
        <artifactId>javax.inject</artifactId>
    </dependency>
    <dependency>
        <groupId>javax.enterprise</groupId>
        <artifactId>cdi-api</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.spec.javax.transaction</groupId>
        <artifactId>jboss-transaction-api_1.2_spec</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jberet</groupId>
        <artifactId>jberet-core</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.marshalling</groupId>
        <artifactId>jboss-marshalling</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.logging</groupId>
        <artifactId>jboss-logging</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.weld</groupId>
        <artifactId>weld-core</artifactId>
    </dependency>
    <dependency>
        <groupId>org.wildfly.security</groupId>
        <artifactId>wildfly-security-manager</artifactId>
    </dependency>
    <dependency>
        <groupId>com.google.guava</groupId>
        <artifactId>guava</artifactId>
    </dependency>

A note on webapp or Jakarta EE application packaging: Jakarta EE API jars are already available in the appserver, and should not be included in WAR, JAR, or EAR files. Their maven dependency scope should be set to provided. In addition, if the application is deployed to JBoss EAP or WildFly, almost all of the above dependencies are already available as JBoss modules, and should not be duplicated in application package.

maven BOM dependency used to encapsulate all the dependencies required by JBeret Java SE.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.jberet</groupId>
            <artifactId>jberet-se-bom</artifactId>
            <version>2.1.2.Final-SNAPSHOT</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

The following is also required for Java SE batch applications (h2 can be omitted when using in-memory batch job repository):

    <dependency>
        <groupId>org.jberet</groupId>
        <artifactId>jberet-se</artifactId>
    </dependency>
    <dependency>
        <groupId>org.jboss.weld.se</groupId>
        <artifactId>weld-se</artifactId>
    </dependency>
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
    </dependency>

Optional application dependencies depending on application usage:

    <!-- any JDBC driver jars, e.g., h2, when using jdbc batch job repository -->
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
    </dependency>

     <!-- infinispan and jgroups jars, when infinispan job repository is used.
          Additional infinispan cachestore jars (e.g., infinispan-cachestore-jdbc, infinispan-cachestore-mongodb,
          infinispan-cachestore-leveldb, infinispan-cachestore-rest, infinispan-cachestore-cassandra, etc) may be
          needed if such a cachestore is used. -->
     <dependency>
         <groupId>org.infinispan</groupId>
         <artifactId>infinispan-core</artifactId>
     </dependency>
     <dependency>
         <groupId>org.infinispan</groupId>
         <artifactId>infinispan-commons</artifactId>
     </dependency>
     <dependency>
         <groupId>org.jgroups</groupId>
         <artifactId>jgroups</artifactId>
     </dependency>

     <!-- MongoDB jars, when MongoDB job repository is used -->
     <dependency>
         <groupId>org.mongodb</groupId>
         <artifactId>mongo-java-driver</artifactId>
         <version>${version.org.mongodb.mongo-java-driver}</version>
         <scope>provided</scope>
     </dependency>

    <!-- replace Java built-in StAX provider with aalto-xml or woodstox
         (woodstox dependencies not shown here)
    -->
    <dependency>
        <groupId>com.fasterxml</groupId>
        <artifactId>aalto-xml</artifactId>
    </dependency>
    <dependency>
        <groupId>org.codehaus.woodstox</groupId>
        <artifactId>stax2-api</artifactId>
    </dependency>

    <!-- jberet-support includes common reusable batch ItemReader & ItemWriter classes for
         various data types such as CSV, XML, JSON, Fixed length, Excel, MongoDB, JDBC, JMS, HornetQ, etc.
         The application should further provide appropriate transitive dependencies from
         jberet-support, depending on its usage.
    -->
    <dependency>
        <groupId>org.jberet</groupId>
        <artifactId>jberet-support</artifactId>
    </dependency>

Releasing

Releasing the project requires permission to deploy to JBoss Nexus. Once everything is setup, you simply need to run the ./release.sh script. There are two required parameters:

1. -r or --release which is the version you want to release
2. -d or --development which is the next development version.

By default the release version cannot contain SNAPSHOT and the development version must contain SNAPSHOT.

./release -r 1.0.0.Final -d 1.0.1.Final-SNAPSHOT

Supported Arguments

Argument	Requires Value	Description
-d, --development	Yes	The next version for the development cycle.
-f, --force	No	Forces to allow a SNAPSHOT suffix in release version and not require one for the development version.
-h, --help	N/A	Displays this help
--notes-start-tag	Unused	Passes the --notes-from-tag and the argument to the gh create release command.
-p, --prerelease	Unused	Passes the --prerelease to the gh create release command.
-r, --release	Yes	The version to be released. Also used for the tag.
--dry-run	No	Executes the release in as a dry-run. Nothing will be updated or pushed.
-v, --verbose	No	Prints verbose output.

Any additional arguments are considered arguments for the Maven command.