January 2014 - xwiki-devs@xwiki.org

[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] [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] [Contrib] Reporting extensions issues
by Ecaterina Moraru (Valica) 11 Feb '14

11 Feb '14

Hi, This mail should be seen as feedback for improving our e.x.o ( extensions.xwiki.org) and our contributions process, while answering some of my questions :) Right now I am playing and testing some XWiki extensions from e.x.o. The problem that I have is that I don't know where is the best place to report bugs and issues. 1. First of all I think we should add a 'Issue Tracker' field in the repository application, where the developer should state where the issues should be reported (what is the preferred way of reporting and even if the developer is available for further iterations of the extension). 2. What issue tracker we should use and how? Right now there are several ways the users can give feedback for a certain extension: A. Direct e-mails to the developers: I've received couple of times e-mails with questions about the extensions I've developed. This approach is not recommended since we are doing open development and other users might have the same question. Usually I suggest to use the mailinglist ( http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists ) if there are additional questions, but an issue tracker could also solve the problem. B. Community mailinglist: We receive many questions about the extensions on the mailinglists. The problem is that the answers are very hard to track and share among other users (you need to know that the question has been asked before and than that an answer has been provided). An issue tracker would improve the process. C. Comments on the extension page: There are several extensions that have comments on their extension page. While this approach is the most accessible, it is hard to know what is the status of a comment and the responsible person for it (was it fixed already? in what version? is the comment still valid?). D. GitHub issue tracker: While some extensions contain just snippet code or local XARs, other have a repository attached to it. I know some extensions that track their issues on github. The advantages of this approach is that you keep total control of your extension and also you don't need approvals from xwiki community to have your repository created or help with the management of it (rights, etc.). You handle your own development while using e.x.o as a publishing platform. The above statements are in case you have a personal repository. The alternative is to have a repository on xwiki-contrib ( https://github.com/xwiki-contrib ), but these repository could also have the github issue tracker activated. E. jira.xwiki.org project: On jira.xwiki.org there is a whole section of Contributed Projects ( http://jira.xwiki.org/secure/BrowseProjects.jspa#all ). There is also a generic XWiki Contrib project ( http://jira.xwiki.org/browse/XCONTRIB ) " to be used by all projects till they achieve a first release or till they grow to a size significant enough to warrant a dedicated JIRA project" (quote taken from http://contrib.xwiki.org/ ) F. IRC: Even harder than mailinglist to reference. G. other? I've written all the ways in order to agree on the recommended way (which I guess is E.) while I don't think there is a way to force the others from happening. 3. Related extensions vs. Branched extensions vs. Forked extensions My problem is like this: Lets say I want to test the Forum Application. Currently there are 3 versions of the Forum application (read more at http://design.xwiki.org/xwiki/bin/view/Proposal/ForumApplication ). - First of all it was hard to know that we have 3 versions for the 'same' functionality. A feature like "Related extensions" would have been great to have on e.x.o. - Then it was difficult to find out where is the place to report issues for each of these applications (see the whole point of this mail). Currently there are 2 JIRA projects created for Forum (XAFORUM and XBB) but there is no place to report for SimpleForumApp. - It was hard to know what version still work and if there is still active development on it (especially if you have just an attached XAR and not a repository). - It is hard to know if the apps are completely different or if they are just forks of the same base code. Do they share the same functionality, do they want to be improved versions or are just completely different things? These questions are important because they give you an answer if the entries should have separate JIRA projects or we could solve the problem by creating just a COMPONENT in the same JIRA project. - Whose responsibility is it to create the issue tracker, to link to the related applications, etc? (the developer? the contrib managers? other members of the community?) The same questions apply for Calendar Application ( http://design.xwiki.org/xwiki/bin/view/Proposal/CalendarApplication ). I have 3 variants with other related extensions. The only extension that has a JIRA project associated with it is the older extension. So, as an user of the extension, where do I report issues? - Do I need to ask for the creation of a separate project? - Do I ask for the creation of a separate component in the existing project? - Do I report in the generic xcontrib project? - Do I need the permission of the developer to have the project created? - Should we enforce the creation of projects for the new extensions? - How we decide if an extension is big enough or important enough to have its own project? - Who should monitor these growth? (since we actually don't know if the extensions are used or downloaded?) Let me know what you think. Thanks, Caty

2 4

[xwiki-devs] [Reminder] Review and removal of @Unstable annotation for 6.x
by vincent＠massol.net 10 Feb '14

10 Feb '14

Hi guys, According to your rules since we’re starting a new cycle we need to review all existing @Unstable annotations and remove ones that have been there for at least one cycle (i.e. prior to the 5.x cycle). See http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#H40Unsta… It’s also the occasion to check @Unstable APIs that we can consider stable now. Thanks -Vincent

4 9

[xwiki-devs] [VOTE] Move to Java 7 as minimum supported version
by Thomas Mortagne 09 Feb '14

09 Feb '14

Hi devs, I would like to propose that we move to Java 7 as minimum version in XWiki 6.0. You can look at http://jira.xwiki.org/browse/XCOMMONS-432 for details on why and why not. The only cons basically is that Java 6 may still be used in production but we are talking about a version that won't be used in production before at least 3 months. WDYT ? Here is my +1 -- Thomas Mortagne

11 12

[xwiki-devs] [Proposal] WebJar integration in XWiki
by Vincent Massol 08 Feb '14

08 Feb '14

Hi devs, I'd like to make it easy in XWiki to use javascript frameworks required by extensions. I've found the webjars project (http://webjars.org) which packages javascript frameworks in JAR files available in Maven Central. They work out of the box if you drop them in WEB-INF/lib in a Servlet 3.0 container (like Jetty 7). It works because the 3.0 spec says that any files located in META-INF/resources/<path> will be made available by the servlet container as static resources (accessible as <path>). However the servlet 3.0 specs doesn't support adding those JAR dynamically outside of WEB-INF/lib so it doesn't work with our extension mechanism. Thus I'm proposing the following (which I have tested to work): * Add a new WebJarFilter filter to web.xml * The URL to access, for ex, angular.js packaged in the http://repo2.maven.org/maven2/org/webjars/angularjs/1.1.5-1/angularjs-1.1.5… jar would be: /xwiki/webjar/angularjs/1.1.5/angular.js This allows for example to have a dep on: <dependency> <groupId>org.webjars</groupId> <artifactId>angularjs</artifactId> <version>1.1.5-1</version> <scope>runtime</scope> </dependency> Then in a JSX object: require(["/xwiki/webjar/angularjs/1.1.5/angular.js"], function() { … }); WDYT? Thanks -Vincent

5 11

[xwiki-devs] [Brainstorming] Default rights in subwikis
by Guillaume "Louis-Marie" Delhumeau 06 Feb '14

06 Feb '14

Hi devs. Since 5.3, we have this issue opened: http://jira.xwiki.org/browse/XWIKI-9726 - The default rights of subwikis has changed. I am not shocked by the new settings - same as in the main wiki - but it is different from what Workspaces used to be. What do you think about it? Thanks, Louis-Marie

5 8

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

06 Feb '14

Hi devs, Today is Bug Fixing Day 53. We're currently at -47 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#53 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11997 Happy BFD! -Vincent PS: I’m sending an email later on to propose some changes for BFDs for the 6.x cycle.

1 1

[xwiki-devs] [VOTE] Remove feature of extracting the title from the content
by vincent＠massol.net 03 Feb '14

03 Feb '14

Hi devs, I’d like to propose removing the feature of extracting the title from the content in 6.x. The rationale is: * This is costing more than it should. It needs parsing the document content to get its XDOM and then to traverse it to find Heading blocks. When we display doc titles in lists (in livetables for example or in the activity stream) it costs a lot to do so. * Our implementation is broken since if you use an include macro that generates a heading for ex, it won’t be taken into account since we don’t apply transformations ATM when computing the title since it would be even more expensive. Since 6.x is about performance I believe this would be a good step forward. Now in order to handle backward compatibility. I propose that we: * Add a legacy configuration parameter to keep the behavior (but off by default). This would be in order to let users using this feature convert their wiki * Move the code to a legacy module (I hope it’s possible) Here’s my +1 Thanks -Vincent

9 10

[xwiki-devs] [VOTE] Stop supporting export to RTF without an open office server
by vincent＠massol.net 03 Feb '14

03 Feb '14

Hi, Our RTF export has never been very good and is even crashing depending on the reader you use (see for example http://jira.xwiki.org/browse/XWIKI-5251 ). I propose to drop the RTF support without OO Rationale: * If a user really needs it he can make it work with an OO server connected to xwiki * RTF is not really a mainstream format * I don’t think we want to invest in fixing our RTF export Here’s my +1 Thanks -Vincent

9 9