Difference between revisions of "Google Summer of Code 2022 Ideas"

Revision as of 07:58, 26 January 2022

Please see our main Google Summer of Code page for participation information.

This year, projects should take ~175 hours or ~350 hours for GSoC contributors to complete.

Each project on the Ideas list should include:

• a project title/description
• more detailed description of the project (2-5 sentences)
• expected outcomes
• skills required/preferred
• possible mentors
• expected size of project (175 or 350 hour).
• And if possible, an easy, medium or hard rating of each project.

Project ideas

Project team member and potential mentors, add your content here. The format suggested below is just an idea. Play with the layout, but please don't mess with content provided by other projects. Please be sure to follow branding guidelines (e.g. "Eclipse Dash", not "Dash"). Putting things in alphabetical order seems like a fair thing to do. Links to content hosted elsewhere are fine, but bear in mind that this page will likely be the main point of contact for people who are not already inside your community.

Example Project idea

Description of the Example Project idea with links to more information, bugs, and other useful content. This could include a list of specific objectives

Expected outcomes list of the results expected to be achieved after completing of the project.

Skills required/preferred list of skill set required to be able to complete the project in the proposed time.

Project size 175/350 hours

Possible mentors: Somebody Mentor

Rating Easy, medium or hard rating of each project.

Eclipse Ditto – Cloud Events mappings

Description Eclipse Ditto is a digital twin project and can consume events for device updates from several messaging solutions (MQTT, Kafka). As Ditto needs to understand the payload, it provides a data model, which defines how data is represented inside Ditto. However, it needs to interface with existing systems, which do not follow the Ditto data model or encoding of that. Kafka (or MQTT) on the other hand can transport any kind of payload.

Cloud Events are a definition of some common properties of events, like payload and header, which maps to multiple event drive technologies (like Kafka, MQTT, HTTP/WS, AMQP, …). So a "cloud event" can be represented in all of those technologies, still allowing to transport any kind of payload.

This proposal is to bring Cloud Events to Ditto. There currently already exists a Cloud Events HTTP endpoint, which can passively accept Cloud Events. However, Ditto supports "connections", which are more active and implemented in a different way. These connections (might be Kafka, MQTT, …) either require the payload to be in the Ditto format, or allowing hooking in default/custom payload/event mapping logic to translate events into the Ditto format. Same for outbound messages, these can be mapped from Ditto into something that is understood be an external system.

So what is required to complete this project:

• Create an out-of-the-box inbound and outbound mapper, which translates Ditto events into Cloud Events (and back)
• Provide a way to use e.g. the "Normalize" step as part of that mapping

This includes:

• Defining a mapping specification
• Creating an implementation
• Creating unit-tests
• Updating the documentation

Expected outcomes an event mapper for Ditto Events to/from Cloud Events including a mapping specification, an implementation, unit tests, and documentation.

Skills required/preferred Java, Cloud Events, Maven

Project size 175 hours

Possible mentors: Jens Reimann

Rating Easy

Eclipse SWTChart (Radar/Spider Chart Support)

Description Add support to easily create radar and spider charts in SWTChart. Other chart types like Pie-, Doughnut-, Line-, Scatter- or Barplots are supported out-of-the-box already.

Expected outcomes: A specific type for radar and spider charts as well as an example section how to use them must be available after finishing the project successfully.

Skills required/preferred: Java, SWT, Eclipse, RCP, OSGi

Project size: 350 hours

Possible mentors: Philip Wenig

Rating: Medium

Eclipse SWTChart (Export Options)

Description Improve the existing export options in SWTChart, especially the SVG template export.

Expected outcomes: More export types shall be supported like Pie- and Doughnutplots. Additional options shall be added to export labels.

Skills required/preferred: Java, SWT, Eclipse, RCP, OSGi

Project size: 350 hours

Possible mentors: Philip Wenig

Rating: Easy

Eclipse 4diac (Domain-specific modelling environment)

Description Add user interface for testing software components (so-called Function Blocks) based on behavior models. Currently, the tool environment has limited tool support for (semi-)automated testing of Function Blocks. A framework for the test execution is however available.

Expected outcomes: A user interface for generating tests based on behavior models and executing them must be available (including documentation). It should be furthermore possible to record new scenarios, which can be later used as test cases.

Skills required/preferred: Programming skills required, preferably one or more of the following technologies: Java, SWT, Eclipse, RCP

Project size: 175 or 350 hours (scope can be adjusted)

Possible mentors: Alois Zoitl Bianca Wiesmayr

Rating: Medium

Eclipse Vert.x: JSONRPC as wire protocol for the eventbus TCP bridge

Description: Eclipse Vert.x offers a message-driven programming model based on an event bus that allows applications to scale to multiple processes or nodes without requiring code changes or knowledge during development. The event bus can be extended to non-native vert.x applications, including other platforms such as nodejs, python, etc... At the moment the wire format of the messages in this event bus bridge is vert.x specific. To make the bridge more accessible to everyone, a more popular format should be added. We would like to see JSON-RPC as a wire format as the current format is JSON based so the project should not require many changes for clients to adapt.

Expected outcomes: At the end of the project we should have simple communication with the existing bridge using a client of choice of the student using JSON-RPC showcasing the communication modes:

• send and forget
• request-response
• push

Skills required/preferred: Students should be fluent in Java programming language and have some basic knowledge on another language of choice to test the client.

Having some experience with asynchronous programming is highly recommended in order to understand the vert.x code base.

Project size: 350 hours

Possible mentor: Paulo Lopes

Rating: Medium/Hard.

Eclipse Vert.x: Implement Security audit logging for Vert.x Web

Description: Eclipse Vert.x Web is a small library to build modern web applications with vert.x. Although vert.x web already supports many security handlers, there is no easy way to create an audit authentcation logging trail. This project is to create a simple logging audit trail handler, that captures all the authentication related events and logs then to a specific logger.

Expected outcomes: At the end of the project, a handler, test and documentation should be delivered. One of the goals is to keep the handler agnostic to the backend logger, so the documentation should include examples on how to use common logging frameworks, either local or remote. Remove examples are required to showcase non repudiation.

Skills required/preferred: Students should have a good understanding of Java programming language and be able to learn or experiment with logging frameworks like logback or log4j.

Project size: 175/350 hours The scope can be adjusted to reflect the desired length.

Possible mentor: Paulo Lopes

Rating: Easy/Medium.