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

[xwiki-devs] [Proposal] Roadmap for XWiki 4.2
by Vincent Massol 05 Jul '12

05 Jul '12

Hi devs, It's Roadmap time again, this time for 4.2 :) We've brainstormed internally at XWiki SAS and here's below what we've come up with and that we are proposing for the 4.2 roadmap. Could all devs interested in participating please reply to the list below and mark what they're interesting in implementing (and assign themselves to jira issues). You can also propose other stuff from what is listed of course (what's listed is what is important from the POV of XWiki SAS). In this case please add them to this thread so that they can then be added to the Roadmap page. Dates ===== * 4.2M1: 9 July 2012 * 4.2M2: 6 Aug 2012 (Note: the whole XWiki SAS team goes to a 10 day seminar from 19 to 28 July and thus dev speed will be reduced during this period, this is why I've put 4 weeks instead of the usual 3). * 4.2RC1: 20 Aug 2012 * 4.2Final: 27 Aug 2012 Large features ============ * Continue the Extension Manager and finish implementing the following use case which was initially planned for 4.1: "be able to upgrade an xwiki farm in a few minutes" + bug fixes/polishing. Proposed devs: Thomas and Marius for the UI - TODO: Thomas to create the different jiras required to finish this task and list them here in the roadmap * Usability and more specifically home page experience improvement. Proposed devs: Caty and JV. - TODO: Caty to create the different jiras required to implement this task and list them here in the roadmap * AWM improvements: user fields, suggests, validation, automated naming of pages, doc title + doc content, app generation quality. Proposed devs: Marius + Sergiu for the autogeneration of page names (which was supposed to be done in 4.1 and slipped). - TODO: Marius to create the different jiras required to implement this task and list them here in the roadmap Specific JIRAs sorted by order of priority =============================== Most important jiras are listed first. * Be able to rename a space from the UI (also Rename Application) XWIKI-6722 * Add option to 'show more entries' on displaying the Activity Stream XE-748 * tag suggest feature does not work if Main.WebHome is not saved with programming rights XE-539 * PDF Export when CDATA section (generated by Livetable) XWIKI-7871 * Generate and register a document bundle for the application XWIKI-7371 (NOTE: This is the l10n module) * Improvements on Statistics * Improvements on Dashboard editing XWIKI-7681 * Auto-create Space.WebHome when creating a page in an underfined space XWIKI-5399 * The autosuggest widget should use the first_name and last_name instead of the user profile name XWIKI-7696 * Occasionally the livetable fails to load on index pages XE-844 * Add more/all configuration parameters in the wiki administration (activate Stats for a given wiki) XWIKI-7066 * Applications entry point XWIKI-7927 * Log-in automatically on registration XWIKI-6892 * Auto-suggest doesn't work for global users XWIKI-6207 * Import / export perf improvement * Wrong date should not be accepted (in poperties of type Date) XE-1103 * "When a ssx / jsx is included manually with prefixed full name and also * included with ""always on this wiki"" then it is actually included twice" XWIKI-7702 * Tracking Active Installs * Messages sent to global users from a subwiki are not displayed in the global user's profile but only in subwiki's activity stream. XWIKI-6668 * XWiki is not able to automatically start OpenOffice daemon on Windows Server XWIKI-7510 * Cannot filter using "/" on a Date column in the livetable XWIKI-5889 * Change stylesheet and javascript extension filename when a modification is done on those XWIKI-6073 * Problems displaying the correct attachment version when using a proxy XWIKI-6569 * Modifing attachments when viewing only attachments for a page with ?viewer=attachments redirects to the Document#Attachments url instead of the ?viewer=attachments XWIKI-7719 * PDF Export of document created with app within minutes only displays values of fields (no labels) XWIKI-7868 * Suggest improvements * New XWiki Syntax Guide XE-880 * Importing does not delete attachments from previous version XWIKI-7587 * Mobile Skin * Attachment storage, better handling XWIKI-7587 * Profile Improvements XWIKI-6307 * Add Required and Hint meta properties for class fields XWIKI-7373 * XWiki automatically connect to an external openoffice daemon XWIKI-7509 * Page creation date should be the date of the installation XWIKI-7058 * When using filesystem attachments with attachment versioning disabled, deleted attachments are duplicated on the hard disk. XWIKI-6951 * Deleted attachments duplication in recycle bin while File Storage is on XWIKI-6917 * Performance of blog category panel is still not enough XWIKI-6363 * Better placement of the documentation link XE-1031 Investigations =========== - Home Page Changes Proposals - Caty - 4.x Skin - Caty - Title Handling: Decide page name vs title, make title mandatory, make title readable when using scripting, etc - Caty/Vincent - More configuration options available from Administration - Caty/Vincent We also need a RM for 4.2. Volunteers welcome! :) Thanks -Vincent

5 10

[xwiki-devs] [Proposal] Macro parameter name spaces.
by Andreas Jonsson 05 Jul '12

05 Jul '12

Hi, For some macros, the parameter situation can become very complex. The chart macro is the obvious example, where several different aspects can be independently configured. I will therefore propose adding support for namespaces in macro parameters. This example illustrates the idea: public class ChartMacroParameters { private String title; private DatasetType datasetType; private DatasourceType datasourceType; private LocaleConfiguration locale; private AxisConfiguration domainAxis; private AxisConfiguration rangeAxis; private DatasetConfiguration dataset; private DataSourceConfiguration datasource; } {{chart datasourceType="xdom_table" datasetType="timetable_xy" domainAxis:type="date" locale:timeformat="yyyy" datasource:range="A1-B."}} I have already implemented a bean manager for this and can commit it if this proposal is accepted. But maybe we want the name space support already in the default bean manager? I'm also thinking that the bean manager should set the values in the base bean before proceeding with the sub-beans. This would make it possible to instantiate the sub beans differently depending on some configured value, for instance: public DataSourceConfiguration getDatasource() { if (datasource == null) { switch (datasourceType) { case XDOM_TABLE: datasource = new XDOMTableDatasourceConfiguration(); break; case INLINE_TABLE: datasource = new InlineTableDatasourceConfiguration(); break; // etc. } return datasource; } } Best Regards, /Andreas

1 0

Re: [xwiki-devs] [xwiki-users] Announcing Curriki-1.11
by Paul Libbrecht 05 Jul '12

05 Jul '12

thank you Arloch, Here is the corrected link: http://xclams.xwiki.org/ paul Le 5 juil. 2012 à 09:10, Arioch a écrit : >> http://xclams.currikirg > > broken link, hope only in this announcement > > > -- > View this message in context: http://xwiki.475771.n2.nabble.com/Announcing-Curriki-1-11-tp7580161p7580170… > Sent from the XWiki- Users mailing list archive at Nabble.com. > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users

1 0

[xwiki-devs] Announcing Curriki-1.11
by Paul Libbrecht 05 Jul '12

05 Jul '12

The Curriki team is happy to announce that Curriki-1.11 is released in source trees and deployed on www.curriki.org. It is made of: - XCLAMS branch curriki-1.11 (maven version 1.11.1) - CurrikiSolr, 1.2 (maven version 1.2.1) - a set of Apache rewrite rules and xwiki configurations We are particularly proud of this release because it updates us to XWiki 3.5 which brings access to new useful features for our platform such as attachments delivered from files and a much stronger monitoring. Supplementary to these, this release bring us: - an enriched registration with the required user-location - a considerable performance boost for the content-tree-view (views of collections when you add or organize) More information about XCLAMS, the XWiki Collaborative Learning Assets Management System is at http://xclams.currikirg More information about the Curriki platform is at http://www.curriki.org/xwiki/bin/view/Main/About The detailed issue-based release notes is here: http://jira.xwiki.org/secure/ReleaseNote.jspa?projectId=10160&version=12108 Paul

3 3

[xwiki-devs] [Video] XWiki-G3 demo - Distributed XWiki cluster storing native Java objects
by Caleb James DeLisle 04 Jul '12

04 Jul '12

Hi, Over in the XWiki Research Department, we've been working on some exciting new developments. While XWiki provides industry leading flexibility for defining, storing and querying data structures in SQL based stores, we are researching how to bring storage to Cassandra distributed NoSQL data store and give you the power to define and store your own true Java native Objects. In this demonstration we run 2 integrated XWiki/Cassandra nodes and show changes propagating from one to the other as we edit pages. We show that you can stop one node and the wiki is still fully functional with only one node running. Then we restart the downed node and show the edits which were made while the node was down propagating over from the running node. Here is the demonstration video: http://www.youtube.com/watch?v=NngAKdeWuH0 While this is still in heavy development, we hope to be bringing up live nodes for you to play with as soon as possible. Thanks, Caleb

4 5

[xwiki-devs] Fwd: [ANN] Apache FOP 1.1rc1 Released
by Sergiu Dumitriu 04 Jul '12

04 Jul '12

Something new on the FOP front as well (we're using FOP for PDF export): -------- Original Message -------- Subject: [ANN] Apache FOP 1.1rc1 Released Date: Tue, 3 Jul 2012 19:29:25 -0600 The Apache XML Graphics team is pleased to announce the immediate availability of Apache FOP Version 1.1rc1 [1], the first candidate for an upcoming stable 1.1 release. Apache FOP (Formatting Objects Processor) [2] is an output independent print formatter driven by XSL Formatting Objects (XSL-FO) [3]. FOP is a Java application that reads a formatting object tree and renders the resulting pages to a specified output format, of which a variety of formats are supported. Apache FOP is published under the Apache License v2.0. This candidate release will be available for testing for at least one month, after which a stable release is occur. Feedback is welcome, and we would like to encourage as many people as possible to try it out and report bugs and issues on the fop-users [4] or fop-dev [5] mailing lists (as appropriate). This release fixes a number of bugs and provides important performance improvements. In addition the following significant functional enhancements are provided: - Adds support for complex scripts (e.g. Arabic, Indic, etc), aka the "complex text path". - Adds possibility to embed TrueType fonts in the PostScript output. - Adds possibility to reduce the file size of accessible PDF outputs by using Object Streams (a PDF 1.5 feature). - Adds support for 128bit PDF encryption. For release notes see [6]. Source and binary distributions can be downloaded from an ASF Mirror at [7]. Further download information is available at [8]. [1] http://xmlgraphics.apache.org/fop/1.1rc1/index.html [2] http://xmlgraphics.apache.org/fop [3] http://www.w3.org/TR/xsl11/ [4] http://xmlgraphics.apache.org/mail.html#fop-users [5] http://xmlgraphics.apache.org/mail.html#fop-dev [6] http://xmlgraphics.apache.org/fop/1.1rc1/releaseNotes_1.1rc1.html [7] http://www.apache.org/dyn/closer.cgi/xmlgraphics/fop [8] http://xmlgraphics.apache.org/fop/download.html On behalf of the XML Graphics team, Glenn Adams

1 0

[xwiki-devs] [GSOC][doubt] Solr Search Component
by savitha sundaramurthy 04 Jul '12

04 Jul '12

Hi all, While trying to retrieve the search results had the following doubts. *Problem: * * * * *Say XWiki has three languages English, Spanish, French. I give a query in English(some *proper noun*) , should it return the documents pertaining only to english or it can return documents pertaining to other languages too? If the scenario is such that it retrieves the documents irrespective of languages, I have few ideas to deal with it. 1) We can get the documents, merge them, add the scores and give it a high rating. This would help to avoid super results such as a display of a different match in each language to some extent. 2) Make it a part of facet search , where search results could be differentiated base don language. Would be really helpful to gain your suggestions. -- Thanks a lot, Savitha.s

6 12

[xwiki-devs] [GSoC] please share xwiki data to test intensively the solr implementation
by Paul Libbrecht 04 Jul '12

04 Jul '12

Dear XWiki community, Savitha's SOLR implementation is starting to be available and more and more precise wishes are coming up which is really good. Thus far, we only have a handful of documents available to test the tool, which we create manually... this is not very realistic. Would it be possible that administrators of XWiki platforms share (privately?) with us the xar of (almost) their complete wiki? Maybe users need to be scrubbed before (which is easy in a xar) but otherwise, it'd be interesting to get complete wikis. There are important aspects that are changed when having a considerable amount of data. For example, the scoring gets much more important since you don't want to go through the list of all results. Also facetting gets more interesting. Ideally there should be: - one multilingual xwiki - one highly structured xwiki (with loads of objects) - one rather regular editorial xwiki Savitha can probably try external datasets, e.g. even from TREC or from wikipedia, but this is a lot more artificial and a bit more work. Her limit is 8Gb of overall disk space. Sharing your wiki data with this project would make it that the solr search would run sensibly on your wiki in the future. Paul

1 0

[xwiki-devs] [VOTE] Clirr excludes for 'ChartModel' in xwiki-platform-chart
by Andreas Jonsson 04 Jul '12

04 Jul '12

Hi, This vote is about adding the following three clirr excludes: * This interface is completely refactored: <exclude>org/xwiki/chart/model/ChartModel</exclude> * This class is removed: <exclude>org/xwiki/chart/model/DefaultChartModel</exclude> * The constants 'SOURCE' and 'PARAMS' are removed from this interface: <exclude>org/xwiki/rendering/macro/chart/ChartDataSource</exclude> I am refactoring the chart macro and the interface 'ChartModel' is could previously only be used for producing table-like datasets, but the jfree chart library can produce plots from a wide range of dataset types. So the new version of the interface is instead used for delivering the dataset and the axis configuration to the chart generator. I have deliberately choosed to not try abstracting away the fact that the chart macro uses the jfree chart library. Doing so would require introducing a large number of wrapper classes that would duplicate the functionality existing classes and it would still not be particularly easy to just plug in another chart library. Here is my +1. Best Regards, /Andreas

3 4

[xwiki-devs] [Video] XWiki-G3 demo - XWiki cluster storing native Java objects in Cassandra distributed store.
by Caleb James DeLisle 04 Jul '12

04 Jul '12

Hi, Over in the XWiki Research Department, we've been working on some exciting new developments. While XWiki provides industry leading flexibility for defining, storing and querying data structures in SQL based stores, we are researching how to bring storage to Cassandra distributed NoSQL data store and give you the power to define and store your own true Java native Objects. In this demonstration we run 2 integrated XWiki/Cassandra nodes and show changes propagating from one to the other as we edit pages. We show that you can stop one node and the wiki is still fully functional with only one node running. Then we restart the downed node and show the edits which were made while the node was down propagating over from the running node. XWiki documents and objects are stored in an integrated Cassandra NoSQL Cloud data store allowing for horizontal scalability without any single point of failure. Users can define XClasses using the XWiki class creation interface and those XClasses are compiled into native Java classes which can be loaded and stored in the Cassandra distributed store. Here is the demonstration video: https://www.youtube.com/watch?v=NngAKdeWuH0 While this is still in heavy development, we hope to be bringing up live nodes for you to play with as soon as possible. Thanks, Caleb

1 1