xwiki-devs September 2014

xwiki-devs@xwiki.org

26 participants
68 discussions

[xwiki-devs] Proposal: use the {{spaces /}} macro in the "Spaces" panel

by Guillaume Lerouge

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

9 years, 11 months

Re: [xwiki-devs] [xwiki-notifications] [xwiki/xwiki-platform] 8be389: XWIKI-11132: Formula Cache is not purged at startu...

by vincent＠massol.net

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 >

9 years, 11 months

[xwiki-devs] [XWiki Day] BFD #63 - second attempt tomorrow

by Eduard Moraru

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

9 years, 11 months

[xwiki-devs] [Proposal] Introduce 2 new loggers "org.xwiki.initialization" and "org.xwiki.shutdown"

by vincent＠massol.net

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

9 years, 11 months

[xwiki-devs] [Proposal] Remove branch 6.1.x in Git + 6.1.1 version in JIRA and on Jenkins

by vincent＠massol.net

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

9 years, 11 months

[xwiki-devs] Multilingual Blog application

by Valdis Vītoliņš

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

9 years, 11 months

[xwiki-devs] [Brainstorming] Controlling XWiki's performance

by vincent＠massol.net

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

9 years, 11 months

[xwiki-devs] Naming of "Filter Application" can be improved?

by vincent＠massol.net

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

9 years, 11 months

[xwiki-devs] [VOTE] Use jsTree as the standard library for creating trees in XWiki

by Marius Dumitru Florea

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

9 years, 11 months

[xwiki-devs] Xwiki translation

by Pascal BASTIEN

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

9 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 September 2014