Below, you will find various project ideas for Google Summer of Code 2013, and we'll update this page as we refine our application and as other project proposals arrive and by including feedback both from the Groovy ecosystem and the students who would like to work on a Groovy based project.
Students, if you wish to have further details about the below projects, don't hesitate to reach out to us through comments on this page, or by discussing those projects ideas on our mailing-lists. We'll be happy to expand the descriptions of those projects, and give more details or guidelines as to what our expectations are.
Groovy on Android (DiscoBot project)
Possible mentor: Jochen Theodorou
Lazy data structures and comprehensions
The idea would be to have Groovy support generators, lazy evaluations, ... See for example: http://blog.bloidonia.com/post/22117894718/groovy-stream-a-lazy-generator-class-for-groovy
It is also important to take a look at what APIs are being written in JDK 8 because most of the APIs written for the new lambdas are specifically lazy.
Possible mentor: Paul King
As we are overhauling our documentation, the Groovy project is interested into having documentation that is fully tested and always up-to-date with our codebase. With those objectives in mind, a little tool has been created to provide a solution for having "executable documentation": Dokspek (https://github.com/glaforge/dokspek). This tool takes wiki pages in entry, extracts Groovy code snippets from the content, to run those snippets as JUnit tests, and then resulting in HTML documentation and tests that are passing as part of our test harness.
We'd like to further improve this tool and put it in place in the Groovy codebase. Additional refinements can be brought, like having nice table of content, indexing of concepts, PDF and HTML documentation generation, etc.
Project: Groovy / DokSpek
Possible mentor: Guillaume Laforge
Remoting and distribution for GPars
The distinction between single-VM concurrency and concurrency among distributed nodes is becoming blurred. Actors can be distributed across multiple nodes in a network, dataflow variables and channels can transport values across the single-machine boundary as well as the state preserved by agents can reside on a particular place in the network and may need to be accessed from other places. As part of this assignment the participant would design and implement remoting for actors, agents and dataflow channels. Ideally remoting should not have impact on the existing API, should be pluggable to leverage different communication protocols and should be implemented as an optional add-on to limit performance and memory overhead when single-machine concurrency is used.
Possible mentor: Václav Pech
GPars provides several concurrency and parallel solutions, like actors, dataflow, etc. And in enterprise contexts, it's interesting to know how those solutions perform, how to get feedback from them, in the form of various metrics. For example, how much actor mailboxes may be full or not, which queues are currently used, etc. The idea of this GSoC project is to introduce a way of monitoring those various concurrency constructs so as to be able to gather useful feedback on the usage in a concrete usage context, so as to be able to further fine tune the configuration of those constructs (increase the thread pool, etc). This project likely involves wiring in some JMX beans for the monitoring.
Possible mentor: Václav Pech
Project: Groovy / GrooScript
Possible mentor: Jorge Franco