XWiki @ Google Summer of Code 2011

Last modified by Eduard Moraru on 2020/03/24 12:54

XWiki has been accepted as a mentoring organization for Google Summer of Code 2011.

This page hosts information and project ideas for the Google Summer of Code 2011. 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 and if these practices are followed then 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 which means 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 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 XWiki development process. As such we'd like each GSoC student to pick one or several existing issues in JIRA and send a patch that fixes it/them before that period ends (from April 25th to May 23rd) 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 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 help them, answer their questions but also know what they are doing. This will make patch applications and integration of their work back into XWiki trunk 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, 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.

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

Selected Projects for GSoC 2011

Auto Completion in Content Editors

The general goal is to allow auto completion in Wiki and WYSIWYG editors for inserting links, images, macros and more. In practice you'd start typing some characters and you'd get a completion list as you get in Java IDEs for example. Here's an example: you start typing "[" and you get a list of documents to which you've recently navigated to, you continue typing letters and the suggestion lists narrows to documents containing this letter, etc.

One goal is to make the WYSIWYG editor as fast to use as the wiki editor.

For details see http://jira.xwiki.org/jira/browse/XWIKI-206 See also the implementation done by Confluence: http://confluence.atlassian.com/display/DOC/Confluence+3.2+Beta+Release+Notes

In addition a secondary goal could be to support wiki syntax in the WYSIWYG editor (for example with an option to activate the wiki syntax mode for a given syntax). In this mode if the user types, for example, "**hello**" then it's transformed into bold. This would allow to benefit from the best of both worlds.

To summarize the general goals of this project are:

  • Speed up content editing in both WYSIWYG and Wiki editors
  • Make the wysiwyg editor attractive to advanced users too and make it approach the speed of the wiki editor

Coordinated by

. Estimated workload: 3 months. Read more...

XEclipse

XEclipse is an Eclipse plug-in that allows the user to edit, view, save or delete XWiki pages directly from within the Eclipse IDE. 

The current XEclipse version is unmaintained and has several limitations. The most important one is that it is tied to the XMLRPC interface of XWiki which was originally built having Confluence compatibility in mind. This fact introduced some "impedance mismatches".

This project aims to "RESTify" the communication layer so that all XWiki features would be available and easily accessible from XEclipse. This means:

  • Review of the storage abstraction layer
  • New storage implementation using the XWiki REST API
  • Multiwiki support in the navigator view (using the updated storage)

Coordinated by

. Estimated workload: 3 months. Read more...

Google Android client

An Android application which offer easy edition and navigation in a wiki.

Two separated packages:

  • an Android library which offer an API to make easier for an application to communicate with XWiki (using REST behind the scene probably): it's maybe the most important part on the long term, would be great for any kind of android application to synchronize its datas with an XWiki instance so that it can be shared between several phones
  • an Android application with at least the following
    • navigate between wikis, spaces and pages
    • edit page source
    • edit page objects/classes
    • some way to view the page rendered (at the minimum a link to launch the browser on the proper page)
    • should be possible to continue edit the page and save it when there is no connection (it will be synchronized latter when the connexion come back)

Nice to have:

  • integrated view of the page
  • rights/groups/users management UI

Proposed Projects (21)

Annotations for images and other content types

Extend the Annotations Module (svn, demo) in order to allow annotating images and sections of images.

Additionally, research and implement a method to add and visualize annotations on document attachments: .pdf, office documents (word, presentation), etc.

Coordinated by

. Estimated workload: 3 months. Read more...

Auto Completion in Content Editors

The general goal is to allow auto completion in Wiki and WYSIWYG editors for inserting links, images, macros and more. In practice you'd start typing some characters and you'd get a completion list as you get in Java IDEs for example. Here's an example: you start typing "[" and you get a list of documents to which you've recently navigated to, you continue typing letters and the suggestion lists narrows to documents containing this letter, etc.

One goal is to make the WYSIWYG editor as fast to use as the wiki editor.

For details see http://jira.xwiki.org/jira/browse/XWIKI-206 See also the implementation done by Confluence: http://confluence.atlassian.com/display/DOC/Confluence+3.2+Beta+Release+Notes

In addition a secondary goal could be to support wiki syntax in the WYSIWYG editor (for example with an option to activate the wiki syntax mode for a given syntax). In this mode if the user types, for example, "**hello**" then it's transformed into bold. This would allow to benefit from the best of both worlds.

To summarize the general goals of this project are:

  • Speed up content editing in both WYSIWYG and Wiki editors
  • Make the wysiwyg editor attractive to advanced users too and make it approach the speed of the wiki editor

Coordinated by

. Estimated workload: 3 months. Read more...

Mobile Skin for XWiki

Create a lightweight mobile skin for XWiki, or rather make the already existing colibri skin websafe for the mobile devices. Use W3C widgets to put the core files on the mobile phone so that you only need to download the data (save network traffic). See also:

Coordinated by

. Estimated workload: 3 months. Read more...

Photo Album Application

The previous Photo album in XWiki was very basic, allowing only to create albums with a description, add photos without any information attached to them and browse through these photos in simple manner. This application was removed from the default distribution of XWiki Enterprise, as it did not meet the quality and usability requirements.

We wish to recreate this application, with the following features:

  • creation of albums, with additional data attached to them: title, description, date(s), location
  • adding and managing photos and information about them (such as description, date, location, author, camera information, etc); could be done automatically by reading EXIF information from the photos
  • view as thumbnails and slideshow (with adjustable timer and with manual browsing) - see also the new Gallety Macro
  • migration tool from the old version photo albums.

The application should have a friendly AJAX UI, but should also be functional in browsers without JavaScript. Il must be easily skinnable through CSS.

In addition to the client side UI, some interesting features requiring platform changes would be:

  • uploading an archive that contains several photos, and automatically extract the photos from it (as opposed to uploading the photos one by one).
  • better tags implementation, allowing to tag attachments
  • better comment implementation, allowing to associate comments with an attachment

More modern features based on the upcoming HTML5 standard could be:

Coordinated by

. Estimated workload: 3 months. Read more...

Specific WikiMacro Editors

XWiki now has a very powerful WYSIWYG editor based on GWT which includes a wizard for inserting wiki macros (for example, for displaying message boxes, footnotes, mathematical formulas, etc).

This GSoC project consists of improving the macro editing mechanism, by allowing to use macro-specific WYSIWYG editors: a mathematical expression editor for the formula macro, a SVG editor for the svg macro, etc.

Coordinated by

. Estimated workload: 3 months. Read more...

Wiki Editor Improvements

XWiki now has a very powerful WYSIWYG editor based on GWT which includes wizards for inserting links, images, tables and wiki macros.

However, some users may prefer to use the Wiki editor, which allows to have full control over the source of the wiki page.

This GSoC project consists in redesigning and improving the Wiki editor, with the main purpose of enriching it with the aforementioned wizards, and of integrating a user friendly Wiki Syntax Help and Syntax suggest feature.

Coordinated by

. Estimated workload: 2 months. Read more...

Macro support improvements

This project proposal is a draft. More macros need to be added to the list.

Add support for parameter types for wiki macros.

Reimplement existing Radeox and Velocity macros as 2.0 syntax macros:

  • IM Presence
  • image
  • jira
  • spoiler
  • twitter/identi.ca

Develop new macros:

  • author (document, lang, withLink)
  • creator (document, lang, withLink)
  • version (document, lang)
  • object display
  • children (doument, lang)
  • history (document, lang, withMinorEdits)
  • attachments (document, type, by, orderBy=name)
  • blog (space|global, number of posts, summary or content, categories)
  • recent changes (space, tags, number, type=all|comments|attachments...)
  • search
  • tabs (type=horizontal|vertical, {label: page})

See also:

Coordinated by

. Estimated workload: 3 months. Read more...

Improved ColorTheme Wizard

The current ColorTheme Wizard has a hardcoded layout that does not always reflect the current layout of the wiki and for this reason is not 100% WYSIWYG.

A first step is towards a better ColorTheme Wizard is to standardize the key html elements of the UI. This should to be done by the dev team before starting the project.

The new wizard should appear in full screen and should take into account all the CSS/velocity changes that have been introduced in the wiki (i.e. not rely on the default look).

Coordinated by

. Estimated workload: 2 months. Read more...

Blog application performance improvements

This project mainly consists of re-writing the velocity macros powering the Blog Application into a Groovy component with access to protected API which performs the same tasks with increased efficiency.

Coordinated by

. Estimated workload: 3 months. Read more...

Calendar Application

The previous Event Calendar in XWiki was very basic: in a monthly view, it would allow to add and display events stored as XWiki objects in the calendar's wiki document. This application was removed from the default distribution of XWiki Enterprise, as it did not meet the quality and usability requirements.

We wish to recreate the Event Calendar application, such that it would allow to:

  • display day, week, month, year view for the calendar
  • store the event objects anywhere in the wiki
  • have a friendly UI for adding, changing and filtering events
  • import events from the old version event calendar.
  • support microformats
  • export in standard formats (ical)

The application should have a friendly AJAX UI, but should also be somewhat functional in browsers without JavaScript. It must be easily skinnable through CSS.

Coordinated by

. Estimated workload: 2 months. Read more...

XWiki Pseudoversions

Currently, each XWiki document modification creates a new version of that document: the save and continue action, adding/deleting objects or class properties, etc. In the end, most documents will end up with a lot of versions that should not be visible in the document's history because they constitute work in progress and are not informative by themselves. Additionally, the results of actions like adding or deleting an object from the object editor do not disappear when canceling the edit, which may create confusion for unexperienced users.

A possible solution to these issues are pseudoversions. Pseudoversions are temporary versions of a document being edited, and can be seen as short-lived versioning branches, resulting in a one official version when the user finishes editing the document.

A chain of pseudoversions is tied to a user, meaning that by default the user's changes are saved as pseudoversions in a private branch. When the user finishes editing the page by clicking "save", the last pseudoversion is saved as a full version, and the branch is deleted.

In addition to giving an answer to the problems listed above, pseudoversions created regularly during document editing can serve as a back-up system, so that users can recover unsaved work in case of a browser crash or other types of accidents that may cause data loss. 

See also: http://jira.xwiki.org/jira/browse/XWIKI-500

Coordinated by           .  Read more...

CMIS Integration

CMIS (Content Management Interoperability Services) is a proposed standard for improving interoperability between Enterprise Content Management systems (http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services)

The idea is to implement a CMIS layer that will provide XWiki content to clients.

The CMIS specs proposes two types of bindings 1) A RESTful one based on AtomPub 2) A SOAP one 

The project will focus on the RESTful binding.

The implementation would leverage the Apache Chemistry framework and will be integrated in the current REST backend of XWiki (taking into account also the needed modifications)

Links:

Coordinated by

. Estimated workload: 3 months. Read more...

Add support for parameters types in Wiki Macros

In XWiki Rendering macros parameters are typed and automatically converted when the macro is executed.

The goal is to support the same thing in Wiki Macros:

  • add UI to choose the type of the parameter (probably link it somehow with the types supported by the WYSIWYG)
  • do the conversion when the wiki macro is executed

See also http://jira.xwiki.org/jira/browse/XWIKI-5496

Coordinated by

.  Read more...

XEclipse

XEclipse is an Eclipse plug-in that allows the user to edit, view, save or delete XWiki pages directly from within the Eclipse IDE. 

The current XEclipse version is unmaintained and has several limitations. The most important one is that it is tied to the XMLRPC interface of XWiki which was originally built having Confluence compatibility in mind. This fact introduced some "impedance mismatches".

This project aims to "RESTify" the communication layer so that all XWiki features would be available and easily accessible from XEclipse. This means:

  • Review of the storage abstraction layer
  • New storage implementation using the XWiki REST API
  • Multiwiki support in the navigator view (using the updated storage)

Coordinated by

. Estimated workload: 3 months. Read more...

XEclipse editors improvement

XEclipse is an Eclipse plug-in that allows the user to edit, view, save or delete XWiki pages directly from within the Eclipse IDE. 

The current XEclipse version is unmaintained and has several limitations. Editors have syntax-highlighting but they are not in sync with the current evolutions of XWiki and they do not reuse code from the XWiki codebase for implementing their features.

This project aims at improving content editors (documents, scripts and objects) starting from a correct support for XWiki syntaxes (and scripting fragments). In particular:

  • Integration of the existing parsers that are used in XWiki for parsing content (see http://rendering.xwiki.org)
  • Move from a static and hardcoded API definition to a dynamic one that queries the (velocity, groovy, etc.) APIs from the server and caches it locally.
  • Object editor improvements

Coordinated by

. Estimated workload: 3 months. Read more...

Google Android client

An Android application which offer easy edition and navigation in a wiki.

Two separated packages:

  • an Android library which offer an API to make easier for an application to communicate with XWiki (using REST behind the scene probably): it's maybe the most important part on the long term, would be great for any kind of android application to synchronize its datas with an XWiki instance so that it can be shared between several phones
  • an Android application with at least the following
    • navigate between wikis, spaces and pages
    • edit page source
    • edit page objects/classes
    • some way to view the page rendered (at the minimum a link to launch the browser on the proper page)
    • should be possible to continue edit the page and save it when there is no connection (it will be synchronized latter when the connexion come back)

Nice to have:

  • integrated view of the page
  • rights/groups/users management UI

AJAX Form Editor

As part of the "App Within Minute" project, it would be interesting to have an AJAX form editor. This form editor would allow to drag and drop fields in a visual design with multiple columns and sections. Empty spaces could be included and some cells could be widden to multiple columns or rows.

The result of the visual editor should allow to generate the adequate velocity script and reload it in the editor.

Coordinated by

. Estimated workload: 3 month. Read more...

Scalable XWiki on NoSQL (AppEngine, Cassandra prototype)

The objective of this project is to have a working prototype of XWiki running on AppEngine and/or Cassandra using the DataNucleus API for storage and querying. This requires writing a query layer to translate XWiki queries to DataNucleus queries compatible with Google's storage.

Coordinated by

. Estimated workload: 3 month. Read more...

XWiki Cloud9 IDE integration

The objective is to use the Cloud9 IDE to edit XWiki code. All pages should be saved in XWiki and have nice editors with syntax highlighting.

An interesting part of the project would be to support velocity and/or groovy debugging running the Cloud9 Editor's debugging APIs.

Coordinated by

. Estimated workload: 3 month+. Read more...

Dynamic RESTful services

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.

Coordinated by

. Estimated workload: 3 months. Read more...

Structural Search and Replace

Implement something similar to IntelliJ's IDEA Structural Search & Replace (see http://tv.jetbrains.net/videocontent/intellij-idea-static-analysis-custom-rules-with-structural-search-replace ), i.e. the ability to perform search and replace on multiple documents, based on structure. The elements that can be searched/replaced could be:

  • title
  • syntax
  • some elements of the XDOM (for ex search for an HeaderBlock containing such content followed by a ListBlock and replace it
  • ... and more

Coordinated by

. Estimated workload: 2 months. Read more...

Previous GSoC editions

Tags:
   

Get Connected