XWiki @ Google Summer of Code 2013

Last modified by Thomas Mortagne on 2017/03/24 12:15

This page hosts information and project ideas for the Google Summer of Code 2013. Students can come up with their own ideas, and propose them on the mailing list or the IRC channel.

Suggested way of working for GSoC students

First and foremost, working on XWiki needs to be fun and a good learning process! However, the XWiki project is already following some development rules that we're asking GSoC students to follow too. This is for the good of the XWiki project but more importantly it's a good way to learn how an open source community works. Also, if these practices are followed, it'll be much easier to integrate the resulting work into XWiki's official releases.

So here are some practices we'd like GSoC students to follow (please comment on the list if you'd like to change some of them or propose other things):

  • GSoC students should be considered like any XWiki contributor which means they should respect the same rules and that they are not committers on XWiki core. Note that a GSoC student can become a Committer in the same manner a contributor can become one.
  • GSoC students will be given commit access to the sandbox only, where they'll create their project (one top level directory for each project). For projects which need to modify some existing code, JIRA issues will need to be created and patches or pull requests to be attached. It's important that patches be of good quality and small in order to be applied quickly. Once sandbox projects reach a good level of maturity (meaning they work and the code is of code quality, documented, etc) then we'd like to migrate them to the main release tree.
  • GSoC students should obey all Community rules. For example this means:
    • using the XWiki coding conventions
    • using the defined communication channels: IRC and mailing list
    • etc
  • GSoC students have time allocated to familiarize with the XWiki development process. As such we'd like each GSoC student to pick one or several existing issues in JIRA and send a patch or pull request that fixes it/them before that period ends (from April 22th to May 22st) This is a critical integration step to ensure all GSoC students understand how XWiki works and it's a chance to start asking questions and get to know each other.
  • GSoC student should post a quick introduction on the xwiki dev mailing list to explain who they are and what they're going to work on.
  • GSoC students must periodically update their progress report for the project they have been assigned to.
  • GSoC students should create a Design page where they document technical aspects of the feature they are working on: architecture, use cases, problems, various solutions with pros and cons, etc. This page should be written as an XWiki community member and not a GSoC student (there is the progress report for that), ensuring that the page will remain relevant even after the GSoC period end.
  • GSoC student should always go to the list when communicating about their project. They should not talk directly to their mentors. They should use the XWiki IRC channel if they need to talk to them. The goal is that everyone in the XWiki community helps them, answers their questions but also knows what they are doing. This will make the integration of their work back into XWiki easier later on. This is very important and a criteria of success for the student. This is about learning how open source works... Note that student can also CC their mentor's email address if they want but the mails have to go to the XWiki dev list.
  • GSoC students should not block on anything for a long period of time. They should ask plenty of questions on the list (but they should also be autonomous!)
  • GSoC students should be as much as possible in contact with the community, following the mailing lists (and answering mails, when they know what to say), stay on the IRC channel, give regular status updates on their project. This does not mean that a GSoC student is not allowed to take a break, of course, but that, while working, a student should be integrated as much as possible with the community.
  • When taking a vacation/break, students have to notify the mentor; a mysterious disappearance could lead to a negative feedback afterwards.

Remember that this is not a summer job, or a Rent-a-coder like project, but a rewarded successful integration in an free software/open source community. If all you are interested in is the money, then better look for a real job, as Free Software requires passionate people; an ideal candidate is more interested in the t-shirt.

Good generic advises:

Conditions for success

Students will need to meet these criteria for success: 

  1. Must have something that works and is in some finished state.
  2. Must be integrated or close to be integrated in XWiki without too much effort
  3. Must have interacted correctly and continuously with the community
  4. The work must have been enough (it's supposed to be a 2 men/month effort)

Note that the real important part is 3) since this is a criteria for success for 1), 2) and 4).

Student Application template

Please use this template as the basis for your student application which must be submitted to Google.

Selected Projects for GSoC 2013 (1)

The projects below, out of all the proposed projects, have been selected to participate in GSoC 2013.

Improve/Add features of XWiki mobile client by Buddhiprabha Erabadda

Our current XWiki mobile client enables users to access their XWiki cloud instances through their mobile devices. Improve this mobile client in order to let the users benefit from XWiki's powerful features.

Coordinated by

. Estimated workload: 3 months.

Proposed Projects (20)

AJAX Interface Improvements2013

The current skin was written with accessibility in mind, meaning that it works well without javascript.

The next step is to add AJAX functionality on top of the existing code, minimizing the number of page reloads, adding new sliding effect to the interface elements, etc.

Coordinated by

. Estimated workload: 2 months.

ActivityStream 2.0

The Activity Stream offers an efficient way of keeping up with all the changes occurring in the wiki. However, the current implementation (for both the backend and the {{activity}} macro) is not very efficient and flexible. Work on a new backend has been started, but only as a lightweight component API, which still relies on the old activity macro for its implementation.

The goals of this project are:

  • extend the EventStream API to offer more usable methods
  • properly implement a Hibernate-based storage engine for the EventStream (improving the performance as well)
  • refactor the existing code that uses the ActivityStream plugin to use the EventStream
  • write a more scalable and performant {{activity}} macro:
    • seamlessly supports new event types
    • detects new events and offers to display them (like Twitter's UI)
    • supports loading more items
    • supports dynamic filtering / faceted search

Coordinated by           . 

Advanced Email Integration

Advanced email/chat integration would allow to have a full email/chat conversation that is captured as a discussion in an XWiki Document. Any email or jabber message in a specific channel would be automatically attached as a comment to a page. Any change or new comment to the page would be automatically sent to the jabber/email channel. An email channel could be a mailing list or a list of individual's emails.


  • Meeting notes
  • Brainstorming session
  • Directly answer from your email client to a notification mail regarding a document change event

Coordinated by

. Estimated workload: 3 month.

Any Integration with one or more Major Open Source Tool

We would love to see integration with other Open Source Tools. These integrations could be brining data and interaction of the other tool in XWiki or the opposite. 

This project leaves the student to propose which integration he would like to work on. 

Coordinated by

. Estimated workload: 3 month.

Dynamic RESTful services and other REST improvements

XWiki has a RESTful API that is implemented using server-side components written using the JAX-RS API. In order to deploy a new service, a new jar has to be deployed and the server restarted.

The goal of this project is to provide a way for extending XWiki with new additional RESTful services without restarting the server. This can be done by writing the definition of the service directly in XWiki pages using the Groovy scripting language, and by leveraging structured data (XWiki classes+objects) in order to provide metadata about the defined services.

Additionally new services would also be implemented:

  • XWiki livetable implementation
  • Full page access (read and write) in one request (page + objects + attachements)


This project is quite important as it would allow to play nicer for Mobile and with Advanced Javascript Framework

Coordinated by

. Estimated workload: 3 months.

Git/GitHub application

There are already several extensions that deal with git: a module that allows to perform operations on a git repository from the wiki, a small GitHub stub that allows to list committers for an organization or a project, and a more complex application that allows to synchronize wiki pages with a repository on GitHub. The goal of this project is to provide a richer integration with git:

  • a space in the wiki can be linked to a repository on GitHub (or any other git repository)
  • display in the wiki active pull requests and their status (when using a GitHub repository)
  • insert custom events in the Activity Stream for new commits, pull requests, comments on commits, new/deleted branches or tags...
  • code and committers statistics
  • list commits, linking user names to users in the wiki, and issue numbers to the corresponding Jira issue

Another direction is enhancing the GitHub Commit Application:

  • better UI
  • better handling of merges
  • support for selective commits (like git add --interactive)
  • better support for user configuration

Coordinated by           . 

Improve/Add features of XWiki mobile client

Our current XWiki mobile client enables users to access their XWiki cloud instances through their mobile devices. Improve this mobile client in order to let the users benefit from XWiki's powerful features.

Coordinated by

. Estimated workload: 3 months.

Improve Extension Repository

XWiki provide an extensions repository for anyone to easily deploy contributions. See http://extensions.xwiki.org.

The goal of this GSOC is to improve it. The student will have to study it and propose improvements, there is no definite list of things to do.

Here are some ideas: Repository open Jira issues.

Coordinated by

. 

Improve l10n.xwiki.org

XWiki community maintain a wiki with a special application to help translation XWiki projects on. See http://l10n.xwiki.org. Sources can be found on https://github.com/xwiki-contrib/application-l10n.

The goal of this GSOC is to improve it. The student will have to study it and propose improvements, there is no definite list of things to do.

Various ideas:

  • make all this a lot more dynamic
  • provide tools to refactor things a bit:
    • it's hard to move some translation from one space to another (for example the applicationresources on XE should be on Platform)


Coordinated by

. 

Improve the messaging feature

A relatively new feature of XWiki is the ability to send messages to certain users, groups, or globally in a whole wiki. Although useful, messages can easily go unnoticed, since there are no notifications about received messages. Some improvements could be:

  • a more inbox-like view of received messages
  • keep track of read/unread messages
  • a global notification of unread messages in the top menu bar
  • UI for replying to a message
  • improved message sender UI

Coordinated by           . 

Integrate the CKEditor WYSIWYG Editor

The goal is to replace the xwiki-coded editor by the CK Editor one: http://ckeditor.com/ (see demo at  http://ckeditor.com/demo).


  • Better, with more features, less bugs, more active development (http://ckeditor.com/get-involved/our-team).
  • It's not XWiki's business to write a WYSIWYG editor
  • All our competitors are using bleeding edge editors and we need to catch up
  • CKEditor supports Data Processors to integrate with wiki markup, see http://docs.cksource.com/CKEditor_3.x/Developers_Guide/Data_Processor
  • Cool features:
    • Inline editing
    • Magic line
    • Skins/colors
    • Search/replace
    • Table resizer
    • Right click actions for tables (insert new column, etc)

The goal of this GSoc project is to succeed in creating an extension to replace the current editor with the CKEditor one. One area to pay attention too is Macro rendering and ability to editor macro content/parameters.

Coordinated by

. 

LDAP server implementation

The idea is to be able to use an XWiki instance as a LDAP server to authenticate users and get groups.

The LDAP and XWiki models are very close (entries containing object of defined classes) so the idea came to implement an LDAP interface with XWiki model as backend.

The GSOC will be a success if the following user case is covered: use XWiki as LDAP server for another instance of XWiki.

Coordinated by

. 

Live Notifications inside XWiki

The project refers to the ability of having Live Notifications integrated inside XWiki.

The notification system will be generic and able to address use cases such as:

  • When editing a page inside XWiki and a new editor opens the page, notify the current editor about the other collaborators;
  • Notify the user that the page he is viewing has been updated;
  • Integration with the current Activity Stream (display live notifications of new/deleted comments, new/deleted pages, etc.);
  • Integration with the current Watchlist (receive a notification when a favorite page has been modified);
  • A private message has been received (an advanced mode would be a real-time chat);
  • Applications events:
    a new event has been added in your calendar;
    • you have been invited to a workspace;
    • added/removed to a group;
    • etc.

The notification system will have both a server-side (Java) component and a client-side (JavaScript) component. It will be implemented as a generic system available to all applications that would like to send live notifications to an user or a group of users. 

More extension repositories

Right now XWiki Extension Manager support plain Maven and XWiki Extension (http://extensions.xwiki.org) repositories.

The idea is to add support for as much other kind of repositories as possible.

Here are some good examples:

  • Nexus
  • Bintray
  • Pypi

See http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManagerRepositories for more details.

Coordinated by

. 

Translation in context

XWiki 4.4 introduce new translation macro which will allow to find easily translated content in a page when using annotated XHTML renderer.

The idea is to use that and provide a "translation mode" where you can directly select and translate what you see in the page (when the translation macro is used). The idea is also to make easy to contribute to http://l10n.xwiki.org from your local wiki by sending your corrections to it.

Coordinated by

. 

Wiki Collections

An XWiki extension for creating and managing collections of wiki pages. The extension must provide both

  • a component and a script service to access the collections programmatically (i.e. an API to create and manage the collections programmatically)
  • and a user interface to allow simple users to manage their collections of wiki pages.

For the API you can rewrite the xwiki-plugin-collection into a component, but only after a discussion on the devs mailing list. For the UI you can implement Caty's proposal for Selective Export UI, of course, without the export options.

Collections are extremely useful as the input for:

You should check how the existing Multipage Export Application uses the xwiki-plugin-collection in order to understand the main use case for Wiki Collections.

Coordinated by

. Estimated workload: 175 hours (Medium size project).

Wiki Console

Enhance the CRaSH Console extension to:

  • make it available for users that don't have programming rights (limiting the set of available commands based on user rights)
  • be able to write commands that redirect the current page (e.g. a document export command)
  • be able to write new commands outside the crash-api jar (e.g. in wiki pages, using Groovy code).

Then implement XWiki specific commands to:

  • browse the wiki using a "cd"-like command
  • list the "children" of the current entity (wiki, space, document) using a "ls"-like command
  • delete, move, rename wiki entities (wikis, spaces, documents, objects, attachments)
  • create or edit wiki entities (redirect to edit mode)
  • less, grep, find, uname etc.
  • actions specific to each wiki entity (export a wiki page with various parameters, view the history of a document, etc.)
  • more (ask the community)

Coordinated by

. Estimated workload: 175 hours (Medium size project).

Write Eclipse Orion Plugin to edit XWiki pages and embed Orion in XWiki

Eclipse Orion is a Web IDE from Eclipse: http://www.eclipse.org/orion/

XWiki is a powerfull development framework allowing to develop 100% from the Web

The first objective it to build an Orion plugin to communicate with XWiki and allow to view the applications installed in an XWiki instance and add code to them (Javascript extensions, CSS extensions, Velocity and Groovy scripts, Scheduler jobs, etc..). This would allow to edit XWiki code from Orion and save changes to XWiki and view the results right away.

The second objective is to embed the Orion code inside XWiki to be able to run the IDE from XWiki itself. From App Within Minutes you should be able to launch the Orion IDE UI and load all the code from the AppWithinMinutes application.

Finally it should be possible to edit and XWiki class from the Orion UI.

Coordinated by

. Estimated workload: 3 month.

XCLAMS: Federated Servers

The XWiki Collaborative Learning Assets Management System is used in several projects of sharing platforms for learning content, among others: curriki.org, i2geo.net, and planete.sankore.org.

The project's work is to implement web-based tools in these platforms so that content in one platform can be made visible in another. Differently than federated search, the objective is to allow an easy transport of a resource from one server to another where it starts a new life while it keeps a link to the original. That transport should be initiated by a function triggered by a user who thinks it is useful to copy to bring the resource closer to him/her or a group or him/her.

Ideally, the tool should scale to support administrators that transport complete collections (as much as 1000) of selected learning resources.
Moreover, the link to the original should be kept and displayed and it should be possible for a user to request an upgrade of the transported resource if the source has been updated and if compatible. The practice of versionning systems such as git or mercurial should be a model. The project would be very successful if it can employ the 3-way-merge facilities of the underlying XWiki to this process, making it possible to work in parallel.

Such a contribution is likely to support initiatives as to build an local copy of Curriki with selected content which can serve a local community of teachers (the Curriki team has been asked for such by governments of countries with a relatively limited external internet bandwidth). Moreover, this contribution should be created in a sufficiently generic way so that any XWiki installation that has the necessary XWiki objects to transport the learning resources can exploit it.

Mentors: the XCLAMS community, including Joshua Marks, Paul Libbrecht (confirmed),  Ludovic Dubost and Flavius Olaru (to be confirmed) with regular checks with active members of the communities of the servers above.

Delivery: open-source code (LGPL) using Groovy, Velocity, Unix command-line-tools, that can be made part of the XCLAMS core code.

Coordinated by

. Estimated workload: several weeks.

ePub Publisher

The tool proposed here is to provide a shell to publish ePub archives that work on mobile devices. The objective is to export assemblies of pages within an ePub book that can be enjoyed offline on devices following identified profiles.

In particular the XWiki Collaborative Learning Assets Management System, an OER sharing platform in use by several projects, supports the assembly of learning resources of diverse origins and types by a concept of collections which encourages re-usability. This project should enhance this re-usability by an export feature that allows the content of a collection to be exported as e-book.

The software should support the author in predicting and verifying the playability of the content on various devices (e.g. warning that a Flash file is not going to work on the profile Aldiko on Android). It should also leverage open-source softwares such as Swify, ImageMagick, of ffmpeg to ensure an embedding that is reasonable in size and that works. An environment for prototyping the delivered ePub is central to this work.

The Curriki and Sankoré teams, together with the trainee, will support this choice in suggesting environments in wide use in their target population where this can be tested in the timeframe of the project (schools in the US, India, France, and the French speaking Africa).

A very successful contribution would include code that we can deploy to any XCLAMS installation. It should, with a small amount of changes, allow developers to also export to other package formats such as SCORM or Common Cartridge.

Mentors: the XCLAMS community and Curriki team, among others Paul Libbrecht and Joshua Marks (confirmed), as well as Ludovic Dubost and Flavius Olaru.

Delivery: open-source code (LGPL) using Groovy, Velocity, Unix command-line-tools, that can be made part of the XCLAMS core code.

Coordinated by

. Estimated workload: several weeks.

Previous GSoC editions

Get Connected