January 2016 - xwiki-devs@xwiki.org

[xwiki-devs] [VOTE] First set of extensions to move out of wiki-platform
by vincent＠massol.net 12 Feb '16

12 Feb '16

Hi devs, Following the “XWiki Core” VOTE (http://markmail.org/message/rqgqzbepzms3p6h2) I’m now proposing to move the following extensions out of xwiki-platform and into xwiki-contrib: I’ll also start moving some extensions from platform, starting with: - xwiki-platform-blog - xwiki-platform-faq - xwiki-platform-jira - xwiki-platform-release - xwiki-platform-selenium Please vote. Here’s my +1 Thanks -Vincent

9 12

[xwiki-devs] [Contrib] Demo flavor
by vincent＠massol.net 11 Feb '16

11 Feb '16

Hi, I’d like to request a github repo in xwiki-contrib for a Demo flavor extension. The idea is that: - since we want to demonstrate the power of xwiki on playground.xwiki.org - and since the xwiki github org will focus on providing generic runtime only (made only with core extensions), it would be interesting for users testing xwiki to have a demo flavor that users can pick from on the DW screen (in addition to the default flavor). In the future we expect the community to create a lot more flavors but that’s for later, won’t happen overnight. So I’m proposing to create a demo flavor that includes a maximum number of high-quality extensions that we have in xwiki-contrib: To start with: - Blog - File Manager - Meeting Manager - Forum - Task Manager - Idea - FAQ - Diagram In addition, in term of layout I’m proposing: * Navigation panel on the left * App bar on the right * A demo text on the home page and beneath the activity stream (one under another so that clicking edit makes it easy to update the page) WDYT? Thanks -Vincent

5 12

[xwiki-devs] [Idea] Sponsoring issues
by Vincent Massol 04 Feb '16

04 Feb '16

Hi devs, WDYT of doing like Jenkins is doing and adding a "Sponsor this issue" button on JIRA? For example: https://issues.jenkins-ci.org/browse/JENKINS-9030 When you click it redirects to http://www.freedomsponsors.org/core/login/?next=/core/issue/sponsor%3Ftrack… You can check http://www.freedomsponsors.org/ It could be interesting to try it and see how it goes. WDYT? Thanks -Vincent

8 16

[xwiki-devs] [Proposal] Hiding "WebHome" in wiki syntax for links and images
by Eduard Moraru 03 Feb '16

03 Feb '16

Hi devs, As XWIKI-12920 [1] mentions, we need to hide "WebHome" references in the wiki syntax for links and images (for now) in order to be consistent with what we did in the UI. What this means is that [[label>>Page.WebHome]] should be equivalent to [[label>>Page]]. The plan is to apply the same logic as we did for URLs and detailed by Vincent in "Solution 2" in his comment on the issue [2]. In order to achieve this, Vincent proposed to introduce a new "space:" resource type and make this new type the default instead of "doc:" which is the current default. Before: [[label>>Page]] => [[label>>doc:Page]] After: [[label>>Page]] => [[label>>space:Page]] if "Page.WebHome" exists, or => [[label>>doc:Page]] if "<currentSpace>.Page" exists, or => wanted link to create "Page.WebHome" when clicked. Using either the "doc:" or the "space:" versions manually will resolve the requested resource, without doing any fallback resolution (which is applied only for the no-prefix version). For the same consistency reason, we need to apply the same fallback to the "attach:" resource type, e.g: [[attach:Page@file.ext]] => [[label>>attach:space:Page@file.ext]] || [[label>>attach:doc:Page@file.ext]] However, a resource is defined as ((type:) resource) so for attachments we would need to extend the type's definition to allow it to contain ":" in the type name (i.e. "attach:doc" and "attach:space") so that more variations are tested when resolving a link reference before treating it as a generic/untyped reference (this is where the fallback mechanism kicks in). There is also the image syntax that needs to be extended to support the same fallback logic, so something like: image:Page => image:space:Page || image:doc:Page In all these cases: * link space: prefix, * link attach:doc and attach:space prefixes and * image space: and doc: prefix ... we would be breaking backwards compatibility in the sense that if a wiki with the name "space" (and/or "doc", depending on which case of the above you are) already existed in the wiki farm, any links pointing to documents in that wiki from other wikis will be broken, because, for example [[label>>space:Page]] no longer points to the document "space:Page.WebHome" (from wiki "space"), but to the document "Page.WebHome" from the current wiki (where the link is made). To fix this, one would have to write [[label>>space:space:Page]] instead. I guess we could/should write a migrator to try to fix most of these cases automatically (like we fix links to a document that was renamed), but a couple of links will be unfixable if they are built programatically (e.g. by velocity scripts) and the process could prove to be extremely lengthy one (due to the parsing, processing, serialization and resaving of each document). Please feel free to comment on the above described approach. Thanks, Eduard P.S.: I did not mention macro parameter references which would also need a solution for hiding the "WebHome" part, but I`d prefer it if we handle that another time / in another thread. ---------- [1] http://jira.xwiki.org/browse/XWIKI-12920 [2] http://jira.xwiki.org/browse/XWIKI-12920?focusedCommentId=89129&page=com.at…

3 14

[xwiki-devs] PDFMulti Export
by Alessandro Strambini 01 Feb '16

01 Feb '16

Hello, I wanted to ask if there is any Tool or Script at the moment to export Multiple Pages as PDF (like The PDFCollection Maker extension http://extensions.xwiki.org/xwiki/bin/view/Extension/PDF+Export+Collection+…) or the MultiPage Export, which works for me but not when i have alot of Pages to export. Im at version 7.2 and it seems like the Collection one isnt working anymore. Is there any alternative? Or did i skipped some important configuration change that it should work? I would be glad for any help. Best Regards Alessandro Strambini

2 1

[xwiki-devs] [Proposal] New Anti Spam API in xwiki-platform-spam
by vincent＠massol.net 31 Jan '16

31 Jan '16

Hi devs, We’ve suffered some spamming attacks on xwiki.org recently and we’ve put xwiki.org under cloudflare. This should prevent some attacks but it’s not enough and spam is still going through. I’d like to propose creating a new xwiki-platform-spam module with an API module and a simple implementation using keyword blacklisting. xwiki-platform-spam |_ xwiki-platform-spam-api |_ xwiki-platform-spam-simple We could imagine adding an akismet implementation later on: xwiki-platform-spam-akismet For the simple implementation, I’d like to be able to configure the keywords in xobjects to make it simple to update and have the community helping. The API would be simple: @Role public interface SpamChecker { /** * Checks if the passed content is considered spam or not. * * @param content the content to check * @param parameters a map of parameters that depends on the implementation used. For example this can include the * IP address of the submitter of the content, its email address, the date of submission, etc * @return true if the content is considered spam or false otherwise */ boolean isSpam(Reader content, Map<String, Object> parameters); } Then the idea would be to have an EventListener for page save and comment save and go through this API. WDYT? Thanks -Vincent

4 6

[xwiki-devs] [Proposal] Support retro-compatibility for page objects
by Guillaume Delhumeau 29 Jan '16

29 Jan '16

Hello. In XWiki, we take care of retro-compatibility. Each class that is not internal is considered as API, and we have clirr to detect when an API breakage is done. However, we don't apply this strategy regarding the page objects of our functional tests. I noticed this when I've tried to use some pages objects defined on an application based on platform 6.4.1 on an other application based on platform 7.4. Due to incompatibility issues, I had to rewrite some page objects in my new application. It will be a major issue when we will move some current core extensions to contrib. So I propose considered Page Objects as API, and to add CLIRR checks on the build. WDYT? Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

3 5

[xwiki-devs] [Feedback] Evaluation of Travis as a CI tool
by Jean SIMARD 28 Jan '16

28 Jan '16

Dear devs, It's been a while I'm using Travis-CI.org as a CI tool for my projects. And I thought why not using it with XWiki? So I investigate a bit with xwiki/xwiki-commons [1]. If you don't want to read the details below, here is a resume. I would push to keep Jenkins at this point (much more complete than Travis) but, one killing-feature is missing (in my opinion): integration with Github (display the result of a build in Pull Request is of great value when evaluating a PR). The following list is not exhaustive and is mainly about the most important features I've noticed. ### Travis # Benefit * We don't maintain a server * It's well-integrated with Github * It builds Pull Requests * It builds Branches * UI is pretty nice (at least better than Jenkins, hey!) # Drawbacks * You cannot choose which branches you want to build (all or none) * The UI is crashing often on Firefox (blocks the browser for few seconds before Firefox propose to kill the script) * You only have a raw log (meaning Travis cannot present information of the log with a organised structure) ### Jenkins # Benefits * We already have it and it works * It's specifically adapted for Java project (much much more details to parse the result of the build logs) * It can build branches * It can build Pull Requests # Drawbacks * Consumes a lot of resources on our servers * UI is not easy to browse (note that it show much more than Travis so of course, it's more difficult to do an UI with more information!) [1] https://travis-ci.org/woshilapin/xwiki-commons/ -- Jean Simard jean.simard(a)xwiki.com Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org

3 2

[xwiki-devs] [Contrib] New repository for anti spam tool: application-antispam
by vincent＠massol.net 28 Jan '16

28 Jan '16

Hi devs, I’d like a new contrib project on xwiki-contrib to host the API I’m developing that offers antispam tools. I’m going to create it but this is a heads up about this new project. Right now it offers this Java API (with a corresponding script service): @Role public interface AntiSpam { /** * Get references and last authors of all documents matching a given solr query string. * * @param solrQueryString the solr query string to search with (e.g. "mcafee") * @param nb the number of matching results to return * @param offset the start position in the full list of matching results * @return the list of references of matching documents and their last authors * @exception AntiSpamException if an error occurs such as a failure to find matching documents */ Pair<List<DocumentReference>, Set<DocumentReference>> getMatchingDocuments(String solrQueryString, int nb, int offset) throws AntiSpamException; /** * Clean the passed documents of all changes made by the passed authors. * * @param documentReference the reference to the document to clean * @param authorReferences the reference to the authors for which to remove all changes from the document * @param skipActivityStream if true then don't generate events in the Activity Stream for the changes made to * the document * @exception AntiSpamException if an error occurs */ void cleanDocument(DocumentReference documentReference, Collection<DocumentReference> authorReferences, boolean skipActivityStream) throws AntiSpamException; /** * Find all documents with the passed author. * * @param authorReference the author for which to return the list of modified documents (i.e the last author of * the returned documents) * @param nb the number of results to return * @param offset the start position in the full list of results * @return the list of references to documents for which the passed author was the last author * @exception AntiSpamException if an error occurs */ List<DocumentReference> getDocumentsForAuthor(DocumentReference authorReference, int nb, int offset) throws AntiSpamException; } Thanks -Vincent

1 1

[xwiki-devs] Google Apps Application
by Florian Véron 22 Jan '16

22 Jan '16

Hello, We are working with Ludovic on the google apps application. You can find the code here https://github.com/xwiki-contrib/application-googleapps, and we already have some version released. Can we have a jira for this project in order to follow issues on this app ? Thanks, Florian Véron

2 3