Proposals

Eclipse SysDaC modernizes the code journey from requirements to test, covering system architecture aspects like topology, interfaces, deployment, and communication.  The language is designed for creation and interpretation by AI agents, yet remains natural for humans to author and review.

Eclipse SysDaC provides a foundation for new workflows and collaboration models by:

• Centralizing the system description in a single model
• Enabling code-like collaboration with Git workflows
• Supporting agentic development loops

It also serves as input for automated derivation of downstream artifacts for µC- and µP-based nodes and subsystems.

In contrast to existing approaches, the project is built on two core principles: an open-source foundation and a consistent configuration-as-code methodology. It is explicitly designed for cross-industry use, covering automotive, commercial vehicles, medtech, agriculture, industrial automation, avionics, and defense.

The project consists of the following building blocks:

1. Schema (meta-model) and text-based syntax for SysDaC files
2. Tooling for creating and validating of SysDaC files
3. Documentation and examples

The initial contribution will be sponsored by Technica Engineering GmbH (Member of KPIT Group) and Vector Informatik GmbH, which will each fund a first group of committers. The project is nevertheless intended to be governed as an open, vendor-neutral community from the outset, and contributions from OEMs, Tier-1 suppliers, tool vendors, and adopters in other industries are actively invited.

Eclipse SCINTX (Supply Chain Intelligence Exchange) is a vendor-neutral open standard and reference implementation for package-security integration. It sits between package registries / CI systems and security providers. Users submit package artifacts (e.g. by PURL and digests). The gateway assesses them via pluggable providers, evaluates consumer policy, and returns portable decisions and findings. Outcomes can be delivered by polling or signed CloudEvents webhooks; consumers may adjudicate review decisions and share the final allow/deny gate back to the gateway.

The goal is to eliminate duplicated registry–vendor integrations, make security verdicts comparable and portable, and let registries and enterprises mix-and-match conforming providers without lock-in.

Eclipse Coffee Builder for Jakarta EE is an open source tool that helps developers create and evolve Jakarta EE applications progressively.

Eclipse Coffee Builder creates a small and understandable Jakarta EE project foundation that developers can extend by adding capabilities as their application evolves. Each capability can introduce the dependencies, Maven configuration, and supporting project structure required for the selected Jakarta EE technologies.

The central idea of Eclipse Coffee Builder is:

"Eclipse Coffee Builder generates the foundation. The developer builds the application."

This approach keeps the generated project transparent and allows developers to understand how Jakarta EE technologies are introduced into the application, including their dependencies, build configuration, and project structure.

Eclipse Coffee Builder is intended to serve primarily as a practical development tool while also supporting developers who want to better understand how Jakarta EE applications are assembled. By making the evolution of the generated project explicit, Eclipse Coffee Builder encourages developers to remain in control of the resulting application rather than treating generated code and configuration as a black box.

Eclipse AAS Core Works provides reusable core libraries and tooling for working with Asset Administration Shells (AAS), the standardized Digital Twin concept used in Industry 4.0.

The project formalizes published AAS meta-models in machine-readable form and uses these representations to generate consistent SDKs, schemas, serialization logic, verification logic, package handling libraries, test data, and utility tools across multiple programming languages.

The goal is to make it easier for tool builders, application developers, researchers, and other Eclipse Digital Twin projects to create, validate, serialize, deserialize, inspect, package, and exchange AAS data with a high degree of correctness and consistency.

Eclipse Atesor is an agentic, state-driven system that takes a Git repository URL (only required input) and returns a verified RISC-V build together with a complete porting recipe. The architecture is a hierarchical planner / supervisor / executor graph implemented with LangGraph, in which roughly 70% of routine analysis is handled by deterministic, zero-LLM scripted operations and the remaining steps are delegated to specialised agents that operate strictly inside a sandboxed RISC-V container. These LLMs are fine-tuned very precisely to handle build-neutral package porting.

The system is composed of the following coordinated agents:
 

PLANNER
Derives a high-level TaskPlan from the repository's structure, build system, and detected architecture-specific code.
 

SCOUT
Produces a concrete BuildPlan (configure, compile, install, verify) tailored to the detected build system (CMake, Make/Autotools, Meson, Ninja, Go modules, Cargo).
 

BUILDER
Executes the plan inside the RISC-V sandbox, captures structured output, and records every command, exit code, and duration.

FIXER
When the Builder reports an error, classifies it (dependency, compilation, linking, architecture, configuration, missing tools, …), retrieves relevant few-shot examples, and proposes either shell remediations or source patches that are re-applied through a validated patch pipeline.

SUPERVISOR
Verifies agent outputs against known anti-patterns (hallucinated commands, unsafe operations), routes the next step, and escalates when the system detects a loop, repeated error category, or budget exhaustion.
 

SUMMURIZER
On success, writes a Markdown porting recipe and persists the build to a recipe cache so that future requests for the same package short-circuit the LLM pipeline entirely.

The project further includes a lightweight few-shot memory system. Curated examples for each agent role live in JSON files in the repository; successful porting runs can append novel patterns back into this store under file-lock-protected I/O. This delivers measurable accuracy improvements without requiring a vector database or any external infrastructure. 

A separate recipe cache records every package that has been successfully ported, keyed by package and sandbox profile, so that a project ported once can be re-built deterministically by anyone without re-invoking any LLM.

Eclipse QSOS (Qualification and Selection of Open Source Software) is a methodology and a collaborative tool that allows users to collaboratively define, evaluate, qualify and compare open source software based on the specific needs and constraints of a company, organization, project or individual.

The QSOS methodology provides a structured framework for analyzing the maturity of open source solutions, based on predefined generic criteria. In addition to the maturity, it also allows users to define evaluation grids with specific criteria for each type of software.

Once software are evaluated through this framework, users can qualify their needs through requirements presets that are weights applied to the evaluation grid.

Finally, users can compare open source software. The comparison results can be visualized as a table, bubble chart or radar chart.

The end goal of this project is to share the effort of evaluating and referencing open source solutions through a collaborative platform, to facilitate the selection of the most suitable open source software for everyone’s needs.

Every hospital, clinic, and lab runs on a patchwork of software systems that were never designed to talk to each other. A patient's record might live in one application, their lab results in another, their imaging in a third, and their billing in a fourth - each speaking a different digital language, often built decades apart. Getting these systems to share information reliably is one of the most persistent and expensive problems in healthcare, and it is the problem the Eclipse Open Integration Engine exists to solve.

Eclipse Open Integration Engine sits between healthcare systems and translates between them. When one system needs to send information to another, the engine receives the message, converts it into a format the receiving system understands, applies any rules the organization has defined, and delivers it. It does this thousands or millions of times a day in production environments around the world, quietly handling the flow of clinical and administrative data that keeps a healthcare organization running. Healthcare IT teams use it to connect electronic health records to laboratory systems, to route imaging orders, to feed data warehouses, to exchange information with public health registries, and to bridge older systems with modern, standards-based interfaces.

The project provides three things: the engine itself, an administrator application for designing and monitoring message flows, and the documentation needed to operate both. Implementers organize their work into channels, each representing a single integration between systems. A channel defines where messages come from, what should happen to them along the way (filtering, transformation, enrichment, routing), and where they should go. Channel logic is expressed in a combination of configuration and JavaScript, which gives integration teams enough flexibility to handle the unusual real-world cases that healthcare data is famous for, without forcing them to build and deploy custom applications.

Under the hood, Eclipse Open Integration Engine is a cross-platform integration engine (written in Java) that acts as an interpreter for healthcare systems, translating message standards into formats that target systems can process. The engine allows health IT teams to manage message pathways (channels) through filtering, transformation, extraction, and routing stages. It supports bidirectional conversion between standards like HL7, JSON, and XML. The project features a modular architecture with custom JavaScript-based scripting and connectors for protocols like HTTP/S, FTP, and direct database connectivity. It also includes a management administrator interface for channel development and operational monitoring.

AI coding agents are most useful when they can act autonomously: run commands, install packages, edit files, and iterate without asking for permission at every step. Granting that autonomy directly on a developer's host machine is risky: agents can damage system files, leak secrets, fall victim to prompt injection, or interfere with one another when running in parallel. Most organizations have no consistent way to constrain or audit what their agents actually do.

Eclipse Enclave addresses this gap by providing a sandboxed runtime in which agents operate inside isolated containers (and, in the future, microVMs or other isolation backends) with their own filesystem, process tree, and network stack. A sidecar gateway restricts outbound network traffic to allowlisted domains and records what each agent reached out to. Multiple agents work in parallel without interfering with each other by operating on separate Git worktrees of the same project. Auth, configuration, and history persist across restarts under user control. A control center surfaces the state of all running agents and provides a single place to start, stop, inspect, and review their work.

The same isolation, logging, and policy infrastructure that makes agentic development safer for individual developers also produces the evidence and controls needed by organizations to operate agents responsibly: per-session audit trails, network access logs, dependency provenance records, and policy enforcement points that map to requirements emerging from the EU AI Act and the EU Cyber Resilience Act.

Eclipse Enclave deliberately separates agent execution from agent identity. It treats agents as pluggable workloads behind a common runtime, configuration, and policy surface. This lets the community focus on isolation, observability, governance, and integration — and lets adopters mix and match agents and editors without rebuilding the surrounding infrastructure each time.

In summary, the Eclipse Particle Cloud Security (PCS) project provides vendor-neutral, open source technology for multi-provider storage protection, improving data sovereignty by ensuring no single provider can recover customer plaintext from its store alone, while supporting recovery and embedding in existing storage software and services.

Eclipse Bucky is a lightweight Java S3 client with no 3rd party dependencies. It is designed to be minimal and easy to use, providing a straightforward interface for interacting with Amazon S3 compatible services.
After much searching we could not find a Java S3 client that did not have a large number of dependencies. This client only uses the Java standard library.