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

[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

Re: [xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?
by daniel glazman 16 Jun '17

16 Jun '17

> > * "Base XWiki Flavor” > > * “Classic XWiki Flavor” > > * “Raw XWiki Flavor” > > * “Starter XWiki Flavor” > > * "Default XWiki Flavor” > > * "Generic XWiki Flavor” > > * “Standard XWiki Flavor” > > * "XWiki Flavor” > > * "Vanilla XWiki" Sorry to send this message without the threading references; I just subscribed to the devs(a)xwiki.org mailing-list and I would like to contribute my €0.02 to the discussion The items below are numbered for commenting convenience but are not ordered in any way. 1. The name XWiki already has its first letter at the end of the alphabet. Marketing-wise in the Software ecosystem, lists of apps are most often alphabetically sorted, granting a bonus to apps with a name in A, B or C, and a minus to the end of the alphabet. So all names there have to counterbalance that handicap and I think "self-descriptiveness" does matter. 2. if you except "XWiki Flavor", the word "XWiki" comes in second position in all proposals, and that is not the best thing ever. 3. the name must be chosen wrt the targeted audience and the product's position on the market. I think Olivier has a point when he writes « what is the audience and the objectives ? » 4. more specifically about the proposals above: 4.1. a "flavor" holds the notion of specialization. 4.2. "Classic" can mean "legacy" in the Software world. Use carefully... 4.3. "Vanilla" is a geeky choice. Nobody else but geeks will get it,sorry. IMHO, "XWiki Foundation", "XWiki Core" or "XWiki Starter Kit" represent quite well what this is all about. </Daniel>

4 10

[xwiki-devs] [Brainstorming] Templates exposure
by Ecaterina Moraru (Valica) 14 Jun '17

14 Jun '17

Hi devs, This roadmap we had 2 suggestions: - "Find a way of avoiding to have 2 "Add" entries ("+" and "Add new entry")" in AWM - "Drop down on "+" Menu + Admin UI to select some templates" What we have implemented so far was: http://jira.xwiki.org/browse/XWIKI-14310 "Propose and pre-select "recommended" templates in the create UI based on the current location" So now, if you go to the Blog app and create on the "+" button, since Blog provides a template with a create restriction, the "Blog" template will be preselected. Also, AWM has the option to create a template for each application the users create. So after you created your app with AWM and go to the "+" button, the app template will be preselected. This will allow us in the future to remove the AWM actions area and rely on the "+" button. In the future, we could also separate templates in their own "Recommended" category. A separate category will be necessary for applications that provide multiple related templates (like Forum for example that will contain the Forum, Topic templates) or in the more general case when multiple templates are recommended for the current location. Currently we are doing only sorting and preselecting the first one. In terms of implementation we just need to make sure all our recommended apps provide template providers and after that we could change the UI for AWM and remove the "Add" action from the actions area. Now, I want to ask your opinion on the suggestion to add a dropdown for the "+" button. Some input: - a dropdown will not be scalable: you cannot have more than a few options there; - in a dropdown you cannot specify the page name; - in the dropdown you cannot change or specify another location - you always need to go to the page first and after choose a template from the dropdown list; - you will only see an admin selection of templates - so we invalidate the templates filtering and you cannot even choose another template after your initial selection; - we make the current create step deprecated, since users will not see it anymore. The main reason of this request was to increase visibility and order for the templates. In the user recording sessions I've seen and with the current layout (2 columns, templates on right) users don't have problems seeing the "Templates" section in the Create step. Now, for the ordering / selection - the current mechanism of automatic ordering is a step in that direction - but sure we could implement more (like the separate category I described earlier). Another difference between what was asked and what was currently implemented is that now the selection comes from the Template Provider; while the idea was to allow the Administrator to select the displayed Templates. With the current implementation we can still create an administration UI to select them and save the changes in the Template Providers, in a future iteration. ----- So the question is: - Do you have other ideas on how we could solve the requests? - What do you think about having a dropdown with the templates selection - compared to a recommended category in the creation step? Thanks, Caty

4 6