June 2017 - xwiki-devs@xwiki.org

[xwiki-devs] Status on scope of XWiki GitHub organization and its implementation
by Vincent Massol 27 Jun '17

27 Jun '17

Hi devs, Part 1 ===== I was looking at http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTopLeve… and found the thread where it was voted in July 2014: http://markmail.org/message/4hglttljiio5v2km Does anyone remember the thread were we decided to not do it? I also found this VOTEd thread from 21st June 2016: http://markmail.org/message/rb5xuex3mpzg3lsm This new thread is not contradictory with http://markmail.org/message/4hglttljiio5v2km so it doesn’t supersedes it. Thus there really must be some other thread where we decided to not implement http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTopLeve…. Part 2 ===== Now, about http://markmail.org/message/4hglttljiio5v2km we have almost implemented it. We’re just missing one point: “ * The Default Flavor would have at least the same release cycle as the base flavor but it could have more releases (if some of the bundled third-party extensions has some important bug fixes or new features that we want to offer quickly without waiting for the next base flavor release). “ And later on: “ Technically this means putting the Default Flavor in a separate github repo (same as xwiki-enterprise being in a separate repo). We need to discuss how we do it: - consider it’s XE for now and just add the 2 deps of Tour and CK to XE - introduce a new repo for the default flavor and do the build for it and deprecate XE in favor of it. For now we probably need to hardcode the flavor id in the platform WAR till we’re ready to have the flavor selection screen at startup (and for HSQLDB/Jetty packaging we need a hard-coded flavor anyway). " Right now we’ve put the “Standard Flavor” (that’s the new name) inside xwiki-platform but we discussed back then move it to a separate repo in the xwiki github organization and have only the base flavor in platform. Should we do what we decided? Thanks -Vincent

3 6

[xwiki-devs] (no subject)
by Sarthak Gupta 26 Jun '17

26 Jun '17

Hello, I have written some java code on 'transformations'. https://pastebin.com/CCHsg0hq In order to navigate to the required page, I am using the method 'ResourceReference' (highlighted region-line 86,87). Now I want to navigate to the page named 'Glossary.doc' which is located in XWiki. I know my current implementation is wrong and I have been struggling for 2 days to find the right implementation/method. Is there any method that I can use which can return me the String 'Glossary.doc' so that I can create a linkReference to the same page in XWiki? Thanks Sarthak Gupta

2 4

[xwiki-devs] [GSoC] Extension Repository Connector - Bintray 1.0 released.
by Krzysiek Płachno 26 Jun '17

26 Jun '17

Hello everybody! I'm very happy and quite proud to announce that 1.0 version of "Extension Repository Connector - Bintray" is released. I kindly encourage everybody to check it out: http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension%20Repository… (installable with Extension Manager) I'd very grateful for any feedback ;) Best, Krzysztof Płachno

3 2

[xwiki-devs] [Proposal] Make users list readonly?
by Vincent Massol 23 Jun '17

23 Jun '17

Hi devs, Now that our forum is working well I’d like to propose to make the users list readonly and move all users to the forum. So the plan I’m proposing is: * On Monday, make the users list readonly * Send a last message on it, inviting users to move to the forum Note that we’ve already been putting a notice to all messages sent on the users lists inviting users to move to the forum and this has been running for 2 weeks already. My feeling is that we need to finalize the move now and prevent too much scattering of user posts both on the users list and on the forum and have them all on the forum ASAP. WDYT? Thanks -Vincent

5 17

[xwiki-devs] [ANN] XWiki 9.5 Release Candidate 1 released
by Eduard Moraru 22 Jun '17

22 Jun '17

The XWiki development team is proud to announce the availability of XWiki 9.5 Release Candidate 1. This release features a major restructuring of the XWiki Enterprise distribution by converting it into the XWiki Standard Flavor. User features cover notifications by email, attachments list showing icons and image previews, recommended template at page creation, LiveTable date and multilist filters, and minor visual improvements. Admins can more easily customize the look and feel by the extended use of Icon Themes and the improvements done to setting the wiki logo. Finally, devs have a new API for working with wiki components, new icon theme mappings and notifications API improvements. 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.5RC1 Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [UX][Proposal] Multipage Tours
by Ecaterina Moraru (Valica) 19 Jun '17

19 Jun '17

Hi devs, I've made an investigation on what technical problems we have while wanting to provide our beginner users with multipage tours. You can see how the Tours would integrate with the current UI, some tours proposals and issues found at: http://design.xwiki.org/xwiki/bin/view/Proposal/MultiPageTours Let me know what you think and if you have other ideas. Thank you, Caty

1 0

[xwiki-devs] JIRA, JQL and Release Notes
by Vincent Massol 19 Jun '17

19 Jun '17

Hi devs, Almost all our filters on jira.xwiki.org were wrong (all bugs for xwiki committers, all issues for xwiki committers, etc) because they were only filtering on the “top level” category (id = 10000) and thus were forgetting the contrib extensions that we bundled in XE. Thus I’ve renamed the "top level projects” category into “XWiki Enterprise” (and soon we’ll rename it with the name of the flavor replacing it). I’ve also moved the conrib extensions that we bundled into that category. See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000 As a consequence this fixed https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 for example, which is now correct. However this leads to a problem: All JQL we wrote that were using things like “category in (“Top Level Projects”)” instead of “category = 10000” are now broken. For example we use this in our Relaese Notes for bug fix releases. I’ve fixed all of them using the Release Application but not old ones yet. Also, in our RN for bug fix releases we need to specify all projects one by one along with versions. Writing the following (as can be seen in http://www.xwiki.org/xwiki/bin/edit/ReleaseNotes/Data/XWiki/9.3.1/WebHome?e…) is wrong for example: category = 10000 AND fixVersion in ("9.3.1") AND resolution in (Fixed) and component not in ("Development Issues only”) FTR in the RN for 8.4.2 I wrote: category = 10000 and fixVersion = "8.4.2" and resolution = Fixed and component != "Development Issues only" OR project = "CKEditor Integration" and fixVersion = "1.10" and resolution = Fixed OR project = "Tour Application" and fixVersion = "1.1" and resolution = Fixed But even that is not correct anymore and we now need to write instead: project IN ("XCOMMONS", "XRENDERING", "XWIKI", "XE") AND fixVersion = "8.4.2" AND resolution = Fixed and component != "Development Issues only" OR project = "CKEDITOR" AND fixVersion = "1.10" AND resolution = Fixed OR project = "TOUR" AND fixVersion = "1.1" AND resolution = Fixed So we need to review: * The filters and dashboard in jira.xwiki.org and fix them (for example GD, in the RN for 9.4 we point to https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13894 which is broken now since its filter uses “Top Level Projects” but I can’t fix it since I don’t own it in jira…) * The JQL statements used in xwiki.org and especially in the RNs. We should probably create some scripts/tools to help us write those JQL. Any comment? Any other idea? Thanks -Vincent

1 3

[xwiki-devs] [Idea] Also save the previous version when upgrading
by Vincent Massol 19 Jun '17

19 Jun '17

Hi devs, I’d like to propose that we also save the previous version of XWiki when we upgrade. I can think of 2 use cases for that: * After the user upgrades we display a What’s New (could be something in the notification area, in the Admin UI home page, as a popup on the first connexion after the upgrade, etc) and we take the data from the Release Notes app on xwiki.org using the previous version information to list what’s new. * When a user reports a problem of upgrade, we can ask him to tell us the previous version that is stored. WDYT? Note that the info should probably be stored somewhere in the permanent directory. It could even be stored in the existing status.xml file. EDIT: Actually it could already exist maybe. I’ve just checked distribution/status.xml on xwiki.org and I can see: <previousDistributionExtension> <id>org.xwiki.enterprise:xwiki-enterprise-web</id> <version class="org.xwiki.extension.version.internal.DefaultVersion" serialization="custom"> <org.xwiki.extension.version.internal.DefaultVersion> <string>8.4.4</string> </org.xwiki.extension.version.internal.DefaultVersion> </version> <hashCode>-1</hashCode> </previousDistributionExtension> <previousDistributionExtensionUi> <id>org.xwiki.enterprise:xwiki-enterprise-ui-mainwiki</id> <version class="org.xwiki.extension.version.internal.DefaultVersion" reference="../../previousDistributionExtension/version"/> <hashCode>-1</hashCode> </previousDistributionExtensionUi> <distributionExtension> <id>org.xwiki.enterprise:xwiki-enterprise-web</id> <version class="org.xwiki.extension.version.internal.DefaultVersion" serialization="custom"> <org.xwiki.extension.version.internal.DefaultVersion> <string>8.4.4</string> </org.xwiki.extension.version.internal.DefaultVersion> </version> <hashCode>-1</hashCode> </distributionExtension> @Thomas: Any idea with previous version = new version = 8.4.4? @Thomas: Do we have an API to get that info from a velocity script for example (or from Java)? Thanks -Vincent

2 5

[xwiki-devs] [Glossary Application] Creating Transformations
by Sarthak Gupta 17 Jun '17

17 Jun '17

Hello, The next part of my project is creating transformations i.e displaying words included in glossary differently when a page renders. After going through docs, I understood that I have to write a new rendering transformation. This new transformation will match the words on different pages to the glossary items present in the glossary space, and then create links to the required glossary page. What should be the name of this transformation? glossaryTransformation? Furthermore, I have used the xwiki-rendering-archetype-macro for generating the component using maven [ mvn archetype:generate \ -DarchetypeArtifactId=xwiki-rendering-archetype-macro \ -DarchetypeGroupId=org.xwiki.rendering \ -DarchetypeVersion=9.5-SNAPSHOT ] I am still working on the component implementation. Hope I am going on the right track. Thanks :) Sarthak Gupta

2 3

[xwiki-devs] [Proposal] New configuration strategy - Take 2
by Vincent Massol 17 Jun '17

17 Jun '17

Hi devs, Current Situation ============= In the past we discussed this and even reached some conclusions but it wasn’t implemented. The relevant thread: * Original idea: http://markmail.org/message/yl77mvdtznii263l * Updated idea: http://markmail.org/message/6cvm5hocvtbqtgp6 This thread supersedes these old threads. In the meantime Thomas has also implemented https://jira.xwiki.org/browse/XWIKI-13867 (BTW I added several comments but didn’t get any answer from them ;)). So here’s an updated proposal: Use Cases: ========= - UC1: Easy install: no need to explode the WAR to install XWiki. - UC2: Easy upgrade: no need to take care about backupping specifically the configuration in WEB-INF so that it's not overwritten by an upgrade of the WAR - UC3: Should be possible to have multiple installs on the same machine and running at the same time - UC4: Should be possible to control the location of the configuration files for our automated functional tests (so that we control the configuration used) - UC5: (Future) Make XWiki work without configuration files - UC6: Allow our users of the Docker image to configure XWiki outside of the container (see https://jira.xwiki.org/browse/XDOCKER-20) Implementation Proposal: ==================== * Configuration files = xwiki.cfg, xwiki.poperties and hibernate.cfg.xml * Allow configuring the permanent directory with the XWIKI_DATA_DIR environment variable (in addition to the existing xwiki.data.dir system property, i.e. -Dxwiki.data.dir=…). In Java this is done by using System.getenv() * Load the configuration files in a specific order, each level overwriting the previous level, except for hibernate.cfg.xml since it’s harder to merge XML. The idea is that users will only need to define configuration properties that they want to override. * The order is the following: ** Load from WEB-INF/ ** Load from the location defined by the JNDI property ** Load from [permanent directory]/config/ * For xwiki.properties and xwiki.cfg, if the property is not found, then default to a value provided by the code. * Add some comments at the top of xwiki.cfg, xwiki.properties and hibernate.cfg.xml to explain to the user how they should customize them. Option 1: * Right now if the permanent dir is not defined, we default to using the servlet temporary directory (i.e. “javax.servlet.context.tempdir” system property). One option is check the OS and: ** If on unix, default to /etc/xwiki/ ** If on windows, default to the user home profile (using System.getProperty("user.home”) or System.getenv("USERPROFILE”)) Option 1bis: * Right now if the permanent dir is not defined, we default to using the servlet temporary directory (i.e. “javax.servlet.context.tempdir” system property). One option is to default to the user ome directory instead (using System.getProperty("user.home”)). Note that for UC5 my POV is that in the future: * We should move the database configuration to a step in an Installation Wizard that execues on XWiki’s first run. This would internally generate the Hibernate configuration. * Provide defaults for all xwiki.cfg properties (it’s already the case for xwiki.properties normally). Note: I don’t know where https://jira.xwiki.org/browse/XWIKI-13867 fits; it could maybe fit with Option 1 (which is why I wrote option 1 and 1bis actually). WDYT? Thanks -Vincent

1 0