April 2015 - xwiki-devs@xwiki.org

[xwiki-devs] Account on nexus.xwiki.org
by Raluca Stavro 22 Apr '15

22 Apr '15

Hello, Can someone please create an account for me on nexus.xwiki.org ? username : rstavro Thank you, Raluca.

2 2

[xwiki-devs] PR: Add boolean property support on livetables
by Pascal BASTIEN 21 Apr '15

21 Apr '15

Hello everyone, Someone have some time to look my tiny PR for http://jira.xwiki.org/browse/XWIKI-6118 issue?Of course to avoid new 'listboolean' option, a better way is to identify property type: if "is boolean type" but I don't know if xwiki API have a method for this. Thxs Pascal B

1 0

[xwiki-devs] [PROPOSAL] Change the webjars URL mapping
by Eduard Moraru 21 Apr '15

21 Apr '15

Hi, Currently, the webjars URL mapping is the following: http://localhost:8080/xwiki/bin/webjars/resources/path?value= <id>%2F<version>%2F<filePath> Example: $services.webjars.url('codemirror', 'lib/codemirror.js') returns http://localhost:8080/xwiki/bin/webjars/resources/path?value=codemirror%2F5… The problem with this is that require modules that use relative paths for their dependencies are broken because of the URL mapping we use, more specifically by the "?" character inside the URL we use. A concrete example is the CodeMirror webjar that defines its own modules which express their dependencies relatively: "../../lib/codemirror" Here we have a problem, since if we directly depend on "$services.webjars.url('codemirror', 'mode/css/css.js')", the module will fail to find its relatively defined dependency. One approach would be to define paths, so that requirejs can work its magic: require.config({ paths: { cm : " http://localhost:8080/xwiki/bin/webjars/resources/path?value=codemirror%2F5… " } }); require(["cm/lib/codemirror", "cm/mode/css/css"], function (CodeMirror) { console.log(CodeMirror); }); This properly finds "/lib/codemirror.js" and "mode/css/css.js" that we explicitly request, however, the internal dependency of css.js fails to be found at the resolved URL " http://localhost:8080/xwiki/bin/webjars/resources/path?value=codemirror%2F5… ". Requirejs does not add the ".js" extension to the resolved path because the resolved path contains a "?" character so it is considered an absolute URL, not a relative path. The proposal is to stop using this URL mapping, since it is awkward to have paths in parameters and, instead, use a more intuitive one that is both good for clients and for requirejs. The proposed mapping/scheme is: http://localhost:8080/xwiki/bin/webjars/<id>/<version>/<filePath> Any additional parameters that we might need for the webjars action would be appended at the end. There is currently 1 case that I know of, which is "evaluate=true|false". Without this change, I can not find any solution to using a webjar such as CodeMirror that uses relative defined modules. Thanks, Eduard P.S.: Any additional advice on using requirejs to circumvent this limitation is most than welcomed.

8 13

[xwiki-devs] Google Maps with polygons
by Niko B 19 Apr '15

19 Apr '15

Hello, I have an Xwiki server setup on Debian 7 using tomcat7 and mysql. I was wondering if there is a way to embed a google map with a polygon (a portion of the map highlighted). I have tried the regular google maps extension and it works great except for the lack of polygons. I was able to generate some javascript code for what I want. Is there a way to display javascript on the page? I have tried the d3js plugin but cant seem to figure out how to insert the code. Any help would be much appreciated. Thanks!

2 1

[xwiki-devs] [ANN] XWiki 6.4.4 released
by vincent＠massol.net 17 Apr '15

17 Apr '15

The XWiki development team is proud to announce the availability of XWiki 6.4.4. This is a bugfix release fixing issues found in XWiki 6.4.3. We recommend upgrading. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki644 Thanks -The XWiki dev team

1 0

[xwiki-devs] [Proposal] Roadmap for XWiki 7.1
by vincent＠massol.net 16 Apr '15

16 Apr '15

Hi Devs, Here are some proposals below that I have discussed with committers from XWiki SAS already. For all other committers (thinking about Denis, Sergiu, Clemens, Andreas or other), feel free to add other stuff you’d like to do in 7.1. Content ======= Large topics: - Improve upgrade tools - Improve DW - Marius - Notifications improvements - Immediate mail notif in watchlist + immediate notif in comment - Edy - Continue performance improvements - Thomas - Totem Application cleanup and release - GuillaumeD - Flavor mechanism - UI part - GuillaumeD - JS API / REST Improvements (http://design.xwiki.org/xwiki/bin/view/Proposal/ExtensibleAPIforaccessingst…) - GuillaumeD does the investigation in 7.1 and if possible starts implementation in 7.1 if enough time Specific JIRA: - Add a simulation feature to the distribution wizard - XWIKI-11502 - Marius - Extension Manager add extension search should suggest only compatible versions - XWIKI-9920 - Edy (with Thomas to help out) - Notify Wiki owners by email when users [request to] join their wiki - XWIKI-11096 - Edy - Presentation Office documents (.ppt files) aren't displayed with LibreOffice 4.3.5.2 - XWIKI-11611 - Marius - Exporting/Replaying the upgrade log - XWIKI-11504, XWIKI-11505, XWIKI-11074 - Marius - Use the new Mail Sender API for the Share Page By Mail feature - XWIKI-11786 - Vincent Investigations: - SOLR performance investigation - Thomas - Totem Design + Public Website Flavor - Caty - Bootstrap tour - Caty - Dropping support for Colibri? - Silvia/Caty - Dropping support for IE8/9? - Silvia/Caty Proposed Dates ============== - 7.1M1: 4 May - 7.1M2: 18 May - 7.1RC1: 1 June - 7.1Final: 8 June We had planned 7.1 to be in May but we’re starting late which is why we’re planning for 8th of June now. What’s important is that we succeed in keeping the cycle on 1 year, ie. finish 7.4 in December (this means 7.2 in August, 7.3 in September/October and 7.4 in November/December). Let me know if there are any concerns. Thanks -Vincent

1 1

[xwiki-devs] [Proposal] Jay Skin - Technical Documentation Skin
by Ecaterina Moraru (Valica) 13 Apr '15

13 Apr '15

Hi, I made a proposal on how a Technical Documentation Skin based on Flamingo could look like, see http://design.xwiki.org/xwiki/bin/view/Proposal/JaySkin The idea behind Flavor Skins is that they just need to satisfy one major use case, not everything XWiki can do, and when writing/reading/searching documentation the focus is on content. The proposal is not complete, since there are multiple views and applications in Documentation Flavor that I didn't had time to make mockups for them, but you get the main idea and the layout. Thanks, Caty

2 1

[xwiki-devs] [Brainstorming] Improving Developer Onboarding
by vincent＠massol.net 12 Apr '15

12 Apr '15

Hi devs, I’ve spent 3 days at Devoxx FR 2015 and I’ve seen interesting things. I have some ideas on how we could improve Developer Onboarding for XWiki. Idea 1: Eclipse Oomph ===================== This tool will allow us to ease developed onboarding a lot by providing our "flavor" of Eclipse with preinstalled list of plugins, bound Git repos, automatically checking out projects, setting our XWiki code styles and more. See https://wiki.eclipse.org/Eclipse_Installer It's going to be available in Eclipse Mars. See also this video: https://www.youtube.com/watch?v=_QlSosecEUo&list=UUej18QqbZDxuYxyERPgs2Fw Idea 2: Codenvy =============== Codenvy is an online IDE that runs in your browser and it provides not only an editor but also auto completion, syntax highlighting, debugging and a lot more. Especially it provides the ability to select project types to generate projet skeletons and ability to deploy your code. See https://codenvy.com/ Thus we can imagine writing several extensions for it that would allow any contributor to very quickly get an environment to develop an XWiki extension: * We could provide 1 or 2 project templates, one for a simple XAR module for example and one for developing some XWiki components * We could also provide a deployment target (and even a docker VM) so that once the contributor has made code changes, he can deploy them into a running XWiki directly from his browser in Codenvy and test his code. I feel that it’s perfectly well adapted to the occasional contributor use case. No environment to setup. Just a few clicks and you’re ready to patch XWiki or one of its extensions, test it and submit a pull request (note that the PR can be submitted directly from within the IDE without anything to set up on your machine! I’ve seen a demo of this in a session at Devoxx). WDYT? Thanks -Vincent

2 1

[xwiki-devs] [Proposal] Having XWiki repositories in pom for extensions
by Jean SIMARD 11 Apr '15

11 Apr '15

Hi devs, I'm kind of annoyed that to build an extension, you need to clone it (ok, every dev can do it), launch Maven (devs can do it too) and... it breaks! It breaks because the ~/.m2/settings.xml file has not been configured. Of course, ideal would be to push everything to Maven Central but as far as I know, there is a lot of work to do before being able to that for XWiki platform. However, for extensions, it's another story. We could define repositories directly into the root POM of the extension. I'm not a Maven expert, but I already tried the following who seems to work, WDYT? ----- <repositories> <repository> <id>xwiki-snapshots</id> <name>XWiki Nexus Snapshot Repository Proxy</name> <url>http://nexus.xwiki.org/nexus/content/groups/public-snapshots</url> <releases> <enabled>false</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </repository> <repository> <id>xwiki-releases</id> <name>XWiki Nexus Releases Repository Proxy</name> <url>http://nexus.xwiki.org/nexus/content/groups/public</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>xwiki-plugins-snapshots</id> <name>XWiki Nexus Plugin Snapshot Repository Proxy</name> <url>http://nexus.xwiki.org/nexus/content/groups/public-snapshots</url> <releases> <enabled>false</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> <pluginRepository> <id>xwiki-plugins-releases</id> <name>XWiki Nexus Plugin Releases Repository Proxy</name> <url>http://nexus.xwiki.org/nexus/content/groups/public</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots> </pluginRepository> </pluginRepositories> ----- -- Jean Simard jean.simard(a)xwiki.com Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org

5 8

[xwiki-devs] [Proposal] Break the XHTML validity to catch HTML5 validy
by Guillaume "Louis-Marie" Delhumeau 09 Apr '15

09 Apr '15

Hello developers. I am working on making the HTML 5 code of XWiki valid. But in some places, I cannot do it without breaking the XHTML validity (which Colibri still uses, but this skin is going to be deprecated). Example: in XHTML 1.0, the attribute target="_blank", for links, is forbidden. In XWiki, we have "fixed" this by using the attribute rel="_blank" instead, and then we have a javascript snippet that dynamically adds the target="_blank" attribute to these links [1]. So the code is valid until the javascript is loaded, which is enough to pass our validation tests. This is not very clean, since the target="_blank" was forbidden by the w3c because they think it should be the user choice to open a link in a new window or not. But nobody respects this, and that is why it is no longer forbidden in HTML5. The problem we have, is that the value "_blank" is not authorized anymore for the "rel" attribute of the links in HTML5. So I propose to remove our workaround, which is useless and prohibited for HTML5. As a consequence, we would lose the XHTML validity (which is actually the case when javascript is loaded anyway). WDYT? Guillaume [1] The code that looks for ref="_blank": https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…

5 8