February 2013 - xwiki-devs@xwiki.org

[xwiki-devs] [Proposal] Roadmap for XWiki 5.0
by Vincent Massol 02 Mar '13

02 Mar '13

Hi devs, With XWiki 4.x cycle coming to an end soon, it's time to prepare the roadmap for XWiki 5.0. This is a proposal that comes from some internal meetings done with XWiki committers who are working for XWiki SAS. If you're interesting in participating to this release, don't hesitate to add yourself to the list so that everyone can have some visibility of what's going to be worked on during this timeframe! If you think some work defined below doesn't go in the interest of the project also feel free to raise issues. Features: * Continue SOLR implementation - Edy * EM upgrade of subwikis + flavor concept (add Flavor type in EM/Repository) + leftover from 4.x for EM/DW - Thomas + Marius for DW UI part for flavors * AWM work from 4.x to finish (see http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome) - Marius * scalable import/export - Thomas * Home page improvements (XE) and usability improvements in general - JV * Horizontal Menu management (add, remove pages) - JV * virtual=1 by default - Edy (Edy will need to make a proposal for that since it's an important decision ;)) * l10n speed improvements - Ludovic Important JIRAs sorted by priority (most important first): * AWM Add the ability to publish an application as an extension XWIKI-7377 - Marius * AWM Add the ability to export an application XWIKI-7376 - Marius * Unable to edit a page using the WYGIWYG editor after adding a dashboard macro to it XWIKI-8495 - Need volunteer * Improve AWM for it to deal with error messages made by Client when filling the AWM form in using special chars XWIKI-8763 - Marius * Import of Office file breaks Activity Stream and Recently Modified Panel XRENDERING-261 - Need volunteer * Cannot change document title from "inline" mode XWIKI-7905 - Not sure if we want it, to be checked with Marius * When the workspace owner is changed, the new owner is not added as a member nor in the admin group XWIKI-8397 - Edy * Unable to upload a new attachment using the "All pages" tab in the WYSIWYG editor XWIKI-8465 - Marius * Workspace owner and initial members not set as members (nor in admin group) when the workspace identifier contains an underscore XWIKI-8394 - Edy Investigations: * XEM Homepage / Portal - Caty * Knowledge base Flavor - Caty/Ludovic * New Activity Stream Investigation Part 1 - JV (he's agree to become our AS champion :)) * General Flavours Investigation - Caty + input from tech Regarding dates I'm proposing the following: * 5.0M1: 4 March 2013 * 5.0M2: 25 March 2013 * 5.0RC1: 8 April 2013 * 5.0Final: 15 April 2013 Thanks -Vincent

1 3

[xwiki-devs] [Notice] BFD#10
by Vincent Massol 01 Mar '13

01 Mar '13

Hi devs, Tomorrow is BFD#10: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HXWikiDa… We currently have 871 bugs fixed out of 908 created for the last 360 days: http://jira.xwiki.org/secure/Dashboard.jspa#Created-vs-Resolved-Chart/10470 We closed 19 bugs last Thursday: http://www.xwiki.org/xwiki/bin/view/Main/Bug+Fixing+Day+9 Let's see if we can do as well tomorrow! We "just" need to fix 37 bugs to be back in the green. Please join us in the bug hunt tomorrow :) Thanks -Vincent

4 8

[xwiki-devs] [Proposal] Provide UI extension points in the current set of templates
by Jean-Vincent Drean 01 Mar '13

01 Mar '13

Hi, in 4.x we introduced UI Extensions (UIX) and "Extension Points", it allows applications to come and plug their bits of UI where it is possible [1]. 5.x is a good time to provide a list of useful Extension Points (UIXP) in our velocity templates, allowing applications to plug themselves in, for example : the header, before the content, the footer, etc. To allow this I can think of 2 strategies: == 1) Manually add UIXPs == Actions: * Discuss where are the common places where applications would like to plug (in our opinion) * Make a lengthy list * Vote it * Introduce an API call (services.uix.getExtensions()) for each item in the list * Commit it Pros: * We can carefully build the UI API Cons: * We can't think of everything * Long process * Overridden templates won't display the extensions == 2) Instrument our templating mechanism with UIXPs == Actions: * Modify the #template macro so that it create UIXPs before and after the parseTemplate call. Calling #template.vm would create the following UIXP: ** platform.template.global.before (or: platform.template.global.above, platform.template.global.top) ** platform.template.global.after (or: platform.template.global.below, platform.template.global.bottom) * Commit it Pros: * A lot of available UIXPs * We've worked on our template architecture for a long time, UIXP would benefit from that * Quick process Cons: * It'd make our current template architecture an API ... but since templates can be overridden in skins, it already is one. * A lot of API calls (but tests with YourKit shows that it doesn't impact performance) Note: 2) doesn't exclude 1), we'd probably still need to introduce UIXP within templates, but we'd have way less UIX API calls with this method. WDYT ? I guess it's quite obvious that my opinion is biased, I've started playing with 2) and it's quite cool :) [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/UIExtension+Module Thanks, JV.

4 15

[xwiki-devs] [PROPOSAL] Change default resolver to used in model ScriptService
by Thomas Mortagne 28 Feb '13

28 Feb '13

Hi devs, Right now the model script service use "currentmixed" as default resolver and it should use "current" one IMO: 1) it's behavior is not very clear for a newcomer 2) it's pretty much unusable for attachments The difference between the two resolver is that "currentmixed" resolve document name beased on default (WebHome) instead of current document. AFAIK this resolver as been introduced for retro compatibility purpose because in some old APIs like XWikiDocument contructors the document name was resolver as WebHome and not based on the current document. So I propose to change the default resolver to "current". Here is my +1. This script service is not much used yet, I doubt anybody is using it expecting to get WebHome when resolving the document name but since it's a behaviour change 5.0 is the right time for it. -- Thomas Mortagne

4 7

[xwiki-devs] [Contrib] Load Test Application
by Sorin Burjan 27 Feb '13

27 Feb '13

Hello everybody, I am building a small application to perform load test in XWiki. I have exported several spaces from xwiki.org used to generate the content, and cleaned them a little bit to suit my needs. I would like to request a repository on Contrib so I can commit the content needed for generation but also the scripts that will generate the content needed for testing. I was thinking of application-loadtest. Thanks, Sorin B.

2 3

[xwiki-devs] Flavors for xwiki.org
by Vincent Massol 26 Feb '13

26 Feb '13

Hi devs, FYI I'm starting a module in xwiki-contrib to hold the 2 xwiki.org flavors (one for the main wiki and one for the subwikis): https://github.com/xwiki-contrib/xwiki-flavor-xwikiorg I'd like to start using the EM/DW on xwiki.org during the next upgrade and for that I'll need these 2 flavors. Thanks -Vincent

1 0

[xwiki-devs] Extension Manager memory usage - too much?
by Vincent Massol 25 Feb '13

25 Feb '13

Hi devs, I've done some memory analysis with yourkit and it happens that the EM takes a lot of memory, namely: * DefaultCoreExtensionRepository takes 31MB of memory as it caches all extensions found in memory * Out of the 31MB, 29MB is used by org.apache.maven.model.Model with 373 instances (I guess that's the number of extensions we have) * Note that 15MB is taken just by Xpp3Dom objects (42814) for the goals of the plugins of the extensions * 10MB by PluginManagement The question is: are we ok with this? Should we reduce it? On a different note, PyDictionary takes 11MB of memory. Actually the total memory taken by python is much more, I've computed to be 50MB, that's quite a lot just for our code macro… Thanks -Vincent

1 0

[xwiki-devs] [Proposal] Backward compatibility strategy w/ young apis included
by Vincent Massol 25 Feb '13

25 Feb '13

Hi devs, Here's my effort to try to put together all that has been said… :) The idea is that whenever you change an API (adding a new one or changing an existing one) you go through the list of strategies below, trying to find the first that matches your use case. * Strategy 1 (already in place): Whenever possible don't break backward compatibility and go through a deprecation mechanism: ** Deprecate classes/methods ** Move them to Legacy modules as soon as our code is not using them anymore ** Note: No need to touch CLIRR * Strategy 2 (new): If possible, code defensively, i.e. put code in internal and open up when api is stable later on, either when users ask for it or when someone feels it's the right time ** Note: No need to touch CLIRR * Strategy 3 (new): If not possible (for example complete new modules where you wish to separate what will become stable APIs in the future from internal code) then use the @Unstable annotation at class level (or method level) ** Whenever we work on a new N.0 milestone 1 version, review all existing @Unstable annotation and for those that were added before N-1.0 remove the annotation ** Exclude the classes/methods marked @Unstable from CLIRR * Strategy 4: If the API is stable and the developers wants to break it (change of signature for example) and all other strategies don't apply, then either: ** (new) Just do it and modify the CLIRR exclude. Preferable (but not mandatory) send a NOTICE email to warn others devs that an API is going to be broken in the next release ** If not sure, send a PROPOSAL or VOTE email depending on how important you think the API to be broken is WDYT? Thanks -Vincent

4 7

[xwiki-devs] OutOfMemory exception when running extension tests
by Marius Dumitru Florea 25 Feb '13

25 Feb '13

I just noticed http://ci.xwiki.org/job/xwiki-enterprise-test-extension/org.xwiki.enterpris… 22:16:29.433 [main] INFO org.xwiki.test.ui.TestDebugger - ExtensionTest-testInstallScriptService started 22:19:55.911 [Thread-2] ERROR o.x.t.i.XWikiLogOutputStream - Exception in thread "qtp850442967-17" java.lang.OutOfMemoryError: PermGen space 22:20:16.643 [Thread-2] ERROR o.x.t.i.XWikiLogOutputStream - Exception in thread "qtp850442967-15" java.lang.OutOfMemoryError: PermGen space 22:20:35.600 [Thread-2] ERROR o.x.t.i.XWikiLogOutputStream - Exception in thread "Lucene Index Updater" java.lang.OutOfMemoryError: PermGen space 22:20:39.197 [Thread-2] ERROR o.x.t.i.XWikiLogOutputStream - Exception in thread "qtp850442967-18" java.lang.OutOfMemoryError: PermGen space 22:20:43.065 [Thread-2] ERROR o.x.t.i.XWikiLogOutputStream - Exception in thread "qtp850442967-642" java.lang.OutOfMemoryError: PermGen space 22:20:46.766 [Thread-2] ERROR o.x.t.i.XWikiLogOutputStream - Exception in thread "qtp850442967-12" java.lang.OutOfMemoryError: PermGen space 22:21:08.863 [main] INFO org.xwiki.test.ui.TestDebugger - ExtensionTest-testInstallScriptService failed What are the qtp threads for? Thanks, Marius

2 1

[xwiki-devs] Translation, is there any cache ?
by xrichard 23 Feb '13

23 Feb '13

Hello, I've defined custom translations for XWiki standard keys. For some the changes are reflected immediately. For other custom translations I have to wait: the new string is displayed only after "hours" (ie the next day). For instance strings for the 3 following translation keys are not changed immediately: login= logout= core.viewers.comments.add.submit= Can someone explain me why? Is there a cache somewhere? but not for all keys? regards, -- View this message in context: http://xwiki.475771.n2.nabble.com/Translation-is-there-any-cache-tp7583975.… Sent from the XWiki- Dev mailing list archive at Nabble.com.

3 2