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

[xwiki-devs] How to switch off Lucene/Solr indexers.
by Karel Gardas 24 Sep '14

24 Sep '14

Hello, I'm attempting to import Wikipedia dump into XWiki using mediawiki/1.0 syntax. Since this process is quite slow and dealing with a lot of data I'm trying to strip everything I don't need now. While connecting visualvm to the xwiki JVM I've noticed that majority of both CPU and memory resource is consumed by Solr index thread and Lucene index thread. Solr leads here. To switch this off, I've switched off completely search suggestions in Home->Administer Wiki->Search Sugest and I've also switched Search system to be based on Database instead of Solr. I've restarted XWiki and to my surprise from console log I see Solr is started again and while profiling with visual vm I see again those two index threads running and consuming majority of resources. The platform is JDK 8, Solaris 11.1, XWiki 6.0.1 on top of PostgreSQL. Is there any hint how to switch those index/search engines off completely? Thanks! Karel

3 4

[xwiki-devs] [Contrib] Repository for Proposal Application
by Ecaterina Moraru (Valica) 19 Sep '14

19 Sep '14

Hi, I would like a repository on https://github.com/xwiki-contrib/ for publishing the code behind the design.xwiki.org application. It's an application intended to collect feature proposals (requirements, design mockups, implementation details, etc.). Name: application-proposal Description: Manages feature proposals from idea state to completion User: evalica Thanks, Caty

2 3

[xwiki-devs] [ANN] XWiki 6.2 released
by Eduard Moraru 18 Sep '14

18 Sep '14

The XWiki development team is proud to announce the availability of XWiki 6.2. This release is mainly focused on the Flamingo skin and it being now used by default, but also features improvements for applications such as AWM and Blog and various performance improvements. Developers can benefit from new APIs such as the new Mail Sender API and the new Blame API but also from improved APIs such as the wiki module API and JS widgets. 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/ReleaseNotesXWiki62 Thanks -The XWiki dev team

1 0

[xwiki-devs] XWikiRights storage… better now?
by Paul Libbrecht 18 Sep '14

18 Sep '14

Dear XWiki developers, again and again I see code in our Curriki (quite some of which has been written by XWiki experts) that employ LIKE hql queries to evaluate if an XWikiRights object applied to a give group or user. I has happened often that some such queries kill our production application server; in the meantime we've managed to remove them. However, there are many more and it really appears inefficient to me. Is the "new xwiki rights model" that has been talked about here and there an enhancement in this respect? (it is in XWiki 6 or so if I remember well, we are still at 3.5). Simply splitting the addresses of the xwikirights object in the DB could leverage effectively an index which these LIKE queries fail to do. thanks in advance. Paul

4 7

[xwiki-devs] A quick tiny "issue" to fix in 6.2RC1
by Pascal BASTIEN 17 Sep '14

17 Sep '14

Hello, There are a tiny "issue" to fix in default xwiki.cfg: #-# HTTP status code to sent when the authentication failed. xwiki.authentication.unauthorized_code=200 I think 401 (OR 403) is more appropriate, isn't it? wdyt? Thxs Pascal B

3 7

Re: [xwiki-devs] XWiki User/Dev meet up in France? Paris? (Follow up #2)
by vincent＠massol.net 16 Sep '14

16 Sep '14

Ok I’ve created a wiki page at http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiMeetup2014 Please make sure to add yourself if you’re interested in participating since I believe we would need at least 10-15 persons before we can consider doing it in a useful manner. Right now we’re only 6 listed… Guillaume, Fabio, Caleb, Anca, Ludovic, Jean Coury: since you live in Paris, wouldn’t you be interested? Denis (I know it’s farther for you but you could stay in Paris for some days maybe)? Thanks -Vincent On 29 Aug 2014 at 14:30:52, vincent(a)massol.net (vincent@massol.net(mailto:vincent@massol.net)) wrote: > Ok so far we have the following persons interested: > - Patrick Moens > - Josef Haimerl > - Clemens Klein-Robbenhaar > - Pascal Bastien > - myself (Vincent Massol) > > Anyone else? > > In term of format I’m thinking about one of: > > - 1/2 day Discussions/Presentations + 1.5 days of Hackathon > - 1 day of Discussions/Presentations > - 1 day of Hackathon > - 2 days of Hackathon > - 1/2 day of Discussions/Presentations > > Any other idea? > > Once we have all ideas listed, I’ll send a doodle to decide on the format + decide on the date. > > Thanks > -Vincent > > > > On 18 Jul 2014 at 21:38:14, vincent(a)massol.net (vincent@massol.net(mailto:vincent@massol.net)) wrote: > > > Hi XWiki users, > > > > I’m wondering if we’d be enough to start organizing an XWiki users/dev meetup in France. > > > > Could you let me know in reply if you’d be interested in joining if I was to organize such a meetup? > > > > If we’re enough we could imagine organizing it in September or October for example. XWiki SAS has an office located in Paris (http://www.xwiki.com/lang/en/Company/Contact) and they could host us. > > > > Note for those who’d be coming from afar, I’m sure that it would be possible to have you sleep at some XWiki SAS employee’s place in Paris or even in the office (there’s a shower and kitchen). > > > > Interesting or not? > > > > If you’re interested what would you be interested in doing/seeing during this time? We could imagine a 3-4 hours meetup or even a 1 day meetup. We could also imagine having a hackathon during the time, in this case probably 2 days would be nicer. > > > > WDYT? > > > > Thanks > > -Vincent > > > >

2 1

[xwiki-devs] [Proposal] Drop RTF export support when no office server is running
by vincent＠massol.net 15 Sep '14

15 Sep '14

Hi devs, Since our RTF export has never worked very well (because FOP doesn't support RTF export too well), I think we could decide to drop RTF export when no office server is running. Note that I’d like to propose doing this now for 6.2 final because it currently causes http://jira.xwiki.org/browse/XWIKI-11013 Another option would be to rollback the upgrade to FOP 1.1 but this means reopening http://jira.xwiki.org/browse/XWIKI-10757 which IMO is more important since PDF exports are used often and FOP 1.1 fixed a lot stuff for PDF exports. WDYT? Please reply quickly. Thanks -Vincent

10 9

[xwiki-devs] [RFC] Review of checkstyle rules.
by Caleb James DeLisle 14 Sep '14

14 Sep '14

Hi all, This is partially an extension of the previous mail thread ``Checkstyle audit audit'' where in the discussion, I formed a few thoughts about checkstyle rules which should be added and removed. Since that thread is very cluttered now, I wanted to begin a new one specifically explaining the changes which I think we should make. Comments are requested. All but the most trivial Codestyle rules all create friction which slows down work. They are however valuable because they identify likely mistakes and make it easier for others to read one's code. Still we must periodically review our rules and identify both new rules which can help us and existing rules which are more bother than they are help, either in general or in specific to the experience level of our team. Changes I would like to make: #1: Remove "duplicate strings" checkstyle rule. This rule is supposed to trap people who are hardcoding constants throughout their code instead of defining them in one place. However when writing this email, I tried to find a coherent example which is much improved by hoisting the string value up into a constant and I cannot think of a single example. False positive examples spring to mind immediately, usually log/error messages or on strings which are sure never to change (at least not before the next major refactoring). "fixing" these errors makes the code worse because one can no-longer read top to bottom, one must scroll up and down between constants and code. I think this rule is more harm than good, especially for our team's experience level. #2: Set class/method/field javadoc requirement to exempt private and package private entities. When I write code, I want to do everything the easiest way that could work. When I read code, I want every comment to be giving me important and up-to-date information. If checkstyle makes me write comments which teach programming, I'm going to be mad at checkstyle, if I try to debug your code and the important details/warnings are mixed in with a rash of CS-101 babble, I'm going to be mad at you. In either case it takes me longer to do what I set out to do. The solution of requiring javadoc only on public classes/interfaces also helps me when developing because I need to think more deeply about the interfaces which I am exposing to the world. "write javadoc here" or "this needs an @param tag" implies "hey, did you really intend to make that public API?". I think the change not only lifts the burden on the programmer but also actually helps checkstyle achieve it's goals more efficiently. #3: Add rule requiring use of 'this.' when accessing class fields and remove rule preventing variable names which shadow fields. This change makes checkstyle *more* strict but I believe the cost is reasonable and the benefit is high. Reading your code I immediately know whether you're accessing a field or a variable which tells me whether there is reason why your function might behave differently depending on the state of the object. In light of this change, there is nolonger any reason to concern ourselves with shadowing of field names since we cannot access them this way so I think the new rule should be accompanied by the removal of the shadowing rule. I'd like to hear comments on these proposed changes. Thanks, Caleb

4 11

[xwiki-devs] I'd like to add you to my professional network on LinkedIn
by Savitha Sundaramoorthi 13 Sep '14

13 Sep '14

Hi XWiki, I'd like to add you to my professional network on LinkedIn. - Savitha Accept: http://www.linkedin.com/blink?simpleRedirect=0OcPwQe3kQdPcVc38Sd3cScjARfkh9… You received an invitation to connect. LinkedIn will use your email address to make suggestions to our members in features like People You May Know. Unsubscribe here: http://www.linkedin.com/blink?simpleRedirect=pT9Lhj8BqmJFtTwMd2lPtClAfmNFom… email was intended for XWiki Developers. Learn why we included this at the following link: http://www.linkedin.com/blink?simpleRedirect=3wUdPgZp4BBr6dFt79x9DhPpnlDnSl… © 2014, LinkedIn Corporation. 2029 Stierlin Ct. Mountain View, CA 94043, USA

1 0

[xwiki-devs] New start_xwiki.sh/stop_xwiki.sh
by vincent＠massol.net 12 Sep '14

12 Sep '14

Hi devs, I’ve been working today on new versions of start_xwiki.sh/stop_xwiki.sh. I’ve modified them to check if xwiki is already running with an option to stop/kill any already running xwiki instance. The rationale is that we need this in our CI for our functional tests in case XE instances are not stopped (for ex if jenkins master is stopped or if the ci machine is restarted, leaving agents in a bad state). start_xwiki.sh: https://gist.github.com/vmassol/2cf7952d71521d626313 stop_xwiki.sh: https://gist.github.com/vmassol/7a99f790445094f06ba4 Note that I’ve introduced a different way to pass parameters to start_xwiki.sh (ex: start_xwiki.sh -p 8080 -sp 8079) Left to do: - use bash also for stop_xwiki.sh - modify stop_xwiki.sh to use the same way to pass parameters than start_xwiki.sh - modify *_xwiki_debug.sh too WDYT? Thanks -Vincent

2 2