September 2014 - xwiki-devs@xwiki.org

[xwiki-devs] Proposal: use the {{spaces /}} macro in the "Spaces" panel
by Guillaume Lerouge 30 Sep '14

30 Sep '14

Hi devs, I saw that on XE 6.2, the "Spaces" panel still uses an old code snippet instead of the more recent and better looking {{spaces/}} macro. I'm therefore suggesting we use that macro in the panel. I created the XE-1430 issue <http://jira.xwiki.org/browse/XE-1430> to this effect. WDYT? Guillaume

1 0

Re: [xwiki-devs] [xwiki-notifications] [xwiki/xwiki-platform] 8be389: XWIKI-11132: Formula Cache is not purged at startu...
by vincent＠massol.net 29 Sep '14

29 Sep '14

Bad commit, I’ve reverted, sorry... -Vincent On 29 Sep 2014 at 11:19:19, GitHub (noreply@github.com(mailto:noreply@github.com)) wrote: > Branch: refs/heads/master > Home: https://github.com/xwiki/xwiki-platform > Commit: 8be389b7890dbd030418faaf3056c63c6e9256f7 > https://github.com/xwiki/xwiki-platform/commit/8be389b7890dbd030418faaf3056… > Author: Vincent Massol > Date: 2014-09-29 (Mon, 29 Sep 2014) > > Changed paths: > A xwiki-platform-core/xwiki-platform-homepage/xwiki-platform-homepage-ui/pom.xml > A xwiki-platform-core/xwiki-platform-homepage/xwiki-platform-homepage-ui/src/main/resources/HomePage/HomePageClass.xml > A xwiki-platform-core/xwiki-platform-homepage/xwiki-platform-homepage-ui/src/main/resources/HomePage/HomePageSheet.xml > A xwiki-platform-core/xwiki-platform-homepage/xwiki-platform-homepage-ui/src/main/resources/HomePage/LiveTableJSON.xml > A xwiki-platform-core/xwiki-platform-homepage/xwiki-platform-homepage-ui/src/main/resources/HomePage/Translations.xml > A xwiki-platform-core/xwiki-platform-homepage/xwiki-platform-homepage-ui/src/main/resources/HomePage/WebHome.xml > A xwiki-platform-core/xwiki-platform-homepage/xwiki-platform-homepage-ui/src/main/resources/Main/WebHome.xml > M xwiki-platform-core/xwiki-platform-web/src/main/webapp/WEB-INF/cache/infinispan/config.xml > > Log Message: > ----------- > XWIKI-11132: Formula Cache is not purged at startup >

1 0

[xwiki-devs] [XWiki Day] BFD #63 - second attempt tomorrow
by Eduard Moraru 29 Sep '14

29 Sep '14

Hi devs, Since we`ve skipped the last ones, I propose we do a BFD (BFD#63) tomorrow: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays As we already know, the numbers for the 1 year status have spiralled out of control. We are currently 102 bugs behind. See: http://jira.xwiki .org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-Resolved-Chart/10470 Also, the release of 6.2.1 is around the corner so the time is right for some bug squashing! Here's the BFD#63 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12598 Thanks and happy bug fixing! -Eduard

2 5

[xwiki-devs] [Proposal] Introduce 2 new loggers "org.xwiki.initialization" and "org.xwiki.shutdown"
by vincent＠massol.net 27 Sep '14

27 Sep '14

Hi Devs, I’d like to add some logging to debug what happens when XWiki shuts down. One solution would be to just use the standard class loggers with LOGGER.debug(…). However this means activating debug logging for everything and thus you cannot just focus on the shutdown part. WDYT about adding 2 new loggers "org.xwiki.initialization" and “org.xwiki.shutdown”? Example usage: /** * Logger to use to log shutdown information. */ private static final Logger SHUTDOWN_LOGGER = LoggerFactory.getLogger("org.xwiki.shutdown"); ... SHUTDOWN_LOGGER.debug("Stopping component [{}]...", instance.getClass().getName()); ... SHUTDOWN_LOGGER.debug("Component [{}] has been stopped", instance.getClass().getName()); Then it becomes easy to set, in logback.xml: <logger name=“org.xwiki.shutdown" level=“debug"/> A small variation would be to use SHUTDOWN_LOGGER.info() and in logback.xml, by default to have: <logger name=“org.xwiki.shutdown" level=“warn"/> Note that this would be the first time we use non-class loggers which is why I’m asking for your go-ahead. Thanks -Vincent

4 13

[xwiki-devs] [Proposal] Remove branch 6.1.x in Git + 6.1.1 version in JIRA and on Jenkins
by vincent＠massol.net 27 Sep '14

27 Sep '14

Hi devs, AFAIK we have no plans to release a 6.1.1 version since we’re releasing 6.2 final next week. I’m thus proposing to remove the 6.1.x branch. Let me know if someone needs this branch. Otherwise I’ll remove it at the end of this week or early next week. Thanks -Vincent

2 2

[xwiki-devs] Multilingual Blog application
by Valdis Vītoliņš 26 Sep '14

26 Sep '14

Hello! During Java Bootcamp organized bu Accenture Riga delivery center, students have developed updated XWiki Blog application which support multiple languages for the posts and blog. I have cleaned it a bit and could contribute as another extension in http://extensions.xwiki.org/xwiki/bin/view/Extension/ Though, I think it would be better to use this as a default Blog application bundled with XWiki Enterprise (with some fixes and updates, which from XWiki side, which I'll document later). What do you think would be the best way? Thanks! Valdis

4 6

[xwiki-devs] [Brainstorming] Controlling XWiki's performance
by vincent＠massol.net 26 Sep '14

26 Sep '14

Hi devs, I think it’s high time we start to control our performances (page load time, memory consumption, scalability). Here’s what I envision: * At each release (milestone) we get a report of the following (precise details to be defined together): ** page load times *** empty page with “get” action (ie no skin) *** empty page with “view” action *** Dashboard.WebHome with “view” action *** <others?> ** memory consumption *** <scenarios to be defined> ** scalability *** max TPS (transaction per second) with a defined page navigation scenario, injected with lots of users and see how the TPS evolves with # of users *** <precise scenarios to be defined> * Store the results on http://xwiki.org to be able to compare them against past releases and see how it’s progressing Note that Thomas started by installing the jenkins performance plugin with a jmeter job on ci.xwiki.org but it’s not enough and more importantly it’s not used. What we need is a report at each release with a quick analysis of how it compares with past releases and some suggested actions. WDYT? Thanks -Vincent

3 2

[xwiki-devs] Naming of "Filter Application" can be improved?
by vincent＠massol.net 26 Sep '14

26 Sep '14

Hi devs and especially Thomas, I personally don’t like too much the naming of “Filter” for the Filter Application at http://extensions.xwiki.org/xwiki/bin/view/Extension/Filter+Application When I look at it, it doesn’t look like a Filter. A filter is used to transform some content by removing some elements from the content (to filter them out). It looks a lot more like a Conversion Application. WDYT? <aside but related> Also, we really need to improve this because for an end user it’s impossible to understand that to import some Confluence content into XWiki they have to use the Filter Application with the Filter Confluence XML module. It looks more like a Confluence Parser than a Filter module in this case (I don’t think it doesn’t any output, just input AFAIK). Renaming to Conversion Application would not be enough either on this topic. Having a simplified Confluence Importer Application with a simplified UI but based on the “Filter Application” is the best. In the meantime I’ve added a new page for Imports at http://platform.xwiki.org/xwiki/bin/view/Features/Imports </aside but related> Thanks -Vincent

1 0

[xwiki-devs] [VOTE] Use jsTree as the standard library for creating trees in XWiki
by Marius Dumitru Florea 26 Sep '14

26 Sep '14

Hi devs, There are a couple of places in XWiki were a tree widget is used or needed: document index, WYSIWYG editor wiki page linking, XAR import, navigation panel, database tree list, report step of Distribution Wizard, extension upgrade when asking confirmation to clean unused pages, etc. But we don't have a standard / recommended tree widget / library. We use either SmartClient which is very heavy or a custom tree based on Prototype.js. Since we want to ditch the heavy SmartClient tree and we decided to move away from the dead Prototype.js to jQuery I propose to use jsTree ( http://www.jstree.com/ ) as the standard / recommended library for creating trees in XWiki. It is one of the best and most used tree widgets written using jQuery. I have used jsTree on the File Manager ( http://extensions.xwiki.org/xwiki/bin/view/Extension/File+Manager+Applicati… ) and it was a positive experience. Moreover, there are other extensions based on, like the Dynamic Hierarchy Macro ( http://extensions.xwiki.org/xwiki/bin/view/Extension/Dynamic+Hierarchy+Macro ). My plan is: * include jsTree in the default distribution (through a webjar dependency); it won't be loaded by default, obviously; you'll have to use Require.js to load it. * start rewriting the current trees using jsTree Here's my +1. Thanks, Marius

8 15

[xwiki-devs] Xwiki translation
by Pascal BASTIEN 25 Sep '14

25 Sep '14

Hello, Could you synchronized http://l10n.xwiki.org/xwiki/bin/view/Platform/WebHome for Xwiki 6.2? I want correct a french missing translation for 6.2 stable... Thxs by advance Pascal B

2 16