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

[xwiki-devs] Bug Fixing Day #8 has started!
by Vincent Massol 06 Dec '12

06 Dec '12

Hi devs, Let's start and make it a fruitful day :) Reminder: The goal is to make the green win in http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Current situation: 891 created and 822 resolved ==> 69 to go! Thanks -Vincent

1 0

[xwiki-devs] [Brainstorming] Minimal supported resolution?
by Vincent Massol 05 Dec '12

05 Dec '12

Hi devs, We've agreed on the list of databases and browser we want to support but I couldn't find an agreement on the screen resolutions we want to support. I had in mind the 1280x1024 as the minimal resolution for laptop/desktop computers. Note that it's important to know this for the following reasons: * When we do our tests we should do them with various resolutions but especially with the minimum supported resolution * This is true for our automated tests (we run a vnc server in a given resolution on the jenkins agents) but also for the manual tests done by Sorin/Silvia/Manuel and everyone else WDYT? Once we agree I'll post the result on xwiki.org Thanks -Vincent

9 13

[xwiki-devs] [Proposal] Remove old info boxes/warnings for XWiki 1.x and 2.x
by Vincent Massol 04 Dec '12

04 Dec '12

Hi devs, I think it's time to clean up a bit our wiki on xwiki.org and remove old info messages about XWiki 1.x and 2.x. For example at the top of http://platform.xwiki.org/xwiki/bin/view/Features/RightsManagement We could keep XWiki 3.x and 4.x information for now. Thanks -Vincent

5 4

[xwiki-devs] [Contrib] XWiki Object Sort
by crocket 01 Dec '12

01 Dec '12

This message is in response to Sergiu Dumitriu I resent it to revive this thread. >- While I agree that being able to sort objects is important, I'd rather > see this in a patched version of the $sorttool instead of a separate >component; I've checked it and we'd just have to change the way >getComparable works. Doing this means that we're going to reuse a tool >that we're already supposed to be using for general sorting, and we'd >get as benefits the ability to specify a sort direction, and the ability >to mix properties and other object metadata, like owner document or >object number. I agree that the functionality in ObjectSort should go into $sorttool, but I have no influence over the development of XWiki, so I advertised it as a contrib project. What is getComparable by the way? >- Even as it is right now, I don't like that the script service only has >a getInstance method and then exposes the internal object. I thought that if I put just getInstance in the script service, I could reduce redundancy in the code. But I'm only a starting programmer. There are certainly better designs than mine. >- I don't think that both sort and sortCopy are needed. Only the method >that sorts a copy and returns it should be available. If only the method that sort a copy and returns it is available, there can be increased memory usage, so I introduced an in-place sort method, too. Why do you think an in-place sort method should not be available? >- sortCopyByProps should also be called just sort, since the type of >parameters passed will be enough for the right method to be called >(polymorphism). And I'm actually wondering if we need both methods or > not, since sorting by just one property could be done by passing a list >with just one member. You're right. I thought $services.objectsort. getInstance().sortByProps($doc.getObjects("Class"), ["port", "day:asc", "hour:desc"]) was possible but $services.objectsort.getInstance().sortByProps($doc.getObjects("Class"), "port") wasn't possible because I thought String couldn't be cast to List<String>. However, $services.objectsort.getInstance().sortByProps($doc.getObjects("Class"), "port") just worked out of box. I'll remove sort and sortCopy and rename sortByProps and sortCopyByProps to sort and sortByProps, respectively.

1 0

[xwiki-devs] Handling of property values indexing in Solr
by Jerome Velociter 01 Dec '12

01 Dec '12

Hello devs, This mail following a discussion we've had with Eduard on IRC concerning the indexing of object property values. On the current Solr implementation as well as on our lucene plugin, all property values are stored as text/strings. I've expressed the idea that we probably want to store each object's property in a field that matches the XClass property field type. For example, store integers in integer field types, double as doubles, etc. My personnal use case is to store geo objects (for example long/lat coordinates), but I think this has value for other types, numbers for example (it means you can use those numbers as such when querying for instance). Now this will increase the complexity of querying since you would have for example property_text, property_integer, property_double, etc. vs. just propertvalue. Again, I think this complexity should be hidden by the "expending API" Paul mentionned in the mail regarding document translations. WDYT ? Jerome

2 3

[xwiki-devs] [Contrib] Holiday Request Application
by Thomas Delafosse 30 Nov '12

30 Nov '12

Hello, I'm making a new Holiday Request Application, and I'm about to finish the first version. So I would like to have a github repo on xwiki-contrib for it. I would also need a maven groupId and a page for the project on extension.xwiki.org so I could describe it a bit further. You can already see the code of the application on my own github repo : https://github.com/tdelafosse/holiday-request. Thanks, Thomas

3 5

[xwiki-devs] [DISCUSSION] Handling document translations in Solr Search
by Eduard Moraru 29 Nov '12

29 Nov '12

Hi devs, This issue has already been previously [1] discussed during the GSoC project, but I am not particularly happy with the chosen approach. When handling multiple languages, there are generally[2][3] 3 different approaches: 1) Indexing the content in a single field (like title, doccontent, etc.) - This has the advantage that queries are clear and fast - The disadvantage is that you can not run very well tuned analyzers on the fields, having to resort to (at best) basic tokenization and lowercasing. 2) Indexing the content in multiple fields, one field for each language (like title_en, title_fr, doccontent_en, doccontent_fr, etc.) - This has the advantage that you can easily specify (as dynamic fields) that *_en fields are of type text_en (and analyzed by an english-centered chain of analyzers); *_fr of type text_fr (focused on french, etc.), thus making the results much better. - The disadvantage is that querying such a schema is a pain. If you want all the results in all languages, you end up with a big and expensive query. If you want just some language, you have to read the right fields (ex title_en) instead of just getting a clear field name (title). -- Also, the schema.xml definition is a static one in this concern, requiring you to know beforehand which languages you want to support (for example when defining the default fields to search for). Adding a new language requires you to start editing the xml files by hand. 3) Indexing the content in different Solr cores (indexes), one for each language. Each core requires it's on directory and configuration files. - The advantage is that queries are clean to write (like option 1) and that you have a nice separation - The disadvantage is that it's difficult to get it right (administrative issues) and then you also have the (considerable) problem of having to fix the relevancy score of a query result that has entries from different cores; each core has it's own relevancy computed and does not consider the others. - To make it even worst, it seems that you can not [5] also push to a remote Solr instance the configuration files when creating a new core programatically. However, if we are running an embedded Solr instance, we could provide a way to generate the config files and write them to the data directory. Currently I have implemented option 1) in our existing Solr integration, which is also more or less compatible with our existing Lucene queries, but I would like to find a better solution that actually analyses the content. During GSoC, option 2) was preferred but the implementation did not consider practical reasons like the ones described above (query complexity, user configuration, etc.) On a related note, I have also watched an interesting presentation [3] about how Drupal handles its Solr integration and, particularly, a plugin [4] that handles the multilingual aspect. The idea seen there is that you have this UI that helps you generate configuration files, depending you your needs. For instance, you (admin) check that you need search for language English, French and German and the ui/extension gives you a zip with the configuration you need to use in your (remote or embedded) solr instance. The configuration for each language comes preset with the analyzers you should use for it and the additional resources (stopwords.txt, synonims.txt, etc.). This approach helps with avoiding the need for admins to be forced to edit xml files and could also still be useful for other cases, not only option 2). All these problems basically come from the fact that there is no way to specify in the schema.xml that, based on the value of a field (like the field "lang" that stores the document language), you want to run this or that group of analyzers. Perhaps a solution would be a custom kind of "AggregatorAnalyzer" that would call other analyzers at runtime, based on the value of the lang field. However, this solution could only be applied at index time, when you have the lang information (in the solrDocument to be indexed), but when you perform the query, you can not analyze the query text since you do not know the language of the field you're querying (it was determined at runtime - at index time) and thus do not know what operations to apply to the query (to reduce it to the same form as the indexed values). I have also read another interesting analysis [6] on this problem that elaborates on the complexities and limitations of each options. (Ignore the Rosette stuff mentioned there) I have been thinking about this for some time now, but the solution is probably somewhere in between, finding an option that is acceptable while not restrictive. I will probably also send a mail on the Solr list to get some more input from there, but I get the feeling that whatever solution we choose, it will most likely require the users to at least copy (or even edit) some files into some directories (configurations and/or jars), since it does not seem to be easy/possible to do everything on-the-fly, programatically. Any input on this would be highly appreciated, specially if others have more experience with Solr setups. Thanks, Eduard ---------- [1] http://markmail.org/message/kaxaka7lsbgo57ms [2] http://lucidworks.lucidimagination.com/display/lweug/Multilingual+Indexing+… [3] http://drupalcity.de/session/language-specific-and-multilingual-full-text-s… [4] http://drupal.org/project/apachesolr_multilingual [5] http://stackoverflow.com/questions/4064880/create-new-core-directories-in-s… [6] http://info.basistech.com/blog/bid/171842/Indexing-Strategies-for-Multiling…

5 13

[xwiki-devs] [UX][Proposal] XWiki Mobile App
by Ecaterina Moraru (Valica) 28 Nov '12

28 Nov '12

Hi devs, For the Mobile App Investigation, Ludovic has been playing with a XWiki Mobile App prototype done with jQuery Mobile (http://jquerymobile.com/) This is a proposal for a mobile application that matches the jQuery Mobile framework capabilities and that provides minimal XWiki functionality (like listing wikis, spaces, pages, accessing content, viewing recent activity, etc.) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MobileApp Thanks, Caty

3 5

[xwiki-devs] OAI-PMH?
by Paul Libbrecht 28 Nov '12

28 Nov '12

Hello XWiki experts, has anyone started an OAI-PMH endpoint implementation? It seems to me that I could do this in Groovy and Velocity... but maybe I should rather use an existing library. If anyone has done a part of this, I'd be interest. thanks in advance Paul

1 0

[xwiki-devs] [Proposal] Roadmap for 4.4
by Vincent Massol 28 Nov '12

28 Nov '12

Hi devs, 4.4 and 4.5 are the last 2 stabilization releases for the 4.x cycle. As such they are meant to be short releases (1 month per release) and the idea is to have: - 4.4: December - 4.5: January This will allow us to start working on 5.0 at the beginning of February. Thus for 4.4 (and 4.5) I propose to work on the following stabilizations (we shouldn't work on new features): * AWM stabilization. Assignee: Marius ** Remove the i18n hack and use the new localization module to create a translation bundle for the application ** Add new field types (for page, image and attachment at least, with pickers) ** Improve the title and content fields (e.g. prevent dragging more than one title or content field) * Extension Manager. Specifically we still need to able to install/upgrade a wiki farm in a few minutes. Assignee: Thomas/Marius ** XWIKI-8252: Migration from an older version will cause many merge conflicts with the Distribution Manager ** XWIKI-8443: When uninstalling a XAR extension a question should be asked for various conflict use cases ** Find a way to allow having each wiki admin doing upgrade instead of upgrading the whole farm by a farm admin which don't always know how to fix conflict like in myxwiki.org for example ** XWIKI-8173 (EM should not allow installing package exposing an installed feature) * Translation module stabilizations/improvements. Assignee: Thomas ** XWIKI-8263 (Allow providing translations in a jar extension). * SOLR improvements: we need to continue working on it and we can decide in the course of 4.4/4.5 if it's good enough to be made the default search or if we need to wait for 5.x to make it the default. Assignee: Edy * Usability: small usability improvements. Assignee: Caty/JV. Caty/JV, could you please list what you'd like to work on? * Workspace bug fixes (there are some raised by Anca for example). Assignee: Edy * And a lot of bug fixes. Manuel reported a lot of browsers issue for IE that we need to fix Anything else committers/contributors would like to work on for 4.4? Dates ===== 4.4M1: 17 Dec 4.4RC1: 31 Dec 4.4Final: 7 January Note that I'd have normally put RC1 on 24th but since that's the Christmas holidays, I've given RC1 2 weeks instead. Can everyone review what I've put tentatively and tell me if it's ok? Also could you create the associated JIRA issues and reply to this email with them so that I can prepare the roadmap page on xwiki.org? Thanks a lot -Vincent

7 11