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

[xwiki-devs] [Vote][Skin] Keep Colibri look or have another look for 6.x
by Ecaterina Moraru (Valica) 26 Feb '14

26 Feb '14

Hi, As part of the 6.0 Roadmap we have as entry the creation/integration of a new Skin inside XWiki. Currently there are 2 proposals for the new skin: Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin = Similarities = * Both skins have been done using the Twitter's Bootstrap framework ( http://getbootstrap.com) * Both skin are thus responsive = Differences = * Flamingo is just a proposal, while Junco is an extension. The difference is that while for Flamingo I have just a prototype, Junco is functional and installable (with some integration problems/dependencies discussed in another thread). The difference matter just from a development time perspective (if we choose Flamingo it will take longer to implement). * Flamingo provides a new look while Junco offers 'Themes', one of themes being very similar to Colibri, see http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin#HTheme:Coli… This vote mail is about this difference. What to consider: A. Freshness Advantages of Flamingo is that its interface is centered around Applications (it has a new left panel used for navigation). It will provide a visual difference from Colibri and looks more similar to current applications found in the wild. Advantages of Junco is that it provides Themes. Junco's Themes are very similar to our current ColorThemes, the difference is that they can change also the font used, the colors and can also add some esthetic effects (gradients, borders, shadows, etc. - CSS effects) to Bootstrap's components (buttons, navbars, alerts, tables, etc.). But except minor changes, the layout is similar to Colibri. Improvement consist in using refreshed style for font, forms, buttons, messages, etc. B. Extensions Integration One of the reasons I choose to make Junco similar to Colibri was extensions integration. The advantage of XWiki is that you can extend it how you like. The problem is that because the extensions are developed by our community (and not by a single entity) each application is providing it's own style. On extensions.xwiki.org we have applications that provide an unique style, while others are build around and for Colibri. Adding a new skin with a different style (like Flamingo) will make current extensions not look unitary. This problem is more general than just this Colibri/Junco/Flamingo discussion and it the problem of having extensions that adapt to the skin used (without creating special versions for each skin). Junco was created to look similar to Colibri (preserving layout, style, colors) while updating the 'back-end' (created on Bootstrap, it will put at developer's disposal the Bootstrap's guide style and components). One of the reasons we are having this extensions 'incompatibility' is because we are lacking visual standards and guides (maybe using the ones provided by Bootstrap can improve this area - I will send a separate mail about the CSS Framework selection). So from the style standards perspective having Junco integrated first could represent a transition step between our current Colibri and a new skin with a different look, because the developers might use Bootstrap style/structure guides in their extension development (not guaranteed). C. Parallel skin support Another advantage of Junco is that (by having the same layout) is using the same templates as Colibri. Having just a set of templates to maintain is very important from a development perspective especially if your development resources are limited. This is one of the reasons XWiki is not supporting multiple default skins. Flamingo will need some templates changed, so important from a development time and maintenance perspective. So this vote is about: 1. Keep Colibri's current look which is supported by the Junco skin, or 2. Have another look for 6.x which is proposed in the Flamingo skin Thanks, Caty

4 8

[xwiki-devs] [Contrib] Requesting a project for CAS authentication
by Petr Abrahamczik 25 Feb '14

25 Feb '14

Hello, I would like to request for a project that adds Jasig CAS (http://www.jasig.org/cas) authentication support to the XWiki. We started using XWiki in our organization and we are using a CAS authentication. So I developed CAS authentication module to the XWiki and I would like to share it on XWiki Contrib. I would like to request for GitHub access. My GitHub user name is pabro. Name: XWiki Authenticator CAS Description: XWiki authenticator based on Jasig CAS. It supports CAS 2.0 and SAML 1.1 protocol. SAML protocol can be used for attributes and group membership synchronization. Petr Abrahamczik

2 1

[xwiki-devs] [Discussion][Skin] Less vs. Sass vs. Velocity
by Ecaterina Moraru (Valica) 22 Feb '14

22 Feb '14

Hi, As part of the 6.0 Roadmap we have as entry the creation/integration of a new Skin inside XWiki. Currently there are 2 proposals for the new skin: Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin Both proposals are done using Twitter's Bootstrap framework ( http://getbootstrap.com) Bootstrap officially is written using Less ( http://www.lesscss.org/ ) and is the default pre-processor they support. There is also a Sass ( http://sass-lang.com/ ) version for Bootstrap ( https://github.com/twbs/bootstrap-sass ) so the idea is that the preprocessor variant is not limiting us in integrating Bootstrap. The question we discuss in this thread is what preprocessor we should integrate in platform when we integrate Bootstrap (that in the case we integrate either of these tools). Currently Junco's extension is done with Bootstrap + Less. My decision to use this combination was done after a light research and mostly based on a personal preference of the Less language. We are having this preprocessors discussion so late (they appeared in 2007-2009) because we didn't really need a preprocessor until now. The base functionality they add we solved by using Velocity (we have CSS3 prefix macros defined in macro.vm that are similar to the compatibility mixins provided by Bootstrap, we have also a ColorThemes variables solution for reusing color values and because we can have Velocity code inside our stylesheets we cover most of the functions&operations need). The only downside for us using Velocity to do these kind of things is that the functionality we cover is very basic and was done only if we had a certain need. This is not necessarily a bad thing but it's kind of a limitation for external developers that might want to make more complex things. Less and Sass community members are very active and they make sure their functionality is tested and covers most of the cases. Also there are some features (like extends, etc.) that would be hard for us to duplicate in Velocity. Just as a note, adding Less doesn't mean we are replacing Velocity. We are just replacing the CSS things done in Velocity with Less functionality. Replacing Velocity with another templating engine should be the topic for another thread (in case we are considering this). If we integrate Less, what is currently done with CSS+Velocity will be done using Less(CSS)+Velocity(less code). If we integrate Sass (because Sass also has control directives) we transform CSS+Velocity in Sass(CSS)+Velocity(even less code) but the API calls will still need to be added with Velocity (so still we will not have just Sass). One of the problems with the preprocessors is that they depend on Javascript or Ruby (there are some versions also on Java in case of Sass, but not officially maintained). So first we need to find a solution to compile Less/Scss files into CSS, inside our platform. If you make a Google search you'll see that there are much more 'recommendations' to pick Sass over Less. One remark regarding this is that we need to understand that right now Sass is used on a different technologies stack (mostly for Ruby applications). Sass is very attractive because of its power. But what we need to ask ourselves is if we need the full power of Sass (because some of it is already covered by Velocity). Personally I prefer Less, but that's because of the separation of concerns (structure, presentation, behavior). I prefer the limitations Less has (regarding control structure) in order to not be tempted to write logic with a language that is not supposed to do that (even though it can). Preprocessors should be used exclusively to write CSS and especially to write it more rapid (nesting, mixins). Also Less syntax is more close to default CSS syntax, which IMO is a big plus. But because of its power, Sass could be in the future the new 'JQuery', since right now it has a bigger community. One of the advantages of picking a technology later is that at least you see some clear candidates (and we don't need to consider other preprocessors like Stylus, etc.). Let me know what you think. Thanks, Caty

3 5

[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