xwiki-devs September 2014

xwiki-devs@xwiki.org

26 participants
68 discussions

[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, 3 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, 3 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, 3 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, 3 months

[xwiki-devs] [XWiki Day] BFD #63

by Eduard Moraru

Hi devs, Since we`ve skipped the last one, I propose we do a BFD (BFD#63) today: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays As noticed recently, on the 1 year status, we’re behind by 48 bugs, see: http://jira.xwiki .org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-Resolved-Chart/10470 This number is steadily growing and we need to get it into control! (it is even starting to affect a bit the 1600 days status) Here's the BFD#63 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12595 Thanks and happy bug fixing! -Eduard

10 years, 3 months

[xwiki-devs] Checkstyle audit audit

by Caleb James DeLisle

Hi, I just finished rewriting my WebSocket extension using Netty and it now supports SSL. \:D/ To test my work before re-releasing I decided to enable checkstyle and see what issues it pointed out which were important for me to fix. It listed 78 checkstyle errors, many of them are very important and helpful to me, others are second guessing my ability to write clear code or even pedantically pointing out issues of little or no importance. While I was sifting through them, I thought I'd write a little review of our checkstyle rules as seen from my eyes. /src/main/java/org.xwiki.contrib.websocket/WebSocketHandler.java:20:9: Package declaration does not match directory 'org/xwiki/contrib/websocket'. This is possibly good because it will catch errors, in my case it stopped me because I used one directory called org.xwiki.contrib.websocket as opposed to nested org/xwiki/contrib/websocket directories. Perhaps either form should be allowed but it's still useful because it will trap accidental moving of classes from a different directory. Why can't javac infer package from directory?! :) /src/main/java/org.xwiki.contrib.websocket/WebSocketHandler.java:24: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/WebSocketHandler.java:27:5: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/WebSocketHandler.java:27:5: Redundant 'public' modifier. This is a non-internal interface so it's valid that there should be *some* javadoc. /src/main/java/org.xwiki.contrib.websocket/internal/EchoWebSocketHandler.java:41: Line matches the illegal pattern 'System\.(out|err)\.'. Thank you, I forgot all about that one :) /src/main/java/org.xwiki.contrib.websocket/internal/DefaultWebSocketConfig.java:26: Missing a Javadoc comment. Missing javadoc on a class... whose behavior is very obvious. I'm not here to teach programming. /src/main/java/org.xwiki.contrib.websocket/internal/WebSocketConfig.java:24: Missing a Javadoc comment. Documentation on an interface, same as above. /src/main/java/org.xwiki.contrib.websocket/internal/WebSocketConfig.java:28: Expected an @return tag. /src/main/java/org.xwiki.contrib.websocket/internal/WebSocketConfig.java:34: Expected an @return tag. /src/main/java/org.xwiki.contrib.websocket/internal/WebSocketConfig.java:37: Expected an @return tag. /src/main/java/org.xwiki.contrib.websocket/internal/WebSocketConfig.java:40: Expected an @return tag. /src/main/java/org.xwiki.contrib.websocket/internal/WebSocketConfig.java:52: Expected an @return tag. /src/main/java/org.xwiki.contrib.websocket/internal/WebSocketConfig.java:55: Expected an @return tag. I actually wrote javadoc on all of these, without even being prodded to do so. Do you think my freeform documentation is less useful to a reader than it would be if it contained a @return tag? /src/main/java/org.xwiki.contrib.websocket/internal/XWikiWebSocketScriptService.java:35:1: Redundant import from the same package - org.xwiki.contrib.websocket.internal.WebSocketService. Thankyou! This is very helpful, fixed. /src/main/java/org.xwiki.contrib.websocket/internal/XWikiWebSocketScriptService.java:45: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/internal/XWikiWebSocketScriptService.java:50:5: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/internal/XWikiWebSocketScriptService.java:100:5: Missing a Javadoc comment. Do you really think that a 3 line function called getUser() needs a javadoc comment? I can guarantee you that the competition are not going to slow down and smell the flowers. /src/main/java/org.xwiki.contrib.websocket/internal/XWikiWebSocketScriptService.java:121:79: The String "/" appears 4 times in the file. And it might appear 400 times, defining a static final string called URL_SEPERATOR is exercise for my fingers and your eyeballs, nothing more. If I really wanted to obfuscate my code, I could use an external library to make you go hunting for the value of YouWillNeverFindMe.SEPERATOR /src/main/java/org.xwiki.contrib.websocket/internal/XWikiWebSocketScriptService.java:136:16: 'catch' is not followed by whitespace. Thanks, fixed. /src/main/java/org.xwiki.contrib.websocket/internal/WebSocketService.java:25: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/internal/WebSocketService.java:28:5: Missing a Javadoc comment. It's inside of an /internal/ directory, if you can't infer it's meaning then either you can't read or I can't code. /src/main/java/org.xwiki.contrib.websocket/internal/WebSocketService.java:28:5: Redundant 'public' modifier. fixed /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocket.java:33: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocket.java:58:5: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocket.java:59:5: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocket.java:60:5: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocket.java:62:5: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocket.java:67:5: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocket.java:69:5: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocket.java:70:5: Missing a Javadoc comment. It's internal and this module is small, if a reasonable programmer needs this granularity to understand this module, it should be rewritten from scratch. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:24:8: Unused import - java.io.StringWriter. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:29:8: Unused import - javax.inject.Provider. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:31:8: Unused import - java.io.IOException. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:34:8: Unused import - org.apache.commons.io.IOUtils. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:44:1: Duplicate import to line 36 - org.apache.commons.lang3.exception.ExceptionUtils. This is what I'm here for, these are one of the most valuable pieces of feedback. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:85: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:115:5: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:118:40: The String "SSL enabled with websocket.ssl.certChainFile set " appears 2 times in the file. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:118:92: '+' should be on a new line. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:122:92: '+' should be on a new line. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:132:94: '+' should be on a new line. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:133:92: '+' should be on a new line. It's arguably better to put it on the line before because some languages (python) infer semicolons and will fail to parse if it's on the line after. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:138:5: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:176:5: Missing a Javadoc comment. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:235:9: Executable statement count is 37 (max allowed is 30). Statements per function is almost useless as a measure of code complexity. I claim negative usefulness because it is misleading. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:246:58: The String "?k=" appears 2 times in the file. And you don't need to look anything up to understand that line of code, any change would be for the worse. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:246:64: '+' is not preceded with whitespace. /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:246:65: '+' is not followed by whitespace. Ok /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:267: method call child at indentation level 23 not at correct indentation, 24 Ok /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:278:41: Empty catch block. Ok /src/main/java/org.xwiki.contrib.websocket/internal/NettyWebSocketService.java:300:38: 'nws' hides a field. I always use 'this.' prefix when accessing object fields, I would prefer that as a rule but in the absence of that rule, this one is fairly important. /src/main/java/org.xwiki.contrib.websocket/WebSocket.java:27: Type Javadoc comment is missing an @version tag. My name is not git, I just am one. Thanks, Caleb

10 years, 3 months

[xwiki-devs] XWiki 6.2 Release Candidate 1 released

by Eduard Moraru

The XWiki development team is proud to announce the availability of XWiki 6.2 Release Candidate 1. This is a Release Candidate and, as such, it focuses on stabilization, bugfixes (35) and performance improvements. Make sure to try it out and report any problems that may affect the upcoming final release. 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/ReleaseNotesXWiki62RC1 Thanks -The XWiki dev team

10 years, 3 months

[xwiki-devs] [VOTE] Start supporting IE10 and IE11

by Andreea Popescu

Hello all, Following the "Start supporting IE10 and IE11" thread I’d like to propose to vote if we will support IE10 and IE11. The most important reasons for supporting these versions are: - Internet Explorer 8 and Internet Explorer 9 are still widely used by users, but many of them are currently choosing to update to IE10 and IE11. - according to netmarketshare.com (Browsers -> Desktop Share by Version) from a total of 100%, IE10 is used by 6.85% users and IE11 by 16.61% users. It’s true that IE10 is not as popular as the older versions (IE8 - 20.85% and IE9 - 8.89%), but its usage percentage is still significant. Here’s my +1. Andreea

10 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2014