Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

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

(Eclipse Advanced Scripting Environment)
Line 16: Line 16:
  
 
Possible mentors: [mailto:zeratul976@hotmail.com Nathan Ridge]
 
Possible mentors: [mailto:zeratul976@hotmail.com Nathan Ridge]
 +
 +
= Eclipse EMF Client Platform: A generic Editor framework for JSON =
 +
 +
EMF Forms is an Eclipse framework to efficiently develop form-based UIs (see http://eclipse.org/ecp/emfforms/). It also provides a renderer for web applications called “JSON Forms”. JSON Forms transfers the concepts of EMF and EMF Forms to a JSON Schema and a React-based web stack. EMF Forms provides tooling to create and modify UI specifications (UI schemata). However, it is bound to SWT and XML. For JSON Forms there is only text-based editing of schemata currently, this is tedious and error-prone.
 +
 +
The goal of this project is to provide a web-based editor to support the creation and modification of a UI schema, which can directly be consumed by JSON Forms. This editor should be available in a stand-alone version as well as an extension to Theia. The feature set follows the existing desktop version provided by EMF Forms with a focus on usability in the web.
 +
 +
The editor itself shall be implemented based on the framework. This means, tree and form elements of the editor are rendered with JSON Forms. The ultimate goal is that the editor can describe itself and therefore eases the evolution of the tool.
 +
 +
Possible mentor: [mailto:mkoegel@eclipsesource.com Maximilian Koegel]
 +
  
 
= [http://eclipse.org/hono Eclipse Hono]: Web frontend for device registry =
 
= [http://eclipse.org/hono Eclipse Hono]: Web frontend for device registry =

Revision as of 13:48, 5 February 2018

Warning2.png
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.


Eclipse CDT: Integration with the Language Server Protocol

Eclipse CDT (C/C++ Development Tools) currently uses a homegrown C++ parser and code analysis engine for providing semantics-aware navigation, completion, refactoring, and other editing features. This parser has fallen behind in C++ language support (e.g. it currently has only partial C++14 support and no C++17 support) and is increasingly a maintenance burden.

The Language Server Protocol is a protocol that allows decoupling "language servers" that provide support for semantics-aware features, from editors / IDEs that provide the UI for these features. This facilitates reusing the parser and code analysis engine already present in a compiler like clang, exposed via a language server. There is a project underway to support the client side of the protocol in Eclipse, LSP4E.

The goal of this GSoC project is to integrate Eclipse CDT with clang-based C/C++ language servers such as clangd or cquery.

Specific work that this could involve includes:

  • Enhancements to LSP4E (support for new parts of the protocol, or enhancements to the implementation of existing parts), as motivated by CDT's needs
  • Enhancements to CDT to make using the LSP integration smoother (e.g. project configuration, making use of existing settings)
  • Enhancements to CDT to implement LSP protocol extensions that are specific to C/C++, or to a particular C/C++ language server (for example, cquery supports a protocol extension for semantic highlighting that might be neat to support in CDT)

Possible mentors: Nathan Ridge

Eclipse EMF Client Platform: A generic Editor framework for JSON

EMF Forms is an Eclipse framework to efficiently develop form-based UIs (see http://eclipse.org/ecp/emfforms/). It also provides a renderer for web applications called “JSON Forms”. JSON Forms transfers the concepts of EMF and EMF Forms to a JSON Schema and a React-based web stack. EMF Forms provides tooling to create and modify UI specifications (UI schemata). However, it is bound to SWT and XML. For JSON Forms there is only text-based editing of schemata currently, this is tedious and error-prone.

The goal of this project is to provide a web-based editor to support the creation and modification of a UI schema, which can directly be consumed by JSON Forms. This editor should be available in a stand-alone version as well as an extension to Theia. The feature set follows the existing desktop version provided by EMF Forms with a focus on usability in the web.

The editor itself shall be implemented based on the framework. This means, tree and form elements of the editor are rendered with JSON Forms. The ultimate goal is that the editor can describe itself and therefore eases the evolution of the tool.

Possible mentor: Maximilian Koegel


Eclipse Hono: Web frontend for device registry

Eclipse Hono Eclipse Hono™ provides remote service interfaces for connecting large numbers of IoT devices to a back end and interacting with them in a uniform way regardless of the device communication protocol.

The goal of this project would be to develop a simple web frontend for the already existing device registry. Allowing users to view and manage users and devices. For this the existing API should be used when possible. If necessary the backend can be extended with new APIs. Existing technologies and libraries should be re-used.

The tasks would be:

  • Draft a UI
  • Evaluate and choose a frontend technology stack
  • Define necessary APIs
  • Do the actual frontend implementation, backend if necessary

Optionally there could be:

  • An automated UI test
  • A mobile version of the UI

Eclipse Hono: AMQP protocol adapter

Eclipse Hono Eclipse Hono™ provides remote service interfaces for connecting large numbers of IoT devices to a back end and interacting with them in a uniform way regardless of the device communication protocol.

For connecting to devices/gateways Hono allows the use of different protocol adapters in order to normalize the payloads to the internal AMQP 1.0 based network. Current protocol adapters are HTTP and MQTT. However it would be nice to use the flow control features of AMQP 1.0 also from the device/gateway layer. In order to perform authentication and normalization it would be necessary to create an AMQP adapter. Tapping directly into the internal AMQP network is not an option.

The tasks would be:

  • Draft an AMQP 1.0 based API for communicating with the protocol adapter
  • Create an implementation of the protocol adapter based on Hono's abstract base classes for protocol adapters and the vert.x proton library
  • Create unit tests

Optionally there could be:

  • A scale test/performance test

Eclipse Hono: CoAP protocol adapter

Eclipse Hono Eclipse Hono™ provides remote service interfaces for connecting large numbers of IoT devices to a back end and interacting with them in a uniform way regardless of the device communication protocol.

For connecting to devices/gateways Hono allows the use of different protocol adapters in order to normalize the payloads to the internal AMQP 1.0 based network. Current protocol adapters are HTTP and MQTT. Adding CoAP to the list of supported protocols would be a fine extension.

The tasks would be:

  • Draft a CoAP based API for communicating with the protocol adapter
  • Create an implementation of CoAP protocol adapter based on Hono's abstract base classes for protocol adapters and Eclipse Californium
  • Create unit tests

Optionally there could be:

  • A scale test/performance test

Eclipse Kuksa

Eclipse Kuksa unifies technologies across the vehicle, IoT, cloud, and security domains in order to provide an open source ecosystem to developers addressing challenges of the electrified and connected vehicle era. In-vehicle and cloud applications as well as their development infrastructure, maintenance approaches, security, and over-the-air (OTA) update and upgrade management are, with a few exceptions, completely within the scope of Eclipse Kuksa.

Topic 1: IDE for Yocto-image based embedded systems development

Eclipse Kuksa unifies various key technologies such as e.g.

  • Yocto for creating customized operating systems for each of the individual target platforms
  • Automotive Grade Linux (AGL) as an open operating system and framework for automotive application
  • Eclipse Che for developing applications and services for these platforms

As setting up workspaces for cross-developments towards custom targets tends to be very time-consuming and complicated, the goal of this topic is to enable support for Yocto-generated images and SDKs in the Eclipse Kuksa IDE.

Possible Mentor: Lukas Krawczyk

Topic 2: Kuksa-based LWM2M Implementation

Another major open issue to be addressed within Eclipse Kuksa is the investigation and utilization of LWM2M communication. Eclipse Leshan already provides java client and server implementations. Consequently, the Leshan protocol adapter must be added to the running Kuksa environment such that device registry and device management services can be utilized. For convenience purposes, implementations can be based on the RPI3 Rover in order to address the following topics:

  • Client implementation for a RPI3 Rover based on AGL (Automotive Grade Linux)
  • Server implementation of the Leshan adapter on Eclipse Kuksa
  • LWM2M over MQTT investigation: UDP vs TCP etc.
  • Investigation of security concepts (e.g. DTLS) & possible implementation of further security concepts
  • Evaluation of LWM2M communication for real-world vehicle use cases

Possible Mentor: Robert Hoettger

Eclipse OMR

Eclipse OMR provides reliable C and C++ high performance components (garbage collector, Just In Time compiler, platform porting library, asynchronous event handling, tracing, diagnostics, ...) for building all kinds of language runtimes such as Java, Ruby, Python, Lua, etc. These components were originally distilled and contributed from the IBM J9 Java Virtual Machine and made available for use in other language runtimes. The OMR project also includes a library called JitBuilder, which lets you create a JIT compiler for a new language relatively quickly.

Our ultimate goal is to build an open reusable language runtime foundation for cloud platforms in full cooperation with existing language communities. There are currently OMR based runtimes for Java (IBM J9), CRuby (Ruby+OMR Technology Preview), Lua (Lua Vermelha), Smalltalk (SOM++ with OMR), Rosie Pattern Language, Base9 (an ultra simple runtime for workshop-based learning about the OMR JitBuilder library).

Here are some of our project ideas :

  • Port a (subset of a) new language or runtime to use OMR (e.g. Python,R, Julia, make a suggestion!) using the JitBuilder library
  • Use JitBuilder to dynamically compile native code to accelerate some application (e.g. Apache Spark, NumPy/SciPy, or make a suggestion!)
  • Implement a general/dynamic object model. The object model should support Javascript and Ruby.
  • Port JitBuilder interface to another language (e.g. Ruby, Python, make a suggestion!)
    • Java bindings exist so you can write Java code to dynamically generate native code callable as a JNI method
    • similar model could be applied to another language or possibly using SWIG to make JitBuilder accessible from more languages
  • Port OMR to a new hardware platform (e.g. ARM64)
  • Enhance Intel processor vector instruction support in the OMR compiler
    • add support for 256- and 512-wide vector data types and enhance JitBuilder interface to handle different width data
    • showcase with JIT compiled vectorized code!

Eclipse SmartHome

Eclipse SmartHome is a framework for home automation solutions which integrates many different protocols and smart home technologies.

Topic 1: IOTA Tangle Integration

Eclipse SmartHome could potentially interact with the IOTA distributed ledger for machine-to-machine communication. The project proposal is to develop a proof-of-concept which integrates Eclipse SmartHome with the IOTA technologies.

  • A project proposal could include the following features:
    • Access the IOTA tangle with an Eclipse SmartHome instance.
    • Provide actions for rules to start transactions on the IOTA tangle.
    • React on transactions happening on the SmartHome instances address.
    • Implement a IOTA transaction based transport between sensors and the SmartHome hub.

Topic 2: Integrate with Google's Physical Web

Google's Physical Web is an approach to make things easily discoverable and usable based on proximity information. As Eclipse SmartHome deals with many "Things", it would be nice to smoothly integrate with the Physical Web, i.e. an Eclipse SmartHome instance can announce itself and could potentially make subsets of things available based on the user's location. The project could also target openHAB 2 and its Android app and iOS app, where Bluetooth beacon support could help on indoor location and writing urls to the beacon.

  • Proposal Focus: A project proposal could include the following features:
    • An Eclipse SmartHome instance (e.g. the openHAB 2 runtime) should announce itself through mDNS in the local network. Any smartphone that is in the same network and has the Physical Web app installed should directly find the instance and open the web client (Eclipse SmartHome Basic UI) of it.
    • A concept for persons and locations should be introduced, which allows tracking user locations, so that rules can compare and relate user and beacon locations.
    • Bluetooth beacons could be programmed with (local) URLs that are location specific (e.g. "living room") and which open the web client with this context, i.e. directly display the page for the living room. As this uses local URLs, this obviously only works for smartphones that are on the local network.
    • As an extension, the Bluetooth beacons could use public URLs that point to https://myopenHAB.org (or some other reverse proxy mechanism), which can provide access to certain functionality for guests that are NOT on the local network. The tricky part of this is how to ensure the proximity of the guest (it should only provide access, if he is physically present). The beacons might have to broadcast a temporary access token with the URL that needs to be validated by the reverse proxy service.
    • As openHAB 2 is the main open source solution that uses Eclipse SmartHome, its native smartphone clients could be enhanced to directly support the Physical Web: Bluetooth beacons could be directly programmed with a location-aware URL through the smartphone app.
    • Additionally the native apps could use the Bluetooth beacons to determine the current location of the user (at the granularity of a room, if there is at least one beacon inside) and provide this information to the runtime, so that rules can make use of this information for context-aware use cases.
    • Last but not least, the last two features can be combined: The smartphone app (in the background) reports the user location to the runtime, which in turn sends local mDNS (or global Bluetooth) announcements for the room or even for relevant devices within this room.

Topic 3: Enable Dynamic UI Layouts

Currently, Eclipse SmartHome defines a textual way for describing contents and hierarchies for user interfaces (the so-called Sitemaps). This rather static approach does not allow graphical editors, which would e.g. enable the user to move around widgets, add and hide some and in general customise his graphical user interfaces from directly within the UI.

There have been ideas for a new sitemap concept since a while, but no prototype has been built yet. The goal would be to be able to edit the sitemap information as a JSON structure through the REST API and that event notifications would be adjusted to (only) provide what is relevant for the active page.

The project could also adapt the existing Basic UI to allow the user to do customations like re-arranging the widgets. Another worthwhile feature would be a clever algorithm that comes up with an initial sitemap based on the devices and rooms that are available in the user's setup - this would provide an easy way to get started without being confronted with an empty screen.

Eclipse SUMO: Simulation of Urban Mobility

SUMO is a free and open traffic simulation suite. SUMO allows modelling of intermodal traffic systems including road vehicles, public transport and pedestrians. Included with SUMO is a wealth of supporting tools which handle tasks such as route finding, visualization, network import and emission calculation. SUMO can be enhanced with custom models and provides various APIs to remotely control the simulation.

The goal of our GSoC project is to make SUMO more accessible for users of graphical user interfaces and facilitate alternative ways of setting up and interacting with the simulation. Specific work that this could involve includes:

  • Development of a GUI for traffic demand generation/definition/modification
  • Development of a "Replay" functionality for trajectories of vehicles
  • Development of SUMO-as-a-WebService functionalities / WebWizard / WebGL prototyping
  • Development of GUI-elements to visualize critical situations and locations in a traffic simulation
  • Development of interfaces and connections to external (live) data, e.g., General Transit Feed Specification (GTFS) for public transport
  • Development of GUI-elements to visualize public transport timetables and public transport networks
  • Initial concept and development for a model describing the dynamics of (container) ships
  • Development of 3D visualization components for SUMO (open scene graph, Web3D, HTC Vive)

Possible mentors: Michael Behrisch, Jakob Erdmann


Eclipse Dash

NOTE that this is basically a placeholder to give mentors an idea of how they might format a section of their own. This may actually survive as an idea to present to students, but--by way of expectation management--expect that it will disappear.

Eclipse Dash is a place where the community itself can collaborate on tools for community awareness and collaboration in support of our ultimate objective of committer quality and cooperation. This is very much a research project as we are not entirely sure what these tools will be.

Here are some of our project ideas:

  • Extend the Eclipse Dash Gently Dependency analysis tools to identify the use of third-party JavaScript libraries bug 509617
  • Update the IP cartoons and move them to the handbook bug 498290

Eclipse SW360

Eclipse SW360 is a software catalogue for organizations, small companies, large enterprises, open source projects. This software catalogue captures with software components (commercial and open source) are used in projects and products. It allows for sharing information about these software components and enable reuse for following aspects:

  • Licensing of components and generate open source documentation
  • Source files for generating source distributions
  • Vulnerabilities
  • Metadata such as links, contributors inside the organizations

For example, SW360 can trigger a clearing process in FOSSology and import the resulting clearing report, it can import scan projects from other compliance tooling, import security vulnerabilities from cve- search and manage license obligations applicable to components.

Technical Project Information

Technologies: Java, JavaScript, Angular 2, Docker, CouchDB, Tomcat, Spring, REST, Liferay, Thrift

SW360 is an active project licensed under the EPL-1.0. We as developers have two teleconference calls a week and do most conversations on Github, the rest is done on sw360chat.slack.com. We do a feature based workflow on Github, so the best way to get started with our is: fork our project, looks at the issues labeled "low hanging fruit" and propose a pull request when you are ready.

We have a definition of done in our github wiki.

And, we have a very simple dev enviromment setup using vagrant: https://github.com/sw360/sw360vagrant

And of course, if you want to have our solution state of the art deployed, use the dev deployment profile for our docker scripting: https://github.com/sw360/sw360chores

General Link: https://github.com/sw360/sw360portal

GSoC Information

We have a lot of ideas of course. You could also check the issue tracker for large issues. But the best way would be to have a cool subproject which is adding a new story to Eclipse SW360, which can be segmented in several steps and which provides something awesome out of our daily issue crunching flow. Subprojects include:

  • Topic 1: Control Room. Having a cockpit view for the components and projects: How many components do we have on average in use in our products? What is the share of commercial and OSS components? Which are the most popular components? This could be also implemented with some charting framework such, drawing management friendly pie charts (yay!)
  • Topic 2: New Web GUI for selected services of Eclipse SW360. Web GUI for Services SW360 has a REST-API exposing its functionality and a set of portlets that can be integrated into a enterprise portal. However, for many people it would be much nicer if they just have a ready to use Web UI without the need to have a web portal running. Therefore, exposing the functionality with a new Web frontend would be good. Work has already started into that direction and an implementation for the component service is already available. As part of this project you would implement a GUI for the Project and License service respectively using the available REST-API.
  • Topic 3: Database Migration Automatic for CouchDB. We need to use this when doing version updates (we use semantic versioning), then we need to have migration scripts, currently written in python, but they shall automatically recognize versions. There is flycouchdb on github, but there is last commit 2015. Let's think how to do this right.
  • Topic 4: Artifact Storage in external Artifact Repositories Eclipse SW360 maintains its own artifact repository to store and maintain artifacts. However, in many organizations other solutions such as Sonatype Nexus or JFrog Artifactory are used for that task. In this project you would implement another artifact storage backend that uses already existing artifact repositories to manage artifacts.
  • Topic 5: User Management with external Key-Cloak Service To allow an easy integration of SW360 in enterprise IT it is crucial to allow to connect user management systems. Key-Cloak allows to integrate with a lot of different systems via various protocols and additionally also allows to do its own user management. Using such a system would simplify setting up user management for SW360. Your task would be to (1) setup a custom service to run a Key-Cloak instance in SW360 and (2) implement a connector to Key-Cloak for SW360.
  • Topic 6: Integrate SW360 with Workflow Engine Compliance issues are often defined in enterprise processes and need to be implemented in workflow engines. It would ease the integration of SW360 into company processes if it would directly allow to integrate into an existing workflow engine. The project would be to realize some base processes in a selected workflow engine.


Eclipse Dirigible: Cloud Development Platform

Eclipse Dirigible™ is a Cloud Development Platform providing development tools and runtime environment. It supports full development life-cycle of on-demand applications by leveraging in-system programming models and rapid application development techniques.

Some quick-wins that can help students to dig deeper into the database technologies:

Integration scenarios related to API facades and Security:

  • Integrate noSQL database (e.g. Cassandra) by providing a client module as well as exposing an Enterprise Javascript API for application developers
  • Integration of external OAuth providers (Google, Facebook, etc.) in Dirigible's applications
  • Exposing some of the standard Java cryptography algorithms as (KeyStore, Signature, etc.) as Enterprise Javascript API
  • Integrating an external Messaging Server (e.g. Kafka, RabitMQ) by providing a client module and exposing an Enterprise Javascript API

Form based editors implementation using Angular 1.x and Bootstrap:

Debug support for V8 engine:

  • Integrating the V8 engine with the Chrome DevTools via WebSockets protocol

Applications developed with Eclipse Dirigible itself, which can be easily embeddable in bigger business applications afterwards (Javascript at the backend + Angular 1.x and Bootstrap at the front-end):

  • Wiki - collaboration portal using the built-in Markdown wiki engine
  • Forum - collaboration platform with topics, discussion boards, voting, etc.
  • Project - simple project management platform with tasks, priorities, collaboration, etc.
  • by student's choice

Eclipse Advanced Scripting Environment

EASE allows to dynamically execute scripts within the Eclipse context and therefore automate your IDE. Further script language extensions can be used to build your own DSL-like dialects.

If you are interested in one of the topics you have to apply on the mailing list.

Topic 1: Cucumber (behavior driven testing) integration

Behavior driven testing is an interesting approach to separate the process of defining tests and implementing them on a specific language. EASE comes with a full featured unit test environment for JavaScript and Python. The task here is to provide builders and binding for the Gherkin syntax and allow to compile and execute such test definitions to script code.

Possible Mentor: Christian Pontesegger

Topic 2: Dependency keyword

By introducing a new keyword for plugin dependencies, scripts could aid the user to install required components before run. A detailed description is given in Bug 511525.

Possible Mentor: Christian Pontesegger

Back to the top