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

[xwiki-devs] [New extension request] Class migrator application
by Clément Aubin 28 Jul '18

28 Jul '18

Hi devs, I would like to start a new contrib extension called application-class-migrator. What is it? If you want to maintain an application, you might need to perform some migrations on the data structure used by the app (rename xproperties, add some, remove some, refactor some, …). The idea of this application is simply to provide a user friendly solution for application developers to handle migrations. Those migrations can be described in a specific XObject in a page. The migrations will be executed on extension upgrade. I'll take care of creating the repo and the project on JIRA. Thanks, Clément

1 2

[xwiki-devs] [ANN] XWiki 10.6.1 released
by Guillaume Delhumeau 22 Jul '18

22 Jul '18

The XWiki development team is proud to announce the availability of XWiki 10.6.1. This is a bugfix release that covers important issues that we have discovered since 10.6 has been released. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.6.1 Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [ANN] XWiki 10.6 released
by Alex Cotiugă 20 Jul '18

20 Jul '18

The XWiki development team is proud to announce the availability of XWiki 10.6. This release adds a RSS view to the Notifications macro and improves the user picker with compact display and in-line selection. The developers should check the new Page API and the improvements to the existing Icon API. In addition there have been 24 bugs fixed and a couple of small improvements done. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.6/ Thanks for your support -The XWiki dev team

2 1

[xwiki-devs] [XWiki Day] BFD#184
by Alex Cotiugă 19 Jul '18

19 Jul '18

Hello devs, This Thursday is BFD#184: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday <http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays> Our current status is: * -49 bugs over 120 days (4 months), i.e. we need to close 49 bugs to have created bugs # = closed bugs # * -105 bugs over 365 days (1 year) * -155 bugs over 500 days (between 1 and 2 years) * -345 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#184 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14310 Happy Bug Fixing Day, Alex

1 0

[xwiki-devs] [ANN] XWiki 10.6RC1 released
by Marius Dumitru Florea 16 Jul '18

16 Jul '18

The XWiki development team is proud to announce the availability of XWiki 10.6RC1. This release adds a RSS view to the Notifications macro and improves the user picker with compact display and in-line selection. The developers should check the new Page API and the improvements to the existing Icon API. In addition there have been 23 bugs fixed and a couple of small improvements done. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.6RC1/ Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [Contrib] New repo and JIRA for an OpenStreetMap macro
by Stéphane Laurière 12 Jul '18

12 Jul '18

Hi devs, We have a MapMacro already [1], for displaying Google Maps. I'd like to create a distinct one for creating maps based on OpenStreetMap. Another option would be to enhance the existing MapMacro for supporting the display of OSM maps in addition, but this would make the code more complex, and in general an administrator willing to use maps in his wiki is likely to opt for one map type, probably not both, what do you think? If you agree, the proposed repo name and JIRA would be: - Repo: macro-openstreetmap - JIRA project: OSM [1] https://extensions.xwiki.org/xwiki/bin/view/Extension/Map%20Macro Thank you, Stéphane -- Stéphane Laurière XWiki www.xwiki.com @slauriere

6 15

[xwiki-devs] First batch of the new experimental Page oriented APIs
by Thomas Mortagne 09 Jul '18

09 Jul '18

Hi xwikiers, Some of us discussed that for a while and created/improved http://design.xwiki.org/xwiki/bin/view/Proposal/DeprecatingSpaceAndSpaceRef… and I finally started working on it. So here is what I pushed on master already: = PAGE EntityType and Page*Reference classes First thing first we now have a few new type in EntityType and the corresponding typed Page*Reference helpers. One for each of the element you can have in a page: * PAGE * PAGE_ATTACHMENT * PAGE_OBJECT * PAGE_OBJECT_PROPERTY * PAGE_CLASS_PROPERTY = Corresponding resolvers/serializer/providers Each of the already existing DOCUMENT oriented resolvers and serializers have their PAGE oriented implementation. = Conversion from DOCUMENT to PAGE world The entity resolvers automatically convert from/to DOCUMENT from/to PAGE world references. Do yes using a resolver is the official way to do that conversion. = Model script service The $services.model API also got his own new helpers to manipulate pages = New syntax Last but not least: pages reference have a very different syntax. To summarize it's a filesystem path syntax with support for parameters. Here is are a few examples: wiki:page1/page2;param1=value1;param2=value2;en_US wiki:page1/page2/attachment ../siblingpage * separator: "/" between all elements except WIKI which is still ":" * escaping: still "\" * current, parent support: like in a filesystem you can refer to the current page or parent page/wiki using "." and ".." * parameters: we now have syntax to express the parameters of an EntityReference. Each parameter is separated by a ";" at the end of the entity name * default parameter: the syntax have the concept of default parameter which mean a parameter for which you don't need to indicate the name. For example PAGE reference default parameter is "locale" = TODO The next elements on the short term TODO list are: * support for page references in XWiki#getDocument (which essentially means add a fallback) * support for page references in various macros (generally means adding a "page" parameter as alternative to the existing "reference" or "document" parameter) Thanks, -- Thomas Mortagne

4 9

[xwiki-devs] [GSoC] Reminder: 2nd evaluation deadline on July 13, 16:00 UTC (less than 1 week)
by Eduard Moraru 07 Jul '18

07 Jul '18

Hello, GSoC students and mentors. Quick reminder about the 2nd evaluation that is quickly coming up [1]: July 9 16:00 UTC Mentors and students can begin submitting Phase 2 evaluations July 13 16:00 UTC Phase 2 Evaluation deadline Same as last time, make sure you are clear on the expectations and *do not forget to fill in your evaluations* when asked by Google. You should be quite far now into your projects and things should have already begun taking shape. Don't be shy in sharing your progress ;) As always, have fun and build cool stuff! Thanks, Eduard ---------- [1] https://developers.google.com/open-source/gsoc/timeline

1 0

[xwiki-devs] Request to move Blockly fork to Contrb
by Vivek Iyer 07 Jul '18

07 Jul '18

Hi everyone! I would like to request my Blockly fork (https://github.com/Remorax/blockly) to be moved to xwiki-contrib. Please do the needful ASAP :) Thanks and regards, Vivek Iyer

2 1

[xwiki-devs] [VOTE] Add new check to measure quality of tests
by Vincent Massol 06 Jul '18

06 Jul '18

Hi devs, As part of the STAMP research project, we’ve developed a new tool (Descartes, based on Pitest) to measure the quality of tests. It generates a mutation score for your tests, defining how good the tests are. Technical Descartes performs some extreme mutations on the code under test (e.g. remove content of void methods, return true for methods returning a boolean, etc - See https://github.com/STAMP-project/pitest-descartes) If the test continues to pass then it means it’s not killing the mutant and thus its mutation score decreases. So in short: * Jacoco/Clover: measure how much of the code is tested * Pitest/Descartes: measure how good the tests are Both provide a percentage value. I’m proposing to compute the current mutation scores for xwiki-commons and xwiki-rendering and fail the build when new code is added that reduce the mutation score threshold (exactly the same as our jacoco threshold and strategy). I consider this is an experiment to push the limit of software engineering a bit further. I don’t know how well it’ll work or not. I propose to do the work and test this for over 2-3 months and see how well it works or not. At that time we can then decide whether it works or not (i.e whether the gains it brings are more important than the problems it causes). Here’s my +1 to try this out. Some links: * pitest: http://pitest.org/ * descartes: https://github.com/STAMP-project/pitest-descartes * http://massol.myxwiki.org/xwiki/bin/view/Blog/ControllingTestQuality * http://massol.myxwiki.org/xwiki/bin/view/Blog/MutationTestingDescartes If you’re curious, you can see a screenshot of a mutation score report at http://massol.myxwiki.org/xwiki/bin/download/Blog/MutationTestingDescartes/… Please cast your votes. Thanks -Vincent

6 12