GitHub

Eclipse Public License 2.0

Proposal State

Created

Background

Autonomous driving and connectivity are cornerstones of the next generation of mobility. Users expect mobility experience to be personal, seamlessly integrated, connected and with demand services that can adapt to their immediate needs. These systems demand immense computing power in order to mimic the adaptivity and the awareness of a human driver under different driving circumstances and context variations. Contextual adaptivity requires a system to make sense of large volumes of rich & continuous data coming from the devices, the user behavior and the environment.

Many solutions use hardwired, closed & proprietary software with often unexplainable built-in biases. Robot Operating System (ROS) allows a modular system to be designed as a fully distributed computation, so different functional modules (i.e. sensing, perception, decision, planning, actuation, etc) can act together as a single autonomous vehicle.

A challenge with a typical ROS based hardwired solution is that the components (nodes, a network of interconnected computational and executable units) constituting the system are deployed into an environment to fulfill a certain concern with a specific mission plan, and they are not typically designed or implemented to react and to adapt changing requirements in the environment. A major difficulty that prevails for any adaptive system is being able to update the system without compromising its mission, plan, safety and security while it is active because the damages could be substantial.

Scope

Eclipse Muto provides an adaptive framework and a runtime platform for dynamically composable model-driven ROS software stacks on autonomous vehicles and robots in general.

Eclipse Muto introduces the concept of a lightweight model for ROS software stacks, which in its simplest form is a model for the system of connected ROS nodes and the context for which it is applicable. The Muto Agent and Muto Composer are ROS based runtimes designed to run on edge devices (i.e. AVs). Muto Dashboard is an extensible Web/Mobile application for centralized management of edge devices and Muto stacks deployed on these devices. Muto Composer runtime can introspect and change (i.e launch, stop, restart, configure, etc.) the network of distributed components running on a device using the Muto Stack definitions. Muto Agent allow remote management and monitoring of the devices and stacks and uses eclipse IoT technology such as Eclipse Ditto to define a digital twin for each device providing synchronous and asynchronous APIs and use the digital twin API to manage Muto stacks and ROS behavior.

The adaptive behavior is introduced by an extensible model where the context detection, stack rewriting, validation, constraint satisfaction, safety and security concerns can be offloaded to other modules (i.e proprietary systems). An example of such a module would be a remote control system where human operators determine the next configuration. A different implementation might use machine learning and scene detection to switch and transition to different stacks that are suitable to the current context.

Description

Eclipse Muto provides an adaptive framework and a runtime platform for dynamically composable model-driven ROS software stacks. Eclipse Muto can be used to introspect, monitor and manipulate the actively running ROS graph (the network of ROS nodes).

Agent

Agent is a runtime ROS component (Node) acting as a transceiver between the edge device and the twin server (Eclipse Ditto). Agent acts as a gateway between the device and remote management capabilities with support for asynchronous communication capabilities via MQTT. It acts as a communication bridge between edge devices and their respective virtual twins. The main aspects of data transported by Agent are as follows:

Device Telemetry

Agent is capable of publishing data streams up to the Twin Server, such as data that streams in ROS topics. Stream of data mapped from edge device to virtual one, could represent instant telemetry information and/or any other device specific details. This kind of data is useful for monitoring devices and algorithmic parameters with adjustable-frequency updates. Data such as odometry, speed, localization, goal or any other drive and device related can be broadcasted via declarative models. This kind of fast paced, high frequency data moving up to digital twins is also read by Muto Dashboard to provide a graphical interface and an adequate representation of aforementioned data.

Command Relay

Agent relays commands from the twin server to Composer running on the edge device. This type of information may be related to the lifecycle of ROS nodes that constitute the software stack actively running on the edge device as well as the lifecycle actions (start, stop, update etc) that may trigger the composer to respond.

Composer

Composer is a runtime ROS component (Node) that is responsible for the life cycle of a stack; Composer uses various ROS packages and APIs to launch ROS Nodes defined by the software stacks. It can be thought of as a smart launch manager. Composer uses the stack information model and computes the delta between the current and the desired state of the ROS graph and manages the lifecycle of ROS nodes accordingly.

Dashboard

A simple extensible Web/Mobile application for centralized management of edge devices and software stacks. It provides a plugable micro front end architecture for extensibility and an exemplary view for managing edge devices and composable ROS stacks on these devices. It supports and uses Eclipse Ditto device twins technology (and therefore protocols such as MQTT and REST/HTTP) for managing ROS based devices. It is designed to be modular at architectural level to make it easy to extend for a multitude of ROS applications.

The dashboard provides the following functionalities:

Node Viewer : A graphical visualization of the ROS computational network that represents the actively running ROS nodes of the current state. It displays the node-to-node and node-to-topic affiliations with introspection information ( name, subscriber, publisher etc.)
Stack Panel
- List: An interface to list the stack models that describe the components of a software stack that complies with the information model stored in the twin server.
- Diff: An interface to describe the algebraic differences between two models in terms of nodes and node related parameters .
- Remote Control Actions: An interface to manage (start,stop, update) the lifecycle of the software stack on the edge device.
ROS Controls: Dashboard provides a graphical UI for some of the common ROS cli commands.

LiveUI

Micro frontends is an architectural style where independently deliverable frontend applications are composed into a greater whole. Muto LiveUI has been developed for building any such extensible Web or Mobile apps, such as the Muto Dashboard.

LiveUI opts for run-time integration via JavaScript that is tightly integrated with popular Javascript frameworks such as React.js, Vue.js and integrates well with packaging and development tools such as npm, Webpack and Metro bundler. There is a cost to using distributed, micro service based architecture; there are more pieces, more repositories, more tools, more build/deploy pipelines, more servers, more domains, etc. We created LiveUI to help us manage some of these issues and improve the developers' experience using micro frontends. Live UI can be fully configurable to be integrated into many different devops processes and pipelines allowing many different custom project and repository layouts, test and quality tools. Development tooling and debugging experience is seamless with or without the inclusion of the container (parent) frontend.

Examples

We use/fork code and examples from open initiatives such as f1tenth.org Autonomous Vehicle System, a powerful and versatile open-source platform for autonomous systems research and education, and Autoware.org an open-source software stack for self-driving vehicles to demonstrate dynamically adaptive ROS stacks. These examples provide a common repository for learning and teaching ROS and adaptive AD capabilities.

Why Here?

Current industry practices for automotive software embrace proprietary and closed solutions. Many common building blocks are replicated within the industry. Open Source software such as the Robot Operating System (ROS) and Autoware demonstrate how the industry can benefit from Open Source. Eclipse Software Defined Vehicle can become a focal point for open technology and collaboration within which Muto can contribute to solving some of the harder questions about contextual and adaptive ROS software, and create opportunities for collaboration for innovative niche solutions and large scale implementations driven by OEMs and Industry leaders.

Licenses

Legal Issues

Initial contribution includes code derived from other open-source projects please see the relevant section where we disclose these projects and their licenses.

Project Scheduling

Initial contribution will be submitted before the end of Q2, 2022.

Future Work

In future release, we plan to provide:

Enhanced ROS/Ditto Twins integration
Adaptivity plugins (i.e. remote-control)
Mobile Extensions for LiveUI (react-native)

People

Project Leads

Committers

Mentors

Source Code

Initial Contribution

Initial code contribution will be organized under the following repositories:

Core (for common models and utilities)
Agent
Composer
Dashboard
LiveUI
Examples

The source code for Eclipse Muto is partially available in open source repositories (https://github.com/composiv and https://liveui.composiv.ai/ ) and internal private repositories (Agent, Composer, Dashboard). The runtime components target ROS runtimes, therefore use APIs and some code derived from the ROS repositories.

Composiv examples use/fork code from various f1tenth.org, autoware.org repositories and are subject to copyright and ownership of these repositories.

The following are some of the primary open-source, third party libraries that are relevant to Eclipse Muto:

Robot Operating System (ROS)
- https://www.ros.org/
- https://github.com/ros
- Apache v2 (ROS2) and (ROS 1) BSD, MIT and other Various Licenses
F1Tenth.org (MIT, BSD and other Various Licenses)
- https://github.com/f1tenth/f1tenth_system F1tenth System
- https://github.com/f1tenth/particle_filter Particle Filter (a fork from https://github.com/mit-racecar/particle_filter )
- https://github.com/f1tenth/f1tenth_simulator F1tenth Simulator

Source Repository Type

https://github.com/composiv

Source Repositories

Read more about Eclipse Muto
Log in to post comments

Eclipse eCAL (enhanced Communication Abstraction Layer)

Basics

Project

Eclipse eCAL (enhanced Communication Abstraction Layer)

Parent Project

Proposal State

Created

Background

eCAL was originally developed by Continental Automotive out of the need of a communication middleware solution for rapid prototyping in the area of autonomous driving. It supports a wide range of operating systems and covers embedded hardware as well as high performance multi core systems.

Scope

Eclipse eCAL (enhanced Communication Abstraction Layer) provides a communication middleware for distributed computing systems written in C++ and designed for high performance / low latency communication. Besides this communication core Eclipse eCAL provides mature eco system tools for recording, replaying and monitoring data flows and for the automated startup and shutdown of a distributed system.

Description

The Eclipse eCAL (enhanced Communication Abstraction Layer) provides a middleware that enables scalable, high performance interprocess communication on a single computer node or between different nodes in a computer network. Eclipse eCAL uses a publish-subscribe pattern to automatically connect different nodes in the network.

Eclipse eCAL is choosing the best available data transport mechanism for each link:

Shared memory for local communication
UDP / TCP for network communication

The Eclipse eCAL middleware solution enables rapid prototyping for those high performance distributed application by providing the following base features:

intraprocess, interprocess and interhost communication
different transport layer implementations (shared memory, UDP, TCP)
publish/subscribe and server/client communication pattern
different message serialization formats
Windows and POSIX operating systems
language bindings to C, C++, C#, Python, Rust, Go, M-Script

For full documentation see official eCAL documentation.

Why Here?

By abstracting software components from specific operating system API's and forcing the component provider to specify a clear software component interface (publish / subscribe or client / server) Eclipse eCAL simplifies and accelerates the development, the maintenance, the deployment and the integration and test of an overall AD system in a SDV setup.

Licenses

Legal Issues

none

Project Scheduling

Release cycle is every 6 months - see releases
Current release is 5.10

Future Work

Project can be used as common integration platform for AD prototyping vehicles, simulation, test and validation environments. By using the existing powerful tools for recording, replay and monitoring and the support of multiple programming languages there is a wide range of different use cases.

We plan to:

support more existing AD sensor system natively (first project with GeneSys ongoing)
improve documentation by new (video) tutorials and more official doc pages
integration in other open source solutions in the SDV Eclipse working group

People

Project Leads

Committers

Mentors

Interested Parties

Source Code

Initial Contribution

Project owned by Continental
Project licensed under Apache 2.0 - see eCAL License
All thirdparty dependencies including licences are listed here

Source Repository Type

https://github.com/continental/ecal

Source Repositories

Read more about Eclipse eCAL (enhanced Communication Abstraction Layer)
1 comment
Log in to post comments

Eclipse Chariott

Basics

Project

Eclipse Chariott

Parent Project

Proposal State

Created

Background

The Eclipse Chariott project provides:

Middleware: Centralized middleware layer to connect to different providers in the vehicle, as well as host the vehicle twin store, Access Control List (ACL), and other middleware services. Abstracts the vehicle specific providers implementation through a common and agnostic set of vehicle interfaces between providers and the applications that need to consume the data.

Application: The business logic component talking through the client/provider library to receive events and execute lower-level functions. Applications are envisioned as providing a specific set of Quality Management (QM) level functionality in the vehicle, for example, seat adjustment or interior climate control. Applications describe their ACLs and their capabilities that other applications can consume.

Providers: The vehicle has different lower-level protocols it uses to communicate with the different Electronic Control Units (ECUs) in the vehicle (e.g. SOME/IP, DDS, UDS, etc.). These providers connect the exposed services and state from the ECUs to the middleware and eventually the application. Providers are intended to be created by the suppliers, except for a reference provider that is generated for the purpose of testing and development.

Scope

The Eclipse Chariott project aims to develop a metadata-driven middleware/abstraction layer that allows modern programming models to target in-vehicle functions, providing a common way to access the vehicle hardware and sensors, while enhancing the developer journey.

Description

The Eclipse Chariott project aims to develop a metadata-driven middleware/abstraction layer that allows modern programming models to target in-vehicle functions, providing a common way to access the vehicle hardware and sensors, while enhancing the developer journey.

Automotive original equipment manufacturers (OEMs), partners and software providers require a consistent and well-architected experience that allows them to continuously develop and deploy new software capabilities, new features, new services and new applications to vehicles without having to re-architect and reducing or eliminating system integration effort. The metadata-driven middleware/abstraction model is thus a key building block to provide a common way to access the vehicle hardware and sensors that eventually will be adopted by automotive customers and partners to enhanced developer journey. At core, the programming model should provide a service interface that 3rd party software providers can rely upon to access services and features of the vehicle.

Licenses

The MIT License (MIT)

People

Project Leads

Committers

Atif Aziz

Mentors

Jay Billings

Source Code

Initial Contribution

The plan for the initial contribution, here described as Community Technical Preview (CTP), is to deliver a working proof of concept of the middleware/abstraction layer, written in Rust, that can send instructions to and receive state from a reference implementation that simulates a vehicle resource provider.

•   Client/Provider Library to communicate with the middleware through an abstract interface

•   Middleware to route function calls and provide an event system over registered provider

•   Provider service API to extend/add vehicle provided services and data

•   In memory vehicle store with point reads on the keys.

Source Repository Type

Eclipse Public License 2.0

Read more about Eclipse Chariott
Log in to post comments

daanse

Administration

Date Review

never

Date Trademark

never

Date Provisioned

never

Date Initial Contribution

never

Date Initial Contribution Approved

never

Basics

Parent Project

Eclipse Technology

Proposal State

Draft

Background

analyssis systems open source

smart city

xmla standads

mondrian-> emondrian

Scope

data analysis services

OLAP based

Southbound Connectors

SQL-JDBC based connectors

optimised for each database dialect

optimised for each database product

expacially newer like Clickhouse)

xmla interface

MDX interface

standadised dimension

xmla tck

xmla spec compatibitility test

connector tests for all major BI-software

Writeback

agg of textste

webclient/gisClient

komments of data!!

Aggregation of distrebuted xmla data

Description

[dæns] (also ok : [dɑːns])

Why Here?

governance

related projects birt

Licenses

Legal Issues

pentaho mondrian eclipse 1.1

Source Code

Initial Contribution

Mondrian

emondrian

xmla-services

Source Repository Type

Eclipse ADAAA (Adaptive Cruise Control Demo Application for Adaptive AUTOSAR)

Read more about daanse
Log in to post comments

Eclipse ADAAA (Adaptive Cruise Control Demo Application for Adaptive AUTOSAR)

Basics

Project

Parent Project

Proposal State

Created

Background

ZF is working with Adaptive AUTOSAR (AUTomotive Open System ARchitecture), a worldwide development partnership of vehicle manufacturers, suppliers, service providers and companies from the automotive electronics, semiconductor and software industry. For many years ZF has been member of the AUTOSAR consortium. ZF has established a solid base around the Adaptive AUTOSAR methodology. SW engineers new to the Adaptive AUTOSAR methodology are educated with dedicated SW examples that are bundled in the example project called ADAAA. This project has been proven to be very useful to provide inside information into the Adaptive AUTOSAR methodology and how Adaptive AUTOSAR being used.

ZF would like to contribute this example framework to help the automotive industry to explore the standard based on common grounds.

Scope

The Eclipse ADAAA project provides an Adaptive Cruise Control (ACC) Demo Application for the Adaptive AUTOSAR standards.

The first version contains the following artifacts:

* Considered functional cluster list

* Documentation

* Integration architecture

* Test cases

* Example requirements

* Build setup

Description

ADAAA is example application for Adaptive AUTOSAR with the following goals:

* Provide a tutorial with simple examples code base for getting involved with AUTOSAR methodology and each functional cluster

* Address one of the features available and known as a convenience function in modern cars: the Adaptive Cruise Control functionality

* Provide additional examples to illustrate the automotive how to put an AUTOSAR application into an automotive SW devlopment context with its specific processes

* Build AUTOSAR expertise on common basic example accross the community

* Use the community support to adapt to different Adaptve AUTOSAR providers and maintain it

Why Here?

Adaptive AUTOSAR is one of the building blocks for Software Defined Vehicle in the future. Adaptive AUTOSAR is a standard to operate current and future software in high-performance computing for Software Defined Vehicles (SDVs). An important contribution to acceptance of common standards is an efficient enablement of new people interested in using the standard. An example maintained by the community will greatly facilitate the common understanding on how to achieve the first steps.

Licenses

The MIT License (MIT)

Legal Issues

Although the example is intended to be used with different Adaptive AUTOSAR suppliers, the current example is based on the Stack of Vector. We are currently in discussion with Vector to receive their consent to this project.

Currently the ZF department responsible for the IP also has to provide the agreement still.

It is expected that both Vector and the IP department provide their agreement before the 1st of June 2022.

Future Work

ZF will remain user and contributer to the standard and support at least one version of the Adaptive AUTOSAR stacks currently available on the market.

People

Project Leads

Sairam Sharma Shanagala

Committers

Mentors

Source Code

Initial Contribution

Vector based version of ADAAA.

- Source code

- Build routines

- Documentation

- Integration architecture

- Example requirements

- Summary illustrations

- Example test code

- ...

Source Repository Type

Eclipse Backend function Bindings (BfB)

Read more about Eclipse ADAAA (Adaptive Cruise Control Demo Application for Adaptive AUTOSAR)
Log in to post comments

Eclipse Backend function Bindings (BfB)

Basics

Project

Parent Project

Proposal State

Created

Background

One of the future trends in mobility and in the automotive sector is the shift towards the Software Defined Vehicle: Features and services will increasingly be provided/enabled by software components on the vehicle in collaboration with complex application landscapes in the backend. This will create new markets and enable new players to contribute digital services.

The Eclipse BfB project aims to contribute to the ecosystem surrounding these services by providing a way to define the interface between backend service and in-vehicle component in a protocol-independant manner. An open specification ecosystem can help to enable more contributions to the market and fosters innovation in the area of connected vehicles.

Scope

The Eclipse BfB project provides a protocol-agnostic interface specification and tooling environment in the ecosystem of mobility and automotive applications

Description

The Eclipse BfB project provides a protocol and technology agnostic interface specification in the ecosystem of mobility and automotive applications.

The Eclipse BfB specification is maintained in a markdown-based technology-independent format which is human readable and can be used for API documentation. A set of kotlin based tools is provided to translate/compile this specification into protocol specific specification formats like protobuf over MQTT or json over HTTP.

Why Here?

Backend to Vehicle communication is a key concern for Software Defined Vehicles, and should therefore be a valuable building block in the greater Eclipse SDV portfolio. While it is fully clear that Eclipse BfB only constitutes one specific view on what this communication semantic can look like, the published definitions have been proven to be useful in production.

What's more, the Eclipse BfB tooling offers a simple but effective solution for decoupling the definition of (and reasoning about) APIs from specific technology patterns, and thus also from organizational structures (compare Conway's law) - again, this has been proven to be effective for driving consensus about APIs in the real-world.

Licenses

Future Work

In the future, the Eclipse BfB project can be extended by concrete specifications for common automotive use cases. Examples can be

- managing, starting and monitoring SW updates in the vehicle over the air

- managing data collection in the vehicle and transferring it into the backend

- sending commands from the backend to the vehicle

Other possible extensions in the future may include new adaptors and compilers for even more communication protocols, like e.g.

- SOAP schema

- Apache Kafka connectors

Complementing the Eclipse BfB tooling, we are preparing reference client implementations and use-case oriented API definitions to be published in SDV later this year.

People

Project Leads

Committers

Mentors

Source Code

Source Repository Type

Read more about Eclipse Backend function Bindings (BfB)
Log in to post comments

Eclipse SommR

Basics

Project

Eclipse SommR

Parent Project

Proposal State

Created

Background

The usage of ethernet in automotive offers a bandwidth between 10 Mbit/s and 1 Gbit/s and a commonly used protocol in this environment is SOME/IP (Scalable service-Oriented MiddlewarE over IP). It allows applications to offer and consume services within the vehicle network and sits on top of TCP/IP addressing a variety of automotive usecases. (RPC, fire-forget messaging, optimized serialization, ..). SOME/IP can be implemented as well for small micro controllers in static RTOS systems.

Commonly used implementations only covered C++ or have been embedded in vendor specific product offerings. In future, we see the clear need to support modern and robust languages like RUST in the automotive ecosystem.

Scope

Eclipse SommR provides an automotive grade implementation of the someIP specification for embedded Linux systems together with the required tools to support developers.

Description

Eclipse SommR provides an automotive grade implementation of the someIP specification for embedded Linux systems together with the required tools to support developers.

Eclipse SommR fosters interoperability between EUCs (Electronic Control Units) and help engineers to focus on application development in less time. In contrast to existing solutions, Eclipse SommR is language agnostic. Initially we plan to support C++, Rust and Java for the applications using Eclipse SommR. The project will support additional language implementations in the future, given these make sense in the embedded automotive world.

The core of Eclipse SommR contains a daemon, which is implemented in RUST. The daemon provides the core functionalities required for SOME/IP.

Why Here?

Eclipse SDV as a foundation and umbrella for automotive software allows carmakers and the industry to create viable building blocks without the need to take full stacks with potentially hidden dependencies. Every ethernet ECU nowadays needs a SOME/IP implementation. Therefore, Eclipse SommR at SDV aims to provide such an efficient building block that could be used by pretty much every Linux based ECU in the future.

As the vehicle is not simply a datacenter on wheels, we as an industry need to consider the embedded constraints of our systems. Future trends like higher integration, usage of powerful multicore SoCs will still need an efficient, robust and performant implementation of common protocols to work towards interoperability within our vehicle network.

Licenses

Legal Issues

Due to already existing implementations (https://github.com/COVESA/vsomeip) we do not expect legal issues.

Project Scheduling

We plan to open source of the initial the MVP during Q3/22. This would allow the SDV community to get in touch with the codebase at the upcoming SDV hackathon end of 2022.

Future Work

Roadmap and upcoming items:

* Feature complete regarding the specification

* Support of additional language bindings

* Verification and Verification suite

* Design guidelines and pitfalls to avoid

* Generated requirements coverage report, potentially with OFT

Description

Eclipse SommR provides an automotive grade implementation of the someIP specification for embedded Linux systems together with the required tools to support developers.

Eclipse SommR fosters interoperability between EUCs (Electronic Control Units) and help engineers to focus on application development in less time. In contrast to existing solutions, Eclipse SommR is language agnostic. Initially we plan to support Rust and Java for the applications using Eclipse SommR. The project will support additional language implementations in the future, given these make sense in the embedded automotive world.

The core of Eclipse SommR contains a daemon, which is implemented in RUST. The daemon provides the core functionalities required for SOME/IP.

People

Project Leads

Committers

Mentors

Source Code

Initial Contribution

SommR MVP

Stack features (Java/Rust)
- Service Discovery
- Request/Response RPC
- Code Generator
- Daemon (Rust) + Client Libraries
Documentation, Examples, Tutorials and Integration Tests
Mac/Linux

Source Repository Type

Read more about Eclipse SommR
Log in to post comments

Eclipse Leda

Basics

Project

Eclipse Leda

Parent Project

Proposal State

Created

Background

The newly instantiated Eclipse SDV working group is currently gearing up to receive a first batch of project proposals for technology building blocks that will begin to populate the landscape of what will become an SDV ecosystem. The mid-term goal is to form a technology ecosystem, where a myriad of projects and companies contribute diverse functional additions around a set of core APIs, extension points and integration patterns. To enable developers and users of the SDV ecosystem, an SDV distribution is expected to help integrating several individual components and various other open-source projects to a ready-to-use development environment for new and existing components, as well as creating a basis for automotive-grade, production-ready SDV solutions.

Scope

The Eclipse Leda project will provide system image “recipes” to deliver a functional Linux-based image/distribution in the context of SDV (Software Defined Vehicle), by pulling together individual contributons from the SDV and the larger OSS community.

The Eclipse Leda distribution will work with build scripts, package definitions, image build pipelines, etc, with the goal to pull SDV projects and dependecies from the larger OSS community into a working Linux system. Such system images (or other useful forms of delivery, as determined by the project) will be made available for consumption for anyone who is interested in working with the SDV tech stack. These deliveries take the form of container (base) images, installable/flashable image files, etc (again to be evolved by the project team according to community needs). Also in scope is concise and useful documentation for consumers of the project's deliverables, plus a method of delivering that documentation.

Description

In the context described above - the ambition of SDV to build a technology ecosystem for software-defined vehicle concern - a prime challenge will be the combination of these initially diverse components into a coherent and useful whole: all the software components in the world will not have the impact needed to transform the automotive industry unless we can make them play together coherently an form a functional portfolio. As a first step towards that goal, this proposal (Eclipse Leda) is for a "SDV distribution" project that pulls together individual contributor pieces from SDV and the larger OSS community, to deliver a functional and always-available Linux-based image/distribution with two primary goals:

be the crystalization point for functionally integrating diverse SDV-scope projects into a working whole
deliver a continually available, always working starting image for developers interested in getting going with the SDV tech stack

Why Here?

The Eclipse Leda project aims to become the integration point for individual SDV-related projects, so it only makes sense in the scope of the Eclipse SDV working group. At the same time, it could be a driving force for showcasing SDV to the wider communtiy, and for providing a great onboarding experience to SDV-driven technology.

Licenses

Legal Issues

none

Project Scheduling

Initial contribution expected by Q2 2022
Release cycles are planned every 3-6 months
Release planning will be conducted together with corresponding Eclipse projects

Future Work

Be the integration and collaboration platform for Software defined Vehicle functionality.

include/update [Eclipse kanto] parts
include [Eclipse velocitas]
include [Eclipse Backend function Bindings]
add Open Telemetry
include more functionality of SDV special interest group

People

Project Leads

Christian Heissenberger

Mike Haller

Committers

mhaller

chheis

mariaivanova

bym2hi

elpaso

Mentors

Jens Reimann

Interested Parties

Robert Bosch GmbH
ETAS
Microsoft

Source Code

Initial Contribution

The Eclipse Leda project will start out with the following setup:

yocto build system and build chain setup
built on Poky base image
bootable image for Raspberry Pi4 and QEmu
include Eclipse kanto Edge stack
pull in a set of OSS dependencies (e.g. Eclipse Mosquitto)
an initial set of smoke tests

Source Repository Type

Eclipse Migration Toolkit for Java

Read more about Eclipse Leda
Log in to post comments

Eclipse Migration Toolkit for Java

Basics

Project

Parent Project

Eclipse Adoptium®

Proposal State

Created

Background

With the gradual popularity of Java 11 and the official release of Java 17, many applications that are still using Java 8 have begun to migrate to higher versions. During the migration process, developers will encounter many problems, hindering their progress.

The project goal is to simplify the migration of Java applications from previous versions of OpenJDK, especially those deemed as Long Term Service (LTS) release versions. That is:

from 8 to 11
from 8 to 17
from 11 to 17

The proposed migration toolkit supports examining application artifacts statically, including project source directories and applications archives, or running as a dynamic agent for runtime detection. The toolkit can produce the analysis results in different formats, including a raw TEXT file, JSON file, or HTML report highlighting areas that need changes for migration.

Scope

Eclipse Migration Toolkit for Java offers a toolkit that simplifies the migration of Java applications from previous versions of OpenJDK, especially those deemed as Long Term Service (LTS) release versions.

The toolkit contains core rule-based services available through different user interfaces, including a command-line interface (CLI), build automation tool plugins, a Java agent, and some other popular DevOps tooling as the project sees fit. Finally, it will produce various report formats (TEXT, JSON, HTML) to help developers migrate to the Java version.

Participants in the project are responsible for developing, managing, and supporting technologies that:

Develop the rule-based services for the Java version migration. LTS versions are the primary focus.
- Define the rule set for the best coverage in Incompatible/Internal/Deprecated/Removed JDK API usage, closely collaborate with the OpenJDK community, and maintain/enrich them along with the new OpenJDK release.
Develop the rule-based service for Java options migration across different OpenJDK versions
- Define the ruleset to identify the Removed/Deprecated/Replaced/Recommended options while upgrading to the new JDK version.
Define the dependency checking rules for popular third-party libraries and engage third-party communities to maintain the validating relationship between the version of the third-party library and their supported Java release.
Implement the mechanism to analyze and detect the dependencies on the internal structure layout of JDK classes via Reflection API and the incompatibility issues introduced by Java modularity.
Support the integration with the automation build tools, such as Maven, Gradle, etc., via plugins.
Develop various friendly user interfaces, which rely on core rule-based services to assist the users for easy migration, including CLI, Web UI, and Agent.
Provide the results in different formats highlighting areas that need changes for the migration.
Provide documentation assistance for different version migrations.
Integrate with JDK built-in tools: jdeps and jdeprscan.

Description

The Eclipse Migration Toolkit for Java is a tooling project for assisting the Java version migration. The project provides static/dynamic tools and documents that support the migration of Java applications from previous versions of OpenJDK. The needed changes are highlighted in the final analysis reports.

To better illustrate what the tool can provide, consider the user story like this:

1. Tom is a Java developer who is migrating his application from Java 8 to Java 11.

2. His application consists of 1000~ jars, written in 100,000~ lines of code. Tom reads related migration guides on the internet and finally finds it is tough to check/make all required changes in such a large codebase suggested by these migration docs.

3. Tom decides to use this toolset for his migration.

4. Tom attaches the Java agent in the toolset to his application when the application is started with Java 8. He runs all test cases of this application in the test environment. After completion, a compatibility report is generated for him.

5. Tom makes the required changes according to the capability report. He also uses the command-line tool to scan all jars of this application, ensuring all potential problems are fixed.

6. After completing all changes suggested by the toolset, his application runs with Java 11 successfully.

Why Here?

The Eclipse Foundation has always been the home for vendor-neutral developer tools developed under open-source governance. We think the Eclipse community will help make it a diverse and successful open-source project. Software organizations have to tackle the challenges incurred by version migration when they best keep their projects valuable over a long time. We hope this project can help their projects succeed in the long term. Moreover, hosting this project at Eclipse will help more synergies with Adoptium and other Eclipse Java projects.

Licenses

Future Work

After the initial contribution, we are planning to engage more parties to participate in and co-work with communities to:

Improve the static analysis tool, and reduce the false positive rate
Enhance the migration rule set, and the Java 17 migration support
Support the toolset integration with other EF Java projects
Explore the methods to automatically generate checking rules based on CSR (compatibility and specification review)

People

Project Leads

Committers

Mentors

Source Code

Source Repository Type

Can you give an example

Submitted by Kai Hudalla on Wed, 04/13/2022 - 01:48

of an incompatibility that I might run into when trying to run/compile my Java 11 based application with a Java 17 JDK?

Re: Can you give an example

Submitted by Denghui Dong on Fri, 04/15/2022 - 23:16

Thanks for the comment.

An example we encountered in practice is that some middleware will rely on the reflection API to obtain fields or methods of ClassLoader. JDK-8210496 restricts the reflection access of ClassLoader and some other special classes.

This kind of access works fine on 11 but runs into problems on 17, and the migration tool can help developers find code locations where this problem may occur.

Read more about Eclipse Migration Toolkit for Java
2 comments
Log in to post comments

Eclipse jbom

Basics

Project

Eclipse jbom

Parent Project

Eclipse Technology

Proposal State

Created

Background

Eclipse jbom was initially created to create Runtime SBOMs (Software Bill of Materials). There are significant weaknesses creating SBOMs from static analysis of code repos or binaries. Runtime SBOMs capture library and service information directly from a running application using instrumentation, ensuring only truly deployed libraries are included, including platform and appserver libraries not available statically. Jbom was later extended to support remote SBOM generation as well as binary static SBOMs.

Scope

Eclipse Jbom generates Runtime and Static SBOMs for local and remote Java apps. The project focuses on making fast and highly accurate SBOMs as easy as possible.

Description

Every software project ideally should create a Software Bill of Materials (SBOM) and make it available to the public, so that people know the exact version and other details about libraries leveraged by the project.

Eclipse jbom generates "Runtime SBOM" by directly measuring library use in a running application (both local and remote). This is the most accurate approach as it captures the exact libraries used by the application, even if they are in the platform, appserver, plugins, or anywhere else. This approach also include details of services invoked and which libraries are active. Eclipse jbom also offers the possibility to generate static SBOMs both from source and binaries.

Eclipse jbom:

offers a fast, complete, and accurate SBOM generator
produces standard CycloneDX SBOM in JSON format
works on both running apps/APIs and binaries
finds all libraries, including platform, appserver, plug-in, and dynamic sources
doesn't report test or other libraries not present at runtime
handles nested jar, war, ear, and zip files (including Spring)
handles jars using common shaded and relocation techniques
no source code required

Why Here?

We believe that all software should be delivered with a complete and accurate software bill of materials. We think the Eclipse Foundation is a good organization to help promote software transparency and make it easily accessible to all developers.

Licenses