xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] How to switch off Lucene/Solr indexers.

by Karel Gardas

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

10 years, 3 months

[xwiki-devs] [Contrib] Repository for Proposal Application

by Ecaterina Moraru (Valica)

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

10 years, 3 months

[xwiki-devs] [ANN] XWiki 6.2 released

by Eduard Moraru

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

10 years, 3 months

[xwiki-devs] XWikiRights storage… better now?

by Paul Libbrecht

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

10 years, 3 months

[xwiki-devs] A quick tiny "issue" to fix in 6.2RC1

by Pascal BASTIEN

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

10 years, 3 months

Re: [xwiki-devs] XWiki User/Dev meet up in France? Paris? (Follow up #2)

by vincent＠massol.net

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 > > > >

10 years, 3 months

[xwiki-devs] [Proposal] Drop RTF export support when no office server is running

by vincent＠massol.net

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 years, 4 months

[xwiki-devs] [RFC] Review of checkstyle rules.

by Caleb James DeLisle

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

10 years, 4 months

[xwiki-devs] I'd like to add you to my professional network on LinkedIn

by Savitha Sundaramoorthi

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

10 years, 4 months

[xwiki-devs] New start_xwiki.sh/stop_xwiki.sh

by vincent＠massol.net

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

10 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs