xwiki-devs January 2018

xwiki-devs@xwiki.org

12 participants
29 discussions

[xwiki-devs] [PROPOSAL] Implement decorators in xwiki-platform-container

by Clément Aubin

Hi devs, This proposal is related to the following discussion on IRC : https://botbot.me/freenode/xwiki/2018-01-08/?msg=95495049&page=5 Abstract: We currently have an abstraction of the notion of a "container" defined in xwiki-platform-container-api [1]. This abstraction is very basic, but allows XWiki to support two different types of containers : Servlet and Portlet, and maybe support other types in the future. Problem: As those abstractions are very basic, it's quite hard to use them without downcasting them. A common example is the following: if I want to send a redirection in a Response object [2], I will need either to forge my own output that returns the correct HTTP code, with the correct header, etc … or I can downcast the given Response to all of its possible implementations and, for each implementation, find the correct method to use for sending a redirect. In order to avoid such tricks in the future, we could implement decorators that will allow Request and Response implementations to handle certain actions. In my previous example, a Response implementing RedirectResponse would expose a method `#sendRedirect(String url)`. The advantage here is that we don't really need to know on which Response implementation we are working on. WDYT ? Thanks, Clément [1] https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwi… [2] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…

6 years, 11 months

[xwiki-devs] [ANN] XWiki 9.11.1 released

by Eduard Moraru

The XWiki development team is proud to announce the availability of XWiki 9.11.1. This is a bugfix release that covers important issues that we have discovered since 9.11 has been released. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.11.1 Thanks for your support -The XWiki dev team

6 years, 11 months

[xwiki-devs] [XWiki Day] BFD#160

by Alex Cotiugă

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

6 years, 11 months

[xwiki-devs] Emeritus Committers - Batch of Jan 2018

by Vincent Massol

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

6 years, 11 months

[xwiki-devs] [Idea] Look at Thymeleaf as an optional templating language?

by Vincent Massol

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 years, 11 months

[xwiki-devs] [Proposal] Terminology: Using XS to signify XWiki Standard

by Vincent Massol

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

6 years, 11 months

[xwiki-devs] [Proposal] Roadmap for XWiki 10.0

by Vincent Massol

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

6 years, 11 months

[xwiki-devs] [Proposal] Use JSON in Wiki Components

by Guillaume Delhumeau

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

6 years, 11 months

[xwiki-devs] [Brainstorming] Implementing multi-environment tests - Take 2

by Vincent Massol

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

6 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs January 2018