GitHub

Project is hosted in the Eclipse organization at GitHub.

DBeaver

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

We have developed open-source project based on Eclipse for 7 years. We think it's time to make it an official Eclipse project.

Scope

Universal database manager and SQL client.

Description

It is a tool for databases (SQL or NoSQL) data/metadata management. Somehow it is similar to existing Eclipse DTP project but uses very different workflow, UI and internal structure. also it doesn't rely on JDBC only. It is hosten on Eclipse Marketplace for years and now it is in top 50 (https://marketplace.eclipse.org/content/dbeaver)

Why Here?

Because we have very tight connection with Eclipse platform. We have a lot of users world-wide which we support and we would like to participate in Eclipse community more deeply.

We need better understanding where Eclipse platform is moving, we'd like to contribute fixes and suggest features.

Initial Contribution

We have a quite big code base on our GitHub: https://github.com/dbeaver/dbeaver

Source Repository Type

Eclipse Packager

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

From the Eclipse NeoSCADA and Eclipse Package Drone projects came a bunch of helper functionality in Java to work with RPM and APT files. Core functionality to parse and write RPM files, write DEB files, create a YUM and APT repository. This functionality ended up in Package Drone as this project is all about software artifacts.

Unfortunately I don't have the time anymore to maintain the Package Drone project. However maintaining a simpler project with a focus on the RPM and Deb functionality would work. Also it has been problematic to get new contributors on board as they are overwhelmed with the project structure (of Package Drone) which is way different than a simple Maven project.

This leads me to the idea of creating a dedicated Eclipse project with the sole scope of working with RPM and DEB files. Offering the core functionality and tooling (Maven plugin) and offering a simple project structure and release process aside from Package Drone and NeoSCADA.

Scope

The scope of the project is:

  • Reading and writing of software package formats for Linux-ish distributions (RPM, DEB)
  • Providing tools around that core functionality (Maven plugin, Gradle plugin, …)
Description

The project offers a set of core functionality to work with RPM and Debian package files in plain Java. This functionality is offered in simple JAR variant to create your own solutions, or in ready-to-run tools like an Apache Maven plugin.

Why Here?

The core functionality was born from Eclipse projects and so it makes sense to me to give this functionality a dedicated project at Eclipse. As a growing number of contributors start proposing PRs, reporting issues and making suggestions I would like to continue using the governance of the Eclipse Foundation in order to provide a neutral place for all contributors.

Project Scheduling

As this is a working set of features and little effort is required to perform a new build. It is expected that an initial release at the Eclipse Foundation can be made as soon as the project is created and the IP review has been done of the initial contribution. My expectection would be that there is something ready around September.

Future Work

The main reason to put this functionality in a dedicated project is to give new contributors an easy entry. There is currently interest to add a Gradle plugin in addition the the Maven plugin. Add more features from RPM (like additional payload codes, header flags, …).

Project Leads
Committers
Mentors
Initial Contribution

The initial contribution partly comes from an existing Eclipse project (the core functionality) and part from an existing, personal GitHub repository (Maven plugin). The Maven plugin has a small community of contributors.

The Maven Plugin has dependencies on core Maven libraries. Other than that there are dependencies on:

  • Apache Commons Compress
  • Tukani XZ
  • Guava
  • Bouncycastle
  • Apache Commons Codec
Source Repository Type

Eclipse Wild Web Developer

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

Because of technical reasons (reimplementation of parsers mostly) and strategical priorities (Java EE), Eclipse IDE and the WebTools project have hard time catching up with innovation in the front-end Web development world. As a result, several editors for typical web languages (CSS, HTML, JavaScript...) shipped in the Simultaneous Release are of low quality compared to the state of the domain and competiting IDEs.

Scope

Eclipse Wild Web Developer provides a rich development experience for Web development in Eclipse IDE, including editing assistance, debugging and other features that ease development of web applications.

Eclipse Wild Web Developer relies on existing mainstream and maintained components to provide the language smartness, over popular configuration files like TextMate and protocols like Language Server Protocol or Debug Adapter Protocol; and may rely on some valuable pieces of Eclipse WebTools.

But Eclipse Wild Web Developer is not meant to be a project where we (re)implement parsers or debuggers; it's only focused on integrating existing components. Any work that deals with plain language or debugger logic should be excluded from Wild Web Developer and directed to the underlying components used by Wild Web Developer.

As such, Eclipse Wild Web Developer won't host specific language server or TextMate grammars and will only consume those artifacts produced by other projects.

Description

Eclipse Wild Web Developer integrates existing artifacts like TextMate grammars and Language Servers to provide a rich development experience to Web developers using typical programming languages for the Web (CSS, HTML, JSon, JavaScript, TypeScript...).

Eclipse Wild Web Developer is about integrating existing technologies for those languages more than creating more specific language smartness.

Why Here?

Eclipse Wild Web Developer deeply integrates with Eclipse IDE and several related projects. It also targets a wide audience of Web developers.

We believe contributing Wild Web Develoepr (formerly BlueSky) to Eclipse.org will allow Eclipse IDE to provide some better quality support for Web technologies with a low maintenance cost. We also think that the interest in Wild Web Developer from the Eclipse ecosystem is going to be big enough to make it worth enforcing top-quality governance by embracing the Eclipse Development Process.

Project Scheduling

The project will release a 0.1.0 version as soon as it's migrated to Eclipse.org.

The project would then release minor updates whenever one of the included language servers provides interesting updates.

Future Work

Future work will involve:

* typical bugfixes and minor improvements in code and UI

* Adoption of newer Eclipse Platform/TM4E/LSP4E when they release

* Adoption of newer language servers and textmate grammars

* (Probably) adoption of debuggers conforming ot the Debug Adapter Protocol

* ...

Initial Contribution

Intiial contribution from https://github.com/mickaelistria/eclipse-bluesky contains:

* rich CSS edition using Generic Editor, TM4E and a TextMate grammar, and LSP4E and the VSCode CSS Language Server (included)

* rich HTML edition using Generic Editor, TM4E and a TextMate grammar, and LSP4E and the VSCode HTML Language Server (included)

* rich JSon edition using Generic Editor, TM4E and a TextMate grammar, and LSP4E and the VSCode JSon Language Server (included)

* rich JavaScript edition using Generic Editor, TM4E and a TextMate grammar, and LSP4E and the SourceGraph's Javascript-typescript Language Server (included)

* rich TypeScript edition using Generic Editor, TM4E and a TextMate grammar, and LSP4E and the SourceGraph's Javascript-typescript Language Server (included)

* Debug support for JavaScript re-using JSDT's node debugger integration

Source Repository Type

I'm currently using this and only problem we have is HTML files does not have intelisence for anuguler sysntaxes.Can we get it in future.

I added WWD through the Eclipse Marketplace on my Windows x64 version of Eclipse IDE for Java Developers, 2020-06. I guess it works, but it sure doesn't integrate like JSDT did.

I'm not thrilled with WWD since the first thing I tried to do is comment a line in JavaScript using Ctrl+/ and it summons a dropdown of keyword and available function choices. Ctrl+. does the same thing, and feels more appropriate, so what's the deal?  Want to change the keyboard shortcuts? Too bad. There's nothing under the Keys preference that has anything to do with this kind of TextMate/WWD actions.

Want to change the syntax coloring? Better love what you're given. There is no Syntax Coloring section or anything like it. There's a TextMate set of preferences, but it seems like anything regarding Theme doesn't actually work. Is it because I use DevStyle and the Darkest Dark theme? Who knows.

There's only one WWD preference (XML), which does nothing but tell you "See 'XML Catalogs' for XML catalogs preferences". Thanks? It's also version 0.10.0.etc, which feels like we're being forced to test it. Overall I'm pretty disappointed, especially since Eclipse just automatically upgraded itself from 2020-03 to 2020-06 and now I'm stuck with this. Boo to you on this move, Eclipse

Eclipse SWTChart

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

Charts are an important part of modern applications. The visualization of data has become a vital part, especially in the area of data science. Java as a technology allows to create charts. But its handling is tedious, that why toolkits like AWT, Swing, SWT or JavaFX have been developed to display graphical elements easily. Depending on the aforementioned technologies, specialized libraries to display graphs and time series have entered the scene. One of those is SWTChart [1], which has a well defined API and allows to create line, bar and scatter charts easily. The next enhancement of SWTChart is already developed under the hood of Eclipse as part of the Eclipse Advanced Visualization Project (EAVP) [2]. It allows to create customized charts, to define several axes and to offer several export options.

 

  • Line Charts (time series, etc.)
  • Bar Charts (histograms, etc.)
  • Scatter Charts (value distributions, etc.)

 

Instead of having two repositories for SWTChart and its extensions, it would make sense to combine both into one repository. People would benefit from a consolidated development by making the use of both libraries even easier.

[1] http://www.swtchart.org

[2] https://github.com/eclipse/eavp/tree/chemclipse/org.eclipse.eavp.service.swtchart

Scope

Eclipse SWTChart provides the means to create rich, flexible and interactive data visualizations natively in SWT.

Description

Eclipse SWTChart allows to create different types of charts. The API is well designed and allows to create Line, Bar and Scatter charts easily. Size, colors, axes, ranges and all aspects of the charts can be modified via code. So, it's easy to create customized charts. Moreover, the library already contains a data compression to show large data sets in a performant way. In addition to that, charts can be created even more easily with the SWTChart extensions. It uses the convention over configuration pattern and offers many additional improvements to scale axes of different type automatically or to select specific data ranges.

 

 

Figure 1 – SWTChart

 

Figure 2 – SWTChart Extensions

 

Figure 3 – SWTChart Extensions - Default Theme

 

Figure 4 – SWTChart Extensions - Dark Theme

Why Here?

The Eclipse Foundation is the right place to collaborate for SWTChart because of its many users, the vivid community and the Science Working Group. The Eclipse Foundation in general and the Science Working Group in particular offers great opportunities to collaborate with other projects and to find new ways for the data evaluation. The migration to the Eclipse Foundation will help SWTChart grow its open source community and makes its usage more secure due to the strong IP review process of the Eclipse Foundation. An integration into the Science Working Group helps also to adopt SWTChart more easily by its members and technologies. Why shouldn't SWTChart be merged into the existing Eclipse Advanced Visualization Project (EAVP)? SWTChart has a long history and is well known in the community. That's why the project identity should be preserved. Moreover, EAVP offers a high-level platform to offer services for various types of charts. SWTChart is a base library, which could be consumed by EAVP. A well defined separation of concerns is seen as highly beneficial in this case.

Project Scheduling

The initial contribution will be made in quarter three of 2018 and the first release will happen by the end of quarter two of 2019.

Future Work

Implementation of:

  • Additional export converters, e.g. SVG, PDF and EPS
  • Improvements of the axis handling, e.g. a reversed axis scale
  • Improvements of the performance by compression algorithms when handling huge data sets
  • Fix SWTChart issues under Mac OS
Mentors
Interested Parties

Lablicate GmbH

Science Working Group Members

Initial Contribution

Yoshitaka has created the project SWTChart. He is the project owner.

Philip Wenig has created the SWTChart extensions, already managed by Eclipse via the Eclipse Advanced Visualization Project (EAVP).

Source Repository Type

The Nebula project contains many SWT controls already, has established release processes and with the recent example of the Opal widgets being added shows it is still growing. I would recommend this be added simply as another bundle in Nebula. The Nebula project also has it's own incubator for bundles that aren't fully read for release. 

Also, why is this under Science and not Technology, it is of use to a much wider group than the Eclipse Science TLP project implies.

In reply to by Jonah Graham

SWTChart is well known already and has a good reputation. That's why the name should be preserved as part of an own Eclipse project. Nebula plays an important and very well role in supplying widgets than can be used by the platform. But my fear is, that SWTChart becomes less important and would loose its attraction if it's just one of many parts of Nebula.

 

Science has been chosen as I'm familiar with it. But you're right, Technology also makes sense.

In reply to by Philip Wenig

The things you mention have to do with presentation. Giving SWTChart a special place in Nebula is perfectly possible. You can even open your own Nebula sub-project like NatTable did, but it did not take long for the original maintainers to jump ship and AFAIK it is now being maintained by one person. Kind of lonely if you ask me ;) Realisticly, SWTChart has not seen much action over the past years, therefore I foresee that this will also happen with SWTChart if you pull it to it's own little space.

I just wanted to chime in to say that you are welcome to join the Nebula project. We have committers that know how to polish a pixel. Don't expect them all to jump on SWTChart immediately but you may want to ponder this.

Cheers, Wim

In reply to by Wim Jongman

Howdy Wim, a benefit of being part of Nebula like "NatTable" would be indeed, that several SWT developers lurk around in the project. We would like to use the Eclipse GitHub account as a place to host the source code. Would that also be possible with Nebula?

Let's chat the next days. I'll send you my mobile number via email. Will you attend the ECE2018?

I also think this has wider audience, so Technology would fit better. Regarding Nebula: not sure. I have no idea how heavy weight a Nebule release process can be, I fear the burden of being a part of a much bigger project could hinder faster / simple releases. So probably I agree that a dedicated project would be a better choice.

In reply to by Andrey Loskutov

Switching to Technology as the top-level project shouldn't be a problem. I've chosen Science, cause SWTChart is well suited to display scientific data. But you're right, it can be also used in other areas, e.g. to display the number of bugs or commits over time.

Let's wait a few days if more people vote for Technology or for Science.

Eclipse Memory Analyzer uses BIRT for its charts which are generally just pie charts with a legend. The charts themselves are PNG as part of web pages. Occasionally they are interactive with a bit of JavaScript so that hovering over a segment gives its details. How is SWTChart different from BIRT? I don't think we would switch from BIRT unless BIRT stopped being supported and broke (as we don't have much time for non-essential changes). It is good to know there may be a choice in the future though.

Andrew Johnson

 

https://www.eclipse.org/mat/about/screenshots.php 

http://help.eclipse.org/photon/topic/org.eclipse.mat.ui.help/tasks/runningleaksuspectreport.html

In reply to by Andrew Johnson

Hi Andrew,

SWTChart renders the data live insteaf of using bitmaps. But it not offers pie charts at the moment. Supported chart types are:

  • Line Charts
  • Bar Charts
  • Scatter Plots

The library is lightweight and offers an easy way to create a chart, e.g.:

 

    private void createChart() throws Exception {

        /*

         * Create the Chart

         */

        IChartSettings chartSettings = getChartSettings();

        chartSettings.setCreateMenu(true);

        /*

         * Primary X-Axis

         */

        IPrimaryAxisSettings primaryAxisSettingsX = chartSettings.getPrimaryAxisSettingsX();

        primaryAxisSettingsX.setTitle("Scan");

        primaryAxisSettingsX.setDecimalFormat(new DecimalFormat(("0.0##"), new DecimalFormatSymbols(Locale.ENGLISH)));

        primaryAxisSettingsX.setColor(Display.getDefault().getSystemColor(SWT.COLOR_BLACK));

        primaryAxisSettingsX.setPosition(Position.Primary);

        primaryAxisSettingsX.setVisible(false);

        /*

         * Primary Y-Axis

         */

        IPrimaryAxisSettings primaryAxisSettingsY = chartSettings.getPrimaryAxisSettingsY();

        primaryAxisSettingsY.setTitle("Intensity");

        primaryAxisSettingsY.setDecimalFormat(new DecimalFormat(("0.0#E0"), new DecimalFormatSymbols(Locale.ENGLISH)));

        primaryAxisSettingsY.setColor(Display.getDefault().getSystemColor(SWT.COLOR_BLACK));

        //

        applySettings(chartSettings);

        /*

         * Create series.

         */

        List<ILineSeriesData> lineSeriesDataList = new ArrayList<ILineSeriesData>();

        ISeriesData seriesData = SeriesConverter.getSeriesXY(SeriesConverter.LINE_SERIES_2);

        //

        ILineSeriesData lineSeriesData = new LineSeriesData(seriesData);

        ILineSeriesSettings lineSeriesSettings = lineSeriesData.getLineSeriesSettings();

        lineSeriesSettings.setEnableArea(false);

        lineSeriesDataList.add(lineSeriesData);

        /*

         * Set series.

         */

        addSeriesData(lineSeriesDataList);

    }

 

ZigBee (possible name Osmia)

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

The ZigBee framework is used in the Eclipse SmartHome (openHAB) project. It was developped over the past few years, originally as a fork from other problems, but now largely rewritten. It provides a ZigBee Cluster Library, and is designed to support different dongle implementations through well defined interfaces.

Scope

The project provides a basic ZigBee implementation to be used for any ZigBee application. The project should include all ZigBee Cluster Library clusters, and functionality to configure, administer and control the ZigBee network.

Project Leads
Committers

Eclipse Sprotty

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

An increasing number of tools that have originally been rich clients are moving into the web. E.g. cloud IDEs already offer a coding experience close to those based on the traditional Eclipse Rich Client Platform. But they still lag behind when it comes to diagrams: Existing graphical frameworks for the web, like D3.js or JointJS, either focus on visualizing datasets (i.e. numbers rather than models), require the models to be fully available on the client, or are too low-level to implement a diagram view with reasonable effort.

The work on Sprotty started in March 2017 as a joint effort of Ericsson and TypeFox to fill exactly this gap. Sprotty is a framework that allows to easily add modern graphical views and editors to cloud IDEs or other applications that run in a browser. The role of Sprotty for web-apps is similar to that of the Graphical Editing Framework for Eclipse Rich Clients. Using web-technologies only, Sprotty has a fast and reactive architecture. Based on several years of experiences with graphical frameworks we aimed at providing a unique user experience.

Starting with a few prototypes we have now integrated Sprotty diagrams successfully with Xtext, the Language Server Protocol (LSP), Eclipse Layout Kernel (ELK), Eclipse Theia, and even Eclipse IDE. We first presented Sprotty to the public at EclipseCon Europe 2017 and got excellent feedback. Since then, we have started using Sprotty in customer projects, and others have picked it up as well, e.g. Obeo implemented their prototype of Sirius in the Web based on Sprotty.

Scope

Within the scope of Eclipse Sprotty are

  • Diagrams to browse and manipulate models in web applications.

  • Support for a distributed runtime: share the workload between a client and server.

  • An extensible protocol for the communication between client and server

  • Diagram authoring facilities: choosing the content of a diagram, arranging diagram elements manually, adding/removing diagram elements, exploring the neighborhood of an element, reconciling a diagram with changes of the underlying model, trigger auto-layout.

  • Diagram navigation facilities: open elements, drill up/down, zoom/scroll/center/fit, selection etc.

  • Graphical editing facilities: changing the underlying model via the diagram, create/delete/change/customize/connect elements, undo/redo etc.

  • Exporting diagrams to a vector-based graphics format.

  • Integration with Xtext and LSP to visualize programming artifacts.

  • Integration with IDE frontends like Eclipse Theia or Eclipse IDE.

  • Integration with auto-layout engines such as the ELK.

Out of scope are

  • Auto-layout algorithms for diagrams. We rely on existing frameworks like ELK instead.

  • Visualization of huge datasets, like statistical data or timeseries. These are much better handled with frameworks like D3.js. Sprotty focusses on models, i.e. connected elements with fewer properties.

  • 3-dimensional visualization.

  • Specific model editors/views, e.g. for UML. Of course, Sprotty can be used to implement such a thing, but this should be done in separate downstream projects.

  • Tools to author specific diagram editors, like GMF Tooling or Sirius do.

Description

Eclipse Sprotty is a next-generation, open-source, web-based diagramming framework.

Instead of using a cross-compiler or an existing framework, we decided to start from scratch with web technologies: The client is implemented in TypeScript, SVG is used for rendering, and CSS for styling. We also use a unidirectional event-cycle with a virtual DOM as opposed to the traditional model-view-controller pattern to better fit the demands of web applications.

One focus is on a modern, user-centric look and feel. For example, animations are built right into the core of the framework, such that the user always sees smooth transitions to guide the user’s eye. Model updates, undo/redo, navigation, everything is animated by default.

Sprotty explicitly supports to use a remote backend, allowing to visualize data that is not necessarily present in the browser app. This is not only a preferred scenario for database backends, but also meets the setting of the Language Server Protocol, where the backend encapsulates the semantics of the language. Thus, you can extend a language server with a Sprotty backend that delivers Sprotty diagrams to the frontend. As most Cloud IDEs are using the LSP, this makes Sprotty an excellent choice for diagrams to visualize code, like type-hierarchies, component dependencies etc.

For the communication between client and server, Sprotty defines a very simple but extensible JSON protocol. As the same messages are used as events in the client internally, you can almost arbitrarily balance the memory demands and computational workload between client and server by passing certain messages to the server while processing others locally. Part of the protocol is a similarly extensible diagram model, which can even be used for models beyond the usual nodes, edges and ports.

As the code is wired-up using dependency injection, you can not only add your own model elements, figures, behaviors, etc. but also replace other default components that don’t fit your need. This way Sprotty is extremely adaptable to all kinds of use cases.

In addition, Sprotty provides glue code to integrate with

  • The Language Server Protocol,

  • Xtext language backends based on LSP,

  • The Eclipse Theia IDE framework, and as such with Eclipse Che,

  • The Eclipse Layout Kernel, both client-side and server-side,

  • Eclipse RCP, via lsp4e and the SWT browser widget.

Why Here?

In company of Eclipse Che, Eclipse Orion and soon Eclipse Theia as well, Eclipse Sprotty seems to provide the missing graphical piece to the cloud technologies at Eclipse. Eclipse also has a very strong standing in the modeling community, to whom Sprotty could be interesting as well. Into the bargain, the currently involved parties are already well organized and connected by the Eclipse project.

Project Scheduling

The initial contribution can be done as soon as the project proposal is accepted. First builds will be ready shortly after.

Future Work
  • Improve diagram authoring facilities.

  • Allow graphical editing. Sprotty is currently focussed on views, i.e. it is not possible to change the underlying model by means of the diagram.

  • Clean up APIs.

  • Extract a JSON protocol analogously to LSP.

Committers
Mentors
Interested Parties
  • Philip Langer (EclipseSource)
  • Mélanie Bats (Obeo)
Initial Contribution

Source code from Github including

  • Client (TypeScript/SVG/CSS)


  • Server (JSON protocol, Xtend, Java)


  • Integration with Xtext LSPs (Xtend, Java)


  • Integration with the Eclipse Theia IDE (TypeScript)


  • Integration with Eclipse
 (Xtend, Java)

  • Examples

Source Repository Type

I think this proposal will take web diagramming to the next level.

By making this an Eclipse project collaboration of all interested parties wil supported.

Can't wait for the Sprotty Eclipse Project

 

Eclipse SmartMDSD

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

Eclipse SmartMDSD and its main development asset, the SmartMDSD Toolchain, started in 2009 by the Service Robotics Research Center at Ulm University of Applied Sciences. The initial contributors who will kickstart and actively maintain SmartMDSD are still actively maintaining the project.

The SmartMDSD Toolchain started in 2009 using the Itemis Open-Architecture Ware (OAW) and Papyrus UML, then between 2013 and 2016 used Xtext, Xtend and Papyrus UML. It has currently moved towards using the latest Eclipse Modeling technologies based on latest Xtext, Xtend and Sirius plugins. This major rework enabled additional internal flexibility and conformance to the European Union's Horizon 2020 research and innovation programme “RobMoSys” (https://robmosys.eu/) and BWMi SeRoNet project. The initial version that will be included in the SmartMDSD Eclipse project is the fourth generation of the tooling.

Since 2008, several research projects on German national level and the european level have contributed to the background of this eclipse project: ZAFH Servicerobotik (Germany, state of Baden Württemberg), FIONA (european level), iserveU (German national level) etc.

The underlying structures for robotics software development that become accessible through the tooling provided by SmartMDSD date back to 1998. They have been constantly refined and enhanced and are now being formalized on the european level via the European Union's Horizon 2020 research and innovation programme “RobMoSys” (https://robmosys.eu/) with the support of the Eclipse Foundation as a consortium partner.

A lot of robotics software components exist and are being used. The initial code-base of SmartMDSD builds upon the third generation of the SmartMDSD Toolchain. It is very mature as it is being used in operational environments (technology readiness level 6). Its development artifacts (software components and systems) are shipped worldwide within products of FESTO Didactic and REC.

Scope

Eclipse SmartMDSD will focus on model-driven tooling for service-oriented and component-based robotics software development (hence the project name). The main outcome in this project is the SmartMDSD Toolchain, an IDE for robotics software development.

  • SmartMDSD will mainly support the “SmartSoft Framework”, a service-oriented component-based framework for software development in service robotics. It also outreaches and supports ROS and OPC UA

  • SmartMDSD is conformant to the RobMoSys and SeRoNet approaches

  • Other infrastructure (e.g. meta-models, examples, etc.) will be hosted here as well.

  • Apart from examples, the project will not host robotics software components for composition. Due to the robotics ecosystem organization and separation of roles, these (open or closed-source) software components originate from vendor-specific repositories. The project focuses on (open) tooling for (open) structures to enable composition.

Description

Tooling developed in this project is the “SmartMDSD Toolchain”, an Eclipse-based Integrated Development Environment (IDE). The model-driven SmartMDSD Toolchain provides support and guidance to apply structures and best-practices the composition of software building blocks to robotics systems. This project will maintain the eclipse-based tooling and necessary infrastructure (e.g. meta-models, code-generators).

Underlying methodology

The SmartMDSD Toolchain supports users in applying the necessary structures to enable composition in an robotics ecosystem. The tooling enables domain experts to model robotics domain structures, enables component suppliers to provide software components and enables system builders to flexibly combine and re-combine (“compose”) them to new applications according to their needs.

Main target is the SmartSoft Framework

SmartMDSD covers the complete workflow from domain structures and interface definitions, to component development, to system composition. SmartMDSD will mainly support the “SmartSoft Framework”, a service-oriented component-based framework for software development in service robotics. However, it also outreaches to make use of the ROS framework and OPC UA.

SmartMDSD conforms to the structures proposed by the European Union's Horizon 2020 research and innovation programme “RobMoSys” (https://robmosys.eu/) and BMWi/PAiCE “SeRoNet” (https://www.seronet-projekt.de).

For more information, see the following resources:

Why Here?

Eclipse SmartMDSD is contributing to an composition-oriented approach for robotics software development to create an ecosystem in which robotics developers can exchange building blocks. A key enabler for this vision are technical structures that need to be open (e.g. open meta-models). These structures must be maintained by an active community. An eclipse project supports in kickstarting this open community and in providing a frame for further evolvement.

The members of the proposed project have a strong background in software engineering and robotics. Both the robotics and the eclipse community can benefit from fostering a close link via this eclipse project:

  • Model-driven engineering demonstrated to be a key driver to manage system complexity. Robotics can benefit from knowledge in tooling and model-driven engineering which is both well established in the eclipse community.
  • Through the proposed project, the Eclipse community can extend its scope to the robotics domain. The main outcome of “SmartMDSD” will be the “SmartMDSD Toolchain”, a matured robotics software development IDE that is well known in the service robotics domain.
  • The very same arguments hold true for choosing “Eclipse Modeling Project” as the parent project: SmartMDSD heavily applies tools from the Eclipse Modeling Project.
Project Scheduling

An initial contribution is to be expected very soon after the infrastructure is available.

We expect that the incubation phase can be kept short as the project has a history since 2009, is in active use by a broad user basis, and the development (at time of writing) supported by two publicly funded projects (RobMoSys and SeRoNet, see Background and Interested Parties), and two private companies.

Future Work

The functionality is stable and mature as the project is under development since 2009. We will focus on the enhanced usability in the first year. We will further work on getting current experimental features stable: support for using ROS nodes and OPC UA devices in order to link to these communities. We further plan to connect closer to industry 4.0 / asset administration shell.

 

Project Leads
Committers
Interested Parties

RobMoSys (“Composable Models and Software for Robotics Systems”, https://robmosys.eu), a project funded in the European Union's Horizon 2020 research and innovation programme. RobMoSys is working towards an EU digital platform for industrial robotics. RobMoSys brings to the robotics software community a model-driven support, specifically targeting the autonomous nature of robotics systems and their validation. RobMoSys adopts a composition-oriented approach that manages, maintains and assures system-level properties, while preserving modularity and independence of existing robotics frameworks and code bases.

SeRoNet (“Service Robotics Network”, https://www.seronet-projekt.de) is a German national project funded by the Federal Ministry for Economic Affairs and Energy (Bundesministerium für Wirtschaft und Energie, BMWi). SeRoNet is creating an IT platform for robotics users, component suppliers, and system integrators. SeRoNet aims at reducing the overall costs to service robotics software development.

The members of the proposed eclipse project are active in the euRobotics aisbl Topic Group on “Software Engineering, System Integration, System Engineering”. They thus maintain a link to the service robotics community.

Further, the project is actively supported by two private companies.

Initial Contribution

The initial contribution will be the code of the SmartMDSD Toolchain IDE that is being developed since 2009. It is fully functional in modeling the complete composition workflow and code-generation to build real robotics systems. See section “Background” for more detailed information.

The code/repository to be moved to eclipse is: https://github.com/Servicerobotics-Ulm/SmartMDSD-Toolchain

Source Repository Type

java

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

Eclipse Tahu

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
Working Group
Proposal State
Created
Background

MQTT was originally designed as a message transport for real-time SCADA (Supervisory Control and Data Acquisition) systems. The MQTT message transport specification does not specify the topic namespace to use nor does it define the Payload representation of the data being published and/or subscribed to. In addition to this, since the original use case for MQTT was targeting real-time SCADA, there are mechanisms defined to provide the state of an MQTT session such that SCADA/Control HMI application can monitor the current state of any MQTT device in the infrastructure. As with the topic namespace and payload the way state information is implemented and managed within the MQTT infrastructure is not defined. All of this was intentional within the original MQTT specification to provide maximum flexibility across any solution sector that might choose to use MQTT infrastructures.

But at some point, for industrial MQTT based solutions to be interoperable within a given market sector, the topic namespace, payload representation, and session state must be defined. The intent and purpose of the Sparkplug specification is to define an MQTT topic namespace, payload, and session state management that can be applied generically to the overall IIoT market sector, but specifically meets the requirements of real-time SCADA/DSC (Distributed Control System)/ICS (Industrial Control System) OT solutions. Meeting the operational requirements for these systems will enable MQTT based infrastructures to provide more valuable real-time information to Line of Business MES/OEE/Track-and-Trace/Cloud Services solution requirements as well.

The purpose of the Sparkplug specification is to remain true to the original notion of keeping the topic namespace and message sizes to a minimum while still making the overall message transactions and session state management between MQTT devices and MQTT SCADA/DCS/ICS applications simple, efficient and easy to understand and implement.

This project proposal includes the Sparkplug specification itself, client libraries, and sample applications.

Scope

The scope of the Eclipse Tahu project consists of three major components:

  1. The Sparkplug Specification - This document describes the MQTT topic namespace, the payload-encoding scheme, and the required flow of messages, which ensure state of data originating from an edge device reporting to a backend/central application.
  2. Client library implementations initially in the following programming languages:
    1. C
    2. Java
    3. Javascript
    4. Python
  3. Reference implementations of Sparkplug applications using the client libraries.
Description

Eclipse Tahu addresses the existence of legacy SCADA/DCS/ICS protocols and infrastructures and provides a much-needed definition of how best to apply MQTT into these existing industrial operational environments.

Basic network architecture:

Tahu is currently addressing the following features required for MQTT centric IIoT:

Well-defined MQTT Topic Namespace applicable for the IIoT market

In order to be interoperable across the plethora of OEM device manufacturers of industrial equipment and the SCADA/HMI/Control/Cloud Services backend components that desired to subscribe to the resulting information a well-defined MQTT topic namespace needs to be defined. The topic namespace needs to be both efficient yet applicable to the applications that currently exist in the industrial market. The topic namespace needs to provide both the contextual information all the way to an individual device in the field, but also provide topic “verbs” to efficiently manage the “life cycle” of an MQTT session.

Efficient MQTT payload definition

Staying with the original intent of MQTT, the payload specification needs to stay “lean and mean” to best utilize low bandwidth networks (VSAT, Radio, Cellular). Not only does the payload need to be efficient, it needs to recognize the fact that the primary purpose of IIoT solutions is to provide Industrial Process Variable information from devices in the field to both SCADA/DCS/FCS OT solutions as well as line of business IT solutions.

MQTT STATE Management definition

MQTT has the awareness of the current MQTT session built in using the LWT feature. But for STATE aware OT applications like SCADA/DCS/FCS, there needs to be a succinct definition on how best to use MQTT’s built in STATE awareness in an overall SCADA/DCS/ICS infrastructure.

The Sparkplug specification provides all of the definitions and requirements listed above. In addition to the Sparkplug specification, Tahu will provide the required libraries and reference implementation code following the Sparkplug specification in:

  • C
  • Java
  • Javascript
  • Python

Tutorials on getting the reference implementation code running on popular open hardware platforms like the Raspberry Pi will also be included in Tahu.

Why Here?

Eclipse IoT is a good location for Eclipse Tahu for a number of reasons.  We believe that one of the best features of this technology is providing consistency around how MQTT is used in the Industrial Internet of Things (IIoT).  There are a number of hardware/device manufacturers that have already implemented it natively as well as some cloud/application software companies.  By open sourcing this technology through Eclipse IoT we believe it will accelerate the growth and adoption of it as well as provide a better and open forum for improvement and compatibility over time.

We also believe that there are a number of synergies with existing Eclipse IoT projects for Eclipse Tahu.  These include but are not limited to:

  • Kura
  • Kapua
  • Milo
  • Mosquitto
  • NeoSCADA
  • Paho
  • Smarthome
Project Scheduling

The Sparkplug specification already exists as does the code.  We'll need to do a bit of cleanup, refactoring, and completing the Eclipse legal review process but since we don't have too many dependencies we expect this should all happen fairly quickly.  Rough estimates:

Initial contribution expected: 5/2018

First working build expected: 6/2018

Future Work
  • Potential improvements/revisions of the Sparkplug specification.
  • Additional client library language support
  • Additional reference/sample applications
Project Leads
Committers
Chad Kienle
Mentors
Initial Contribution

There are three primary components to Tahu.  The first is the Sparkplug specification which is a document and will be released under a TBD license (creative commons maybe?).  The other two components are both Sparkplug libraries and reference Sparkplug implementations using the libraries if C, Java, Javascript, and Python.  All of these components will be included in the initial contribution.

The code is owned by Cirrus Link Solutions but has already been made available on a public Github site.  This is the code that will be moved to Eclipse under Tahu.  There are a number of OEM hardware manufacturers that are already using these libraries in their own commercial Sparkplug implementations.

With regard to third party licenses we have been careful all along to use 'Eclipse friendly' licenses.  This is a list of third party dependencies:

Jackson-annotations - Apache Software License v2.0

Jackson-core - Apache Software License v2.0

Jackson-databind - Apache Software License v2.0

Protocol Buffers - New BSD License

Apache Commons IO - Apache Software License v2.0

Log4J - Apache Software License v2.0

Eclipse Paho - EPL v1.0

SLF4J - MIT License

NanoPB - https://github.com/metormote/nanopb/blob/master/LICENSE

Source Repository Type

Eclipse Implementation of JAXB

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

This project is created as part of the process of transitioning Oracle Java EE 8 and GlassFish technologies to the Eclipse Foundation as described in The Eclipse Enterprise for Java Project Top Level Project Charter.

Scope

Eclipse Implementation of JAXB contains the source code, documentation, and tests for JAXB reference implementation.

Description

The Java™ Architecture for XML Binding (JAXB) provides an API and tools that automate the mapping between XML documents and Java objects. This project contains implementation of JAXB API.

Why Here?

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