Skip to main content
Jump to: navigation, search

Google Summer of Code 2012 Ideas

Revision as of 12:14, 16 February 2012 by (Talk | contribs)


  • Be creative
  • Be specific: what do you want to be implemented
  • If you are willing to mentor those ideas, add your name and email to the idea.
  • GSoC project ideas should align with an existing Eclipse project
  • If you're an interested student, add your name and email next to the idea. It is ok to have several students interested in one idea.
  • Aspiring students and mentors need to register and submit their proposals on the SoC app

Mentors info

If you were a mentor last year then you are automatically in the list this year (the GSoC site may require that you re-register, but we think of you as "in").

Note that we only accept as mentors people who are known to us. This includes Eclipse committers. If you would like to be a mentor, please either introduce yourself to the group using the soc-dev mailing list, or send a note to EMO.

Ideas submission

Idea proposal should contain the following information:

  • project title, like "WTP - Improve auto-complete in xml editor"
  • description with links to bug reports, project wiki pages, etc
  • Reporter: who submitted idea (optional e-mail)
  • Possible Mentors: who would like to mentor the students
  • More info: other links or e-mail
  • Eclipse Project: link to main eclipse project that improvement is targeting
  • Potential students: who is interested (with optional e-mail). This one completely informal, to actually be interested you need to submit the proposal. Contact the idea owner or possible mentor to get some details before submitting it.


These are some ideas. Students feel free to base your GSoC proposals on these ideas (note that you are more likely to find a mentor for an idea that has been proposed by a mentor). Some of these ideas can be factored into multiple projects; a GSoC project proposal can work on parts of these ideas (i.e. you don't necessarily have to do it all).

There are other sources of ideas. There are numerous bugs in the Eclipse Bugzilla issue tracking system marked as "helpwanted" that may give you ideas.

Xtext, EMF, and MongoDB

Ed Merks and Bryan Hunt have created a project called MongoEMF that allows you to persist EMF objects to MongoDB. MongoEMF has the ability to query objects based on attribute and reference values, but is lacking some functionality and robustness. We think a re-write of the query engine using Xtext and EMF would make for a great Google Summer of Code project. This project has a very well defined scope, is easily unit tested, and involves some pretty cool technology.

The project will consist of two major parts. The first will be to define a query grammar (possibly re-using an existing grammar) using Xtext. The result will be an EMF query model that can be serialized and de-serialized to a string. The string will be used as the query portion of a URI, and must be human readable. For example: mongo://host/db/collection/?(tag == 'java' || tag == 'JSON') && (category == 'Eclipse'). Clients will be able to specify the query as string or EMF model. The second part of the project will be to create a processing engine that builds a MongoDB query from the EMF query model. The result will be a DBObject that can be sent to MongoDB as a query.

An example use-case is as follows: A client constructs an EMF query model. The query model is then serialized to a string and included in a URI. The URI is sent to a server in a HTTP GET call. The server extracts the query string from the URI and re-builds the EMF query model. The query model is passed to the query engine and a DBObject is returned containing a MongoDB specific query. The DBObject is sent to MongoDB resulting in some number of DBObjects returned. The resulting DBObjects are converted into EMF objects and returned to the client.

The student is expected to develop extensive unit tests for his / her code as well as end-user documentation. Documentation will be contributed to the UserGuide on the MongoEMF wiki. We also anticipate that the student will become a committer on MongoEMF, and will continue to provide bug fixes and enhancements after the project is complete.

We consider this to be an advanced Eclipse project. The student should already be comfortable coding in Java and developing OSGi bundles with Eclipse. A student with working knowledge of EMF will be preferred, but you are not required to already know Xtext or MongoDB. If you are interested in this project, I would recommend forking the MongoEMF project on GitHub and experimenting with the latest code in the master branch. Instructions for setting up your environment can be found on the Development wiki page.

Ideas around the eTrice project

The Eclipse eTrice project [1] is an exciting project that applies modeling techniques to the domain of embedded real-time software development.

The project team has collected and formulated four ideas, each of witch is probably to the same degree challenging as it is rewarding. Henrik [2], the eTrice team's contact persons for Google Summer of Code related questions, is looking forward to answer the questions of interested people.


[2] contact person for all four proposals: Henrik Rentz-Reichert

Diagram Layout with KIELER

The University of Kiel (Germany) has developed a framework for the "graphical model-based design of complex systems" [1]. We would like to enhance the graphical editors of eTrice using this technology. Currently there is an editor for hierarchical finite state machines and another one for structural system specifications, both according to the specification of the ROOM language [2]. Since the semantic model information of eTrice ROOM models is stored in a pure textual form (using Xtext) the diagrams just contain layout information. We see two use cases for automatic diagram layout: during creation of an initial diagram from the textual model and during editing (including model modification) using the graphical editor. KIELER already integrates into Eclipse and Graphiti. For this project it is necessary to investigate the capabilities of the KIELER framework and to apply it to the two diagram types of eTrice.

Applicants should already be familiar with plug-in development in Eclipse and have at least some experiences with EMF.


[2] Bran Selic, Garth Gullekson, Paul T. Ward: Real-Time Object Oriented Modeling, New York: John Wiley, 1994 (ISBN 0-471-59917-4)

Generic Action Code Language

The ROOM modeling language [1] spans the modeling space along three dimensions: behavior (using finite state machines), structure and inheritance. The so called Detail Level Language in ROOM closes the gap to the target programming language for which the code is generated from the model. The Detail Level Language is used for the entry, exit and action codes of the state machines and usually is identical with the target language. Since eTrice provides code generators for Java and C (and later also for C++) it would be nice to have a common Detail Level Language for all of the supported target languages. The idea of this proposal is to create a language based on Xbase [2] which should be powerful enough to express typical constructs common to the three target languages like variable declarations, assignments, expressions, method calls and execution control (if/else and loops). This language could then be used as the Detail Level Language in eTrice ROOM models and the code generators would translate the code into the respective target language. Such a Generic Action Code Language would not only allow to keep the models independent of the target language but would also offer the possibility to apply methods of abstract model execution to do extended model validation and proposal generation on a semantic level.

Applicants should already be familiar with plug-in development in Eclipse and with language design using Xtext.

[1] Bran Selic, Garth Gullekson, Paul T. Ward: Real-Time Object Oriented Modeling, New York: John Wiley, 1994 (ISBN 0-471-59917-4)


Extended Model Validation and State Graph Proposal Generation Based on Protocol Semantics

Protocols in ROOM [1] define sets of incoming and outgoing messages. Those messages are exchanged between actors and consumed by the actor behavior which is implemented as a hierarchical finite state machine. A consumed message may result in a state transition. If now the protocol is equipped with a semantical description which specifies for each message the allowed reply message then it is possible to apply some extended model checking and generate proposals for the state machine elements using methods of abstract model execution. In a precursor tool we already have shown that this method is very powerful. The idea is to apply this technology in the context of the eTrice tools.

Applicants should already be familiar with plug-in development in Eclipse and have at least some experiences with EMF.

[1] Bran Selic, Garth Gullekson, Paul T. Ward: Real-Time Object Oriented Modeling, New York: John Wiley, 1994 (ISBN 0-471-59917-4)

Worst-Case Execution Time Analysis

For embedded software with hard real-time constraints it is crucial to be able to guarantee upper bounds of execution times. In an event driven systems with state machines like in ROOM [1] the typically scenario is: an interrupt creates a first event. This is processed by a state machine which may in turn create new events which are processed by other state machines and so on. After some time all events are processed and the system is idle until the next interrupt. The interesting time is that from the first event until the time when the system goes idle again. The model offers enough information to be able to compute this execution time provided that the user annotates timing information in the model. Together with some measured timing information for the runtime library (implementing messaging etc.) the picture is complete and rich enough to derive reasonable upper bounds. The idea of this proposal is to develop an abstract execution engine which allows to compute (a conservative upper bound for) the longest execution time for a given initial event (cf. [2]).

Applicants should already be familiar with plug-in development in Eclipse and have at least some experiences with EMF.

[1] Bran Selic, Garth Gullekson, Paul T. Ward: Real-Time Object Oriented Modeling, New York: John Wiley, 1994 (ISBN 0-471-59917-4)

[2] Automatic Derivation of Loop Bounds and Infeasible Paths for WCET Analysis Using Abstract Execution

Back to the top