Skip to content

JBeret Roadmap 2018 2019

chengfang edited this page Jul 17, 2018 · 4 revisions

Development Themes and Tasks

Better Modular Development Experience

Repository Re-organization

Over the past few years, we've been actively developing project JBeret under a single JBeret Repo. As we keep implementing new features and adding additional capabilities, it's becoming a bit unweildy to house all sub-modules under this unified repository structure. Therefore, we're currently moving certain JBeret sub-modules out of the main JBeret repository and into their own github repository. Of course, all repositories, whether existing one and new ones, will still be under Project JBeret. This change is planned for JBeret master branch (currently 1.4.0.Alpha-snapshot).

We believe this reorganization will make various JBeret-related modules more modular and more self-contained. Project contributors will find it easier to manage the modules they will be working on with much quicker build time. Each module will be able to evolve according to their own roadmap and release with its own cadence, instead of the single JBeret release train.

For more details, see JBERET-382 Split the current single repo into several separate modules .

Reduced jberet-distribution

As a lateral to repo re-organization, the content of jberet distribution zip file will also change, to reduce the number of jar files packaged in jberet distribution zip.

Over the past few years, we've been releasing jberet-distribution-.zip that includes jberet-core, jberet-se, jberet-support, and their transitive dependencies. The intent was to enable batch developers to write and run common batch tasks with JBeret right out of the box. However, we've also found that there is no one size fit all requirements so we ended up having too many unrelated jar files packaged in jberet distribution zip. It may be a better option to keep jberet distribution zip to a workable minimum, and developers can then choose to add whatever is needed in their batch application development. This should result in a more modular structure.

Therefore, in jberet/jsr350 repo master branch, we've modified jberet-distribution module to include only jberet-core, jberet-se, and their dependency libraries.

Upgrade of Opensource License

Eclipse released a new 2.0 version of EPL, and deprecated EPL-1.0 in August 2017. We plan to upgrade all JBeret projects to have the new EPL-2.0 license. For details, see JBERET-435 Upgrade project license from EPL-1.0 to EPL-2.0

Better Modular Runtime Support

Re-organizing jberet-support module

Current jberet-support module contains all batch components for common batch processing tasks, such as

  • CSV item reader/writer,
  • XML item reader/writer,
  • JSON item reader/writer,
  • Jms item reader/writer,
  • Jdbc batchlet and item reader/writer,
  • BeanIO item reader/writer,
  • Excel item reader/writer,
  • REST API item reader/writer,
  • Mongo item reader/writer,
  • Cassandra item reader/writer,
  • Jpa item reader/writer,
  • Jasper Reports batchlet, etc

As we expand JBeret features and capabilities, both the size and scope of jberet-support module keep growing. A batch application typically only uses a small subset of those components. Sometimes it becomes a pain to have to package many unused components, and take care of their respective transitive dependencies. So we should explore ways to further modularize jberet-support module to deliver smaller, many focused modules that are easier to be consumed by batch applications.

Extracting jberet-api out of jberet-core

Current jberet-core module includes both JBeret implementation classes and JBeret API classes. The latter may be referenced by batch applications whereas the former is typically not directly exposed to applications. So it is desirable to separate them into separate modules. For details, see JBERET-236 Move public API's out of jberet-core into a public jberet-api module

Improved Quality and Stability

As we continue receiving customer bug report and user feedback, we strive to resolve these issues in a timely manner and incorporate them into appropriate releases.

Test apps and sample apps will be added and enhanced in certain areas to provide better quality coverage. A CI Job has been set up to perform sanity check and continuous integration for project JBeret.

OpenShift Integration

JBeret has been providing effective batch processing in both Java SE and Java EE environment. Next we need to expand it to cloud environment. First and foremost, we will focus on JBeret's integration with OpenShift. There are various areas to explore, for instance:

  • deploy and run JBeret-based batch applications with WildFly or JBoss EAP base image on OpenShift. This is already well supported since batch applications are packaged and deployed as regular web application or enterprise applications. And we need to write more samples, tutorial, docs to highlight and publicize this feature.
  • deploy and run JBeret-based batch applications with Vert.x runtime on OpenShift
  • deploy and run JBeret-based batch applications directly on OpenShift
  • manage JBeret-based batch applications on OpenShift with OpenShift CLI

Improving User Experience

Application Server CLI and Admin Console

As part of WildFly and JBoss EAP, the JBeret batch processing subsystem is centrally managed via the application server CLI or Admin Console. Any improvement in application server CLI and Admin Console will directly benefit JBeret users. And so JBeret will implement any such requirement or bug fixes in the upstream project to make JBeret works better in WildFly and EAP.

jberet-ui

jberet-ui is currently based on dated AngularJS 1.0 and a revamp is in order. For details, see JBERET-416 Upgrade jberet-ui to use newer JavaScript framework

Release Timeline

This document lists some high-level tasks, and a more detailed list of tasks and issues is in JBeret JIRA Issue Track. As JBeret project work progresses, more tasks will be taken from JBeret JIRA to be implemented in appropriate releases.

The following is a rough estimate of upcoming releases (subject to change without notice):

  • 2018 Q2 1.3.0.Final (released 2018-05-16)
  • 2018 Q2 1.2.6.Final (released 2018-05-25)
  • 2018 Q3 1.3.1.Final (planned 2018-07 to 2018-08): maintenance release for critial bug fixes
  • 2018 Q3 1.4.0.Alpha: initial 1.4.0 release after major repository re-organization
  • 2018 Q4 1.4.0.Beta1: with limited new features
  • 2019 Q1 1.4.0.Beta2: with majority of new features
  • 2019 Q2 1.4.0.Final: includes all planned features