- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Vote] Move the caches files to permdir and make the launch of XWiki faster
by Guillaume "Louis-Marie" Delhumeau 16 Feb '15

16 Feb '15

Hi. Currently, XWiki is quite long to start, and this is mainly because of the LESS compiler which generates the CSS file of the skin. Fortunately, we cache the results of the compilation in the LESS cache, which is stored in the file-system (this is important). Some actions can be done to make the launch quicker: 1 - Not purge the cache at startup. The idea is to keep the cache of the previous launch of XWiki, so LESS would have nothing to compile anymore. This does not solve the first launch issue, but it is a great progress anyway. The disadvantage of this is that restarting XWiki will not solve any issue related to a bad cached file (ex: a buggy CSS file stored in the cache will still be there after a restart. The only way to fix this is to re-save the buggy LESS resource). Note that this behaviour can easily be changed by modifying a config file: http://extensions.xwiki.org/xwiki/bin/view/Extension/LESS+Module#HCacheStra… 2 - During the build of XE, run an integration test that performs a simple view request to XWiki in order to make the LESS compiler builds the CSS file and pushes it into the cache. After the integration test, we just copy the generated LESS cache file into the Jetty/HSQLDB distribution, and so when you launch XWiki from this distribution, you use the pre-generated cache. Of course it could only work for our Jetty distributions that users test locally. It will not solve the issue on production servers. But it is already good that a user have a good impression by starting XWiki quickly on her computer. I have made a proof of concept on a branch [1] and the thing is working well. The first request to XWiki is really faster. The only blocking point I have now is that the current cache directory is currently configured to be the temporary directory. Instead, I need to use a directory from the distribution (where I can put my pre-generated cache files). I have solved this locally by setting an absolute path to my "data" folder [2], but it is not clean. Thomas suggested me to configure all the caches to use the "permdir" directory, which actually is the "data" directory in the case of our jetty distributions, and so it does the job. So the vote is for the following proposal: 1 - move the cache files to permdir 2 - do not purge the LESS cache at startup (by default) 3 - add a new module that pre-generate the LESS cache file to make the first XWiki launch faster Here is my +1. Thanks, [1] https://github.com/xwiki/xwiki-enterprise/compare/feature-datalesscache [2] http://jira.xwiki.org/browse/XWIKI-10879?focusedCommentId=85369&page=com.at… -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

6 13

[xwiki-devs] [GSOC] XWiki is applying for GSoC 2015. Proposals and mentors needed!
by Eduard Moraru 16 Feb '15

16 Feb '15

Hello fellow XWiki community members, This year XWiki is planning to participate once more at Google's Summer of Code [1]. The organization registration period has already started (9th of February) and the deadline is the 20th of February: 19:00 UTC [2] (a bit more than a week from now). 1. We need to provide by then a list of proposals and assign mentors for the students that are going to implement them. I would like to ask everybody that wants to participate as a mentor from the XWiki organization to review the proposals [3] list (currently empty) and add as many interesting proposals as possible. The proposals can be either new, or they can be revived from previous years. Just navigate to the previous years [4], find the proposal you like and know about, go to its proposal page (click it) and press the "Clone to this year" link. Now you can assign yourself as lead for that project, update it's description if needed and wait for the student applications to start pouring [image: emoticon_smile] 2. We also need to submit the actual application [5] of the XWiki organization to participate to the GSoC 2015 project so I would also like to ask you to review it so that we have a better chance of being selected into the program. 3. If you feel that you would like to help on improving XWiki's GSoC guides and application forms, please find the tips for students [6] on XWiki's GSoC page, the student application form [7] and the lessons learned [8] from previous years participations. Thanks for your help, Eduard ---------- [1] http://www.google-melange.com/gsoc/homepage/google/gsoc2015 [2] http://www.google-melange.com/gsoc/events/google/gsoc2015 [3] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/#HProposedProjects28… [4] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HPreviousGSo… [5] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/OrganizationApplicat… [6] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines [7] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/student+application+… [8] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/LessonsLearned

2 3

[xwiki-devs] Documenting how to contribute XAR XWiki extensions.
by Caleb James DeLisle 16 Feb '15

16 Feb '15

Hi all, Today I worked with Mohamed to release an extension (TotemApplication) to the extension manager and he wrote an excellent tutorial for uploading a xar file so that is is accessible from the extension manager. http://www.xwiki.org/xwiki/bin/view/Drafts/ContributingExtensions I'd like to propose we move this to a more official location than /Drafts/ since at this point it's the only end-to-end tutorial on contributing XAR extensions. WDYT? Caleb -- Satire is the escape hatch from the cycle of sorrow, hatred and violence. #JeSuisCharlie

4 5

[xwiki-devs] Mail sender API doesn't work with template?
by Pascal BASTIEN 16 Feb '15

16 Feb '15

Hello, On Xwiki 6.4, it seem that new mail sender API doesn't work. I didn't manage to use exemple 3 and 4 from doc: http://extensions.xwiki.org/xwiki/bin/view/Extension/Mail+Sender+API#HExamp… I use Admin account and use this code: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki641#HIssu… I attached a Xwiki/Mail objetct to MailTemplatePage but no mail are sent and /bin/admin/XWiki/XWikiPreferences?editor=globaladmin&section=emailStatus page are empty. Example 1 and 2 are working (I fixed a typo). Pascal B.

2 4

[xwiki-devs] [myxwiki] XWiki Enterprise 6.4.1 Upgrade
by Thomas Mortagne 13 Feb '15

13 Feb '15

Hi everyone, myxwiki.org has been upgraded to XE 6.4.1. If you own a wiki hosted there you should have a look at the release notes for this version at: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ You should automatically get an upgrade wizard for your wiki when you login as admin. For more details see the upgrade guide available at : http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Upgrade#HUpgradingwikid… To be notified of the myxwiki.org server upgrade you can follow myxwiki on twitter: http://twitter.com/myxwiki Thanks, -XWiki Community

1 0

[xwiki-devs] How to check if a document is publicly readable?
by Paul Libbrecht 13 Feb '15

13 Feb '15

Hello dear fellow XWikiers, what can I do to check if a document is publicly readable? thanks in advance. Paul

3 4

[xwiki-devs] [XWiki Day] BFD#79
by Eduard Moraru 13 Feb '15

13 Feb '15

Hi devs, Today is BFD#79: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 69 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#79 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13093 Thanks and enjoy your bug fixing day! -Eduard

1 1

[xwiki-devs] Search inside page source
by walid yaich 12 Feb '15

12 Feb '15

Hi XWIKI Team, Please, is there any way to make a search inside page sources. I need to search for a word inside page sources in the Space "Main". Even by a query on the database. Thanks in advance. Best Regards, Walid YAICH

3 4

[xwiki-devs] [ANN] XWiki 6.4.1 released
by Ecaterina Moraru (Valica) 10 Feb '15

10 Feb '15

The XWiki development team is proud to announce the availability of XWiki Enterprise 6.4.1. This is a stabilization release that fixes important bugs discovered in the previous 6.4 version, while also providing an integration of the new Tree Widget with the Index Application and the WYSIWYG Editor. 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/ReleaseNotesXWiki641 Thanks -The XWiki dev team

1 0

[xwiki-devs] [Brainstorming] New Group API?
by vincent＠massol.net 10 Feb '15

10 Feb '15

Hi devs, I need to code some stuff for the new mail sender API (ability to send mails to all users of several groups) and I’ve noticed 5 issues with the current group API (XWikiGroupService): 1) It’s not implemented as components (you need to get the XWiki object and call getGroupService() to get an instance) 2) The APIs uses String to reference groups (instead of an EntityReference/DocumentReference). Note that ideally we should have a Java interface to represent a Group and a Group Reference since we could want to implement Groups differently than as wiki pages in some future (for example, by using JAAS, LDAP, etc) but this is probably for later and for now having an EntityReference/DocumentReference is probably good enough 3) The API to return all users of a group (getAllMembersNamesForGroup) return a Collection<String> and takes as input an offset and a number of users to return. This is a very DB-oriented way to scale an API but it’s not easy to use in Java when you want to get all users of a group (you need to maintain a cursor). What is useful in Java is an API that return an Iterator<DocumentReference>. 4) The getAllMembersNamesForGroup() API doesn’t seem to handle subgroups... 5) I’ve also noticed that we have **lots** of group-related APIs in a RightsManager class (which is javadoc-ed as being internal BTW but used elsewhere…), used by the RightsManagerPluginApi. I don’t see why we have users or group-related APIs in a an API related to permissions/rights (i.e. authentication)… This API suffers from another problem: even though is has a resolveUsers(String userOrGroup, XWikiContext context) method to extract users from a list of users or group references, it doesn’t scale! Indeed it doesn’t accept any offset/count parameters and it returns a Collection<DocumentReference>... Thus, I have 2 options: A) do the conversion between String <-> DocumentReference on my side (in the mail sender api) + handle subgroups in the mail sender api + maintain cursor in the mail sender code B) Start quickly a new component-based Group API which would have just the method I need for now (and would be marked unstable). For B) I‘m thinking about something like: Option 1: ========= GroupManager |_ Iterator<DocumentReference> getAllUsers() (in the future we would also have a getMatchingUsers(…)) By default the impl would retrieve batches of user references from the group (say 100 at a time) However, if you want to get just 1 user for example, this is a bit overkill to get 100 DB results. But is that a real use case? So we also have option 2: Option 2: ========== GroupManager |_ GroupResultSet getAllUsers() Where: GroupResultSet |_ Iterator<DocumentReference> iterator() - default to batch size of 100 |_ Iterator<DocumentReference> iterator(int batchSize) |_ Collection<DocumentReference> get(int nb, int offset) (do we really need this api?) I’d prefer to not use option 2 if possible but there may be use cases I don’t see right now that would require 2 and it has the nice advantage of being able to add new methods to GroupResultSet without impacting backward compatibility. Note that this discussion between option 1 and 2 is interesting more generally speaking since we would need to decide what’s our best practices in all our APIs when we require to return large collections of values. So far a lot of our old APIs use the (int nb, int offset) solution, which is versatile but not easy to use IMO and I don’t find it nice that we mix business parameters with technical ones. Last question would be where to put this new code. I can see 2 choices: i) in a new xwiki-platform-group module ii) in a new xwiki-platform-user/xwiki-platform-user-api module where we would put both APIs for both Users and Groups option ii) seems better IMO. WDYT? Thanks -Vincent

3 4