On Fri, Feb 10, 2017 at 8:17 AM, Stefan Helmerichs <s...@form-solutions.de> 
> Hello,
> I am using (as stated) XWiki 8.4.3 on a CentOS7-VM running in a
> docker-container.
> I am using a gradle script to push markdown-files and images to the
> wiki. The markdown is being wrapped in an xml envelope and pushed to
> the REST-API, which works nicely. The envelope looks like this:
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <page xmlns="http://www.xwiki.org";>
>   <title>TITLE</title>
>   <syntax>markdown/1.2</syntax>
>   <content>CONTENT</content>
> </page>
> TITLE and CONTENT are being replaced with the corresponding items, which
> are all escaped, so the problem is not with escaping.
> We are keeping the files in a structure like the XWiki page-structure,
> so we have a directory which contains the markdown and its images
> (corresponding to page, WenHome and attachments) and this contains other
> directories which in turn.. you get the idea. Basically, every directory
> is a page, every markdown-file is a WebHome and every other file is
> an attachment.
> Right now I am doing two iterations, one fetches the markdown files and
> the second fetches all other files.
> I am pushing the markdown with XML Content type and the Attachments
> with BINARY content-type (both from groovyx.net.http.ContentType.*).
> Now my problem is that when I upload the attachments, every single
> attachment adds a new version to the page history. I tried to mitigate
> this by adding
> <majorVersion>1</majorVersion>
> and
> <version>1.1</version>
> to the envelope, but these seem to be unevaluated, as the major version
> is still increased with every upload.
> So my question is: is there a way to:
> a) make sure the minor version is upgraded instead of the major version
> when sending an attachment

No. Would need to add support for some "majorVersion" parameter in
But hard to make it memory efficient (but yes not a big issue with
small attachments).

> b) replace the history of the page with a single major.minor-version
> history (as is done when importing .xar-files)

Not using standard REST API.

> c) upload the page with all its attachments at once, without having to
> change it from markdown to XAR?

No with the current standard REST API. Would need to add an optional
content property in the Page model and add support for it in


The possible alternatives are:
* go trough XAR import REST resource as you probably seen from what I understand
* write a wiki page which act as custom REST service
* write a custom /rest/ resource component in Java

Thomas Mortagne

Reply via email to