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

[xwiki-devs] [ANN] XWiki 5.1 Release Candidate 1 Released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki 5.1 Release Candidate 1. This is mostly a stabilization release leading to XWiki 5.1 and it brings Sorl search improvements and bug fixes as we plan to make Solr the default search engine in 5.1 final. There is also a new Menu Application in platform (not bundled by default) to help you create navigation menus. 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/ReleaseNotesXWiki51RC1 Thanks -The XWiki dev team

12 years, 2 months

1
0
0 0

[xwiki-devs] [Reminder] BFD#27

by Vincent Massol

Hi everyone, Today is BFD27. Our goal is still to have more bugs closed than created for the past 1300 days! http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 As of now we're 49 bugs behind! Let's make a dent today :) Here's the BFD#27 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11601 Thanks Marius

12 years, 2 months

1
1
0 0

[xwiki-devs] Fast build times in Java: "down from 45 mins to 3+ minutes"

by Caleb James DeLisle

This is amusing: http://dan.bodar.com/2012/02/28/crazy-fast-build-times-or-when-10-seconds-s… Interesting stats: cjdns - 40k LoC* - clean build in 40 seconds - 1k LoC/sec xwiki - 800k LoC* - clean build in 60 minutes(?) - 222 LoC/sec Cjdns build is still embarrassingly slow because cmake invokes the linker far more often than necessary. * LoC is the total line count for every source file in the project.

12 years, 2 months

2
2
0 0

[xwiki-devs] [Proposal] API breakage or changing a behaviour ? (Inclusion of groups in groups)

by Guillaume "Louis-Marie" Delhumeau

Hi devs ! In order to fix http://jira.xwiki.org/browse/XWIKI-2900, I have some proposals to you. The problem is : the Inclusion of groups in groups aren't taken into account when querying user memberships. Let suppose we have the following use case: User 1 inside the Goup A Group A inside the Group B The actual behaviour of XwikiGroupService# getAllGroupsNamesForMember() when calling it with "User 1" as input, is to return "Group A" only. Because, only "Group A" has actually a member called "User 1". We might want to keep this behaviour, because we may need to have only the declared members of that group. But we can modify this method to also returns the members of the subgroups, by changing XwikiGroupService#getAllGroupsNamesForMember(), which returns the groups of a member. Other solution, adding a new method: boolean isMemberInGroup(DocumentReference memberReference, DocumentReference groupReference) which only check if the user (or the group) given on the input is a member of the group or not. But it's an API breakage. So my proposal is: 1/ Changing the behaviour of XWikiGroupService#getAllGroupsNamesForMember(), XWikiGroupService#getAllGroupsReferencesForMember(), XWikiGroupService#getAllMembersNamesForGroup(), XWikiGroupService#getAllMatchedMembersNamesForGroup(), XWikiGroupService#countAllGroupsNamesForMember() and XWikiGroupService#countAllMembersNamesForGroup() or 2/ Adding isMemberInGroup(DocumentReference memberReference, DocumentReference groupReference, XWikiContext context) in XWikiGroupService, which is an API breakage, and my Pull Request : https://github.com/xwiki/xwiki-platform/pull/117/ or 3/ Only change XWikiUser#isUserInGroup() and do the recursive stuff there. Thanks for your help! Louis-Marie

12 years, 2 months

5
9
0 0

[xwiki-devs] Should Main.Spaces/Main.Activity be hidden by default?

by Vincent Massol

Hi, I think it should since it's the page that serves to define the {{spaces/}} macro. Similar question for the Main.Activity page which defines the {{activity/}} macro. If we want to have those pages used by the user as "features", then I think we should separate the pages: have one page for the macro definition and another page for using the macro. One reason is that we don't want technical code to be returned by default in searches for example and if we have a separate page for the macro then we can mark it hidden and it won't be returned by default in searches. I think we need to hunt for all pages that return code by default. Personally I think that Main.Spaces and Main.Activity should be hidden since there's no navigation leading to them. WDYT? Thanks -Vincent

12 years, 2 months

4
7
0 0

[xwiki-devs] [Proposal] Make Solr the default search engine for 5.1 final

by Marius Dumitru Florea

Hi devs, I'd like to enable Solr by default for 5.1 final. What's left to do in order for it to be really usable is to have some feedback about the indexing progress in the administration section but I think I can work on this before the 5.1 final (shouldn't take long since Thomas has already committed some helping script service). Hope this is fine with you, Marius

12 years, 2 months

5
6
0 0

[xwiki-devs] [Proposal] Restricting the wiki syntax

by Thomas Delafosse

Hi all, We have some security issues with the wiki syntax : people can use it for including some javascript, as you can pass javascript attributes (onclick, etc...) in links parameters for example. As it is dangerous to let anyone include javascript code, we should at least restrict which attributes unprivileged users could use with the wiki syntax. The question is, should users with PR rights still be able to include Javascript thanks to the syntax ? Either : 1) We restrict the wiki syntax for unprivileged users but give no restriction for users with PR. 2) We restrict the wiki syntax for everybody. To my mind, the wiki syntax is not designed for including javascript, there is the HTML macro and Skin extensions for that, so I'm in favor of 2). But perhaps this is something some of you use often, in which case we should perhaps rather go for solution 1). What do you think ? Thanks, Thomas

12 years, 2 months

6
13
0 0

[xwiki-devs] [QA] Feedback for 5.1 RC1

by Manuel Smeria

Hello devs, XWiki 5.1 RC1 is scheduled to be released on Monday, the 24th. Besides the list of bugs fixed for this version, do you want some other features tested as well ? Keep in mind that the Iasi team will be off next Monday. Have a great weekend, Manuel

12 years, 2 months

3
2
0 0

[xwiki-devs] [Reminder] BFD#26

by Marius Dumitru Florea

Hi everyone, Today is BFD26. Our goal is still to have more bugs closed than created for the past 1200 days! http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 As of now we're only 7 bugs behind! Here's the BFD#26 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11600 Thanks Marius

12 years, 2 months

4
6
0 0

[xwiki-devs] Extension Points in 5.1

by Ludovic Dubost

Hi, It's been a few version now that we have the UI Extension mecanism in the core platform. However we have not added many extension points and it's bad to wait to long to do this at it will lead to have to build extensions with versions that have them and versions that do not have them. It would be great to add the most important extension points as soon as possible. Here are from my point of view as an extension developer the most important ones: 1/ Page Menu so that you can add an action to the current page 2/ Wiki Menu 3/ Profile Menu 4/ For each attachment 5/ For the attachment area 6/ Next to the document title 7/ Document action tabs (comments, files, etc) 8/ Document action tab links (in the document title area) 9/ Footer Less important: All menus Search form Edit panels Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

12 years, 2 months

4
3
0 0

[xwiki-devs] [GSOC] First coding period started

by Ecaterina Moraru (Valica)

Hello Buddhiprabha, Yesterday we entered the 'Coding' period of the Google Summer of Code 2013. There are some things that need to be mentioned about GSOC that could help any student contributing to XWiki: = Mentorship = We prefer open mentorship. While your assigned mentor is the one officially in charge with your guidance, almost all interaction should be done 'in the open' as much as possible, on the IRC channel or on the mailing list. You should choose the communication medium according to the importance of the matters to be discussed: naturally, the less important issues are to be discussed on IRC, while the design decisions, important progress announcements and testing/feedback requests go on the list. This way, the community is informed on the evolution of your project, and other developers can come up any time with useful ideas and suggestions. Moreover, if your mentor is hit by a bus (the bus factor [1]), another developer can take his place with little effort. = Communication = Sitting alone in your room, working secretly on your project is definitely a bad approach. However, please keep in mind that too much communication can also be harmful, as it distracts the others from their own work. You need to be able to communicate just right: - provide meaningful information about your progress, - ask the community's opinion on non-trivial design or implementation decisions - avoid wasting a lot of time on a problem, when a more experienced developer (or a student that fought the same problem) could quickly provide you an answer; however, do try to find the answer yourself at first. Wrong: "Where do I start? What do I do now? And how do I do that? Is this good? It doesn't work, help me!" Right: "Since a couple of hours ago I get a strange exception when building my project, and googling for a solution doesn't seem to help. Looking at the error, I think that there's a wrong setting for the assembly plugin, but nothing I tried works. Can someone please take a look?" Subscribe to the devs list (if you didn't do this already), and start monitoring the discussions. It is also recommended to subscribe to the users list, but not mandatory. The notifications list is a little too high volume and technical for the moment, but it is a great knowledge source. = Development process = The project's lifecycle is NOT design -> implementation -> testing -> documentation. [2] We invite you to adopt a test driven development [3][4][5] approach and to experience agile development [6]. After the first coding week, you must have some code that works. It won't do much, of course, but it will be the seed of your project. Every functionality will be validated by tests. The code must be properly tested and commented at the time of the writing (don't think you'll do that afterwards, because in most cases you won't). We encourage you to do __at least__ weekly commits (ideally, if you are well organized, you should be able to commit code that works daily, so try to aim at daily commits). This way, the code can be properly reviewed, and any problems can be detected before they grow into something too difficult to fix. One big code blob committed at the end, no matter how good it may seem, is a failure at several levels. = Documenting your work/progress = We expect students to document their work/progress in 2 ways: 1) Design page in the Design [7] space on xwiki.org GSoC students should create a Design page where they document technical aspects of the feature they are working on: architecture, use cases, problems, various solutions with pros and cons, etc. This page should be written as an XWiki community member and not a GSoC student (there is the progress report for that), ensuring that the page will remain relevant even after the GSoC period ends. 2) 'Progress' section of the GSoC project [8] This is the place where the students set their goals (milestones and deliverables) and where they report their advance towards completing them. More details and examples are available at [9][10][11]. = Conclusions = Since we are already in the coding period, there are some things that need to be done: 1. Answer this mail :) 2. Create a Design page [7] regarding your project 3. Start idling on the IRC channel 4. Start chatting on the mailing list and on IRC about your project and other aspects of XWiki that you don't yet understand 5. Get your hands dirty by diving into the code and fixing Jira issue 6. Talk about your project We want to know what you don`t understand about XWiki, what issue you are planning to undertake, what you want to start with, etc. It helps you more to start saying incorrect things and fixing them early instead of staying quiet and making a big bad choice towards the end. And a last thing, please remember that one-to-one conversations with your mentor are not encouraged and are actually harmful to the success of your project. Talk to the community, ask for help early and life will be sweeter. According to the timeline [12], you have 6 weeks of work available until the mid-term evaluation. Please make sure you have the conditions for success [13] in mind throughout all of the 12 total weeks of GSoC coding. Happy coding! Ecaterina on behalf of XWiki Mentors [1] http://en.wikipedia.org/wiki/Bus_factor [2] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ [3] http://en.wikipedia.org/wiki/Test-driven_development [4] http://www.amazon.com/dp/0321146530/ [5] http://www.amazon.com/dp/0201485672/ [6] http://www.amazon.com/dp/0596527675/ [7] http://dev.xwiki.org/xwiki/bin/view/Design/ [8] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HSelectedPro… [9] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentPr… [10] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/SOLRsearchcomponent [11] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Responsiveskinbasedo… [12] http://www.google-melange.com/gsoc/events/google/gsoc2013 [13] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HConditionsf…

12 years, 2 months

3
4
0 0

[xwiki-devs] REST API usages

by Fabio Mancinelli

Hi everybody, I am working on some brainstorming about the future of the XWiki REST API... The starting point, of course, would be to understand who is using it, how she's using it (i.e., for which use cases), what are the problems she has encoutered and which kind of feature she would like to see in the API. So, if you have worked/interacted/built something with the REST API it would be great to have your feedback. Thanks, Fabio

12 years, 2 months

3
2
0 0

[xwiki-devs] Fwd: Adding a customer plugin to the wysiwyg editor

by Marius Dumitru Florea

Hi Josef, Yes, you can put your design proposal on the Design space and I'll be happy to help you both with the design and the implementation. It's best if we keep the discussion on the devs mailing list so that everyone can participate. I don't have any advice/recommendation for now regarding the proposal but I'll review and comment it as soon as you have something written down. Of course, don't hesitate to ask me any question regarding the WYSIWYG editor. Thanks, Marius ---------- Forwarded message ---------- From: Haimerl, Josef <Josef.Haimerl(a)de-gmbh.com> Date: Mon, Jun 17, 2013 at 11:34 AM Subject: Adding a customer plugin to the wysiwyg editor To: "mariusdumitru.florea(a)xwiki.com" <mariusdumitru.florea(a)xwiki.com> Dear Marius,**** ** ** as already brought up on the XWiki mailing list, we want to implement a customer plugin to the wysiwyg editor and contribute it. Our head approved that now and we want to post a design proposal to arrange things with the community. We would do that here<http://dev.xwiki.org/xwiki/bin/view/Design/WebHome>- is this the right place? Also I would see you from now on as my contact person for this subject or maybe you tell me who’s the right one.**** Also if you have an further advice or recommendation we should consider, when we put down the design proposal, we would be happy. **** ** ** Regards **** Josef Haimerl**** Projektleiter**** [image: Banner_E-Mail] <http://www.de-gmbh.com/brandaktuell.html>**** ** ** DE software & control GmbH Mengkofener Str. 21, D-84130 Dingolfing Fon: +49 8731 3797-0; Fax: +49 8731 3797-29 http://www.de-gmbh.com Geschäftsführung: Friedrich Steininger, Heino Migge, Onur Mubariz Amtsgericht Landshut, HRB 4478**** ** **

12 years, 2 months

2
2
0 0

[xwiki-devs] Ratings Plugin porting to Components

by Ludovic Dubost

Hi, I have ported the ratings plugin to a component architecture and also to 4.5.x. Could some devs review the pom and apis before I make a release of it ? I mostly interested if the pom are correct for releasing. On the code itself, I don't think we can change the storage classes unless we are ready to loose compatibility with the previous plugin. But we could change the script service API if there are better choices. https://github.com/xwiki-contrib/application-ratings Thanks Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

12 years, 2 months

3
7
0 0

[xwiki-devs] Issue with install on 4.5.3 of extension with dependency on 4.5.4

by Ludovic Dubost

Hi devs, I've tried to install the Xambox extension on 4.5.3 and I'm getting en error: http://extensions.xwiki.org/xwiki/bin/view/Extension/File+Manager+Xambox+Co… Here is the error: Dependency [org.xwiki.commons:xwiki-commons-component-api-4.5.4] is not compatible with core extension [org.xwiki.commons:xwiki-commons-legacy-component-api-4.5.3] Indeed in the build I have a reference to 4.5.4, but in reality it should not make a difference. What is the solution in this case ? Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

12 years, 2 months

3
4
0 0

[xwiki-devs] [Proposal] New Resource module

by Vincent Massol

Hi devs, See http://jira.xwiki.org/browse/XWIKI-9237: {quote} The idea is to rename the URL module's XWikiURL, AbstractXWikiURL, XWikiEntityURL, etc into Resource, AbstractResource and EntityResource and move them to a resource module. The reason is that they are not URL and are thus badly named. In addition since the goal is to the resource in the Execution Context and the EC should be independent of any environment it's not right to put a URL in it. A Resource is much better. This also brings us one step closer to http://markmail.org/thread/wfj4dupq76agqonz {quote} Specifically the code is in a branch right now at: https://github.com/xwiki/xwiki-platform/tree/feature-resource-and-wiki-modu… Let me know what you think. Thanks -Vincent

12 years, 2 months

1
2
0 0

[xwiki-devs] listening to a rename operation?

by Paul Libbrecht

Hello XWiki experts, is there a way using the "EventListener" of the ObservationManager to detect the move of a document to another space and page? Thanks in advance. Paul

12 years, 2 months

3
4
0 0

[xwiki-devs] [Proposal] Adding support for adding dynamic parameters in Query Filters

by Vincent Massol

Hi devs, Right now the QueryFilter interface allows to modify the query statement and to filter returned results but doesn't allow to pass dynamic value. I'm currently implementing a filter that'll return only results for the current language and thus I need this dynamicity. Are you ok that I break the QueryFitler API to add a new method: public interface QueryFilter { String filterStatement(String statement, String language); List filterResults(List results); // New method Map<String, String> getParameters(); } WDYT? Thanks -Vincent

12 years, 2 months

2
4
0 0

[xwiki-devs] Navigation Menu Bar UIX

by Marius Dumitru Florea

Hi devs, I'm going to add an UI extension point after the XWiki header that could be used to inject a navigation top menu bar. The extension point id can be: org.xwiki.platform.template.header.bottom or org.xwiki.platform.template.header.after I'll go with the first option if no one has a strong preference for the second. Regarding the package prefix in the UIX id, even though it was missing from JV's proposal http://lists.xwiki.org/pipermail/devs/2013-March/053739.html the existing UIX have it (e.g. org.xwiki.platform.panels.Applications) so I'm using it too to be consistent. I would also like to integrate http://extensions.xwiki.org/xwiki/bin/view/Extension/Navigation+Menu+Wiki+M… http://extensions.xwiki.org/xwiki/bin/view/Extension/NavigationMenuConfig into xwiki-platform-menu/xwiki-platform-menu-ui (with various code modifications and some functional tests) without bundle it with XE. This new module could host in the future the menu creator proposed by Caty http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MenuCreator . The goal of all this is to have http://jira.xwiki.org/browse/XWIKI-9148 closed for 5.1 final. It's ok IMO to do this during RC phase because it can't break existing features. Thanks, Marius

12 years, 2 months

5
7
0 0

[xwiki-devs] [ANN] XWiki 5.1 Milestone 2 Released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki 5.1 Milestone 2. This release brings automatic Solr indexing with locale inheritance and a few bug fixes and improvements. 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/ReleaseNotesXWiki51M2 Thanks -The XWiki dev team

12 years, 3 months

1
0
0 0

[xwiki-devs] [Reminder] BFD#25

by Vincent Massol

Hi everyone, Today is BFD25. Our goal is still to have more bugs closed than created for the past 1200 days! http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 As of now we're 24 bugs behind (from 35 last week). Here's the BFD#25 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11599 Thanks -Vincent

12 years, 3 months

1
1
0 0

[xwiki-devs] A new XWiki Model! (sort of)

by Caleb James DeLisle

Hi guys, I've been working on this little side project which I originally needed to scratch a personal itch that came up during my work on the Resilience research project. I needed an efficient way to generate XWiki export (.xar) files and post them to a running wiki for rapid prototyping. In the past I would do some work from within the wiki and once the bulk of the work was done, I'd export an xar file and unzip it. Fixing up the XML and making small changes would be done by hand editing the XML dumps. To test it, the XML files would be packaged into .xar file using Maven then uploaded into the wiki by using the import function in the Admin interface. There are a few problems with this process: 1. Manually editing XMhelL files. 2. My attention span lasts from `mvn clean install` to `[INFO] Scanning for projects...` 3. The turnaround cycle from making a change in the git repository to seeing it in the wiki is somewhere around 2 minutes (edit, compile, upload in browser, test) My solution is called xwiki-tools, it's a Javascript framework for scripting the creation of XWiki packages with documents, objects and classes. Code Golf example: This is the shortest xwiki-tools script which will run (it makes a .xar file): var XWiki = require('xwiki-tools'); var pack = new XWiki.Package(); pack.setName("XWiki - Contrib - XWiki Tools Tiny Example"); pack.setDescription("package name, description and extensionId are required"); pack.setExtensionId("org.xwiki.contrib:xwiki-tools-tiny-example"); var doc = new XWiki.model.XWikiDoc(["Main","TinyExample"]); doc.setContent("A code-golf example of making an XWiki .xar file with 1 document."); pack.addDocument(doc); pack.genXar('XWikiToolsTinyExample.xar'); You can copy/paste this little .js script into a file and run `node yourFile.js` and it will output XWikiToolsTinyExample.xar. But wait, there's more! xwiki-tools doesn't just allow you to wrap little documents into .xar files, it allows you to add attachments, XObjects and even define your own XClasses. It can also generate more than a xar file, it can post the package directly to a running wiki which allows you to edit a file, run the command, page over to the browser and immediately see your changes! If you want, it can also generate output as an Apache Maven build. Check out the example here: https://github.com/cjdelisle/xwiki-tools-example to learn how to add attachments, XObjects and XClasses to your package and how to post to a wiki or generate a Maven build. Performance: user@ubnta8:~/wrk/resiliance/xwiki-tools-example$ time ./do >/dev/null real 0m0.643s user@ubnta8:~/wrk/resiliance/xwiki-tools-example$ time ./do --mvn >/dev/null real 0m0.416s user@ubnta8:~/wrk/resiliance/xwiki-tools-example$ cd mvnout/ user@ubnta8:~/wrk/resiliance/xwiki-tools-example/mvnout$ time mvn clean install >/dev/null real 0m20.578s XWiki Classes: So you've decided you want to give this a shot and you have a big ugly class which you need to represent. If you've looked at one of the existing classes such as: https://github.com/cjdelisle/xwiki-tools/blob/master/lib/model/classes/Wiki… then you know what it needs to look like but getting your class in that form would be painful. Fortunately there is a tool which reads your .xml file with the XClass and prints a .js file like the one above. Just unzip the xar export from XWiki and run the following: node ./bin/describeclass.js /path/to/YourBigClass.xml Note: some of the class properties are unimplemented so some classes will not work. License: LGPLv2.1, same as XWiki, generated code/data explicitly exempted. Thanks, Caleb

12 years, 3 months

1
0
0 0

[xwiki-devs] [UX][Iteration] Menu Creator

by Ecaterina Moraru (Valica)

Hi devs, One of the roadmap entries is the ability to create extensible, reusable menus (XWIKI-9148 <http://jira.xwiki.org/browse/XWIKI-9148>). This proposal reuses the AppWithinMinutes wizard mechanism and adapts it to Menu creation, having a limited fields palette (pages, links, separators, extension points): http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MenuCreator/St… http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MenuCreator/St… Submenus will be created by using the Drag&Drop or by using indent actions in the Toolbox: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MenuCreator/St… http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MenuCreator/St… This is an example of the menu that could be created with the MenuCreator: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MenuCreator/Ex… You can read the whole proposal at: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MenuCreator We could also use it for our #mainmenu and #contentmenu in order to let the user customize what entries are displayed or add more. Let me know what you think, Caty

12 years, 3 months

3
2
0 0

[xwiki-devs] [Proposal][QA] Put Test Report Application on xwiki.org

by Sorin Burjan

Hello everybody, After several months of fragmented work, I have finally managed to complete the next iteration of Test Report Application [1]. Final parts of the code will be committed next week. Taking into consideration the feedback I received, I implemented several changes into the application to make it more user friendly and robust. In order to put the application in production, Manuel and me converted the Manual Test Report Template [2] into Test Cases to be used by the Test Report Application. These test cases are committed on Github [3]. Now we have 404 Test Cases, grouped in 22 Spaces as follows: 1) Action Menus Tests 2) App Within Minutes Tests 3) Dashboard Macro Tests 4) Page Tabs Tests 5) Rights Tests 6) Tags Tests 7) Wiki Editor Tests 8) WYSIWYG Editor Tests 9) Activity Stream Tests 10) Blog Tests 11) Document Index Tests 12) Panels Tests 13) Search Tests 14) User Profile Tests 15) Wiki Manager Tests 16) Administration Tests 17) Color Themes Tests 18) Jump To Page Tests 19) Register and Authentication Tests 20) Space Macro Tests 21) User Status Tests 22) Workspaces Tests My proposal is that we create a dedicated subwiki for this, qa.xwiki.orgwhere we will deploy the application + test cases. The rationale behind having a dedicated subwiki for this is that we don't want to crowd an already existing subwiki with the test cases and also the spaces which will hold the test execution pages. WDYT ? I am waiting for your opinions/concerns/questions about this. Regards, Sorin B. [1] https://github.com/xwiki-contrib/application-testreporting [2] http://www.xwiki.org/xwiki/bin/view/TestReports/ManualTestReportTemplate [3] https://github.com/xwiki-contrib/application-testreporting-cases

12 years, 3 months

3
7
0 0

[xwiki-devs] What default language for our documents in releases XAR ?

by Thomas Mortagne

Hi devs, Right now the XAR plugin format goal systematically empty the <defaultLanguage> property. This is wrong IMO since it means we have no idea what is the default document language, it was not too visible before but it's really not very nice for things like the localization module and especially SOLR which store deferently the content depending on the language (stop words, etc). I see several possibilities: 1) We don't touch the XAR maven plugin and we state that when default language is not set, it's en (in the importer for example or in XWikiDocument#getDefaultLanguage) 2) We stop filtering default language in the XAR plugin and we set it to en for all document in which it make sense 3) We force default language to "en" in the XAR plugin WDYT ? I don't like too much 1) since some technical document could really be seen has having no default language, some document without any literal content. But it's more a -0 than a -1, I understand other would want this for simplicity. About 3) as I said having a default language empty is a valid use case IMO so -0 for this one to. Still a bit better than 1) since the use case is still possible. +1 for 2) -- Thomas Mortagne

12 years, 3 months

6
19
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs