Hi devs,
I'd like to make it easy in XWiki to use javascript frameworks required by extensions.
I've found the webjars project (http://webjars.org) which packages javascript frameworks in JAR files available in Maven Central.
They work out of the box if you drop them in WEB-INF/lib in a Servlet 3.0 container (like Jetty 7). It works because the 3.0 spec says that any files located in META-INF/resources/<path> will be made available by the servlet container as static resources (accessible as <path>).
However the servlet 3.0 specs doesn't support adding those JAR dynamically outside of WEB-INF/lib so it doesn't work with our extension mechanism.
Thus I'm proposing the following (which I have tested to work):
* Add a new WebJarFilter filter to web.xml
* The URL to access, for ex, angular.js packaged in the http://repo2.maven.org/maven2/org/webjars/angularjs/1.1.5-1/angularjs-1.1.5… jar would be: /xwiki/webjar/angularjs/1.1.5/angular.js
This allows for example to have a dep on:
<dependency>
<groupId>org.webjars</groupId>
<artifactId>angularjs</artifactId>
<version>1.1.5-1</version>
<scope>runtime</scope>
</dependency>
Then in a JSX object:
require(["/xwiki/webjar/angularjs/1.1.5/angular.js"], function() {
…
});
WDYT?
Thanks
-Vincent
Hi Devs,
Since we’ve found an important issue in 5.4 (see http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki54) and Denis has also fixed a security issue, I’d like to propose releasing 5.4.1 earlier than planned (it was planned for the 17th of Feb) and schedule a 5.4.2 with the leftover.
GuillaumeD has proposed to be the RM for 5.4.1.
Here’s what has been fixed so far in 5.4.1:
http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12003
There are 14 issues so far which makes it more than enough IMO.
WDYT?
Thanks
-Vincent
Hi devs,
Here is a mail to talk about what I plan to do during 6.x related to
performances. I don't have detailed plan for 6.0 yet, I still have
work to do on unfinished 5.x stuff and my priority will goes to that
but before working on it lets present what I already have in mind
about performances and gather some other ideas. I did not really made
much new reseachs yet, it's mostly things I have in mind since some
time for most of them.
First thing first: having good performance is everyone's work, don't
expect me to review everything you do and do all the thinking about
how to design each feature so that it has good performances. My main
job is do things we always puh back because we don't have time so here
it is.
= Automated speed report with history
I plan to write a build dedicated to test performances (of XE for now)
and provide stored and compared reports about it.
My plan is to combine the following tools:
* JMeter and more precisely some jmeter Maven plugin (probably
https://github.com/Ronnie76er/jmeter-maven-plugin/)
* Jenkins Performance Plugin
(https://wiki.jenkins-ci.org/display/JENKINS/Performance+Plugin) to
put a nice UI around that
And probably run that build something like once a day on master branch
for example.
The first step is to report it, second will probably be to set a
maximum timeout (that we ideally reduce over time ;)) to fail the
build when it become too slow (but that will be only after we actually
improved it).
I hope to finish this in 6.0.
= Spot worst places
I plan to do hand testing with a profiler (probably YourKit) and write
detailed reports in jira issues for the slowest parts or our code
during a request (and not only for view, save is a realy a pain
sometimes) and what seems weird so that we find solutions (or not) for
each one.
Same, I think I should have moved forward on it during 6.0 timeframe.
= Things we already know but for which I don't have yet a definitive solution
== Too much database requests
Loading a single document generate tons of requests. The document
cache hide this a little.
Maybe start include some lazy loading of objects in document or things
like this but it's hard since we don't have any real clean interface
and only XWikiDocument to work on it.
== The UI is very expensive
Loading a page with /get/ action for example is a lot quicker (often
more than 5 times quicker) than loading it with the full UI (/view/
action) even a page with lots of content including content we
generally consider very slow like code macro.
= Some ideas of refactoring or new features I already have in mind
(not specifically done by me, it's just ideas of things to look at)
== Async events
I don't think there is much related issues in view but we are doing
way too much blocking stuff when modifying a document so I plan to
allow a listener to declare that it's ok for it to receive
asynchronous events (events sent in a different thread than the one
who actually saved the document) and review the listeners that could
use that (the first one I have in mind is user cleaner but I'm also
thinking about wiki extension module which execute several requests at
each save for example and all the code responsible for parsing and
storing backlinks in modified documents).
== Activity stream UI
This is nothing new and a project of it's own, the UI of Activity
Stream is super slow and probably require a complete analysis and
rewrite by a dedicated developer.
<put other ideas here ;)>
--
Thomas Mortagne
Hi XWiki users,
We’re trying to create a user map of all XWiki users. There are 2 nice effects from this:
1) Increase the feeling of a community
2) Find out other XWiki users close to where you are. The next step will be to organize some XWiki User Group in places where there’s a cluster of xwiki users!
Please join the xwiki community by adding yourself to:
https://maps.google.com/maps/ms?msid=210331808187331529022.0004f02bd076d94d…
Thanks a lot
-Vincent Massol
Before 5.3, we used to have panel "Wiki Information" [1], by default, on
the right column of new workspaces.
In regular subwikis (not workspaces), we did not have this panel.
I propose to not have it by default on the subwiki configuration. It will
still be possible to add it manually since the panel will still be bundled
in the subwiki application.
Here is my +1.
Louis-Marie
[1] http://jira.xwiki.org/secure/attachment/27198/missing-panel.png
Hi devs.
Since 5.3, we have this issue opened:
http://jira.xwiki.org/browse/XWIKI-9726 - The default rights of subwikis
has changed.
I am not shocked by the new settings - same as in the main wiki - but it is
different from what Workspaces used to be.
What do you think about it?
Thanks,
Louis-Marie
Hi devs,
We’ve already decided on the 6.x cycle and on the 6.0 roadmap and dates.
I’d like to propose the following global schedule for the full 6.x cycle:
* 6.0: April 2014
* 6.1: June 2014
* 6.2: August 2014
* 6.3: October 2014
* 6.4: December 2014
Note that I’m implicitly proposing to change one rule defined at http://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices…
I’m proposing to have 5 release per cycle instead of 6 in order to make a cycle fit in 1 year (we did this for 5.x btw).
Also note that I’ve put slightly shorter release times for releases (between 1.5 to 2 months, except for the 1st one for which I’ve allowed 2.5 months).
WDYT?
Thanks
-Vincent
Hi devs,
FYI I’ve updated the 5.x cycle jira dashboard:
http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11607
FTR here’s the 4.x one (that I’ve updated to include latest bug fix releases):
http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11192
For 5.x:
- 988 issues so far (vs 1269 for 4.x but we still have 5.4.1 to go and possibly some 5.4.2, etc later on. But in the end it’ll be slightly less than for 4.x)
- 20 source contributors (vs 15 for the 4.x cycle)
It would be great to start an aggregated release notes of the top features of the 5.x cycle as we did in the past. Any volunteer? :)
Thanks
-Vincent