GitHub

Project is hosted in the Eclipse organization at GitHub.

Eclipse Codewind

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

Traditionally, applications have been created on the developer's desktop, debugged locally, and then built and deployed through an automated devops pipeline. There are often numerous differences between these environments, including operating system, runtime or package versions, and environment.

The advent of Docker allowed the runtime to be packaged and moved between environments with repeatability, and Kubernetes has emerged as the deployment and management system of choice for large-scale Docker deployments. However, development is still usually done on a local environment without using these technologies and taking advatage of this new deployment platform.

Likewise, the Eclipse Foundation hosts both a classic desktop IDE (Eclipse platform) and a cloud-hosted IDE on Kubernetes (Eclipse Che), but no tools that help develop, debug, or deploy applications for Kubernetes, nor consistency in creating cloud-native applications regardless of your IDE.

Scope

The goal of Eclipse Codewind is to provide tools to help building high-quality cloud-native applications for Kubernetes, regardless of which IDE or language you use. This includes the capability to rapidly create an application from template or sample, support for launching, updating, testing, and debugging in Docker containers on the desktop, and support for the same directly on Kubernetes regardless of where the source is. The tools will also provide help to move an existing application to Docker and Kuberenetes, and validation to ensure that applications follow best practises.

To support this, Codewind will include plugins to the Eclipse platform and Eclipse Che, and a VisualStudio Code extension. A common library will be used by all of these tools to provide the function (e.g. creating, testing, and deploying applications) in a consistent way across the IDEs.

Description

Eclipse Codewind will start by providing an IDE-agnostic library for tools required for cloud application development:

  • Generating projects from templates
  • Creating a template or example from a current project
  • On the desktop: starting projects in Docker
  • Deploying applications to Kubernetes
  • Incremental update of applications running in Docker or Kubernetes
  • Debug and other support for these deployed projects
  • Application performance testing tools

Codewind will also provide Eclipse platform and Eclipse Che plugins, and a VisualStudio extension (and possibly others in the future) to allow users of these popular IDEs to create and deploy cloud-native applications in a consistent way from directly within their IDE.

Why Here?

The Eclipse Foundation has a strong history and community around building vendor-agnostic developer tools. Eclipse also hosts two of the main IDEs which we plan to extend, making it a natural fit for Codewind.

Project Scheduling

Initial contribution: May.

Tech preview & beta: 3Q2019

First release: 4Q2019

Future Work

Although the major peices will be in place after the initial contribution, we do not expect Codewind to be 'complete' at this point. Some of the main areas that need to be investigated:

  • Improving incremental development support for more languages
  • Support in other IDEs or development tools
  • Tools for helping with automated testing, and other aspects of app development that may change in cloud
  • Adoption of a vendor-neutral Kubernetes dev CLI

IBM will continue to invest in evolving Codewind and addressing these concerns, but welcomes additional participation in these areas or others.

Project Leads
Committers
Mentors
Interested Parties

IBM

Red Hat

Initial Contribution

The initial contribution will come from the IBM Microclimate project (http://microclimate.dev). This includes all the major functionality listed above, although it is in the process of being refactored to better fit into these environments.

Source Repository Type

Crnk

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Proposal State
Draft
Background

With www.crnk.io I started the project a bit more than 1 1/2 year ago with the focus of getting the solid basics together. Slowely it gets to this point and now would like to focus on community growth, join a project like the eclipse foundation and proceed with the next phase of development.

I think the website states the main motivication for the project:  " By following shared conventions, you can increase productivity, take advantage of generalized tooling, and focus on what matters: your application. ". Today there there are many great solutions for rest development, but I think still involves many lower layer protocol details and boiler-plate. In that regard there could be tremendous potential for common standards, tooling, abstraction to move development to a higher, potentially more productive level.

 

Scope

Out-of-scope: become a framework. It is and should stay a library that integrates well existing frameworks without any lock-in.

Also see below future work

Description

See www.crnk.io

Why Here?

Large community with many interesting projects already in the area (quarkus, microprofile, vert.x, etc.)

Project Scheduling

can get started now and we release quite often

Future Work

In terms of development I would like to proceed with:

- simplification & ease-of-use

- support for more data stores: JOOQ, Elastic, MonoDB, blockchains,...

- better support for frameworks like quarkus, vert.x, microprofile

- performance optimizations to be a first-class citizen for serverless platform

- maybe support for other data formats like GraphQL

Project Leads
Committers
Interested Parties

It has already small existing community. Also commercial ones like https://www.adnovum.ch/.

Initial Contribution

code from https://github.com/crnk-project/crnk-framework/. Originally I started a contributor in https://github.com/katharsis-project/katharsis-framework. At that point it was mostly a katharsis-core with me contributing further modules. But the owner has been gone for time reasons and eventually decided to also rewrite that core part, which now happened of the course of the past year.

 

Source Repository Type

Eclipse Kiso

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Proposal State
Created
Background

 

With IoT booming in recent years, more and more IoT applications come into the world. On “Things” level, software runs on resource constrained devices to collect sensor data and send it to cloud, for which different companies and hardware vendors provide various solutions. Eclipse Kiso is one of the solutions, but designed in a way that it can run on any RTOS or even without RTOS.

Eclipse Kiso was designed from scratch as a software development kit for IoT devices and has already been used and verified on a handful of existing products in the market. Eclipse Kiso’s reusability, robustness and portability is a key factor which enables fast development and quick time to market for almost all kinds of IoT “Things” product development.

Scope

 

The Eclipse Kiso software stack is mainly developed in C, including a core component “essentials” and HAL, device drivers, network support, FOTA etc.

  • Essentials comes to serve the needs for agility in software and hardware development, where changing the underlying OS and hardware does not necessarily mean scrapping all the already developed code. It defines HAL APIs and includes an OS adaption layer.

  • HAL (Hardware Abstraction Layer) which consists of two sub-components: BSP (Board Support Package) and MCU (Micro Controller Unit). If an application needs to migrate from a hardware A to hardware B it needs to have the BSP/MCU for the B hardware without the need to port the entire application.

  • Device drivers are provided for common devices normally available for IoT application, and more drivers will be added in the roadmap as more hardware platforms are supported.

  • Network support is also in place. Kiso includes a generic network stack itself and at the same time adapts third party solutions for supporting BLE, Wlan, LoRa and popular cellular network features.

  • FOTA (Firmware Over-the-Air) is also an important feature in Kiso for IoT devices. It is an efficient and automatic way of distributing software update, configuration and also a way of device management.

In addition to the software stack, the Eclipse Kiso provides hardware reference designs  including schematics, block diagrams, and datasheets. This is not necessary for using Eclipse Kiso software part, but could be interested when developers want to develop their own hardware. Kiso will run and test on the hardware reference designs before they are published.

Moreover, relevant environment regarding toolchains, continuous integration setup, test framework and documentation will also be available.

Description

With the insight of software solutions used in IoT devices, it is not hard to find out that the need for an OS independent IoT device software is indeed there. There are plenty of software products out there, and some of them are full stack including RTOS, drivers, network stack and almost everything; some of them are pure RTOS. Eclipse Kiso is not locked in by any RTOS and is designed with the idea of being RTOS neutral. It comes out of the box working on top of FreeRTOS, which is one of the market leaders, but it can be easily adapted to any other RTOS.

 

Eclipse Kiso appears here more as a friendly value add-on than as a competitor. For instance, if developers do not want to be locked into any specified RTOS, they can choose Kiso and then take whatever RTOS based on their personal needs. Even when comparing Kiso and Zephyr (full software stack including RTOS), Kiso still has the potential of being adapted on Zephyr’s kernel to fulfill certain needs.

Kiso BSP brings huge benefits for the end product. The splitting of the hardware abstraction layer into two sub-components MCU and BSP is the natural consequence of a translation of the circuit board of an embedded product into code, where the BSP takes care of the Board representation and peripherals configuration, and the MCU implements the core assets of a micro-controller's resources without the burden of configuration, which makes code portability to different microcontrollers a seamless task.

 

 

 

For constrained embedded systems, during handover from hardware developer to the software developer five major questions are  to be answered:

  1. How are the components routed (CONNECTED) to the microcontroller?

  2. What is to be done in order to bring a component to the operational state (ENABLED) ?

  3. What is to be done in order to bring a component to OFF state (DISABLED) ?

  4. Once the Component is disabled what GPIO configurations do we need to maintain in order to achieve the lowest power consumption safest state(DISCONNECTED) ?

  5. What special considerations need to be taken to keep the whole system in operational state ?

Those questions are the core of the Kiso BSP concept, and their answer is directly translated into code in the implementation.

Another point worth a mention here is Kiso’s efficient use of hardware resources. As seen from the chart, for a simple application for BT connected sensors, its footprint is only 114kB on flash and 22kB RAM for operation. When it comes to GSM cellular IP based network with complex algorithms, it uses 633kB flash and 124kB RAM. Comparing to even a bare Linux OS without application, it is quite lightweight and can satisfy most resource constrained IoT user cases.

 

 

Why Here?

As part of IoT ecosystem, Kiso can enrich the projects in Eclipse community, especially in IoT area. For example, the Elipse Mita project  was originated and works well alongside with Kiso. The Kiso team has good experience writing application for Kiso with Mita and vice versa. In the same way, it can make Kiso a plus for many other IoT projects. With Kiso going public, it is going to be definitely a contribution in open source community.

Project Scheduling
  • 15 April, 2019, the first code drop should be ready
  • 6 May, 2019, first build running on reference hardware

     
Future Work

More drivers

network stack

New MCU support

BT stack

New IoT connectivities

Toolchain update

CI (continues intigration)

Project Leads
Mentors
Interested Parties

Software AG

XDK2MAN

Eclipse Mita

SEGGER Microcontroller GmbH

Amazon Web Services, Inc. (AWS)

More third parties are on the way

Initial Contribution

Only one copyright owner, which is Robert Bosch GmbH

The code structure and description is:

  • example (demo code to use underline features)
  • core
    • connectivity (cellular, BT, WLAN, etc.)
    • drivers (drivers for sensors, memory chips, etc.)
    • essentials (adaption layer to various MCU, devices)
    • utils (helper functions commonly used in the rest of Kiso components)
  • boards (BSP packages for various boards will be here)
  • thirdparty (thirdparty libs)
    • freertos (MIT)
    • stm32l4 (BSD)
    • sensor drivers (BSD)
Source Repository Type

Eclipse Dartboard

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

Eclipse Dartboard is a recent programming language. Originally proposed by a team at Google in 2010, its main purposes were to be a flexible, but structured language for the web. Its syntax was (and still is) very close to other languages (namely Java or C#) which makes it easy for newcomers to start using Dartboard.

Nowadays there is a new main purpose for the language: Flutter. A project that has been unveiled in 2015 and utilizes Dartboard as its programming language. Currently developers use the project to deliver native cross platform mobile apps to both iOS and Android. In the future there will be other compile targets such as the web, or desktop applications.

The Dartboard toolkits still contain Dart2JS, a tool that can be used to transpile Dartboard code to Javascript code. The transpiled Javascript will run in any browser similiar to Typescript.

The Eclipse IDE was once heavily used for Android development. But with the addition of a dedicated IDE for Android development (Android Studio) Eclipse is no longer the preferred choice for Android development as the tooling did not receive updates anymore.

Scope

The scope of this project is to provide a development environment for Dartboard (and Flutter) developers in the Eclipse IDE. This includes creating Dartboard projects with different archetypes, rich editing of source code and configuration files, running and debugging Dartboard code from the IDE, running test suites, browsing and adding new dependencies, and packaging projects for deployment.

Description

Eclipse Dartboard provides development tools for Dartboard and Flutter in the Eclipse IDE.

Why Here?

With joining the Eclipse Community, we expect to see more contributions (in the form of issues and code) through better visibility. Developing a more active community improves the quality of Eclipse Dartboard through raised issues and code contributions. This makes for a better development experience for Dartboard developers using Eclipse Dartboard.

Eclipse was once heavily used in the mobile application development world and we would like to give developers the opportunity to do so again. Numerous developers are used to Eclipse and its features and they would like to have the option to use Eclipse again.

Depending on the future success of the Dartboard programming language we would like to consider the creation of a dedicated IDE for Dartboard developers. Being part of the Eclipse Community is a requirement for implementing this and will hopefully help the visibility of the Eclipse Dartboard IDE.

Project Scheduling

Initial code contributions will be done once the IP review has been done

Future Work

Bugfixes and improvements will be done on the existing code base.

Version 1.0.0 will be released once debug support is added. This relies on the release of a debug server for Dartboard.

Beyond this as the user base grows, more requirements will come to light and will be added.

Committers
Jonas Hungershausen
Mentors
Interested Parties

vogella GmbH

Redhat Inc.

Google LLC

Initial Contribution
Source Repository Type

Basil

Date Review
never
Date Trademark
never
Date Provisioned
never
Date Initial Contribution
never
Date Initial Contribution Approved
never
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Draft
Background

We are creators, maintaners and owners of DBeaver, universal tool for working with wide range of databases. DBeaver was started as an open-source project about 10 years ago. Now, it is popular tool with a huge community and users around the world. 

DBeaver is an Eclipse-based application. We decided to extract a platform part of DBeaver to a separate Eclipse project Basil. We belive that it will help us to improve and simplify integrations with other Eclipse projects. 

Scope

This is a platform (API) and basic UI components for creation of various database management tools and IDEs. It supposed to connect and work with any existing relational database as well as with NoSQL databases or serevices. It supports various types of data representation and database connectivity protocols.

Description

Basil is a platform for 

Why Here?

Basil (as a part and a base level of DBeaver) is very Eclipse-centric. It is an RCP and uses different Eclipse components widely.

It is already integrated with GEF, Graphiti, ELK, Mylin and some other Eclipse frameworks. We are goign to deeply integrate with JNoSQL project to provide new database connectivity protocol.

We like ideas of open-source and have followed them for almost 10 years. We hope that Eclipse community supports us in the further product development.

Committers
Initial Contribution

Basil is a platform part of the DBeaver project (https://github.com/dbeaver/dbeaver).

DBeaver exists since 2010, most of code was written by Serge Rider. However, GitHub project has more than 60 minor contributors. Copyright belongs to Serge Rider and individual open-source contributors. All contributions are made under Apache OS License.

Source Repository Type

CocoaMQTT

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Draft
Background

We have a long history in open-source contribution. In 2012, EMQ launched on GitHub as an open source project. Now we want to contribute two MQTT Client projects to Eclipse Foundation.

Scope

MQTT v3.1.1 client library for iOS/macOS/tvOS written with Swift 4

Description

MQTT v3.1.1 client library for iOS/macOS/tvOS written with Swift 4.

Why Here?

Adding this project will bring more language and enviroment support and implementation for MQTT Client to "Eclispe Paho".

Future Work

1, Continuously fix bugs in current codebase

2, Implement MQTT5 protocol for COCOA framework

Project Leads
Committers
CrazyWisdom
Initial Contribution

EMQ Technologies Co., Ltd.  holds the copyright.

Third-party libraries: CocoaAsyncSocket

Source Repository Type

QMQTT

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Draft
Background

We have a long history in open-source contribution. In 2012, EMQ launched on GitHub as an open source project. Now we want to contribute two MQTT Client projects to Eclipse Foundation.

Scope

MQTT Client for Qt

Compile the library with Qt >= 5.3 version. On Windows you need to specify CONFIG += NO_UNIT_TESTS, since gtest is not supported.

To add websocket support, compile the library with Qt >= 5.7, and specify 'CONFIG += QMQTT_WEBSOCKETS'.

Description

QMQTT is a MQTT client for Qt which can be used to connect to the MQTT Broker and debug your MQTT project.

Why Here?

Adding this project will bring more language and enviroment support and implementation for MQTT Client to "Eclispe Paho".

Future Work

1, Continuously fix bugs in current codebase

2, Implement MQTT5 protocol for QT framework

Project Leads
Initial Contribution

EMQ Technologies Co., Ltd.  holds the copyright.

Third-party libraries: none

Source Repository Type

Elbfisch.org

Date Review
never
Date Trademark
never
Date Provisioned
never
Date Initial Contribution
never
Date Initial Contribution Approved
never
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Draft
Background

Embedded PC systems are increasingly being implemented in automation projects which for a long time have been an exclusice domain for PLC's , encouraging the design of object-orientated software development processes, a step which is long overdue. To assist with this, Elbfisch offers a runtime environment and a canon of basic functions that allow complex automation tasks to be implemented on inexpensive hardware platforms in Java.

Scope

Elbfisch offers a runtime environment and a canon of basic functions that enable the team-based development of object-orientated automation applications when used in conjunction with common open-source products. A clear and simple concept for modelling even complex automation applications, a network based versatile input/output subsystem (vioss) implementing OPC/UA, ADS, MODBUS communication is included as well as a embedded features like logging and configuration.

Description

have a look at http://www.elbfisch.org/docs/ElbfischLecture.pdf

Why Here?

In our opinion, our project is ideal to implement IoT projects in all fields in which automation of processes with communications to sensors and actors are needed. The rising importance of pc based platforms like for example the raspberry pi in industrial and consumer applications emphasizes this notion.

Project Scheduling

We are running this project since 2011. Several stable versions are available right now.

Future Work

We are working on a concept to run an elbfisch application consisting of several hierarchically organized modules distributed on several hardware nodes seamlessly. That means, that the implementor has no efforts for setting up communication protocols etc. Elbfisch will then be able to swim in a swarm ;-). Will be released in Feb 2019.

Project Leads
Committers
Mentors
Initial Contribution

see http://www.elbfisch.org/

Source Repository Type

I already contacrted eclipse IoT to get their ok to run elbfisch under the hood of eclips Iot. Benjamin Cabe´will hopefully send me the user id of the right mentor.

Regards

Bernd Schuster

Eclipse Yasham

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Proposal State
Created
Background

The current consumer IoT and smart living market suffers under the commercial interests and competition of many companies, fighting for the “ownership” of customers and try to force proprietary ecosystems, leading to more fragmentation of consumer IoT solutions. Companies and developers want to integrate/interact with the mass of consumer IoT & smart living solutions but there is no normalized, future-proof link to connect and manage the smart living/C-IoT services. Developers and companies are therefor facing high integration efforts and interoperability challenges.

Accompanied by the large number of providers there are no common protocol standards. Alliances, standardization organizations or joint ventures try to bundle protocols and standards around consumer IoT and smart home services to cover a larger number of smart living solutions, but still developers or companies have to deal with a very heterogeneous landscape.

In fact, Industries want the highest coverage for their consumer IoT customers, but are restricted by partnerships which only cover smart living services of the partners network with strong limitations by competition, resulting in range and vendor lock-in. This has led to a highly fragmented market, which makes it also difficult for customers to choose a future proof solution. There wont be the one system, protocol or standard that could possibly fulfill all potential requirements. There is a need for platforms that allow the integration of different cloud based systems, protocols or standards and that enables a uniform way for integration, user interfaces and business services.

The origins of Yasham comes from the turkish word for living and stands for the mission of the project, which is to empower an open, flexible smart living and consumer IoT platform in a heterogenous consumer IoT world. The vision and philosophy behind the Eclipse Yasham project is related to the Eclipse IoT project Eclipse SmartHome and openHAB and takes those ideas and concepts to the cloud level, rather focusing on the embedded area. However Eclipse Yasham is not restricted to be a platform for Smart Home solutions and can be combined with other IoT gateway solutions.

Scope

Eclipse Yasham is a highly modular cloud native platform that interconnects a wide range of consumer IoT & smart home services via extensible cloud software adapters to abstract away the specific communication protocols & requirements of cloud based services by a simplified and generic integration model towards the Eclipse Yasham consumer IoT platform. The scope of the platform is mainly about the topics: Consumer IoT, Smart Home, Smart Building and Smart Living. The flexible and modular architecture of Eclipse Yasham will allow the usage of the platform in a Business-to-Consumer (B2C) or commercial Business-to-Business (B2B) deployment scenario

Description

Eclipse Yasham is an Open & Extensible Cloud-Native Smart Living Platform for Consumer IoT.

Some features at a glance

  • Server Side API Gateway (REST API)
    • Service Registration and discovery
    • Caching and Logging
    • Authentication and Authorization
    • Transport security and Request dispatching with transport transformation
    • Load balancing
    • Providing central endpoint for acquiring service data
  • Notification Management
    • Central management for notifications
    • Mobile App notifications
    • SMS & Email Notifications
    • Alarming functionalities
  • Cloud Adapters
    • Central integration point for cloud-to-cloud integrations
    • Adapters based design pattern (like Eclipse SmartHome Binding concept just for the cloud)
    • Adapter template mechanism to “plug-in” into the Yasham platform
    • Flexible and modular extension point to add new smart home, smart living solutions
    • A programmable approach for smart living integrations
    • Management of cloud-to-cloud connections
  • Service Orchestration (Rules Engine)
    • A fllexible, cloud based rule engine that allows to model complex scenarios
    • Management and configuration of rules
    • Pre-configured rules templates for easy adoption
    • Trigger rules based on certain cloud or device events (e.g. time based)
  • ...
Why Here?

Many Eclipse projects are widely used within the smart home and conusmer IoT industry. Eclipse Yasham will add value to the Eclipse community by enabling a consumer IoT ecosystem for smart living and smart home solutions. Yasham will also broaden the Eclipse ecosystem, which covers currently many IIoT (Industrial Internet of Things) projects. Therefor Eclipse Yasham will be a good extension to the Eclipse IoT domain, next to the related Eclipse SmartHome framework. The Eclipse Yasham project will benefit from the visibility in the community and an extended collaboration model with interested parties.

The target of Eclipse Yasham is to deliver a complete end-to-end consumer IoT (C-IoT) & smart living ecosystem. To achieve this in the IoT domain, there is the need to keep other cross concerns in mind, too. That's why Yasham is designed as a pluggable, modular platform and does not explicitly cover all related IoT concerns like connectivity and communication with devices, authentication and authorization, over the air updates for IoT gateway by itself. The main approach is to re-use and plug already existing Eclipse IoT projects into Eclipse Yasham to extend its use case for many possible scenarios, no matter if it is a consumer IoT solution for private or business customers.

Yasham could be combined with other Eclipse IoT projects to enable thie even more complete end-to-end platform as an ecosystem:

  • Eclipse SmartHome as the natural choice for embedded and gateway related integration in the local network
  • Eclipse Vert.X could serve as the main execution runtime for higher level business services
  • Kura can be connected to the platform and act as IoT gateway solution
  • Eclipse Hono as scalable device connectivity platform
  • Eclipse Hawkbit for rolling out software updates for e.g. Kura or Eclipse SmartHome gateways
  • Eclipse Kapua as integration foundational IoT framework
  • Eclipse Keti as authentication and authorization service

     

 

Project Scheduling

Eclipse Yasham aims to finish the initial contribution around Q1/2019.

A first possible release is planned for Q2/2019, mainly based on the refactored initial contribution.

Future Work

The futrue work will include continous platform improvement and releases. There will firscloud integrations contributed by home-iX in a later stage. Some parts of the platform (e.g. openHAB-cloud parts) are planned to be re-designed and re-written form NodeJS to Java/Eclipse Vert.X. The upcoming roadmap and timeline of Eclipse Yasham can be summarized as shown in this overview:

Initial Contribution

The initial contribution of the Eclipse Yasham project will be in the first step the current source code of openHAB Cloud, the companion cloud service and backend for the openHAB open-source home automation software. The initial contribution will contain a ready-to-use cloud service.

  • Source code for the initial Eclipse Yasham cloud platform
  • Documentation of the main Features, Architecture and Concepts
  • A working CI/CD Build System & Pipeline
  • Test Automatisation (Unit and Integration)
  • Kubernetes Deployment
Source Repository Type

Jakarta Batch

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Is this a specification project?
Project
Parent Project
Proposal State
Created
Background

This project is created as part of the process of transitioning Java EE 8 technologies to the Eclipse Foundation as described in The Eclipse Enterprise for Java Project Top Level Project Charter.  A unique aspect of this project creation is that Java Batch was led by a non-Oracle organization, namely IBM.

The project aims to continue the standardization work of JSR-352, which was first finalized at version 1.0 in 2013 as a part of Java EE 7, and which is also designed for use in Java SE environments.

The problem domain targeted by Jakarta Batch can be described by this excerpt from the JSR-352 specification:

  Batch processing is a pervasive workload pattern, expressed by a distinct application organization and execution model. It is found across virtually every industry, applied to such tasks as statement generation, bank postings, risk evaluation, credit score calculation, inventory management, portfolio optimization, and on and on. Nearly any bulk processing task from any business sector is a candidate for batch processing.

  Batch processing is typified by bulk-oriented, non-interactive, background execution. Frequently long-running, it may be data or computationally intensive, execute sequentially or in parallel, and may be initiated through various invocation models, including ad hoc, scheduled, and on-demand.

  Batch applications have common requirements, including logging, checkpointing, and parallelization. Batch workloads have common requirements, especially operational control, which allow for initiation of, and interaction with, batch instances; such interactions include stop and restart.

Scope

Project Scope:  The Jakarta Batch project defines and maintains the Jakarta Batch specification and related artifacts.

Specification Scope:    Jakarta Batch describes a means for developing, executing and managing batch processes in Jakarta EE applications.

Description

The Jakarta Batch project describes the XML-based job specification language (JSL), Java programming model, and runtime environment for batch applications for the Java platform.

The specification ties together the Java API and the JSL (XML) allowing a job designer to compose a job in XML from Java application artifacts and conveniently parameterize them with values for an individual job.  This structure promotes application reuse of artifacts across different jobs. 

Some key features:

  • checkpoint / restart - The application read-process-write loop is performed under a global transaction, one "batch" or "chunk" of data at a time, with the batch implementation atomically storing a "checkpoint" at the end.  This checkpoint provides an index into the data stream which allows you to restart a job after an earlier execution hits a failure (or is stopped), such that picks up where you left off (at the checkpointed value).  
  • steps - jobs can be composed of steps to allow reuse of step logic and definitions within multiple jobs, as well as to faciliate restart (at the step the job left off at).
  • XML configuration - Configuration is externalized from Java code into XML and parameterized through a variety of "job property" substitutions.  As one example, this allows database lock tuning (for locks held during the duration of the chunk transaction) to be tuned without touching Java code.
  • partitions - The read-process-write loop can be broken up into multiple units running in parallel against different segments of the input data.

 

The specification allows the flexibility for batch jobs to be scheduled or orchestrated in any number of ways, and stops short of defining any APIs or constructs regarding scheduling or orchestration of multiple or repeated jobs.   

Why Here?

The top level EE4J project was created consistent with the direction described in The Eclipse Enterprise for Java Project Top Level Project Charter.   This project is created under the top level EE4J project as one of the Java EE 8 technologies being transitioned to the Eclipse Foundation.

Project Scheduling

We intend to use community-driven project scheduling, and so naturally hope to get some consensus about the initial set of priorities from other participants.  

It may help to start with a few steps to build momentum for the project without yet seeking to expand the end user function. 

For example, one set of priorties would be:

  1. Revive JSR 352 spec issues list - Create ("reconstitute") a new issues list starting from the old issues list (with community consensus for those we decide to NOT carry forward) that has been archived since Oracle sunset the java.net site.
  2. Improve TCK automation - Develop the Maven layer around the existing TCK so that it can more easily be executed both in "SE mode" as well as within "EE / app server mode".   This will allow execution of the TCK against existing well-known JSR 352 implementations via a tight iterative loop, which in turn will give us the confidence that we can begin enhancing the TCK with new tests addressing some of the coverage gaps that were identified in the JSR 352 project.  
  3. Package namespace migration ? - If the general javax.* to jakarta.* namespace issue has been resolved by this point, and there is a clear first action, it would make sense to tackle this right away, before starting on new function.

It seems like the first 2-3 months after the project is launched would be a reasonable timeframe to contain or show significant progress on a set of priorities like this.

Future Work

Once we've dealt with the above three things, which don't add any new function to end user developers, we could take the reconstituted issues list, and do a combination of polling and discussion to prioritize some big ticket / bullet point items for a VNext.  

Along with the bigger ticket items there will be quite a few minor additions that we can use to get the ball rolling and show progress.   E.g. "I have a well-defined listener lifecycle, but I just need one more method at point XYZ"...  Everyone will understand it, and it'll force us to produce 1.1-SNAPSHOT or whatever, and force us to build out the new pipeline enough to be able to ship/release anything.

Initial Contribution

The contribution will consist of:

  1. A spec document
  2. An API module
  3. A  TCK module

IBM has the IP rights necessary to allow us to contribute these immediately

Source Repository Type

I was part of the JSR-352 in the previous phase and one of the original architects of the Spring Batch product.  I'd love to participate again.  What do I need to do to get involved again?

My name and contact information is 

Wayne Lund

wlund@pivotal.io

916-296-1893 | twitter: @wxlund