Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Google Summer of Code 2012 Ideas

Rules

  • 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.

Ideas

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.


Add SWTBot support for more Nebula widgets

SWTBot is an open-source Java based UI/functional testing tool for testing SWT and Eclipse based applications. It not only provides APIs that are simple to read and write, but also can run on all platforms that SWT runs on while very few other testing tools can perform such well in SWT and Eclipse based UI testing world. However, Nebula as a popular Eclipse project offering widely useful Custom SWT widgets, SWTBot still does not consider too much for it.

There is already someone realizing that SWTBot should be enhanced to support Nebula widgets, see the bug tracker [1] and Eclipse forum [2]. The bug reporter Aurelien has already done very interesting and significant work to enhance the SWTBot to support Nebula Gallery widget, however many other Nebula widgets(especially the released ones) may still yet not be supported after about 2 years since the bug reported. Thus in this summer, it would be very interesting and significant to help enhance SWTBot to support more Nebula widgets.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=325076

[2] http://www.eclipse.org/forums/index.php/m/537094/

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.

The contact person for this project is Bryan Hunt. For questions on this project, please use the MongoEMF Google Group

Candidate Student: Tiger Gui

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.

[1] http://eclipse.org/etrice

[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.

[1] http://www.informatik.uni-kiel.de/rtsys/kieler/

[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)

[2] http://eclipse.org/Xtext/#xbase

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 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

M2M and EMF Support by UOMo

UOMo and its type-safe Units of Measurement features offer a vast number of use cases for M2M and IoT scenarios. Especially items brought up by the M2M Industry Workgroup and related Eclipse projects like Koneki. These judging from the codebase so far rely almost entirely on string or other weakly-typed data. Thus where devices based on Android, Arduino, etc. are involved, and **sensor** values exchanged, UOMo can help in several ways. Either with **Data Binding** to type-safe beans and objects, or even in plain text information by providing type reliable unit meta information via the **UCUM** standard.

During last year's Eclipse DemoCamps attendees like CDO Lead Eike Stepper and others highlighted a great use for UOMo's unit type-safety in combination with Eclipse Modeling. Creating an EMF and ECore framework on top of UOMo and Unit-API is the second area, where UOMo could both benefit and be extremely useful to the Eclipse Ecosystem and its users.

[1] http://eclipse.org/uomo

Interested Student: Daniel Bali

Orion

The Orion project is a fairly new Eclipse project focused on creating browser-based software development tools. Last year, the Orion project sponsored two very successful GSOC projects, on Orion Git support, and Orion PHP support. Here are some ideas for Orion-related projects in 2012:

  • Orion programming language tooling for <insert programming language here>
  • Orion deployment tooling, and round trip support for <insert cloud platform here>
  • Git style "pull request" infrastructure within Orion
  • PhoneGap support for mobile web development
  • WordPress or Drupal plugin packaging the Orion editor
  • Integration of an open source web testing/automation framework such as Selenium Web Driver for UI regression testing
  • Git command line console
  • Language tooling on CSS:
    • Better CSS outline/parsing, knowledge of CSS3, media queries, etc.
    • Automatic image tooling for CSS be it data URI and/or sprites and keeping CSS up to date
    • CSS front ends like LESS
  • Additional file systems such as Dropbox, Amazon, (insert others). There is boilerplate already in our WebDav implementation.


Interested Student: Gaurav Agarwal

Mylyn

Please contact the development mailing list if you would like to discuss ideas.

Applicants should have prior experience with Eclipse plug-in development and be familiar with using Mylyn. Project proposals should outline a concrete plan for features that are to be implemented including a list of milestones. All ideas are welcome, proposals are not limited to ideas suggested below or tasks listed in Bugzilla.

Task-based workflows for EGit

In Git and Gerrit based workflows it is common to create branches on a per task basis, often referred to as topic branches. First steps to automate the process have been taken through integrating EGit and Mylyn but key pieces are still missing to for single click task-branching in Eclipse. The project should complete the partially implemented feature and propose features how to further improve Mylyn and EGit integration.

Activity tracing for Tasks, Builds, Reviews and Commits

The Mylyn task editor is the hub for task-focused collaboration. Yet, there are many other artifacts and activities that are part of the development workflow that are visualized in different views in the IDE. A unified activity view that aggregates tasks, builds, reviews and commits either in a dashboard or embedded in the task editor would nicely enhance traceability and visibility.

Real-time collaboration and social features for Mylyn

The Gravatar integration for the Task Editor puts names to faces but it's only the tip of the iceberg. There is a lot more potential to connect developers more closely. ECF and other frameworks could to bring real-time collaboration or even easily accessible shared editing to Mylyn.

Hudson/Jenkins Connector Improvements

The Hudson/Jenkins Connector is already a popular Mylyn extension for monitoring build status from Eclipse. Still, we have lots of ideas for improvement such as support for Matrix builds, code coverage integration, monitoring queues or browsing build plans. Working set based management of build plans and automatic subscription to topic branch builds could help automate workflows further.

Gerrit Connector Improvements

The Mylyn Gerrit Connector seamlessly integrates Gerrit code reviews with Eclipse. The extension is gaining rapidly in popularity and there is lots of room for challenging enhancements ranging from offline support to compare view improvements to tighter workspace integration.

SnipMatch and Code Recommenders

Eclipse Code Recommenders is a tool which can make IDEs intelligent, it help developers to reduce development costs. It supplies intelligent code completion, extended javadocs, smart bug detectors, stacktrace search engines and others.

Now, we want to add code snippets autocompletion feature for Code Recommenders project. SnipMatch is a code snippet search tool for Eclipse, you can find video demo, guide and document in its index page http://snipmatch.com/. This GSoC project aims to improve and merge SnipMatch into Code Recommenders project.

Interested Student:Cheng Chen

JGit

JGit Command Line Interface

The Command Line Interface (CLI) in JGit mimics its CGit equivalent. However, there is more to it than just having a second tool doing the same thing. The JGit CLI is a perfect way to verify robustness of the JGit Command API. It can be also used to simplify writing JUnit tests.

The project would be about adding new CLI commands to the o.e.jgit.pgm project and vice versa ie translating some of the existing CLI commands/switches to JGit Command API. In addition, the student could help with randomized JGit tests.

Eclipse Spykit - An Handy Tool for Startup Analysis

Background and History : Almost every day we hear of new companies adopting Eclipse as their application development platform of choice. With the number of Eclipse Projects growing in leaps and bounds in the Eclipse Community chances of the risk of memory bloat and performance degradation is high. Therefore Performance Tuning is the need of the hour in the Eclipse Projects.

This Project is inspired by Runtime Spy, one of Core Tools available from Eclipse.org. During our search for Runtime Spy, we realised that the support for this tool has been stopped since Eclipse 3.2 when Eclipse was moved to OSGI. Our motive of this project is to revive Runtime Spy back and add more functionality into the same and also create a set of tools that would come in handy for Performance Tuning of Eclipse Projects.

Current Implementation Available Eclipse Spykit on EclipseLabs.org Current Download Available Download Here

Tasks in Hand : Currently Eclipse Spykit is using from Internal BundleStats class to retrieve the relevant information for showcasing Startup Data. We need to write our own Bundle Watcher Class and remove dependancy on BundleStats. It also needs to be integrated with JUnit, SWTBOT, WindowsTester so that Plugin Count can be validated during System Test Cases. Reporting and Compare Facility to be made available.

Generating UI Test Cases using Window Builder

This is an interesting project wherein we build the UI and also generate the UI Test Case. This is an attempt to create a successful partnership between Windows Builder and Windows Tester.

What we get to see in most of our clients where we are around doing some Eclipse Consulting Work, they use Windows Tester for testing their UI and Windows Builder for building their UI. But whenever their UI changes they need to rewrite the Windows Tester. And as most of the companies today talk about agile methodologies such as Scrum or Xtreme Programming, this takes up quiet a bit of the unplanned effort in their Sprint Planning causing delays, failure in test case, rework raising the question over maintainability of system test cases.

Therefore this project is intended to build plugins that generates Windows Tester JUnit Code as we build or enhance UIs in Windows Builder ... :) This could be of great help to the developers as even if the UI is changed, UI Test Cases would be auto generated saving a lot of time for rewrite or rerecording of the UI Test Case.

This would relieve the team from worrying about maintainability of the System Test Cases and worry about better functionalities in the Project.

Retrieved from "https://wiki.eclipse.org/index.php?title=Google_Summer_of_Code_2012_Ideas&oldid=300237"

This page was last modified 11:09, 30 April 2012 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top