Git

Project code is hosted on http://git.eclipse.org/c

Eclipse FA³ST

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 Asset Administration Shell (AAS) is the standardized digital representation of the asset, corner stone of the interoperability between the applications managing the manufacturing systems. AAS identifies the Administration Shell and the assets represented by it, holds digital models of various aspects (submodels) and describes technical functionality exposed by the Administration Shell or respective assets. Core elements of AAS are the metamodels and serializations, APIs, and security.

Scope

Eclipse FA³ST aims to provide an implementation of the re-active (or type 2) Asset Administration Shell according to the AAS specification.

This includes the following aspects:

  • AAS APIs, especially AAS & Submodel API, Repository API, and Registry API
  • AAS metamodel as defined in Part 2
  • JSON De-/Serialization including all content modifiers such as $value, $metadata, or $reference
  • Asset Synchronization

Implementation of the metamodel as defined in AAS specification Part 1 as well as basic de-/serialization (i.e. content modifier $normal) are out-of-scope of this project. This functionality will be provided by re-using Eclipse AAS4J.

Why Here?

The Eclipse Foundation provides a professional environment (governance, licensing, intellectual property management) for the future development of Eclipse FA³ST. These advantages facilitate the usage of an open source, extensible ecosystem and helps the software to gain more visibility in the AAS community and beyond.

Furthermore, Eclipse FA³ST nicely integrates with existing Eclipse projects in the AAS domain such as Eclipse BaSyx and Eclipse AAS4J that are already part of the Eclipse Digital Twin Top-Level Project.

Project Scheduling

Eclipse FA³ST and its involved parties intend to move to Eclipse as soon as possible. The plan is to release v1.0 of the software under the existing FA³ST project and then transfer the repositories to the new Eclipse FA³ST project and continue development there.

Future Work

Eclipse FA³ST wants to build an open source community in Eclipse to coordinate the building of an extensible ecosystem in which manufacturers and suppliers, including the providers of applications, platforms and infrastructure, can all participate equally.

Concrete next steps will include features like generic handling of SubmodelTemplates, i.e. to manage time series data within an AAS according the the SubmodelTemplate TimeSeriesData specification.

Description

Eclipse FA³ST aims to provide an implementation of the re-active (or type 2) Asset Administration Shell according to the Asset Administration Shell (AAS) specification by Plattform Industrie 4.0.  In contrast to other implementations such as Eclipse BaSyx, Eclipse FA³ST will focus on the deployment at edge-level rather than cloud-level, meaning that its primary focus will be on asset connectivity rather than scalability. Other expected key features are

  • Easy to set-up & use
  • Open architecture which enables easy customization and extension
  • Implementation of API for HTTP and OPC UA
  • Protocol-agnostic synchronization with assets
  • Usage via command-line interface, docker container, and as embedded library
Interested Parties
  • Fraunhofer-Gesellschaft e. V.
  • Industrial Digital Twin Association e. V.
  • Deutsches Zentrum für Luft- und Raumfahrt e. V.
  • Deutsche Nickel GmbH
  • EKS InTec GmbH
  • KETI (Korea Electronics Technology Institute)
  • MHP Management- und IT-Beratung GmbH
  • NTNU - Norges Teknisk-Naturvitenskapelige Universitet
  • SAP SE
  • SINTEF AS
  • Teknopar Industrial Automation
  • University of Piraeus Research Center
Initial Contribution

Currently the project exists in two separate repositories under the FraunhoferIOSB organization on Github which are considered as initial contribution to this project

https://github.com/FraunhoferIOSB/FAAAST-Service

https://github.com/FraunhoferIOSB/FAAAST-Registry

 

We intend to create a new project-related Github organization (as the current one is affiliated with Fraunhofer) and transfer the repositories there.

Source Repository Type

Eclipse OpenXilEnv

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

SIL (Software In the Loop) is becoming increasingly important during the embedded software development cycle. At the time, there was no fitting SIL environment available, aiming for the support of the embedded classic software development.

Furthermore, a demand for interconnection of software of different organizations inside the SIL environment was established.

Scope

Eclipse OpenXilEnv provides an environment for creating SIL systems for the Software Defined Vehicle ecosystem. It doesn't specificly base on or supply a pre-defined model. Through its versatile nature it is also possible to use it in a HIL environment.

Why Here?

ZF believes as founding member of the Eclipse SDV community in the principle of sharing software. By allowing others to use and contribute, this will benefit all, including ZF.

A lightweight SIL/HIL environment will be of great use by others developing embedded software functions. We would contribute the environment that supported us with many projects. In return we hope for the contribution from others especially towards achieving better interoperability with other SIL users/systems.

Project Scheduling

First public version of OpenXilEnv available Q4 2023.

Future Work

Interface to CARLA

Extend FMI interface to version 3.0

More virtual networking (automotive ethernet).

Description

Eclipse OpenXilEnv is a lightweight SIL/HIL environment that allows running embedded software functions on a PC without a target platform and compiler.

Eclipse OpenXilEnv will provide a configurable graphical user interface and an API for automation.

Use case scenarios:

  • Software in the Loop
  • Model in the Loop
  • Open Loop
  • Hardware in the Loop
  • Module tests
  • Network tests
  • Complete digital twin test
  • Manual tests
  • Automated tests
  • Rapid prototyping
  • Offline calibration

Some highlights are:

  • Easy integration of the code under test
  • Clean separation in own executables (memory protection) Communication over a network layer
  • Platform independent (Windows/Linux)
  • User interface (Qt) with a lot of display items (text, oscilloscope, tacho, ...),  items for manual intervention (text, slider, knob, ...)  and calibration items for single, curve and map parameters
  • Tree view of all static parameter and variables (debug information)
  • Can be extensively automated with a remote procedure call interface (Python) or a build-in script interpreter
  • GUI less variant exist for automation (Headless Variant)
  • Parallel execution (multi core) of test code 
  • Support of FMUs with FMI2.0 interface (64 and 32 bit)
  • Residual bus simulation of non-existing CAN (FD) bus members
  • Recording and replay in stimulation is possible with text or MDF3 files
  • Debug information parser (dwarf)
  •  A small A2L parser is included for calibration.A XCP over ethernet port to connect a calibration system
  •  Parallel execution (multi core) support with barriers for synchronisation.

OpenXilEnv was developed and maintained at ZF for the last 25 years and used in numerous projects.

Initial Contribution

ZF Friedrichshafen AG has the code ownership and holds the copyright of the intial contribution.

Used third-party libraries and associated licenses:

  • Qt6 Library (LGPL3 License)

optional:

  • pugixml (MIT License)
  • esmini (Mozilla Public License Version 2.0)
Source Repository Type

Jakarta Data

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?
Patent License
Implementation Patent License
Project
Parent Project
Proposal State
Created
Background

Persistence is the soul of modern architecture. It is a way to have a state in the stateless application, mainly in distributed systems such as microservices and cloud age app style.

Software Engineers handle various persistence sources such as SQL, NoSQL, or even web services. With a considerable amount of options or flavors, how can they have a business away from these details or have a loose couple between the application and the persistence engine?

 

There is the Domain-Driven Design (DDD), which puts the code closer to the expert's vocabulary in brief words. And inside this design, there is Repository pattern to approach where it mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects. 

The goal of this specification is an API abstraction between the persistence and the application DDD inspired.

We'll create this API inspired by several solutions in the market, such as Spring Data, Apache Delta Spike, Jakarta NoSQL, Quarkus, and so on.

Scope

Jakarta Data defines core APIs for the Jakarta EE platform allowing applications and other Jakarta EE components to explore the benefits of easy access to data technologies such as relational and non-relational databases, cloud-based data services, and so on.

Description

Jakarta Data provides an API to allow easy data access technologies. Thus, a Java developer can split the persistence and the model with several features such as a Repository interface with the method by query, where the framework will implement it.

 

References

Why Here?

This project is intended to be included in the Jakarta EE platform, which is hosted at the Eclipse Foundation.

Project Scheduling

We plan to release the first version in Jakarta EE 11 together with Jakarta NoSQL.

Initial Contribution

None.

Source Repository Type

Eclipse Native Launcher Modernization

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

I am a maintainer for a commercial product that is built on elipse.  As operating systems evolve the main focus of many operating system changes is security.  Software manufacturers have to keep with the times to avoid having their software failing to be installed through various security gatekeepers.

Scope

1. Convert to using Cmake instead of make files in order to build the eclipse library and launcher

2. Update the library and launcher code to remove any deprecated calls

3. explore the addition of code signing into the projects and code hardening options that may be required by operating systems such as MACOS

Source Repository Type

Jakarta Contexts and Dependency Injection V2

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?
Patent License
Implementation Patent License
Parent Project
Working Group
Proposal State
Withdrawn
Background

The Java EE CDI spec was moved from the JCP project to the Eclipse Foundation as part of the move of Java EE. Red Hat led the CDI spec since its inception at the JCP, and introduce ASL as the license model as well as open source specifications, APIs and TCKs. The evolution of the EFSP happened gradually after the transition of the CDI project to the Jakarta Contexts and Dependency Injection. Eventually the Eclipse IP policy was updated to its current form, and as part of that all EE4J specification projects were assigned a Compatible Patent License type without consulting previous JCP project leads. Red Hat favors the Implementation Patent License type, and if consulted as to which patent license type was preferred, we would have choosen the Implementation Patent License type for Jakarta Contexts and Dependency Injection.

After consulting with the EMO on what options existed for chaging the current Jakarta Contexts and Dependency Injection specification patent license type, the only option given was to archive the current specification project and start a new version of the specification with the alternative patent license type. This project proposal is identical to the existing Jakarta Contexts and Dependency Injection specification project with the only change being the choice of the patent license type.

 

Scope

Project Scope

The Jakarta Contexts and Dependency Injection v2 project defines and maintains the Jakarta Contexts and Dependency Injection v2 specification and related artifacts.

Specification Scope

Jakarta Contexts and Dependency Injection v2 defines a programming model based on component’s lifecycle and typesafe dependency injection providing multiple services and integrating with other specifications.

It also provides an eventing system and interception mechanism that adds loose decoupling to the programming model, a powerful SPI and extension mechanism allows extension of the programming model and better integration of third party frameworks.

Description

Jakarta Contexts and Dependency Injection v2 defines a powerful set of complementary services that help to improve the structure of application code.

  • A well-defined lifecycle for stateful objects bound to lifecycle contexts, where the set of contexts is extensible

  • A sophisticated, typesafe dependency injection mechanism, including the ability to select dependencies at either development or deployment time, without verbose configuration

  • Support for Jakarta EE modularity and the Jakarta EE component architecture - the modular structure of a Jakarta EE application is taken into account when resolving dependencies between Jakarta EE components

  • Integration with the Unified Expression Language (EL), allowing any contextual object to be used directly within a Jakarta Server Faces or Jakarta Server Pages page

  • The ability to decorate injected objects

  • The ability to associate interceptors to objects via typesafe interceptor bindings

  • An event notification model

  • A web conversation context in addition to the three standard web contexts defined by the Jakarta Servlets specification

  • An SPI allowing portable extensions to integrate cleanly with the container

For instance the following class defines a CDI bean and inject user credentials and Jakarta Persistence entity manager. It produces another bean of type User with qualifier @LoggedIn

@SessionScoped @Model
public class Login implements Serializable {

@Inject Credentials credentials;
@Inject @Users EntityManager userDatabase;

private CriteriaQuery<User> query;
private Parameter<String> usernameParam;
private Parameter<String> passwordParam;

private User user;

@Inject
void initQuery(@Users EntityManagerFactory emf) {
CriteriaBuilder cb = emf.getCriteriaBuilder();
usernameParam = cb.parameter(String.class);
passwordParam = cb.parameter(String.class);
query = cb.createQuery(User.class);
Root<User> u = query.from(User.class);
query.select(u);
query.where( cb.equal(u.get(User_.username), usernameParam),
cb.equal(u.get(User_.password), passwordParam) );
}

public void login() {

List<User> results = userDatabase.createQuery(query)
.setParameter(usernameParam, credentials.getUsername())
.setParameter(passwordParam, credentials.getPassword())
.getResultList();

if ( !results.isEmpty() ) {
user = results.get(0);
}

}

public void logout() {
user = null;
}

public boolean isLoggedIn() {
return user!=null;
}

@Produces @LoggedIn User getCurrentUser() {
if (user==null) {
throw new NotLoggedInException();
}
else {
return user;
}
}
}

CDI provides far more features. More example can be found in the existing specification document.

Why Here?

This is a relaunch of the existing Jakarta Contexts and Dependency Injection specification project.

Project Scheduling

The project will continue to produce specification updates as technology changes warrent and the Jakarta EE4J major releases dictate. Currently there is a CDI-lite specification underway that is expected to release within the next year.

Future Work

Updates to the existing CDI specification to produce a new CDI-lite specification are underway. This addresses changes in the use of build time creation of applications as a popular vehicle in cloud native deployments. Breaking up the existing CDI TCK to deal with circular dependency release issues is also being targetted.

Initial Contribution

The existing CDI and CDI-TCK project repositories should be used:

https://github.com/eclipse-ee4j/cdi

https://github.com/eclipse-ee4j/cdi-tck

 

Source Repository Type

Eclipse Digital Cockpit

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
Background

We developed the Digital Cockpit at pragmatic industries GmbH as our platform for customer projects focuses mainly around the digitalization of machines and automation lines. So we wanted to have a very modular system with a service oriented architecture where it is easy to add new apps and services.

Common concerns like Login, Storage, PLC Connectivity and such should be handled by services that every app can consume if needed.

Also we wanted to have a single UI that is easy to customize e.g. if machine manufacturers built solutions based on the cockpit to enable them to use their CI.

Scope

The Eclipse Digital Cockpit provides a modular, polyglot and service-based Edge Runtime which enables fast and easy development of apps and services that interact with machines. The Eclipse Digital Cockpit also provides everything needed to setup an App Store backend and telemetry data Collection.

Description

The Eclipse Digital Cockpit provides an Edge Runtime focused on industrial automation. It stands somewhere between a simple Edge Runtime, an "Android for the machine" and a lightweight "Application Server" where services and Apps can be deployed to.

Besides the Edge Runtime there are multiple backends like an App Store (under development) or a Telemetry Backend which takes telemetry values that Apps or Services from the Cockpit send out.

Most importants services for common concerns are

  • User Management (with Keycloak integration)
  • App Management
  • Database Management (based on Flyway for updates)
  • Telemetry Service

Especially in the automation domain there are specifc services which make it easy to interact with industrial machinery like

  • PLC Template for very easy access to PLCs
  • Device Registry
  • Monitoring App
  • Machine Counter Service / App

 

 

Why Here?

We think that the Eclipse Model fits the project very well, especially with the recent acitvity towards IoT, Industrial IoT and industrial automation / industry 4.0.

Also, we have already integrated many Eclipse Projects in our Eco-System and our Digital Cockpit like Eclipse Hawkit, Eclipse Ditto, Eclipse Milo, Eclipse Paho and Eclipse Mosquitto.

Description

The Eclipse Digital Cockpit provides an Edge Runtime focused on industrial automation. It stands somewhere between a simple Edge Runtime, an "Android for the machine" and a lightweight "Application Server" where services and Apps can be deployed to.

Besides the Edge Runtime there are multiple backends like an App Store (under development) or a Telemetry Backend which takes telemetry values that Apps or Services from the Cockpit send out.

Most importants services for common concerns are

  • User Management (with Keycloak integration)
  • App Management
  • Database Management (based on Flyway for updates)
  • Telemetry Service

Especially in the automation domain there are specifc services which make it easy to interact with industrial machinery like

  • PLC Template for very easy access to PLCs
  • Device Registry
  • Monitoring App
  • Machine Counter Service / App

 

 

Project Leads
Committers
Erwin Wagasow
Volker Emmert
Marco Nastasi
Tim Mitsch
Christofer Dutz
Mehedi Hasan
Interested Parties

Eclipse Vorto

Initial Contribution

The Digital Cockpit is a working platform and multiple customer solutions have been built on it already. All code belongs to pragmatic industries GmbH.

Source Repository Type

Eclipse JustJ

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

Eclipse Projects in general and the Eclipse IDE in particular have long suffered from the inability to distribute Java runtimes.  Each end-user is expected to download and install a compatible Java runtime from some other site in order for Java-based Eclipse applications to run.  For the Eclipse IDE, failure to install a compatible Java runtime results in cryptic error messages that offer the user little or no guidance as to why the Eclipse application cannot be launched.  Compound that with the fact that a great many users are not familiar with Java and in fact do not use the Eclipse IDE for the purpose of Java development, the overall experience for the end-user is poor.

Intellectual property restrictions, largely based on licensing concerns, have prevented the redistribution of Java runtimes by Eclipse-hosted projects.  These restrictions have now been relaxed to enable the redistribution of Java runtimes acquired from approved sources. The approved sources are likely to evolve over time.

Scope

Eclipse JustJ provides fully-functional Java runtimes that can be redistributed by Eclipse Projects.

Eclipse JustJ will consume TCK-certified binaries directly from Foundation-approved sources, e.g., OpenJDK, to produce Java runtimes, i.e., Java Development Kits (JDKs) and Java Runtime Environments (JREs), in various easily-consumable forms preferred by many Eclipse Foundation Projects, including but not limited to the following:

  • As p2 installable units in a p2 repository that can be installed into any Eclipse IDE or Eclipse Rich Client Platform application.

  • As downloadable resources, e.g., *.zip or *.tar.gz, that can be unpackaged onto any host machine or can be consumed by the build of any other Eclipse Project’s distribution.

In the future, arbitrary subsets of a full JDK may be produced using jlink to be consumable by clients with a reduced set of module and executable requirements, i.e., where client footprint is of significant concern.

Description

Eclipse JustJ provides fully-functional Java runtimes that can be redistributed by Eclipse Projects.  The form in which these are made available is intended to make these easily consumable. As such, the Java runtimes will be available via p2 repositories as well as via direct packaged downloads. The links for these will evolve over time. The sources of these Java runtimes are any and all versions approved by the Eclipse Foundation for such purposes.  Currently that is limited to the latest release available via https://jdk.java.net.

Why Here?

A number of projects have expressed interest in being able to redistribute a fully-functional Java runtime. E.g., the Eclipse IDE for C/C++ Developers from the Eclipse Packaging Project, and the Eclipse Installer from the Eclipse Oomph project.

Project Scheduling

The project is intended to follow both the release schedule of Java itself, providing regular updates as new versions of Java become available, as well as the release schedule of the Eclipse Simultaneous Release.

Future Work

Eclipse JustJ will develop all the necessary infrastructure for providing easy-to-consume Java runtimes, document the usage, and adapt to the Eclipse community's evolving requirements. 

The current prototype will be fleshed out to produce p2 repositories for all the supported runtime platforms.  

Eclipse JustJ will also address the development and delivery of various other downloadable artifacts, e.g., *.zip and *.tar.gz of JDKs and JREs derived from these approved sources, including artifacts created by the use of jlink.  The full JDK is roughly 200MB while a full JRE, as produced by jlink with compression, is roughly 90MB.  A minimal JRE that satisfies the needs of the Eclipse Installer is only 48MB. Eclipse JustJ will provide access via p2 repositories and downloadable artifacts to such JDKs and JREs.

Project Leads
Mentors
Interested Parties
  • Eclipse Packaging Project
  • Eclipse Oomph Project
Initial Contribution

Preliminary prototype work has been initiated that is analogous to the com.servoy.eclipse.jre.* folders from  https://github.com/Servoy/servoy-eclipse/tree/master/. I.e., plugins (or fragments) will embed the Java runtime folders where the nested content of those folders are JDKs or JREs from Foundation-approved sources.  In combination with features that group the platform-specific plugins (or fragments), this will be used to publish p2 updates site via Maven/Tycho builds.

Source Repository Type

Hi, and thanks for initiating this project! I think it is a foundational and very appreciated initiative for many Eclipse IDE based projects. Eclipse Corrosion is one of these projects, and we would be happy to be listed as an interested party.

I was excited to learn about this project during the CDT monthly call today!  This will be a boon to customers everywhere.  We (and I'm sure many other redistributors) are already doing this downstream in order to improve the usability of our Eclipse-based products, so it will be great to have an official solution coming from Eclipse.

One concern jumps out at me with this proposal is the following sentence from the Description: "Currently that is limited to the latest release available via https://jdk.java.net."  Eclipse is currently moving to standardize on Java 11 which is the current LTS version of Java.  While I understand that components built with Java 11 should work fine with a Java 14 JRE, this proposal is about distributing a JDK.  Many users might prefer to use JDK11 for broader compatibility, not to mention Eclipse for Committers users, which will NEED to use JDK11 in order to build classes that will be compatible with Java 11.

Please amend this proposal to state that the latest LTS version of Java will be distributed (possibly in addition to "the latest release available via https://jdk.java.net") or this will be far less useful for the community.

Thanks for proposing this and thanks for reading.

In reply to by Tony Homer

I believe Java 11 is problematic.  Looking at https://jdk.java.net/11/ I see it directs to the archive https://jdk.java.net/archive/ and that has a big warning "WARNING: These older versions of the JDK are provided to help developers debug issues in older systems. They are not updated with the latest security patches and are not recommended for use in production."  So I don't think we have access to a LTS version of Java 11 via jdk.java.net.  If I look at https://adoptopenjdk.net/?variant=openjdk11 I can see that it has 11.0.6+10 so that seems to have actual recent LTS versions of Java 11.  But this is not currently an approved source.

Perhaps if Intel were a Stragetic Development Member it would have more influence on the Eclipse Foundation Board of Directors' decisions.  Certainly I and your other elected Committer Representatives as well as your elected Sustaining Member Representative do their best to influence those decisions.

Eclipse Jifa

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 Eclipse Memory Analyser Tooling (MAT) is used widely by Java developers for diagnosis. However, MAT currently is a client application/plugin. Generally, the users need to transfer the dump file from the cloud environment to the local environment, such as the developer's machine, this way is less productive, the situation would become worse if the network between cloud and local is slow, that is, the developer has to wait for a long time of completion of file transferring. Furthermore, some dump files are big and may require the local machine with large enough memory.

To make the MAT easy to use and to overcome the above two problems, we developed a web application that integrated the core parser library of MAT and deployed it to the cloud environment. This way, the developers can directly use the browser to parse their heap dump file without file transferring from cloud to local. There now exists some similar products, such as HeapHero. They are attractive but not open source.

Scope

Eclipse Jifa is a web application based on the Eclipse Memory Analyser Tooling (MAT) that provides HTTP services so that users can view the heap dump files analysis through a browser. Eclipse Jifa is relying on the core library of MAT to analyze the heap dump file. Users can deploy Eclipse Jifa to their cloud environments, and share the same analysis result to different users via browser, and we believe it's a more convenient way to troubleshoot Java heap issues.

Description

Eclipse Jifa uses Vert.x as the main backend framework, and uses Vue 2.0 as the frontend framework.

Features currently supported:

Heap dump Analysis:

  • Overview of the target heap
  • Leak suspects
  • GC root analysis
  • Dominator tree analysis
  • Thread information
  • OQL
  • Other features 
Why Here?

Eclipse Jifa project uses Vert.x as the main framework, and the ability of heap dump analysis is relying on the core library of MAT, which is under the Eclipse Foundation, so contributing Eclipse Jifa here under the same umbrella is the best choice. The open-source is a vital step for Eclipse Jifa to benefit the whole Java community. We hope Eclipse Jifa evolves toward the future together with MAT and delivers excellent user experience of troubleshooting in Java Heap issues to all developers.

Future Work

Add other useful features to Eclipse Jifa, such as GC log analysis、JFR log analysis.

Source Repository Type

There has been a previous attempt to provide web access to Eclipse Memory Analyzer tool so I think there would be a demand for a capability like Eclipse Grace.

The previous attempt used Remote Application Platform (RAP) and although it worked I don't think all the changes were merged into the MAT source:

262603: Create single-sourced version of Memory Analyzer which I think was the basis for the Web Edition of IBM® Monitoring and Diagnostic Tools for Java™ - Memory Analyzer.

However I see that IBM Support Assistant Team Server 5.0.2.5 removed that.

Highlights for 5.0.2.5 (Update)



IBM Support Assistant Team Server 5.0.2.5 provides updates and fixes multiple vulnerabilities



The "Memory Analyzer [Web]" tool has been removed beginning with ISA 5.0.2.5. "Memory Analyzer [Report]" and "Memory Analyzer [Desktop]" can be used as an alternative to the Web edition of the tool.

Eclipse Phizog

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 Future Airborn Capability Environment (FACE)   is the open avionics standard that aims at improiving the portability, security, robustness and interoperability of avionics computing modules. The standard eases the creation and deployment of  a wide catalog of applications for use across the entire spectrum of aviation systems through a common operating environment. The latest edition of the standard further promotes application interoperability and portability with enhanced requirements for exchanging data among FACE components and emphasis on defining common language requirements for the standard.

Scope

The Eclipse Phizog project provides open implementations conformant with the FACE-TSS (Transport Services Segment) standard for mainstream programming languages. 

Description

The Eclipse Phizog project goal is to provide the reference implementation based on the Object Management Oriented Data Distribution Service (OMG DDS) for the FACE-TSS. The DDS infrastructure of choice will be Eclipse Cyclone DDS  as a consequence the project will provide a full solution for companies looking for a FACE-TSS conformant implementation  that is completely open and developed under the clear governance of an Open Source Ecosytem such as Eclipse.

Why Here?

There are several reasons for choosing the Eclipse Foundation as the home for this project, but beside the fact that as a company we are fully committed to Eclipse, the most important is perhaps  Eclipse Cyclone DDS. This project is highly synergistic with Eclipse Cyclone DDS and this makes it yet another good reason for having it on eclipse.

Project Scheduling

The current version of Phizog  implements the FACE-TSS v2.x for C++ and Java. This implementation currently leverage OpenSplice DDS community edition as the DDS layer. We are ready to contribute this version immediately. The current version builds and runs without any problems and has production quality.

Future Work

The first milestone for this project will be to port the current implementation to Eclipse Cyclone DDS. Then we will focus on implementing the latest of the standard, namely version 3, which was recently defined. The first release may be after six month once the porting to Eclipse Cyclone DDS will be completed and we'll have sufficient feedback and trials from the community.

Project Leads
Committers
Marcel Jordense
Thijs Sassen
Erik Hendrix
Angelo Corsaro
Mentors
Interested Parties

This project should be relevant for any system integrator working in  avionics.

Initial Contribution

The initial contribution will be an implementation conformant with the FACE-TSS v2.x for both C++ and Java. This implementation is currently based on the OpenSplice DDS but we will port it to Eclipse Cyclone as part of the Eclipse Project. 

Source Repository Type

Eclipse openK Core Modules

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

In 2014 a group of German Distribution System Operator (DSO) started a discussion that led to the creation of the openKonsequenz initiative (OpenKONSEQUENZ). The intention of the group is to develop open source software for system operators which matches the needs of power networks in the 21st century. The main focus is to develop a modular and vendor independent IT-system which is open to different system integrators and 3rd party module provider. Further aspects are the improvement of IT-security and user experience and the reduction of development cycles and costs.The changing energy politics creates a number of new requirements concerning the flexibility, availability, security and performance, which have to be met by the technical platform.

Scope

The Eclipse openK Core Modules provides a set of core modules for developing open source software for system operators which matches the needs of power networks in the 21st century.

The project will develop core modules for openKONSEQUENZ and make them available for the usage within user modules.

Description

This project will be the collection of all core modules that are implemented within the scope of openKONSEQUENZ.

A core module in our definition is not directly affected by users, in contrast to user modules, but is related by the user modules in the background.

The first core module implemented in this project will be „contact master data“. This module carries all the contact information, such as names and telephone numbers of contact persons and firms. The contact information is held in a discreet database and complies with the provisions of the data protection basic regulation („Datenschutz Grundverordnung, DSGVO“). This module is being referred to by the existing and future user modules.

Why Here?

An Eclipse project will garantee an open source software of quality which complies to well recognized IT-standards. Furthermore it will be open to future projects and add-ons by different vendors.

Project Scheduling

Several modules will be implemented in the following years. The first module in this project will be the module „contact master data“ used by all existing and future openK user modules. This will be implemented in the beginning of 2020.

Future Work

In the near future openKONSEQUENZ will develop further modules and implement them in this project.

Initial Contribution

the development of the first module "contact master data" for this project has already began.The code is already hosted in the two eclipse git repositories listet in the Source Code section of this proposal. We want the repositories beeing moved to this project, after this project has been created. All the code was developed by the committers of the project and eclipse contributers. All of them have signed the ECA. All used libraries has been approved, certified or the IP-Check is still in progress or in preparation for a IP-Check

Source Repository Type