February 2014 - xwiki-devs@xwiki.org

[xwiki-devs] [XWiki Day] Deprecation Fixing Day #2
by vincent＠massol.net 21 Feb '14

21 Feb '14

Hi devs, Today is an exciting day, we’re starting something new for the 6.x cycle. Note that we had a first deprecation fixing day in the past: http://www.xwiki.org/xwiki/bin/view/Blog/DeprecationFixingDay1 Also note that we were at 1681 deprecation calls after that first DFD and as of now we are at the following numbers (see http://t.co/lKsIKcqqlX) * platform: 2015 * commons: 39 * rendering: 3 TOTAL: 2057 So this means that since April 2012 we’ve increased deprecated calls by 376. That’s what we need to fight! :) The rules are: * Goal #1: reduce to the maximum the number of deprecated calls. * Goal #2: move the maximum of deprecated apis into legacy modules. * When you fix deprecation or move some API to legacy, edit this blog post to add your score: http://www.xwiki.org/xwiki/bin/view/Blog/Deprecation+Fixing+Day+2 Have a good XWiki Day! :) Thanks -Vincent

3 16

[xwiki-devs] App dev best practice - Update
by vincent＠massol.net 20 Feb '14

20 Feb '14

Hi guys FYI I’ve added a rule to http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… “ Put an XClass definition in a document by itself and refrain from having both the XClass and an XObject using it in the page. It's makes for better separation of concern but also helps for upgrades and solves some dark magic issue (a.k.a bug emoticon_smile) with XWiki import which could import the XObject before the XClass and cause some havoc… “ Let me know if you don’t agree. Also feel free to edit to improve the reasoning ;) Thanks -Vincent

1 0

[xwiki-devs] [Proposal] Java logging best practices additions
by vincent＠massol.net 19 Feb '14

19 Feb '14

Hi devs, On http://dev.xwiki.org/xwiki/bin/view/Community/JavaCodeStyle#HLoggingBestPra… we have some best practices defined for logging. I’d like to propose some additions. Best practices: * Use SLF4J * If you’re in a component get the logger injected using @Inject private Logger logger otherwise use: private static final Logger LOGGER = LoggerFactory.getLogger(My.class); * Use logger.info() when it’s absolutely necessary for the user to see the message in the logs. Usually only used at startup and we want to limit what the user sees to the absolute necessary to avoid swamping him. * Use logger.warning() when an error happens but it doesn’t compromise the stability and general working of an XWiki instance. A warning just shows the user that something has gone wrong and it should provide him with as much information as possible to solve the issue. Do not print a stack trace when you output a warning since stack traces fill the logs and should be reserved for errors. In the view of users stack traces are synonymous with errors. We want it to be easy for admins to visually check the log files and see important problems (ie errors). * Use logger.error() when there’s an important problem that compromises the stability of the XWiki instance or that prevent an important system from working and that should not have happened. Always pass a stack trace when logging errors since it’s something that shouldn’t have happened an a developer will need to debug the problem to fix it. * Always log as much information as possible to make it easier to understand what’s going on. * Surround parameters with “[]” in order to separate visually the text from the parameters and also clearly notice when leading/trailing spaces are located in parameters. * For improved performances, always use the vararg signature of SLF4J for logging parameters and do not concatenate them manually: this.logger.debug("Test message with [{}] and [{}]", param1, param2); vs this.logger.debug("Test message with [“ + param1 + "] and [“ + param2 + “]", param1, param2); * When logging a warning, we don’t want to log the full stack trace but it’s still interesting from time to time to display the root issue. If you do the following you won’t get the root issue: LOGGER.warn("Failed to determine if the index exists: [{}]. Trying to recreate the index..”, e.getMessage()); Instead use ExceptionUtils from commons lang: LOGGER.warn("Failed to determine if the index exists: [{}]. Trying to recreate the index..”, ExceptionUtils.getRootCauseMessage(e)); WDYT? Thanks -Vincent

6 8

[xwiki-devs] [Proposal] XWiki 6.0 + 5.4.1 roadmaps
by vincent＠massol.net 18 Feb '14

18 Feb '14

Hi devs, XWiki 6.0 ======== As usual here’s a proposal resulting from discussions I’ve had with XWiki committers who work at XWiki SAS for 6.0. * Collaborative Applications (Meeting, Calendar, (new) Forum, Tasks, Doodle, Photo) - Caty to work on usability and design (she’s started already at http://design.xwiki.org if you wish to follow the work). Andrea who’s a contributor is helping on the test + implementation part. There might be another contributor joining too. This work is currently done inside xwiki-contrib. * New skin! Caty for the design and Guillaume Delhumeau for the implementation part. We’ve been dreaming about this skin for a while. Caty has whet our appetite with screenshots from Junco (http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin and http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin) and from Flamingo (http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x) The idea is to establish new strong foundations for new skins (like standardizing on bootstrap classes for example) + have a new L&F. Caty and Guillaume will make proposals on the list about this. * At last we agreed to work on identifying performances issues (especially page load times) and work to fix them! Thomas is in charge of leading this extra important domain. One idea is to establish some automated tests to measure current performances and get a baseline so that we can then monitor our progress and start fixing things (and ensure we keep getting better all the time in the future). Thomas will send some proposals on the list too on this to let us know how he plans to tackle performance improvements. * Of course we need to keep some time to fix any remaining issues we get on the major feature we developed in 5.x + some improvements. I’m thinking about our SOLR search, Multiwiki integration, EM/DW, scalable import/export, etc. Thomas needs to finish the scalable import feature which is already well under way (see below). * Marius agreed to lead an investigation on CKEditor to see if it would make sense for us to use it as a replacement of our homemade editor. The general issue is that maintaining a WYSIWYG editor takes time and this is not really our core business at xwiki. We have 2 choices basically: have someone constantly working on improving our WYSIWYG editor or integrate an existing one so that we can benefit from the work of others. In the past few years we haven’t added that many features to our editor so it’s time to evaluate the feasibility and cost of using an external editor such as CKEditor. * The way users develop applications in XWiki hasn’t changed much over the past 10 years. Since then there’s been an explosion in the area of JS frameworks. We want to make it super easy to develop modern applications using XWiki (read ajaxy applications with new dev models). Marius agreed to lead this investigation along with the help of Guillaume Delhumeau. Since it’s an important aspect of XWiki and a complex one, they’ll need to drive various discussions and brainstorming with everyone and make some proposals so that we all agree to the directions we wish to go towards and so that we can start implementing it in 6.1. * Denis is going to continue working on Script signing as way to replace the existing Programming Rights which has shown its limitations. Denis has committed a new Crypto API in 5.x which is a strong base for the script signing implementation. In addition, during those discussions some raised a list of JIRA they consider important and that would be interesting to tackle if we get the time: - Support 2 roles for users for app within minutes: application creator and data creator - XWIKI-8757 - xwiki.cfg & xwiki.properties merging - Add default column and sort choices in AppWithinMinutes livetable setting - XWIKI-9659 - Save & view a section should go to the section anchor instead of the top of the document - XE-1335 - Add a message for the Livetable's empty state - XWIKI-7821 - "Space Templates" should also create the space preferences page - XWIKI-9712 - The Wiki UIExtensions should check the rights before executing extension points - XWIKI-9156 - Add an explanation next to the fields in user profile - XWIKI-6307 - When creating a new sub-wiki, pages are listed with guest - XWIKI-9888 - Cannot remove all panels using the Panel Wizard for space preferences - XWIKI-9891 Please comment if anyone sees a concern or if I have forgotten something! XWiki 5.4.1 ========= In addition we identified the need for a 5.4.1 release to: - finish important issues for the 5.x cycle and any leftover from 5.4. Our idea is to have usable and stable implementation for the bug items we worked on in 5.x: SOLR search, multiwiki integration, EM/DW and scalable export (scalable import has been pushed to 6.0 since we considered it too dangerous to plug by default in the default import UI in 5.x). - implement support for IE11 (there are only a few issues open). Marius agreed to work on the IE11 fixes. The reason we wish to implement this support is because we’re seeing more and more users reporting issues and asking for this support. ATM we support IE till IE9 only. IE10&11 are currently not officially supported at http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy It would be nice that after 5.4.1 we could edit this doc and mark them supported! Dates ===== I’m proposing the date of 17 of Feb for the final release of 5.4.1, assuming 5.4 is released on the 3rd of Feb as currently planned (i.e. 2 weeks after the release of 5.4). For 6.0: - 5.0M1: 10th of March 2014 (ie 3 weeks) - 5.0M2: 31st of March 2014 (ie 3 weeks) - 5.0RC1: 14th of April 2014 (ie 2 weeks) - 5.0Final: 28th of April 2014 (ie 2 weeks) TOTAL: 10 weeks, ie 2.5 months. WDYT? Thanks -Vincent

6 12

[xwiki-devs] XWiki download form feedback - Updated Feb 2014
by vincent＠massol.net 18 Feb '14

18 Feb '14

Hi devs, FYI when someone downloads XWiki from xwiki.org he/she has the option to fill a download form. I’ve created http://www.xwiki.org/xwiki/bin/view/Main/DownloadFormFeedback some time back to share the results of this form. I’ve just updated it for the last few months’ feedback. Make sure to read it since it’s very interesting and shows us areas where we need to improve. Thanks! -Vincent

1 0

[xwiki-devs] [Proposal] XWiki Day for 20 Feb 2014: Deprecation Fixing Day
by vincent＠massol.net 15 Feb '14

15 Feb '14

Hi devs, I’d like to propose a Deprecation Fixing Day for the next XWiki Day, ie for the 20 Feb 2014. The rules I propose: * On that day, I send the reminder email with inside the # of deprecated calls found in Commons, Rendering and Platform. For example right now it’s: - Commons: 39 (http://sonar.xwiki.org/drilldown/issues/1?&rule=squid%3ACallToDeprecatedMet…) - Rendering: 3 (http://sonar.xwiki.org/drilldown/issues/915?&rule=squid%3ACallToDeprecatedM…) - Platform: (still being computed, I don’t have a link to give ATM ;)) * One goal is to replace calls to deprecated methods by new API calls * Another goal is to move deprecated methods and types to legacy modules * On that day, I'll prepare a Blog post on xwiki.org (not published) and everyone who participates to this day should edit the blog post with his score for the day (since it’s hard to compute automatically). There’ll be 2 scores for everyone: a score for removed deprecated calls (1 point per removal) and a score for types and methods moved to legacy modules (1 point per type and method moved). WDYT? Note that in the future I’d like to expand this to a more generic Violation Fixing Day which would be about fixing any type of violations as reported by Sonar but before we do this we need to decide which violations we consider important and configuration Sonar properly for that. I’ll try to propose something on this soon. Thanks -Vincent

4 6

[xwiki-devs] [GSOC] XWiki is applying for GSoC 2014. Proposals and mentors needed ASAP!
by Ecaterina Moraru (Valica) 14 Feb '14

14 Feb '14

Hello fellow XWiki community members, This year XWiki is planning to participate once more at Google's Summer of Code [1]. I know this is very short termed, but the organization registration period has already started (3 Feb) and the deadline is tomorrow (14 Feb 19:00 UTC). 1. We need to provide 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 and add as many interesting proposals as possible. The proposals can be either new, or they can be revived from previous year proposals. 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 should 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 2014 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 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, Caty [1] http://www.google-melange.com/gsoc/homepage/google/gsoc2014 [2] http://www.google-melange.com/gsoc/events/google/gsoc2014 [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 1

[xwiki-devs] [Reminder] BFD#55
by vincent＠massol.net 14 Feb '14

14 Feb '14

Hi devs, Today is Bug Fixing Day #55 and our last BFD for 5.x cycle according to http://markmail.org/message/avl4tl5xuefe7s7w We’ll need to decide what we do for next week. I’ll send another email about that. We're currently at -23 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#55 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12090 Happy BFD! -Vincent

1 1

[xwiki-devs] [Investigation] Investigating using TeamCity
by vincent＠massol.net 14 Feb '14

14 Feb '14

Hi guys, Since we’ve been having stability issues with Jenkins for some time now, I’d like to investigate using TC for XWiki’s CI. I’m playing with it locally ATM and it’s very nice. My proposal would be: * Set up one instance at http://teamcity.xwiki.org * Keep both jenkins and TC running in // for a few months and learn how to use TC and verify it matches our needs * Take a decision after a few months on which one we wish to use Note that I’ve already noticed a lot of nice things that we would get with TC that we don’t have with Jenkins currently: * personal builds (and direct integration in intellij IDEA for those using it) * notion of investigations * job templates WDYT? Any other CI you think would be better than TC? Thanks -Vincent

3 3

[xwiki-devs] [Contrib] Create a repository for the Newsletter Application
by Manuel Smeria 13 Feb '14

13 Feb '14

Hello devs, I would like a repository for the Newsletter Application on https://github.com/xwiki-contrib. The application is available on the extensions wiki here: http://extensions.xwiki.org/xwiki/bin/view/Extension/Newsletter+Application… version 1.0.1. Thanks, Manuel

2 1