xwiki-devs September 2016

xwiki-devs@xwiki.org

20 participants
47 discussions

[xwiki-devs] [ANN] XWiki 8.3 Milestone 2 released

by Eduard Moraru

The XWiki development team is proud to announce the availability of XWiki 8.3 Milestone 2. This is a minor milestone release that adds new template provider restrictions, improved support for the WildFly application server, default support for Let's Encrypt certificates and 26 additional bugfixes which contribute to stabilizing XWiki. 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/ReleaseNotesXWiki83M2 Thanks for your support -The XWiki dev team

8 years, 1 month

[xwiki-devs] [Brainstomring] Size of XE distribution - What are the next steps?

by Vincent Massol

Hi devs, FYI here’s how the size of our XE distribution has evolved over the years: https://www.evernote.com/l/AHe8M7Mpc8dLYbLXUUR4BNshyArvRhxM2e4 The sad news is that we’re working to reduce the size of the core for some time already but globally over the years the XE size is still growing. We started going in the right direction in XE 6.3 and 6.4: * XE 6.2 = 222MB * XE 6.3 = 212MB * XE 6.4 = 210MB But then starting with XE 7.0 we started to increase the XE size again: * XE 7.0 = 211MB * XE 7.1 = 225MB * XE 7.2 = 226MB * XE 7.3 = 230MB * XE 7.4 = 230MB * XE 8.0 = 229MB * XE 8.1 = 230MB * XE 8.2 = 233MB FTR at some point we had: * XE 2.0 = 79MB * XE 3.0 = 111MB * XE 4.0 = 142MB * XE 5.0 = 181MB * XE 6.0 = 211MB Any idea of what we could do to back to reducing the size of XE? Some idea: * Remove the GWT Editor (close to 10MB) * Introduce a check in the build to fail it when the distribution goes over, say, 0.5% more of a threshold (for 230MB, 1% = 1.15MB) so that when we increase the size we’ll have to look at what is making that size increase and if we think it’s ok then we increase the threshold. The idea would be to make us think about it regularly. WDYT? * <more idea here> FTR I was reminded of this by a comment on a blog post: "En rapport avec XWiki, à l'époque où j'ai connu Greenpepper, il y avait un pack de démo avec XWiki. J'ai voulu refaire ce pack, mais j'ai l'impression que XWiki a pris un certain nombre de méga bytes en quelques années ^_^ . Est ce qu'il y aurait une version light disponible ?” In short the guy said that XWiki seems to have increased size over the years and was asking whether there was a lightweight version somewhere… WDYT? Do we agree that we should try to contain the size and even start decreasing it if we can? Thanks -Vincent

8 years, 1 month

[xwiki-devs] [Proposal] XWiki 8.3 Roadmap

by Vincent Massol

Hi devs, I’m sorry to be so late to send this email. I thought I had sent it before going on holidays but apparently I didn’t. Sorry about that. So here’s the proposal: * Thomas: ** Priority 1: l10n support for nested pages ** Priority 2: Curated extensions feature in EM (curated extensions listed + ability to see others if explicitly asked) ** Priority 3: Fix various existing NS issues (example: office macro on NP) + continue improving tools ** Priority 4: Paying + Trial feature in EM (see that an app is paying + has a trial and show it) * Marius: ** Priority 1: Fix performance issue in Document Tree + fix "Add support for sorting the pages by their title in the document tree" at the same time ** Priority 2: Fix various existing NS issues (example: office macro on NP) + continue improving tools. Includes as priority "Viewing a PPT / ODP with the Office Macro fails when on a nested page” ** Priority 3: Bring back XCS flavors in XE (involves dropping XE and replacing it with a KB flavor and start using the platform distribution instead of XE) * Caty: ** Priority 1: Complete Templates (set of sample templates (partially done already) + templates in each App and in AWM) in XE ** Priority 2: Demo content extension for XE ** Priority 3: Curated extensions feature in EM (curated extensions listed + ability to see others if explicitly asked) ** Priority 4: Mouseflow + Inspectlet analysis for xwiki.org ** Priority 5: Task for Usability (investigation) * Vincent: ** Priority 1: Curation of extensions.xwiki.org ** Priority 2: Playground flavor ** Priority 3: Continue Confluence + MediaWiki comparison pages + present XWiki as the best Confluence alternative ** Priority 4: Improvement to activeinstalls to capture some more information (email hash for unicity, country, number of users) * Guillaume: ** Priority 1: <internal XWiki SAS work - Infra work for XWiki Cloud if you’re curious ;)> ** Priority 2: Fix various existing NS issues (example: office macro on NP) + continue improving tools * Alex: ** Priority 1: <internal XWiki SAS work - prepare one paying app and setup an XWiki SAS store> ** Priority 2: Demo content extension for XE ** Priority 3: Fix various existing NS issues (example: office macro on NP) + continue improving tools * Edy: ** Priority 1: <internal XWiki SAS work - Network work, this is XWiki SAS’s customer portal: issue tracking, subscriptions, etc> ** Priority 2: Complete Templates (set of sample templates (partially done already) + templates in each App and in AWM) in XE ** Priority 3: Fix various existing NS issues (example: office macro on NP) + continue improving tools Top JIRA issues to fix: * Viewing a PPT / ODP with the Office Macro fails when on a nested page - XWIKI-11611 * Cannot delete document with many large attachments - XWIKI-8910 * Extend "Add Application" UIX with an order parameter - XWIKI-13075 * Rename and copy page operations don't update the page title - XWIKI-12776 * Presentation Office documents (.ppt & .pptx) aren't displayed with LibreOffice 4.3.5.2+ - XWIKI-13256 Dates: * 8.3M1: 22 August 2016 (one more week than usual to account for Holidays) * 8.3M2: 12 Sep 2016 * 8.3RC1: 26 Sep 2016 * 8.3final: 10 Oct 2016 Let me know what you think and reply if you’re interested to participate to this roadmap and you wish to implement/contribute some other stuff. Thanks -Vincent

8 years, 1 month

[xwiki-devs] [Proposal] Move out Chart Macro + Renderer to Contrib

by Vincent Massol

Hi devs, I’d like to propose: * move out the Chart Macro + Renderer to Contrib since it’s not core. * still depend on it in the XE distribution for now. However if everyone feels that it’s not needed to have it by default for users and that it’s better to let them install it, I’m also fine. But right now I prefer to have it by default. WDYT? Thanks -Vincent

8 years, 1 month

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

by Alexandru Cotiuga

Hello devs, This Thursday is BFD#117: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 56 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#117 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13635 Happy Bug Fixing Day, Alex

8 years, 1 month

[xwiki-devs] [Proposal] New best practice for extensions and especially recommended ones: LATEST branch

by Vincent Massol

Hi devs, Context ======= I’d like to propose a new best practice for extensions and especially recommended ones. We already have the following on http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra…: "In your POM always try to depend on the oldest version of commons/rendering/platform dependencies for which your code works. At least, ensure that your Applications works on the latest LTS version of XWiki. This will allow the largest number of users to use your application.” In addition on the definition of a Recommended Extension at http://extensions.xwiki.org/xwiki/bin/view/ExtensionCode/RecommendedExtensi… we say: “Works at least with the latest stable XWiki versions and with the LTS version” This proposal is about ensuring that an extension works with the latest stable XWiki version. Proposal ======== 1) Always create a LATEST branch for recommended extensions 2) On this branch depend on LATEST for parent pom. For example: <parent> <groupId>org.xwiki.commons</groupId> <artifactId>xwiki-commons-pom</artifactId> <version>LATEST</version> </parent> Note 1: For extensions using https://github.com/xwiki-contrib/parent we also need to release latest version of those poms as part of the XWiki commons/rendering/platform/enterprise release process. Note 2: The advantage of using LATEST is that it doesn’t require maintenance from the extensions whenever new versions of XWiki commons/rendering/platform/enterprise are released. It does require to update the contrib parent poms though. 3) On ci.xwiki.org, make sure that the job is defined to build 2 branches. You can also leave the branch name empty and Jenkins will then build all available branches as I’ve done for IRC Bot app: http://ci.xwiki.org/job/Contrib%20-%20IRC%20Bot%20Application/configure (check the “Source Code Management” section). WDYT? Thanks -Vincent

8 years, 1 month

[xwiki-devs] [ANN] Publication Workflow Application v1.7 released

by Clemens Klein-Robbenhaar

Hi all, a new release of the "XWiki Publication Workflow Application" is available right now: http://extensions.xwiki.org/xwiki/bin/view/Extension/XWiki+Publication+Work… This release mainly adds the new feature to support workflows for multi-language pages. Minor improvements are a marginally more efficient handling of large attachments and less deprecations warnings in the logs. See also the release nots for (pointers to) details: http://extensions.xwiki.org/xwiki/bin/view/Extension/XWiki+Publication+Work… You can install or upgrade with the Extension Manager. Thanks, Clemens

8 years, 1 month

[xwiki-devs] Legal notice for xwiki.org

by Vincent Massol

Hi xwiki committers, According to the French law we have to have a legal notice page on xwiki.org, see: https://www.service-public.fr/professionnels-entreprises/vosdroits/F31228 I’ve thus created http://www.xwiki.org/xwiki/bin/view/Main/LegalNotice/ WDYT? Anything to add? Now we need to link it, somewhere in the footer. @Caty: would you have any idea of where would be the best place? Thanks -Vincent

8 years, 1 month

[xwiki-devs] [PROPOSAL] Make {{html}} default behavior be clean=false

by Caleb James DeLisle

Hello all, Recently we discovered that in XWiki 8.2 the {{html}} macro cleaner now removes <video> tag whereas in 7.4 it did not and this has unfortunately caused problems for the {{video}} macro. 1. After some helpful investigation by a few XWiki developers, we have found that in fact the {{html}} macro is cleaning for XHTML and not for HTML5 which is what XWiki uses and the change has seemingly gone unnoticed since the upgrade to 8.0M1. 2. After some conversation with developers, I have observed that it is rare for an application developer to *intend* to have their HTML cleaned. In the XWiki repositories we find that amongst non-one-liner {{html}} macro invocations, 109 out of 292 (37%) of the invocations explicitly request clean=false [1]. 3. Nowhere is clean="true" specified and though one might think it obvious as it is a default, we find that wiki="false" (also default) is indeed specified 28 times [2]. 4. We see also that the HTML macro proves to be quite slow. During an investigation of SOLR performance Thomas found that "about 23% of the request is spend executing html macros" [3]. I suppose it should be obvious that without the cleaner, the {{html}} macro should not cause any significant performance degradation. Given the status of this feature, I would like to propose that we make an intentional change of behavior and change the default to clean=false. This way we application developers will not need to type it all of the time and XWiki will become measurably faster. Here is my +1 for changing the default. Thanks, Caleb [1]: $ grep -nr '{{html' | grep '.xml:' | grep 'clean=['\''"]*false' | grep -v '{{/html}}' | wc -l 109 $ grep -nr '{{html' | grep '.xml:' | grep -v 'clean=['\''"]*false' | grep -v '{{/html}}' | wc -l 183 [2]: $ grep -nr '{{html' | grep '.xml:' | grep 'wiki=['\''"]*false' | wc -l 28 [3]: https://jira.xwiki.org/browse/XWIKI-12043

8 years, 1 month

[xwiki-devs] [contrib][workflow-publication][Proposal] request for a new release on Tuesday (6.9.)

by Clemens Klein-Robbenhaar

Hi Devs, if nobody objects I would like to cut a new release for the Publication Workflow Application at http://extensions.xwiki.org/xwiki/bin/view/Extension/XWiki+Publication+Work… The version number would be 1.7 I would like to make the release on Tuesday (unless Monday is a bank holiday or the like, in case of the release date shifts to Wednesday) The release would fixes the following issues: http://jira.xwiki.org/browse/XAWORKFLOW/fixforversion/16658 The main change would be some basic support for multi-language documents, which I know someone would really appreciate. There are two new translation keys: one is introduced for XAWORKFLOW-27 and is shown in the workflow panel as a hint for the publisher who is publishing a multi-language document, informing about the fact that all language variants are going to be published workflow.panel.publish.hintLanguages and one that showed up as missing while checking XAWORKFLOW-28: PublicationWorkflow.PublicationWorkflowConfigClass_groupedit_hint = Edit Workflow Group Unfortunately the default "Translations" document is in French, and as I did not want to show in translation key for unsupported languages, I just filled in an English text. If someone could replace these "dummy translations" with a proper French text this would be really appreciated. Are there any objections to the release? Does someone want more time to look at the changes? Cheers Clemens P.S. if there are no objections I can handle most parts of the release on my own, but need a bit of help with updating the versions in JIRA.

8 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2016