XWiki @ Google Summer of Code 2020

Last modified by Eduard Moraru on 2021/02/02 10:54
Contents

This page hosts information and project ideas for the open source project XWiki related to the Google Summer of Code 2020 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.

Getting Started

As a new student, you're probably looking for this section! Please read it carefully (and its linked resources) before asking for guidance or where to start. It applies to all proposed projects and it covers many topics asked by newcomers.

Being part of the XWiki community means knowing our rules and practices. As a GSOC student or candidate, you need to make sure you read and apply our guidelines. It also contains suggested way of getting to know the XWiki project and its community and also what you'd need to get up to speed with developing extensions or making changes to the XWiki product.

Please do not skip this part.

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 2020 (3)

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

Android Authenticator Enhancement by Somenath Sarkar

There is an Android Authenticator application (Google Play link), which aims on synchronization of contacts from any required XWiki instance and able to get the main info about users: phone number, e-mail and others. Currently, this project is already realized, but we have a few possible ideas to improve it: 

  • Upgrade dependencies, fix bugs, minor improvements, actualizing of Jenkins build
    • With actualizing of Jenkins build it is required to implement Jenkins Pipelines (look at the issue in jira)
  • Integrate XWiki notification with Android notifications system (to be warned when something happen in the wiki and click to go to the page)
  • Convert the current application into:
    • A library which contains most of the current application and can be used to create dedicated application authenticators for specific instances of XWiki
    • The current authenticator/application but this time based on the new library
    • A new authenticator dedicated to xwiki.org to serve as an example for people whiling to build their own dedicated XWiki authenticator

Data migration framework by Pengyu Zhou

Overview

Documents stored in XWiki can contain structured data, in the form of XObjects. The structure of these XObjects are defined by XClasses, that can also be created in XWiki documents. Learn more about how XWiki manages XClasses and XObjects here.

Most of the application that we create inside XWiki depends on this model, as it is really easy to access and edit (through a simple page edition). However, once a data model (through XClasses) is defined by an application, it is hard to rework it. On the contrary to databases where it is possible to create migration scripts, XWiki does not provide a migration framework in its core.

Technical structure

The goal of this project is to make improvements to an already existing migration framework (see the documentation and the code). The existing framework can be divided in three components :

  • The core of the framework : its APIs and its main components
  • Migrators : we define a migrator as "something that will execute a migration in the wiki". A migrator could migrate XClasses from one model to another (as explained above), migrate a document content to another document, etc ... the idea is also to help application developers creating their own migrators specific to their use case.
  • The development toolkit : a set of scripts and services that can help an XWiki application developer creating new migrations for his application.

Objectives

As part of this project, you will contribute in the following :

  • Creating new migrators in the framework itself
  • Make sure that migrations can be executed when upgrading an extension
  • Improve the development toolkit of the migrator to help application developers create new migrations
  • Improve the testing strategy of the whole framework

Other resources

GitHub Importer by Hassan Ali

The idea is to develop an importer to import GitHub pages written in GitHub-flavored Markdown into XWiki pages written in XWiki Syntax 2.1.

To do that you would use the following existing modules in XWiki:

Here's an idea of a possible implementation workflow:

  • Since there's no GitHub REST API to access GitHub wiki pages, use the XWiki Git API to checkout/clone the underlying Git repo containing the GitHub wiki pages.
  • Write an input Filter that takes as input a Git repo containing GitHub wiki pages. Use the existing XWiki Instance output filter to convert that into wiki pages.
  • Use the Markdown Syntax to parse the GitHub pages and use XWiki Rendering APIs to convert that to XWiki Syntax 2.1
  • See this snippet to import from GitHub

Coordinated by


Student
Estimated workload: 2 man month.
Read more...

Proposed Projects (16)

Students can come up with their own ideas, but the ideas need to be proposed and discussed on the forum (dev category).

You can contribute to this list! We encourage would-be mentors to propose ideas or even to revive old ideas from the previous years, but, if you do, make sure to assign yourselves as mentors for the proposed project. Proposals without mentors will be discarded, as we have learned from previous years that they are counter-productive.

Students are also encouraged to propose projects, but make sure you first run your idea through the community (see the Contact Us section below) and that you find a mentor interested in the idea that you can assign to the project proposal.

We also recommend students interested in joining XWiki for GSoC 2020 to manifest themselves as early as possible so that we can start working with them on this project list.

Add WebAuthn support to XWiki

The idea is to allow browser to automatically authenticate on XWiki using the new WebAuthn standard.

For more details about WebAuthn see the following links:

See https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Authentication/ for details about XWiki authentication framework.

Amazon AMI for XWiki

Provide an Amazon AMI for XWiki to allow starting XWiki on Amazon EC2 easily.

See also this existing ticket.

The main goal is to offer more ways to distribute XWiki to make it more attractive to all kind of usages, and thus increase our Active Installs.

Coordinated by


Estimated workload: 2 man month.
Read more...

Android Authenticator Enhancement

There is an Android Authenticator application (Google Play link), which aims on synchronization of contacts from any required XWiki instance and able to get the main info about users: phone number, e-mail and others. Currently, this project is already realized, but we have a few possible ideas to improve it: 

  • Upgrade dependencies, fix bugs, minor improvements, actualizing of Jenkins build
    • With actualizing of Jenkins build it is required to implement Jenkins Pipelines (look at the issue in jira)
  • Integrate XWiki notification with Android notifications system (to be warned when something happen in the wiki and click to go to the page)
  • Convert the current application into:
    • A library which contains most of the current application and can be used to create dedicated application authenticators for specific instances of XWiki
    • The current authenticator/application but this time based on the new library
    • A new authenticator dedicated to xwiki.org to serve as an example for people whiling to build their own dedicated XWiki authenticator

CryptPad Integration

The objective of this project would be to provide an integration between XWiki and CryptPad.
There are multiple levels of integrations to implement:

Feature 1: A simple macro to display a live document from CryptPad in XWiki
Feature 2: I have a document on CryptPad and I want to retrieve it and store it in the Wiki
   2a: Wysiwyg documents
   2b: Markdown documents
   2c: OnlyOffice documents
Feature 3: I have a document in an internal XWiki and I want to edit it with external users. I push the document to cryptpad for editing there and I have a way to retrieve it
   3a: XWiki document -> Wysiwyg document
   3b: XWiki document -> Markdown document
   3c: XWiki Attachment -> OnlyOffice documents

The project is challenging as CryptPad is integrating client-side cryptographic security, and multiple ways to store documents, it is necessary to run code in Javascript to read and write CrytpPad documents. This could be done either in the browser or using the Java based Nashorn engine on the server side.

This project will require both Java skills and Javascript skills. The student will have access to a mentor with experience with both XWiki and CryptPad.
 

Coordinated by


Estimated workload: 3 months.
Read more...

Data migration framework

Overview

Documents stored in XWiki can contain structured data, in the form of XObjects. The structure of these XObjects are defined by XClasses, that can also be created in XWiki documents. Learn more about how XWiki manages XClasses and XObjects here.

Most of the application that we create inside XWiki depends on this model, as it is really easy to access and edit (through a simple page edition). However, once a data model (through XClasses) is defined by an application, it is hard to rework it. On the contrary to databases where it is possible to create migration scripts, XWiki does not provide a migration framework in its core.

Technical structure

The goal of this project is to make improvements to an already existing migration framework (see the documentation and the code). The existing framework can be divided in three components :

  • The core of the framework : its APIs and its main components
  • Migrators : we define a migrator as "something that will execute a migration in the wiki". A migrator could migrate XClasses from one model to another (as explained above), migrate a document content to another document, etc ... the idea is also to help application developers creating their own migrators specific to their use case.
  • The development toolkit : a set of scripts and services that can help an XWiki application developer creating new migrations for his application.

Objectives

As part of this project, you will contribute in the following :

  • Creating new migrators in the framework itself
  • Make sure that migrations can be executed when upgrading an extension
  • Improve the development toolkit of the migrator to help application developers create new migrations
  • Improve the testing strategy of the whole framework

Other resources

GitHub Importer

The idea is to develop an importer to import GitHub pages written in GitHub-flavored Markdown into XWiki pages written in XWiki Syntax 2.1.

To do that you would use the following existing modules in XWiki:

Here's an idea of a possible implementation workflow:

  • Since there's no GitHub REST API to access GitHub wiki pages, use the XWiki Git API to checkout/clone the underlying Git repo containing the GitHub wiki pages.
  • Write an input Filter that takes as input a Git repo containing GitHub wiki pages. Use the existing XWiki Instance output filter to convert that into wiki pages.
  • Use the Markdown Syntax to parse the GitHub pages and use XWiki Rendering APIs to convert that to XWiki Syntax 2.1
  • See this snippet to import from GitHub

Coordinated by


Student
Estimated workload: 2 man month.
Read more...

Implement PDF export with XHTML and paged CSS

Currently, the PDF export of XWiki is implemented based on XSL-FO and transformation of XHTML to FO. This poses a couple of problems, mainly related to the current level of support of FO from libraries implementing FO to PDF transformation, as well as the limitations of automatized transformation of XHTML to FO. The problems are mainly related to styling limitations, auto-layouting, etc.

The idea is to try to replace this with a pure XHTML & CSS (paged CSS) export, using an open source library for producing PDFs out of this.

This is only the first step of this project, the next steps being to validate that all customisation that is currently possible on the PDF export will remain possible with the new tool, and explore the new capabilities of the export (once ported to the new technology), build tools for it, etc.

See:

Coordinated by


Estimated workload: 2-3 man months.
Read more...

Improve DokuWiki Importer

Failed to execute the [velocity] macro. Cause: [The execution of the [velocity] script macro is not allowed in [dev:GoogleSummerOfCode.ImproveDokuWikiImporter2020]. Check the rights of its last author or the parameters if it's rendered from another script.]. Click on this message for details.
has seen two iterations in GSOC so far in Failed to execute the [velocity] macro. Cause: [The execution of the [velocity] script macro is not allowed in [dev:GoogleSummerOfCode.ImproveDokuWikiImporter2020]. Check the rights of its last author or the parameters if it's rendered from another script.]. Click on this message for details.
Failed to execute the [velocity] macro. Cause: [The execution of the [velocity] script macro is not allowed in [dev:GoogleSummerOfCode.ImproveDokuWikiImporter2020]. Check the rights of its last author or the parameters if it's rendered from another script.]. Click on this message for details.
. There's still room for plenty of improvements. 

  • Fix remaining bugs. 
  • Understand and document the Macro Framework. 
  • Add support for popular DokuWiki plugins using the Macro framework. 
  • Add more syntax extensions like Failed to execute the [velocity] macro. Cause: [The execution of the [velocity] script macro is not allowed in [dev:GoogleSummerOfCode.ImproveDokuWikiImporter2020]. Check the rights of its last author or the parameters if it's rendered from another script.]. Click on this message for details.
  • Windows Shares support. 
  • Text to Image Conversions : DokuWiki converts commonly used emoticons to their graphical equivalents. Those Smileys and other images can be configured and extended. For example Smileys in DokuWiki
  • Text to HTML Conversions : Typography: DokuWiki can convert simple text characters to their typographically correct entities. 
  • Quoting : For the times you want to mark some text to show it's a reply or comment.
  • Downloadable Code Blocks : When you use the <code> or <file> syntax as above, you might want to make the shown code available for download as well. You can do this by specifying a file name after language code.
  • Control Macros : Some syntax influences how DokuWiki renders a page without creating any output it self. Currently they're of 2 types : ~NOTOC~ and ~NOCACHE~ 

Reference : Failed to execute the [velocity] macro. Cause: [The execution of the [velocity] script macro is not allowed in [dev:GoogleSummerOfCode.ImproveDokuWikiImporter2020]. Check the rights of its last author or the parameters if it's rendered from another script.]. Click on this message for details.

Coordinated by


Estimated workload: 3 month.
Read more...

Improve XWiki docker and Kubernetes Helm chart

The helm chart has basic functionalities and there's lots potential for improvements. 

  • Finalise the release (and distribution) process for the helm chart.
  • Support for both Ingress Ingress and Istio. 
  • Option to choose between using an external database, a single node DB or a multi-cluster DB setup using other official helm charts as dependencies. 
  • Should support popular hosted Kubernetes services like GKE and Amazon EKS and Minikube(for local development).
  • Improve testability for the helm chart

Resources:

Javascript Visualizations Integrations

The objective of this project would be to integrate powerful Javascript visualization libraries in XWiki and particularly those that would allow editing of the visualization, and extend XWiki internal APIs to make it easier to integrate such libraries.

Examples libraries to integrate:

- mapjs mindmap (includes wysiwyg modifications on a mindmap)
- vis.js timeline & graph (includes wysiwyg modifications on a timeline or graph
- vizjs (graphviz)

In terms of XWiki features that could be integrated in the XWiki core:

- support for a REST api to save the content of a macro being edited
- support to saving an "image" version of the visualization capturing the div including the visualization (which would allow PDF export on the visualization)
- support for realtime rendering of a visualization versus the macro content (change the graphviz content and render it in realtime)

Coordinated by


Estimated workload: 3 month.
Read more...

JCR attachment store and storage manager

XWiki Standard current provide two different stores for attachments and deleted documents:

  • filesystem storage (the default)
  • hibernate storage

See https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Attachments#HAttachmentStorage for more details about the attachment store.

The idea is to add a JCR-based (Java Content Repository) XWiki storage to make possible to plug many possible implementations. Also, with the multiplication of stores, a tool to move data from one store to another would be necessary.

The expected minimum for the project are:

  • a generic JCR bridge extension
  • an extension pulling the bridge and a well tested implementation of JCR (like Jackrabbit Oak)
  • an application to move data from one store to another

PAC4J based universal authenticator

The idea is to build a bridge authenticator around PAC4J. XWiki allows writing custom authenticator and there is many of those, see http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Authentication/#HCustomAuthentication but they are written one by one and they don't share much with each other.

It would be nice to have the possibility to reuse the tons of authenticators that comes with PAC4J. Doing that means doing some plumbing and wiring to transmit all the information required by PAC4J and back to the XWiki authentication API (and UI when required).

Screenshot in translation platform

The idea of this project is to provide some tools to improve information about translation context, and in the end to help our translators contributors doing their job.

XWiki is using Weblate as a translation platform, see: https://l10n.xwiki.org. Weblate provide the capability to put screenshots in some translation key to help understand where it is used. See for an example: CAPTCHA translation.

So the idea is to improve the XWiki Application Translation (https://github.com/xwiki-contrib/application-translation) to allow a "screenshot mode": in that mode, a contributor would be able to find every translation key without a screenshot, and to create an upload it automatically to the translation platform.  

Set of useful Macros

Develop a set of XWiki Rendering Macros to make it easy to perform well-defined tasks in XWiki for non-technical users. Right now everything is possible using the Scripting macros of XWiki. However that's reserved to technical users. The idea is to identify common needs and implement specific macros to fulfil those needs.

Goals & Ideas

  • Form macro + Button macros to avoid needing the use of HTML macro and very simply add a button or a form in a wiki page. See also Form in page FAQ
  • Search macro to display a Search box in a wiki page and to display search results, with possibility of passing search parameters.
  • Members macro to display all the members of a given Group into a LiveTable and/or a Tree
  • Contributors macro to display all the authors who have contributed to a wiki page.
  • Develop these new macro as XWiki Extensions on XWiki Contrib and release them.
  • Propose new macros if time permits it. Ideas can be taken from New macros idea list. Some of these macros have already been implemented but the implementation may not work anymore in the latest versions of XWiki or can be improved. Improving them using new technologies would be great.

Considerations

  • Regarding the form macro the idea is to design it and see if we can make it easy to implement some use cases. We should not do something generic or we'll be harder to use than HTML! It may not be a form macro but another name. Example of typical use case.
  • The goal of this project is to look at our pages and find common patterns and provide macros to help implement them more easily, bringing the ability to non devs to do powerful stuff in xwiki
  • There's a big part of the project at the start about researching, brainstorming and making spec proposal.
  • Another source of inspiration is to also look at the snippets and find useful ones that would make sense to be as macros for users to use
  • Yet another source of inspiration is to look at other wikis (such as Confluence) and find nice macros that we could have too.
  • Since it's easy to script in XWiki, we've often forgotten to create plenty of small macros that can be implemented with 1 or 2 lines of code but even writing these few lines can be hard for non-devs and having a read-to-use macro could them.

Translation in context

XWiki 4.4 introduce new translation macro which will allow to find easily translated content in a page when using annotated HTML5 renderer (you can see the result by adding ?outputSyntax=annotatedhtml in the URL).

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:

Location where to code this: https://github.com/xwiki-contrib/application-translation

Wiki Gardening Engine

Overview

As a knowledge management software, it is critical for XWiki to help its users to better organize the information that is put on the wiki.
One frequent problem of wikis is that content is being put in wikis but can not be capitalized/used because it's difficult to retrieve once put in the wiki (because not properly organised, or because search engines are not performant enough).
Usually, in all communities that collaborate around creating a knowledge base, there are a few people (the "gardeners") that watch over the good organisation of the wiki, make sure that all content that is being added is not duplicate, that it is put in the proper place on the graph of knowledge, that relations are properly setup with related documents, etc. The purpose of this project is to use all available language processing / artificial intelligence / machine learning tools in order to create replace the gardeners with robots.

Objectives

The main goal of this project is to build a tool to help document editors to better organize their pages and the pages contents. This tool should be a combination of machine learning coupled with natural language processing. The tool should be able to propose different forms of organisation of content to the editors, which editors can apply to their content or not. Ideally, the automatic gardener would learn from the answers of the editors and improve its algorithm.

A few examples of gardening actions:

  • detecting duplicate content
  • proposing to update a page rather than create a new page
  • inferring a structure (in the sense of the wiki's structured pages) from the created content and proposing to add this structure to a set of pages
  • proposing a location for a page on the wiki (depending on its content)
  • etc. The list is really open, a full analysis of the possible actions should be done by the student.

Mentors (11)

The following community members are assigned to mentor the proposed projects:

Aleksei OvsiannikovAleksei Ovsiannikov
ashishashish
Clément AubinClément Aubin
Anca LucaAnca Luca
Ludovic DubostLudovic Dubost
Neha GuptaNeha Gupta
Paul LibbrechtPaul Libbrecht
Shubham JainShubham Jain
Simon UrliSimon Urli
Thomas MortagneThomas Mortagne
Vincent MassolVincent Massol

Contact us

You can ask for more information about each project proposal and interact with the community and mentors through the usual communication channels: forum or the Matrix channel.

What's next after GSOC?

First and foremost: Thank you for having participated to XWiki!

We want to keep you in the community for as long as possible. We understand that you may have school projects to carry on and won't have the time to continue participating much immediately after GSOC. However, we're really keen to see you coming back to this community when things settle a bit more and you get some time again.

Here's some visibility and ideas of what's next after you've completed a GSOC project and opportunities you may have:

  • You could be voted as Committer
  • You could get hired by one of the companies doing some business on top of the XWiki project
  • Become a Google Code-In mentor
  • You could propose a school project, PhD, etc about XWiki to your teachers!
  • You'll be able to add a nice line to your CV about having participated to an open source project emoticon_smile
  • You can ask for recommendations on LinkedIn, Facebook, etc about your work as a GSOC student
  • (Future, doesn't exist ATM) Your name on the Hall of Fame
  • (Future, doesn't exist ATM) Receive an XWiki GSOC t-shirt
  • (Future, doesn't exist ATM) Be sponsored to take about XWiki at conferences
  • (Future, doesn't exist ATM) Be able to implement some bounties for XWiki and get paid for it
  • (Future, doesn't exist ATM) Be invited to physically participate to an XWiki conference

Org Admin Resources

If you are one of this year's XWiki Organization Administrators, make sure to check out the Organization Admin Guide.

Previous GSoC editions

Tags:
   

About

About

Support

Platform

User Guide

Admin Guide

Developer Guide

Projects

XWiki

Extensions

Other

Contribute

Status

Practices

Under the Hood

Get Involved

Get Connected