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
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.
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
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.
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
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
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
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
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.