- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [XWiki Day] BFD#160
by Alex Cotiugă 05 Jan '18

05 Jan '18

Hello devs, This Thursday is BFD#160: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status is: * -8 bugs over 120 days (4 months), i.e. we need to close 8 bugs to have created bugs # = closed bugs # * -59 bugs over 365 days (1 year) * -50 bugs over 500 days (between 1 and 2 years) * -237 bugs over 1600 days (4.3 years) * -686 bugs since the beginning of XWiki See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#160 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13936 Happy Bug Fixing Day, Alex

1 1

[xwiki-devs] Emeritus Committers - Batch of Jan 2018
by Vincent Massol 05 Jan '18

05 Jan '18

Hi devs, According to our rule, non active committers become Emeritus committers. I’ve cleaned up the list of core committers on github and the following devs are now Emeritus: * Alex Busenius * Andreas Jonssson * Fabio Mancinelli * Jean-Vincent Drean * Jerome Velociter * Marta Girdea This means that you guys are now discharged from VOTEs and such. If you ever want to commit stuff again you won’t need to be VOTEd again. You just need to send us an email and we’ll add you back to the active committer list. Thank you for all your work over all those years! You’re now listed in the hall of fame under emeritus: http://dev.xwiki.org/xwiki/bin/view/Community/HallOfFame#HEmeritusCommitters Thanks -Vincent

2 1

[xwiki-devs] [Idea] Look at Thymeleaf as an optional templating language?
by Vincent Massol 04 Jan '18

04 Jan '18

See http://www.thymeleaf.org/ With this, users could combine HTML and scripting which could be a nice option when using the {{html}} macro for example. {{html}} {{thymeleaf}} … {{/thymeleaf}} {{/html}} Related: * https://dzone.com/articles/template-engines-review-after-deprecated-velocity Thanks -Vincent

6 12

[xwiki-devs] [Proposal] Terminology: Using XS to signify XWiki Standard
by Vincent Massol 04 Jan '18

04 Jan '18

We used to say XE to mean XWiki Enterprise. I’m proposing to use XS to mean XWiki Standard now. WDYT? Thanks -Vincent

3 4

[xwiki-devs] [Proposal] Roadmap for XWiki 10.0
by Vincent Massol 04 Jan '18

04 Jan '18

Hi devs and all, Here’s a proposal for XWiki 10.0 discussed internally at XWiki SAS and based on the available developers for this period. Feel free to add items you’d like to implement too in the period! Also feel free to comment on the proposed items. Note that there’s still some stabilization work that’s needed on XWiki 9.x, especially in the domain of Notifications. The idea is to release new versions of XWiki 9.x every 2 weeks at max. # Topics * Finish notifications - Guillaume (will be backported in 9.x) * FS attachments by default - Thomas * Performance - Thomas * Skin refresh investigation + continue on usability for onboarding of admins and users (examples: inviting and adding users, creating the initial hierarchy of pages, change the logo, create the top menu) - Caty # Dates * 10.0RC1: 22nd of Jan 2018 * 10.0Final: 29th of Jan 2018 Thanks -Vincent

1 2

[xwiki-devs] [Proposal] Use JSON in Wiki Components
by Guillaume Delhumeau 04 Jan '18

04 Jan '18

Hi devs. In XWiki, we have the ability to create wiki components. It means that each extension can define a custom XClass which is used to create a component when a corresponding XObject exists. Sometimes, this XObject contains a textarea where the developer could write velocity code. The velocity code is rendered, and the result is parsed in order to complete other actions. For example, velocity can render a boolean, or a list of documents, etc... The reason why Velocity is used is because it does not require programming rights. On the other-side, it can only return a string: the rendered content. My use-case is to generate a specific list of users when an event is triggered, to perform some actions with these users. Currently, we have no recommended practice about this "velocity-rendered-fields". That's what I propose to always use JSON when velocity is used to render data in a wiki component. The reason is that JSON is standard and easy to parse. Use case: In the Event Stream module [1], the XClass "XWiki.EventStream.Code.EventClass" is used to trigger custom events when some event occurs. Example: if a DocumentUpdatedEvent is triggered and that event contains an XObject of type "Meeting", you can send a new "Meeting Created" event. There is a "Validation Expression" field used to determine either or not the custom event should be sent. Now I need to add an other field to determine which user should receive the event notifications. For example: if userA and userB have been invited to MeetingC, I need to send an event "Meeting Created" only for user A and user B. Here is my +1, Thanks, [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Event%20Stream%20Modul… -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

2 3

[xwiki-devs] [Brainstorming] Implementing multi-environment tests - Take 2
by Vincent Massol 04 Jan '18

04 Jan '18

Hi devs, I wanted to give you some info on what I’m doing for implementing multi environment testing on XWiki. Initially I thought about this architecture (let’s call it the "running maven inside docker” strategy): http://massol.myxwiki.org/xwiki/bin/view/Blog/DockerJenkinsConfigurationTes… However after more thinking, I think it’s not the best solution. I’m now exploring the “‘running docker inside maven” strategy which works as follows: The generation of the docker image + the start/stop of the docker containers is done by the maven build itself. This has the following advantages: * It’s not dependent on the CI system used * It allows the build to be reproduced locally on dev machines (only prerequisite is to have docker installed - note that right now the prerequisite is to have FF installed locally and we would swap this req. in favor of docker) * We’ll generate the official xwiki docker images as part of our build and not anymore as some external build/steps to execute * The build will be done fully with Maven (no more gradle) FYI, the plugin I’m exploring for this is the fabric8.io one: https://dmp.fabric8.io/#introduction I’ve started the work locally and I’ll commit once I have something ready enough. Let me know if you have some opinion or questions about this. Thanks -Vincent

2 5

[xwiki-devs] A subtle problem with the Workflow Application and nested pages
by Clemens Robbenhaar 27 Dec '17

27 Dec '17

Hi Devs, some users reported a problem to me concerning the Publication Workflow Application and the nested pages feature. The problem is as follows: In their old instance (some 6.4.x) they had a draft space and a public space and workflows attaching each page in the draft space with a page in the public space in an 1:1 manner, like: Draft.WebHome --> Public.WebHome Draft.PageA --> Public.PageA Draft.PageB --> Public.PageB Now if a link in, say, PageA in the Draft space points to another page, e.g. PageB, this is done via a relative link like [[link text>>doc:PageB]] After publishing PageA, the link of the published variant points to the published variant of PageB (and not the variant in the Draft space), which is the desired effect from the users point of view. Now after migration to 9.10 the situation is as follows: Draft.WebHome --> Public.WebHome Draft.PageA.WebHome --> Public.PageA.WebHome Draft.PageB.WebHome --> Public.PageB.WebHome Now a link to PageB in PageA looks like: [[link text>>doc:Draft.PageB.WebHome]] because both pages are no longer in the same space, but each in their own space. Publishing the draft makes the link in the published variant point back to the Draft space, of course. However this is different from the behavior before nested pages and the users experience this as a bug. A manual solution would be to edit all pages and make the links point to the published variant of the pages. However this is not only a cumbersome and error prone task, but also the users are used to the "automatic" link conversion that made links in the published variant point to published pages and are wont to continue setting links to pages in the draft space, expecting them to point to the "right place" after publishing. The fact that now titles are used throughout in the navigation tree, and the titles of the draft and published variant are usually the same and thus indistinguishable complicates the problem even more. To fix this I could write a separate extension that listens to Publish events send from the Workflow extension, and which converts the links in the published variant before it gets saved. However I remember that I once experienced strange issues where the events were sometimes not send to the event listener in question, probably due some class loader issues or the like. (I only experienced these problems in a production instance and was not able to hunt them down in a development instance.) Also I cannot think of a use case where users want to link from a published variant back into the draft space (except for pointing to the draft version of the page itself, which is provided by the panel, however.) Thus I would like to implement the link transformation in the extension itself. If a link in a page points to a page in the draft space of that workflow, I would change that link in the published variant to point to the corresponding published variant of the link target. I could add a checkbox to the workflow class so people can switch of that link transformation if they do not want it. What do you think? Are there any objections to implementing such a feature? Or do you have different ideas how to solve the problem? Best Regards Clemens

4 8

[xwiki-devs] [XWiki Day] BFD#159
by Alex Cotiugă 21 Dec '17

21 Dec '17

Hello devs, This Thursday is BFD#159, the last one for this year: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status is: * -12 bugs over 120 days (4 months), i.e. we need to close 12 bugs to have created bugs # = closed bugs # * -56 bugs over 365 days (1 year) * -53 bugs over 500 days (between 1 and 2 years) * -237 bugs over 1600 days (4.3 years) * -684 bugs since the beginning of XWiki See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#159 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13934 Happy Bug Fixing Day, Alex

1 0

[xwiki-devs] Next version for 9.x cycle
by Vincent Massol 19 Dec '17

19 Dec '17

Hi devs, We need to decide what’s our next version for 9.x. Since 9.11 is supposed to be the last release (actually 9.10 was even supposed to be the last one according to http://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices… we might need to change that). We still have some stuff to stabilize: notifications, shortcuts, etc. So I’m proposing that the next version be 9.11.1 and not 9.12 to keep the strategy of 12 main releases per year, and to start stabilizing the 9.x cycle. WDYT? Thanks -Vincent

5 7