XWiki @ Google Summer of Code 2016
- About GSoC
- XWiki Guidelines
- Student Application template
- Selected Projects for GSoC 2016 (1)
- Proposed Projects (16)
- Android XWiki authenticator and contact synchronization
- DokuWiki importer
- Translation in context
- More extension repositories
- MediaWiki importer
- Improve l10n.xwiki.org
- Blame View
- Convert existing tests to the latest technologies
- Glossary Application
- ePub Creator
- MicroData Enrichment
- Any Integration with one or more Major Open Source Tool
- GitLab-GitHub integration in XWiki WebIDE
- RedPen Integration
- Presentation Application Overhaul
- Chart.js Integration
- Contact us
- Previous GSoC editions
This page hosts information and project ideas for the open source project XWiki related to the Google Summer of Code 2016 mentorship program.
About GSoC
You can learn a lot about the program by reading the GSoC FAQ. The timeline of this year's edition is given here.
XWiki Guidelines
Being part of the XWiki community means knowing our rules and practices. As a GSOC student you need to make sure you read and apply our guidelines.
Student Application template
When applying for one of our projects, please provide this information about yourself and the project you choose in the application which you submit to Google.
Selected Projects for GSoC 2016 (1)
The projects below, out of all the proposed projects, have been selected to participate in GSoC 2016.
Android XWiki authenticator and contact synchronization by Fitz Lee
The idea is to integrate a wiki instance in Android accounts.
The main use case is to get all the contact of your company/association intranet automatically synchronized on your phone so that you don't have to use a browser, go to your intranet, login and search form some user to see if he entered his phone in his profile. The other important part is to make sure this is as integrated and as standard as possible from Android point of view and allow other applications to use registered XWiki authenticators to access an XWiki instance without the need for the user to give the password to that application.
In Android parameters add a XWiki account and get a form to indicate the instance URL, a user and a password (or even anonymous for public wikis) and get automatic synchronization of XWiki users in the Android contacts.
Some work in that direction started on https://github.com/xwiki-contrib/android-authenticator but never get finished so the best would probably to start from this.
Proposed Projects (16)
Students can come up with their own ideas, but the ideas need to be proposed and discussed on the mailing list.
- Android XWiki authenticator and contact synchronization
- DokuWiki importer
- Translation in context
- More extension repositories
- MediaWiki importer
- Improve l10n.xwiki.org
- Blame View
- Convert existing tests to the latest technologies
- Glossary Application
- ePub Creator
- MicroData Enrichment
- Any Integration with one or more Major Open Source Tool
- GitLab-GitHub integration in XWiki WebIDE
- RedPen Integration
- Presentation Application Overhaul
- Chart.js Integration
Android XWiki authenticator and contact synchronization
The idea is to integrate a wiki instance in Android accounts.
The main use case is to get all the contact of your company/association intranet automatically synchronized on your phone so that you don't have to use a browser, go to your intranet, login and search form some user to see if he entered his phone in his profile. The other important part is to make sure this is as integrated and as standard as possible from Android point of view and allow other applications to use registered XWiki authenticators to access an XWiki instance without the need for the user to give the password to that application.
In Android parameters add a XWiki account and get a form to indicate the instance URL, a user and a password (or even anonymous for public wikis) and get automatic synchronization of XWiki users in the Android contacts.
Some work in that direction started on https://github.com/xwiki-contrib/android-authenticator but never get finished so the best would probably to start from this.
DokuWiki importer
Filter Stream framework allows converting from one wiki representation to another. The idea here is to provide a Filter input module for DokuWiki so that it's possible to convert from DokuWiki to any Filter output format.
You can get inspiration from http://extensions.xwiki.org/xwiki/bin/view/Extension/Import+DokuWiki+into+XWiki+Application and http://extensions.xwiki.org/xwiki/bin/view/Extension/Dokuwiki+To+XWiki2+Extension.
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.
Various ideas for the look and feel of this feature:
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.
MediaWiki importer
Filter Stream framework allows converting from one wiki representation to another. The idea here is to provide a Filter input module for MediaWiki so that it's possible to convert from MediaWiki to any Filter output format.
The best is probably to convert https://github.com/xwiki-contrib/sandbox/tree/master/xwiki-wikiimporter/xwiki-wikiimporter-mediawiki-xml into a WikiStream module and improve it.
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
- importing is a long task and you always get a timeout before it's finished (it's still continuing on the server so it's not broken but still). A progress bar could be nice (could be based on extensions:Extension.Job Module)
- default translation edition table is not exactly the nicest UI you could think of (http://l10n.xwiki.org/xwiki/bin/view/XE/XWikiCoreResources?action=viewall&language=fr)
- 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)
- use new nested spaces to better organize resources (the whole platform is in the same space right now for example)
etc.
Blame View
A blame view is applied to a specific version of a document (or more generically, some content) and displays which user is responsible for introducing or modifying each section (paragraph/line/word, depends on the granularity) of that content. An example of this can be GitHub`s blame view.
Since 2014 we have a nice Blame Module extension (source code) which is able to provide all the needed information (an analogous of the git blame command, if you like).
What we still need, however, is to create a nice UI over the outputs of the blame module and to integrate it in the history view. You can consider the previously mentioned GitHub blame UI as s starting point, but you are most welcomed (and encouraged) to propose improvements that might be more adapted to XWiki's use case.
Since this is mostly an UI project, your proposal will also need to feature UI mockups on how you plan for the UI to look and justifications for the design choices you`ve made in the attempt of making your result intuitive and easy to use. You could even propose more than one direction, showing pros and cons, etc.
Remember that this is supposed to be a feature used mostly by non-technical persons, so it might need a bit more thinking about it.
As with all projects, this would have to be packaged and published as an extension on http://extensions.xwiki.org so you will also need to think about how it would be the best way of integrating the extension in XWiki's UI, once installed, so that it becomes useful in day to day use, and not just something optional that nobody will discover or use.
Getting this project right has a high chance of it making it into the XWiki product itself, since it is a feature that we've wanted to have in XWiki for a long time.
Convert existing tests to the latest technologies
XWiki is an Open Source project more than 10 years old and it has gone through various technologies and ways of doing things to get where it is. This does not only apply to its functional code, but also to its testing framework.
As you can see from our testing documentation and from the test code itself, we are still dragging along a big part of the tests which are written in older technologies (mostly JUnit3 and JMock 2.x for unit tests, Selenium 1 for functional tests). When we have moved to the newer testing framework, we did not have the manpower to convert existing tests and just started writing the new tests using the new technologies.
We are looking for a student with a passion for testing to convert our older tests (both the functional and unit ones) and help us slowly get rid of the older testing framework (selenium1 and any previous component testing framework). In slightly more details, this involves:
- Upgrading the Selenium 1 functional tests to use Selenium 2 and Page Objects. These tests are currently located in the xwiki-enterprise-test-selenium module.
- Upgrading the Junit3 and JMock unit tests to use JUnit4 and Mockito.
- Moving all the functional tests from xwiki-enterprise-test to the various related projects on xwiki-platform-core since we will eventually remove the xwiki-enterprise repository altogether.
Any remaining time would be used in adding new tests (and missing page objects for functional tests) to increase the overall coverage.
The ratio of focus on either functional or unit tests is up to the student and based on his/her preferences, but this ratio will have to be detailed, agreed upon and committed to by the student in the proposal so that we can clearly evaluate if and when the objective of the GSoC project is achieved by the student or not.
Improvements along the way to our testing framework can also be proposed, including new testing techniques.
There is much to be learned in the process!
Some relevant mails (and threads) with answers to questions already asked by students and additional details on the project. Please read them before asking:
Glossary Application
Develop a Glossary Application in XWiki.
The idea would be to present a list of definitions in the Glossary App (one page per definition), letting users create new Glossary items. This should be developed with the App Within Minutes application.
Then we have 2 possibilities:
- Writing a Rendering Transformation to automatically create links to the Glossary item page when a page renders.
- Provide a Macro so that users can insert manually to both link to a Glossary item page and if this page doesn't exist to directly bring the user clicking it to a new page for creating that Glossary item
Of course there are plenty of other features that can be imagined and it's left to the student to make the best possible Glossary app in the allocated time!
ePub Creator
The tool proposed here is to provide an environment to create ePub archives that work on mobile devices. The objective is to export assemblies of wiki pages within an ePub book (a zip of XHTML files) that can be read offline on mobile devices.
The software should complement the XWiki collaborative editing mechanism to support the author in predicting and verifying the display of the content on various devices (e.g. warning that a given tag is not going to work on the profile Aldiko on Android XVGA, or presenting on a window of that device size to insure a reasonable layout is achieved). It should also leverage open-source media-conversion softwares such as ImageMagick, or ffmpeg to ensure an embedding that is reasonable in size and that works on the target sizes and platforms.
A very successful contribution should, with a small amount of changes, allow developers to also export to other package formats such as Mobi, SCORM or Common Cartridge and maybe even deliver Android's APK applications.
Discussion: is to happen on the xwiki-devs mailing-list as well as on the #xwiki IRC channels.
Delivery: open-source code (LGPL) using Groovy, Velocity, Unix command-line-tools.
MicroData Enrichment
XWiki allows comfortable and user-friendly web-page editing for both novice users and experts. This project aims at creating the necessary XWiki objects, their edition, and the page rendering so that microdata annotations, such as those of schema.org can be included in in HTML page delivery and thus be accessible by custom search engines.
This allows XWiki users to take part to the semantic web.
Examples include the documentation of an event or a business location: based on these annotations, specialized tools such as shows' listings or maps link to the web-page within their context.
The proposed tool is an XWiki extension that allows web-page editors to select the annotations from the list of accepted field names at repositories such as schema.org and the target content, and enriches the rendering engine (at the server side) to produce the tages.
The tool should include tested samples which interoperate with such tools as the Google Custom Search Engines or the Yandex structured data validator.
Technologies: Groovy, XWiki objects, Java
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.
GitLab-GitHub integration in XWiki WebIDE
The new XWiki Web IDE extension allows to edit code of an XWiki Project directory using a "Web IDE" like User interface.
We already have the GitHub and SVNApp applications which allow to commit XWiki code in GitHub and SVN.
We'd like to have these integrations directly in the Web IDE as well as support GitLab or any other Git repository (currently the GitHub integration uses GitHub apis).
RedPen Integration
The idea is to be able to integrate RedPen inside XWiki. RedPen is checkstyle for documentation. See this presentation to know more about it.
There are several integrations possible with XWiki that we could imagine:
- As an XWiki extension that can be installed in an XWiki instance and that would validate the content written when pressing the "save" button, allowing the reader to review the errors and either confirm the save or go back to editing and fixing the problems.
- As an XWiki extension that can be executed inside the wiki to validate several pages (this should be done in a Job with a progress bar)
- As a plugin inside RedPen to support the XWiki Syntax. This could be mandatory required for the previous 2 integrations since pages are saved in Wiki format (when you press save in the WYSIWYG editor the content is transformed to wiki syntax). However we could also imagine that the RedPen integration would take the page content and render it using the plain text renderer and then execute the check on that content too.
An even better integration would be the ability to run RedPen on the fly as user types content but I don't know if RedPen allows for this.
Presentation Application Overhaul
The idea behind the Presentation Application is simple: be able to write nice presentations (slide shows) using wiki syntax. In other words: be able to write a presentation as a wiki page. The presentation slides are generated from the sections of the wiki page. When a wiki page is displayed its wiki syntax is converted to HTML5. The Presentation Application provides a special view mode (with a dedicated skin) where the generated HTML5 matches one of the predefined presentation templates.
As part of the GSoC the student should:
- Update the application code to work with the most recent version of XWiki (7.4+)
- Add support for more HTML5 presentation templates, such as:
- Make sure the presentations work on mobile
- Make sure the presentations can be exported as PDF
- Add support for more wiki syntax elements (e.g. Code Macro, Chart Macro, etc.)
- Create an user interface to manage the presentations (list existing presentations, create new presentation, edit/delete a presentation)
- Move code from Groovy to Java
Chart.js Integration
Create an XWiki extension that integrates Chart.js. The idea is simple: be able to generate nice charts with data coming from the wiki. The following features could be interesting:
- A wiki syntax macro to display a chart inside a wiki page. This should be similar to the existing Chart Macro, but the chart should be generated with Chart.js obviously.
- Support for various chart sources (where the data comes from): wiki syntax table (in-line or from a different wiki page), SQL query, etc.
- Visual chart editor (live preview when modifying the chart source or the chart parameters)
- User interface to manage the charts:
- Integration with the Create Wiki Page wizard to create a new chart
- List existing charts, edit/delete them
Contact us
You can ask for more information about each project proposal and interact with the community and mentors through the usual communication channels: mailing list (devs AT xwiki.org) or the IRC channel.
Previous GSoC editions
- The page prepared for GSoC 2015 (XWiki was not selected for GSoC 2015)
- The page prepared for GSoC 2014 (XWiki was not selected for GSoC 2014)
- The XWiki GSoC 2013 page
- The XWiki GSoC 2012 page
- The XWiki GSoC 2011 page
- The page prepared for GSoC 2010 (XWiki was not selected for GSoC 2010)
- The XWiki GSoC 2009 page
- The XWiki GSoC 2008 page
- The XWiki GSoC 2007 page