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