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