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
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
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
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
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
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