Proposals

The Jakarta Faces Bridge project is responsible for defining the Specification and API, which enables the development of Jakarta Faces web applications that can be deployed within a portlet container running inside a Jakarta EE servlet container or application server. The Faces Bridge Specification defines requirements for mapping the portlet lifecycle (HEADER_PHASE, EVENT_PHASE, ACTION_PHASE, RESOURCE_PHASE, and RENDER_PHASE) to the Faces lifecycle (RESTORE_VIEW, APPLY_REQUEST_VALUES, PROCESS_VALIDATIONS, UPDATE_MODEL_VALUES, INVOKE_APPLICATION, and RENDER_RESPONSE). The goal is to provide Jakarta Faces developers with the ability to deploy their web applications in a portlet container with little-to-no-modification.

The Jakarta Portlet project is responsible for defining the Specification and API, which enables the development of modular, server-side components that can be deployed within a portlet container running inside a Jakarta EE servlet container or application server. 

The Portlet Specification defines requirements for the portlet container, including an execution lifecycle and phases such as HEADER_PHASE, EVENT_PHASE, ACTION_PHASE, RESOURCE_PHASE, and RENDER_PHASE. The portlet lifecycle follows a request/response design similar to the servlet lifecycle, where each portlet has the opportunity to participate in the lifecycle and contribute output to the response. The Specification also specifies requirements for a client-side JavaScript API, including a client-side facility called the Portlet Hub. The Portlet Java API, Javadoc, and JSDoc define the contract for a portlet application to interact with the portlet container. A portlet application consists of one or more portlets that are packaged within a single Jakarta EE Web Application Archive (WAR) artifact.

The Specification also defines minimal requirements for a portal, which is a related technology responsible for aggregating output from a portlet container into a cohesive view, typically a complete HTML document rendered in a browser. Portals typically provide other features, such as page definition, portlet location on pages, and user management.

Eclipse Disco focuses on consuming SBOMs and the resulting actions based on their assessment. It is not meant to produce SBOMs from source code since that is well-supported already by other projects. SBOMs might be created by combining imported SBOMs though. Eclipse Disco comes with a license and policy database that helps a project owner to assess FOSS licenses based on self-configured use cases and understand the resulting license obligations. The content of this license and policy database is out of scope of Eclipse Disco (hence it will be empty except for some examples) since this relies on the local legal interpretation of FOSS licenses.

Eclipse Readability Studio is a desktop applications which provides:

• over 50 readability formulas
• grammar checking features
• ability to analyze individual documents
• ability to analyze batches of documents at once
• support for English, Spanish, and German documents
• support for MS Word, OpenDocument, RTF, HTML, PostScript, and text files

Just as the SAE Levels of Autonomy helped to level-set discussion on autonomous driving, the Eclipse SDV-LVL defines a common terminology/taxonomy for capabilities of SDV. In the field of highly automated driving the industry has converged to a concise language, where there is a universal understanding of what constitutes a Level 3 function. This project defines a comparable language.

To support industry-wide adoption, all descriptions and visuals developed in this project are made accessible and usable for day-to-day communication.

As a consequence of the primary goal (definition of taxonomy and stable language), Eclipse SDV-LVL maintains stability in the structure and semantics of its levels. When adaptations are necessary, the focus is on extensions and clarifications rather than altering fundamental meanings. Meanwhile, the perspective on enablers and key characteristics of software-defined vehicles will evolve over time to keep pace with technological and organizational advancements.

Furthermore, the project favors brevity and conciseness over completeness. Any taxonomy will exhibit grey areas which are expected. Rather than expanding the levels to cover a multitude of “shades of grey”, simplicity is favored. This also holds true to the section of enablers where a complete and unequivocal list is impossible to create. 

The Eclipse Trustable Software Framework project's focus is practical approaches to understanding risks in software engineering.

Describing and quantifying these risks requires a scalable framework that can be applicable for systems of varying degrees of complexity. Complex systems involving software, hardware, safety, and security properties can greatly benefit from continuous quantitative analysis to inform decision-making.

A single generalised system cannot address all domains effectively, so Eclipse Trustable Software Framework aims to evolve into an ecosystem built around a unified methodology in the longer term. The first step in this journey is the Trustable Software Framework (TSF) and its set of Tenets and Assertions: short statements (propositions that could be either true or false) identifying what objectives software projects must consider in order to be considered Trustable. 

TSF specifies how metadata about a software project is stored and managed in a git repository, alongside the software's source code and documentation. This involves systematically tracking a set of statements that specify the software project, which form a directed acyclic graph (DAG) and provide metrics for continuous analysis and iteration.

These statements document claims about the software or the project, identify evidence that supports these, or specify requests that must be satisfied by another claim - or by something or someone external to the project. The graph describes how high-level or external goals for the software project (Expectations) are supported by more specific objectives (Assertions) and ultimately Evidence. The latter must necessarily reference artifacts: files in a git repository, or the result of automated processes operating on such files.

This approach is intended to replace traditional techniques that rely on office tools like MS Word or Excel to author documentation, and specialised commercial tooling to manage system specifications and requirements, and trace these to implemented software and tests. Such approaches frequently fail to maintain integrity in complex, continuously evolving systems, because they are not closely integrated with the software that they describe.

Advantages of Transferring OSCAT to the Eclipse Foundation

Introduction to OSCAT

The Open Source Community for Automation Technology (OSCAT) is a well-established initiative that provides a suite of software packages designed to enhance automation technology. OSCAT consists of three main packages: OSCAT-Basic, OSCAT-Network, and OSCAT-Building. These packages are compatible with various platforms, including CODESYS 2.3, CODESYS 3.5, Siemens S7, and PC Worx (All other brand names and trademarks are the property of their respective owners and are used for descriptive purposes only). OSCAT's mission is to offer open-source solutions that facilitate automation in industrial and building environments, promoting innovation and accessibility in the field.

Benefits to OSCAT

1. Enhanced Governance and Structure:
   • Vendor-Neutral Governance: The Eclipse Foundation offers a vendor-neutral governance model that ensures fair and transparent decision-making processes. This structure can help OSCAT maintain its integrity and independence, avoiding potential conflicts of interest.
   • Intellectual Property Management: The Eclipse Foundation has established processes for managing intellectual property, which can protect OSCAT's assets and ensure compliance with legal standards.
2. Increased Visibility and Adoption:
   • Global Recognition: Being part of the Eclipse Foundation can significantly boost OSCAT's visibility within the global open-source community. The Eclipse brand is well-respected and widely recognized, which can attract more users and contributors.
   • Community Engagement: The Eclipse Foundation's extensive network can facilitate greater community engagement, fostering collaboration and innovation. This can lead to more rapid development and improvement of OSCAT.
3. Access to Resources and Infrastructure:
   • Technical Infrastructure: OSCAT can benefit from the Eclipse Foundation's advanced technical infrastructure, including build systems, code repositories, and continuous integration tools. This can streamline development processes and improve software quality.
   • Funding and Support: The Eclipse Foundation can provide financial support and resources for marketing, events, and other activities that promote OSCAT. This can help sustain and grow the project over time.

Benefits to the Eclipse Foundation

1. Expansion of Project Portfolio:
   • Diverse Ecosystem: Integrating OSCAT into the Eclipse Foundation's portfolio can diversify its ecosystem, attracting new contributors and users from different domains. This can enhance the Foundation's overall impact and reach.
   • Innovation and Collaboration: OSCAT's unique features and capabilities can inspire new projects and collaborations within the Eclipse community, driving innovation and technological advancement.
2. Strengthening Open-Source Standards:
   • Standardization Efforts: The Eclipse Foundation's collaboration with standards organizations can benefit from OSCAT's inclusion. OSCAT can contribute to the development of open-source standards, promoting interoperability and best practices.
   • Compliance and Security: By adhering to the Eclipse Foundation's rigorous development processes, OSCAT can enhance its compliance with industry standards and improve its security posture.
3. Community and Ecosystem Growth:
   • Broader Community: The addition of OSCAT can attract a broader community of developers, users, and stakeholders to the Eclipse Foundation. This can lead to a more vibrant and diverse ecosystem, fostering greater collaboration and knowledge sharing.
   • Ecosystem Synergies: OSCAT can create synergies with other Eclipse projects, enabling the development of integrated solutions and expanding the Foundation's capabilities in various technological areas.

Special Focus on Home and Building Automation

The Eclipse Foundation has ongoing activities and projects focused on home and building automation. By integrating OSCAT, which includes the OSCAT-Building package, the Eclipse Foundation can strengthen its position in this domain. OSCAT's expertise and solutions can complement existing Eclipse projects, leading to more comprehensive and innovative automation solutions for smart homes and buildings.

Industrial Automation

OSCAT is widely used in Industrial Automation, which widens the Scope of the above mentioned Activities into a wider Field of Applications, giving multiple synergy effects in reusability and stability of control Software.

Conclusion

The transfer of OSCAT to the Eclipse Foundation as Eclipse OSCAT offers substantial advantages for both parties. OSCAT can benefit from enhanced governance, increased visibility, and access to resources, while the Eclipse Foundation can expand its project portfolio, strengthen open-source standards, and grow its community. This strategic move can ultimately lead to a more robust, innovative, and collaborative open-source ecosystem, particularly in the field of home and building automation.

Eclipse SEALMAN is an open-source project born from the collaboration of machine builders, offering a comprehensive suite of building blocks for intelligent machines. At its core, Eclipse SEALMAN empowers machine builders to seamlessly integrate edge computing, robust device management, seamless cloud connectivity, and efficient remote maintenance capabilities into their solutions. With a strong emphasis on cyber security, Eclipse SEALMAN provides a secure architecture that safeguards machines from the edge to the cloud, ensuring the integrity and confidentiality of data throughout the entire lifecycle.

Eclipse AASPortal is written in TypeScript and based on a distributed software architecture, that  includes a Node.js based “aas-node” and an Angular based web application “aas-portal” (using Bootstrap 5 and NgRx). Via the standardized AAS REST API, Eclipse AASPortal connects to AAS endpoints, e.g. based on Eclipse AASX Package Explorer and Server, Eclipse BaSyx, or Eclipse FA³ST. These endpoints can be configured during operation by authorized users. Additionally, operational data can be integrated via OPC UA (based on node-opcua) and visualized in corresponding plots. AASPortal enables full text search and filtering of AAS, as well as basic modelling capabilities like adding Submodel templates or editing  values of properties.

The Cyber Resilience Practices Project develops specifications designed to help improve the cyber resilience of open source projects and of the products that incorporate these projects and facilitate compliance with related regulation worldwide.

The first specification to be developed by this project is the Vulnerability Handling Specification.

The Vulnerability Handling Specification focuses on vulnerability management for products with digital elements, as outlined by the Essential Requirements of the CRA. It details the necessary components of a vulnerability handling policy, including procedures for receiving reports, resolving issues, and disclosing vulnerabilities. Additionally, it specifies the requirements for managing vulnerable dependencies.