January 2014 - xwiki-devs@xwiki.org

[xwiki-devs] [Proposal] Improving extensions.xwiki.org classification
by Ecaterina Moraru (Valica) 31 Jan '14

31 Jan '14

Hi, This mails wants to cover two topics: 1. Improving/cleaning/standardizing a bit the current tags added for e.x.o entries; 2. Proposal to use the tag system to mark the extension's compatibility field. ------ 1. Currently we have 545 tags for 660 extensions (with 705 pages in Extension space). Also we have 367 pages with no tag found in the Extension space. The idea is that I will want to clean a bit the useless tags and keep just the relevant ones. Having useful tags will improve the findability of extensions. Also all extensions should have a tag (right now we have extensions without tags). Tags should be written using small-caps. The current tags are a bit more complex because right now e.x.o also contains 'Snippets' and their scope can be much broader. The current extensions 'Types' (JAR, XAR, Plugin) are very technical and not intended for end-user. I've investigated a bit the tags used on e.x.o and you can see some results here: By Count: http://design.xwiki.org/xwiki/bin/download/Proposal/RepositoryApplicationIm… By Type: http://design.xwiki.org/xwiki/bin/download/Proposal/RepositoryApplicationIm… By Keep: http://design.xwiki.org/xwiki/bin/download/Proposal/RepositoryApplicationIm… The tags investigation images contain a 'Keep' (Y/N) column. If a tag is marked as 'No keep' we should remove that tag (in some cases I provide an alternative found in 'Type/Category' column). This is the first organization, we could further improve on the categories/tags. Having some 'standard' categories but also having multiple extensions share the same tag/category will let us have something like 'Related extensions' in the future. Also very important is to 'standardise' the 'deprecated'/'obsolete'/'archive' tag to mark old/unmaintained extensions. In the future we could display the deprecated extensions in a separate place, maybe called 'Archive'. ------ 2. Right now the 'Compatibility' field of extensions is a free form textarea. This is bad when you want to filter working extensions for a specific version. Example: http://extensions.xwiki.org/xwiki/bin/view/Extension/ForumApplication Adding something in the 'Compatibility' field means that the extension has been tested with that version and not that it works only with that version. Using tags for the 'Compatibility' functionality will improve filtering (and maybe reporting). Also we could parse tags and display in top Compatibility section just the numeric tag entries (that will correspond to the tested versions). The format would be the same as in JIRA: '5.2.4', '6.0-milestone-1', '5.4-rc-1', '4.5.x', etc. Let me know what you think, Caty

1 0

[xwiki-devs] [Proposal] XWiki Days for the 6.x cycle
by vincent＠massol.net 31 Jan '14

31 Jan '14

Hi devs, We’ve done one year of BFD on the 5.x cycle and this has allowed us to reach a greater goal: one of having caught up with the number of open bugs. We’ve first succeeded in closing more bugs than there has been created bugs over a year, then over 2 years, then over 3 years, then over 4 years and we’re very close to succeed for the last 1600 days (ie 4.4 years)! :) I’d like to congratulate everyone on this achievement which is really awesome. I don’t know a lot of other projects who’ve had this kind of success so we can be proud of ourselves! Current result can be seen at: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Note that there are still 357 opened bugs which were created since the beginning of the project. My feeling is that it’s hard to keep the sustained pace we’ve set on the BFD days and I think we need a bit of fresh air. Also now that we’ve caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we’re about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success. So what I’m proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity Here’s a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ): A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting? The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above. So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we’ve done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others. I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc. WDYT? Any other proposal or better idea? Thanks -Vincent

6 13

[xwiki-devs] [ANN] XWiki 5.4 Release Candidate 1 released
by Thomas Mortagne 31 Jan '14

31 Jan '14

The XWiki development team is proud to announce the availability of XWiki 5.4 Release Candidate 1. This is an improvement and stability release for things started during the 5.x cycle. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download (please allow a few hours for the binaries to propagate to the download servers if the download doesn't work yet) Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki4RC1 Thanks -The XWiki dev team

1 1

[xwiki-devs] Bootstrap 3.1.0 is out
by vincent＠massol.net 30 Jan '14

30 Jan '14

Good to know for our new skin: http://blog.getbootstrap.com/2014/01/30/bootstrap-3-1-0-released/ Thanks -Vincent

1 0

[xwiki-devs] Pb in 5.4RC1
by vincent＠massol.net 30 Jan '14

30 Jan '14

Hi devs, I’ve just rebuilt enterprise and started XE (hsqldb+jetty) and found a problem: a migrator is executed even though I’m running the latest version! 2014-01-29 22:49:57,799 [http://localhost:8080/xwiki/bin/view/Main/] INFO .HibernateDataMigrationManager - The following data migration(s) will be applied for database [xwiki] currently in version [53010]: 2014-01-29 22:49:57,800 [http://localhost:8080/xwiki/bin/view/Main/] INFO .HibernateDataMigrationManager - R54000WikiTemplateMigration - http://jira.xwiki.org/browse/XWIKI-9934 This is not normal obviously and would need to be fixed ASAP before 5.4 final. Thanks -Vincent

3 3

[xwiki-devs] detect the syntax in the context?
by Paul Libbrecht 28 Jan '14

28 Jan '14

Hello fellow developers, at curriki we are slowly evolving to xwiki 2.1 (finally!) and it is not too easy. Some of our objects are rendering user-interfaces messages that are expressed in xwiki syntax. To do so, they have the context. But these objects are rendered sometimes in syntax 2.1 or syntax 1.0… Is there a way to tell the "current" syntax in the context object? thanks paul

3 3

Re: [xwiki-devs] [Proposal] XWiki 6.0 + 5.4.1 roadmaps
by vincent＠massol.net 28 Jan '14

28 Jan '14

Hi , On 28 Jan 2014 at 16:27:44, Arvind Gupta (arvind.bernaulli@gmail.com(mailto:arvind.bernaulli@gmail.com)) wrote: > Vincent > I agree on Flamingo. I will fetch up JIRA issues start documenting it. I will also like to add few tutorial on customising Xwiki. I think it's good to move on with SASS or Less as Caty mentioned in another thread. I have an observation about Velocity. We used velocity as that time it was best available approach. Now front-end matters a lot, If a front guy think that he also have to get acquainted with Velocity also it may discourage him. > > Is there any other approach we should consider? I know it will be a lot of work shouldn't we think replacing Velocity with CSS/Javascript based layout? Note that Velocity is not front end but back end (it’s executed on the server) and thus doesn’t compete with Javascript per see. Also, note that in the mail below there a full domain about: “ * 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. “ This could be discussed during this investigation. Now if you wish to elaborate or if you have some specific proposal to make, you could start a new email thread with your proposal and we would discuss it there. Thanks -Vincent > -arvind > > > On Tue, Jan 28, 2014 at 5:42 PM, vincent@massol.net(mailto:vincent@massol.net) wrote: > > Hi Arvind, > > > > On 28 Jan 2014 at 12:25:15, Arvind Gupta (arvind.bernaulli@gmail.com(mailto:arvind.bernaulli@gmail.com)(mailto:arvind.bernaulli@gmail.com)) wrote: > > > > > +1 > > > > > > Are there any other options to CKeditor? > > > > AFAIK this is the strongest one to evaluate. Is there a better one you have in mind? Note that in the past xwiki was using TinyMCE but we weren’t very successful (could have been caused by our wrong usage of it though). > > > > > I would like contribute with documentation of new features. > > > > Great! Here are some JIRA about missing documentation items: http://bit.ly/M96bin > > > > If you’re interested in documenting something else please send us a mail on the users list for example detailing what you wish to do so that others know about it and we could give you some directions/help. > > > > > Should be consider to have new xwiki.org(http://xwiki.org) design along with new UI? > > > > As Caty mentioned, the xwiki.org(http://xwiki.org) design has already been modified not that long ago. My take is that if we agree to develop Flamingo then it would be a good idea to update xwiki.org(http://xwiki.org) with it. > > > > Thanks > > -Vincent > > > > > > > -arvind > > > > > > > > > > > On Tue, Jan 28, 2014 at 4:23 PM, vincent@massol.net(mailto:vincent@massol.net) wrote: > > > > > > > Of course this is only the work planned by the committers I mentioned. > > > > > > > > For the other committers, feel free to add stuff you’d like to work on in > > > > 6.0 so that we can add it to our global roadmap. > > > > > > > > Note: I’ll put all this on > > > > http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome in a few days if > > > > people agree about it. > > > > > > > > Thanks > > > > -Vincent > > > > > > > > On 28 Jan 2014 at 11:17:29, vincent@massol.net(mailto:vincent@massol.net) (vincent@massol.net(mailto:vincent@massol.net)) wrote: > > > > > > > > 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 > > > > >

1 0

[xwiki-devs] [Proposal] Members of subwiki migration
by Guillaume "Louis-Marie" Delhumeau 27 Jan '14

27 Jan '14

Hi developers! In Workspaces, we used to add global users in the XWikiAllGroup page of a subwiki to indicate that they are members of that wiki. Now, we have an option called "user scope", and we can have both global & local users in a subwiki. That means we have global & local users in XWikiAllGroup. Then, it is a problem because it can not work when XWikiAllGroup is a virtual group [1]. Then, I have proposed to create a new group, called XWikiMemberGroup, that hold the members of the subwiki. (Note: XWikiAllGroup will be a member of XWikiMemberGroup, in order to say "a local user is a member"). So, I have written a migration (again!) [2], to create the new group with the current content of XWikiAllGroup. In this migration, I also changes all existing rights that occur on XWikiAllGroup to make them effective for XWikiMemberGroup. I did not want to duplicate these rights by just adding the sames for XWikiMemberGroup. I think it is easier for the user to only take care of the XWikiMemberGroup. But it looks a bit "magical", and some people don't like it. I would like to have your opinion. +1 for adding XWikiMemberGroup and to "migrate" rights (replace all rights given to XWikiAllGroup by rights given to XWikiMemberGroup). Thanks, Louis-Marie [1] http://jira.xwiki.org/browse/XWIKI-9886 - Enabling virtual XWikiAllGroup breaks wiki membership [2] https://github.com/xwiki/xwiki-platform/compare/feature-wiki-members - Git branch for this proposal

7 18

[xwiki-devs] WYSIWYG editor menus are behind the editor… how to solve?
by Paul Libbrecht 27 Jan '14

27 Jan '14

Hello fellow XWikiers, we are having a bug at Curriki where one positioning of the wysiwyg editor has the following bug: the menus pop-up behind the tool-bar and editor-pane. Other instances of the editor do not have this issue. What should I investigate? Is this z-index (apparently always 12) not dynamically updated depending on the current z-index? paul

2 3

[xwiki-devs] [Reminder] BFD#51
by vincent＠massol.net 24 Jan '14

24 Jan '14

Hi devs, Today is Bug Fixing Day 51. We're currently at -63 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Note that we’re a bit lucky since there was a cluster of bugs that slipped of, thus reducing our bug count from around -120 three weeks ago to -63 now without us closing more bugs than there were creations :) Let’s grab this opportunity to win against the evil bugs! Here's the BFD#51 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11995 Happy BFD! -Vincent PS: Next week I’ll send some proposal for this special day for the 6.x cycle and we can brainstorm about it.

1 2