June 2013 - xwiki-devs@xwiki.org

[xwiki-devs] [GSOC: mobile client] Welcome to Buddhiprabha Erabadda
by Ludovic Dubost 20 Jul '13

20 Jul '13

Hi all, I'd like to welcome Buddhiprabha Erabadda to our community on the GSOC Mobile Client project, which I will mentor. Buddhiprabha Erabadda is our only GSOC student this year as we were not enough satisfied with the quality of the other proposals. No pressure Buddhiprabha. The objective of Buddhiprabha will be to help me getting the best possible XWiki Mobile out the door on Android and iOS, with particularly notifications implemented. We will also work with Caty on her proposals for the mobile app: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MobileApp We will also add improvements to the XWiki REST Api during the project especially to improve performance. There is already a pull request to get more page data in one request ( https://github.com/xwiki/xwiki-platform/pull/111 ) We have a jira project to track tasks: http://jira.xwiki.org/browse/XMMORPHO Welcome Buddhiprabha to XWiki Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

7 11

[xwiki-devs] API breakage in PropertyClass API during XWiki 4.3M2
by Denis Gervalle 04 Jul '13

04 Jul '13

Hi Devs, Passing CLIRR is far from sufficient to stay backward compatible or document incompatible changes ! I know that you know that already, but I want you to remind it once more because while I was on the road showcasing a site, I had to discover that a major feature of the site got broken, and it was silently true for a while apparently. I missed some potential leads, which get me really upset, so I waited a while before writing. The cause was a very simple incompatible change introduced in 4.3M2 ! But tracking it down was not easy since this API breakage was not reported in the RN. Here it is: com.xpn.xwiki.objects.classes.PropertyClass#getClassType is no more reporting the full classname of the type, but now drop the "Class" suffix. So, "com.xpn.xwiki.objects.classes.StringClass" become "String", "com.xpn.xwiki.objects.classes.NumberClass" become "Number"... and so on. The unprivileged API com.xpn.xwiki.api.PropertyClass#getClassType() was also impacted since "StringClass" become "String", "NumberClass" become "Number" and so on. The javadoc of the latter function get updated, meaning that we were really conscious a breakage was done here. Even more conscious, the following was applied in the toXML() method: String classType = getClassType(); if (this.getClass().getSimpleName().equals(classType + "Class")) { // Keep exporting the full Java class name for old/default property types to avoid breaking the XAR format // (to allow XClasses created with the current version of XWiki to be imported in an older version). classType = this.getClass().getName(); } The com.xpn.xwiki.objects.meta.MetaClass was also, since it was using those name as property names. Some compatibility change was applied as well, with explicit comments. But apparently, no one notice (including myself !), and this incompatible change goes through without even a mention in the RN, nor in the the jira issue (XWIKI-8355). So guys, I have no intend to blame anyone here, but I couldn't warn you more about potential consequence of incompatible changes. These need to be discuss, or at least clearly mentioned in the RN. Do not rely on CLIRR for doing the job, it don't. Probably adding a mention about those changes in the RN of 4.3 is better now than never, Marius, could you take care of it ? Thanks for your attention, -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

3 3

[xwiki-devs] [Idea] XWiki Project Development Flavor
by Vincent Massol 04 Jul '13

04 Jul '13

Hi devs, I've noticed Apache BloodHound (https://issues.apache.org/bloodhound/) and this reminded of this idea I've had several times in the past: Creating a Project Development Flavor of XE. I mentioned it in some other email already but I wanted to see if this excites you as much as it does for me and maybe we could brainstorm in this thread about what it could be like . Some scattered thoughts: * First, from the point of view of the XWiki project I believe it could be a game changer if we did it right since it has the potential of being adopted by projects around the world and thus making them discover xwiki as a result. And since they're developers they would be able to take advantage of XWiki's development features and contribute back to the project through extensions for example. * Ideally it would be awesome that this project be started independently of the XWiki project I think and just use XWiki as the platform since it's a full fledged project with a different goal than the XWiki project itself. * We need to finish the Flavor idea by allowing the DM to list flavors. * Some ideas of content for this Development Project flavor: ** A home page dashboard about metrics of your project. These metrics would be retried from external sources. Examples: *** Statistics about commits using Git/GitHub *** Latest emails (taken from mailman or other mailing list software, possibly by subscribing the project to a mailing list so that it gets the emails) *** Latest issues (taken from JIRA for example) *** Screenshot example: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2#… ** A Release application to help perform releases ** A forum application, for example the Mail Archive Application done by Jeremie which would need to be improved to add ability to post from it ** A Release notes application ** The Blog application ** Ability to generate a whole PDF for the project's documentation for a given version ** A modern and nice skin (either Lyrebird or the new Skin proposal: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x) ** A layout configured for the flavor ** Future: a simple issue tracker (or integrate one) for those who want an all-in-one solution. However keep the external issue tracker possibility for those already having an issue tracker ** Some predefined templates for creating well known project pages: source repository, build, hall in fame, project documentation home page, etc ** The IRC Bot application ** Bundle the JIRA macro ** Bundle the FAQ application ** A Roadmap application * Of course we should use this flavor on xwiki.org itself. And we could move some of the modules we currently have in platform and that would make more sense there (jira macro, IRC Bot application, FAQ application, etc). WDYT? Add your ideas to this email thread or, better, on http://dev.xwiki.org/xwiki/bin/view/Design/DevelopmentFlavor Thanks -Vincent

8 16

[xwiki-devs] [Feedback] Activity Stream
by Ecaterina Moraru (Valica) 02 Jul '13

02 Jul '13

Hi, We introduced the Activity Stream macro in XE 2.6 http://extensions.xwiki.org/xwiki/bin/view/Extension/Activity+Macro We are investigating ways to improve our Activity Stream, but in order to do that we would want to know your feedback about it (both from a technology and an user experience pov): - Is Activity Stream a macro you use? - What features you most miss about it? Maybe filtering? Maybe pagination? - Would you like to see more event types, like events generated by applications? - Are you using the "Send Message" functionality? - Other opinions about it. Your feedback will help us improve the macro by adding needed functionality and not breaking used one. I'll gather ideas on http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamFeed… Thanks, Caty

2 4

[xwiki-devs] [PROPOSAL] Add support for the reference locale in XWiki#getDocument/exist
by Thomas Mortagne 02 Jul '13

02 Jul '13

Hi devs, While working on XWIKI-9200 (which is done expect for that little question ;)) I found that there is no API to check if a document exist in specific language. You have to do a custom query. Since I would like to make my code as readable as possible and considering that we will have to do it eventually anyway here it is: two choices: 1) add support for reference locale in XWiki#exist and XWiki#getDocument as well as XWikiHibernateStore#exists. Both XWikiHibernateStore#loadXWikiDoc and XWikiCacheStore are already taking into account the locale since they are based on the id (so this would also be about consistency) 2) introduce new methods like XWiki#existsWithLocale, XWiki#getDocumentWithLocale and XWikiStoreInterface#existsWithLocale (and the corresponding implementations) WDYT ? 2) is obviously the safest but I can't find method names I like. I would be OK with 1) if everyone is strongly for it but it's probably a bit dangerous so my vote goes to 2) for now. -- Thomas Mortagne

2 3

[xwiki-devs] [Proposal] Get SonarQube installed on xwiki.org?
by Vincent Massol 28 Jun '13

28 Jun '13

Hi devs, I'd like to propose that have our own instance on xwiki.org. Namely on sonar.xwiki.org with an alias of qa.xwiki.org pointing to it. The Sonar guys were kind enough to add XWiki to nemo (http://nemo.sonarsource.org/dashboard/index/XWIKI) but it has some shortcomings for us: * We don't control the configuration (and plugins) * It fails to build XWiki regularly * It's not synced with our CI builds I could ask XWiki SAS (http://xwiki.com) if they would be ok to kindly contribute some new VM/server for the xwiki.org project for that. WDYT? Thanks -Vincent

4 4

[xwiki-devs] [ANN] XWiki 5.1 Release Candidate 1 Released
by Marius Dumitru Florea 28 Jun '13

28 Jun '13

The XWiki development team is proud to announce the availability of XWiki 5.1 Release Candidate 1. This is mostly a stabilization release leading to XWiki 5.1 and it brings Sorl search improvements and bug fixes as we plan to make Solr the default search engine in 5.1 final. There is also a new Menu Application in platform (not bundled by default) to help you create navigation menus. 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/ReleaseNotesXWiki51RC1 Thanks -The XWiki dev team

1 0

[xwiki-devs] [Reminder] BFD#27
by Vincent Massol 28 Jun '13

28 Jun '13

Hi everyone, Today is BFD27. Our goal is still to have more bugs closed than created for the past 1300 days! http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 As of now we're 49 bugs behind! Let's make a dent today :) Here's the BFD#27 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11601 Thanks Marius

1 1

[xwiki-devs] Fast build times in Java: "down from 45 mins to 3+ minutes"
by Caleb James DeLisle 28 Jun '13

28 Jun '13

This is amusing: http://dan.bodar.com/2012/02/28/crazy-fast-build-times-or-when-10-seconds-s… Interesting stats: cjdns - 40k LoC* - clean build in 40 seconds - 1k LoC/sec xwiki - 800k LoC* - clean build in 60 minutes(?) - 222 LoC/sec Cjdns build is still embarrassingly slow because cmake invokes the linker far more often than necessary. * LoC is the total line count for every source file in the project.

2 2

[xwiki-devs] [Proposal] API breakage or changing a behaviour ? (Inclusion of groups in groups)
by Guillaume "Louis-Marie" Delhumeau 27 Jun '13

27 Jun '13

Hi devs ! In order to fix http://jira.xwiki.org/browse/XWIKI-2900, I have some proposals to you. The problem is : the Inclusion of groups in groups aren't taken into account when querying user memberships. Let suppose we have the following use case: User 1 inside the Goup A Group A inside the Group B The actual behaviour of XwikiGroupService# getAllGroupsNamesForMember() when calling it with "User 1" as input, is to return "Group A" only. Because, only "Group A" has actually a member called "User 1". We might want to keep this behaviour, because we may need to have only the declared members of that group. But we can modify this method to also returns the members of the subgroups, by changing XwikiGroupService#getAllGroupsNamesForMember(), which returns the groups of a member. Other solution, adding a new method: boolean isMemberInGroup(DocumentReference memberReference, DocumentReference groupReference) which only check if the user (or the group) given on the input is a member of the group or not. But it's an API breakage. So my proposal is: 1/ Changing the behaviour of XWikiGroupService#getAllGroupsNamesForMember(), XWikiGroupService#getAllGroupsReferencesForMember(), XWikiGroupService#getAllMembersNamesForGroup(), XWikiGroupService#getAllMatchedMembersNamesForGroup(), XWikiGroupService#countAllGroupsNamesForMember() and XWikiGroupService#countAllMembersNamesForGroup() or 2/ Adding isMemberInGroup(DocumentReference memberReference, DocumentReference groupReference, XWikiContext context) in XWikiGroupService, which is an API breakage, and my Pull Request : https://github.com/xwiki/xwiki-platform/pull/117/ or 3/ Only change XWikiUser#isUserInGroup() and do the recursive stuff there. Thanks for your help! Louis-Marie

5 9