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

[xwiki-devs] Release managers wanted for 4.2M1 and 4.1.3

by Vincent Massol

Hi eveyrone, Today is our release date for 4.2M1 (see http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap). We also need to release 4.1.3 ASAP. Thus we need two Release Managers (RM)? Any volunteer? Thanks -Vincent

13 years, 2 months

1
1
0 0

Re: [xwiki-devs] [GSoc] Responsive Skin - markup semantics

by Jonathan Solichin

Hi Jerome, friends, > * Would it make sense to use <aside> for the right sidebar ? The aside is actually only for the comments, attachments, history and info sections of the sidebar only. The reason behind this is that according to html5 specs: > > The aside element represents a section of a page that consists of content that is tangentially related to the content around the asideelement, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography. ( http://html5doctor.com/understanding-aside/) which I thought is appropriate for those sections. > > * I've seen you've used <article> as an overall wrapper. Wouldn't <section> > be more appropriate, with articles implemented within the content of the > document ? (BTW this leads to the question of how this would translate in > wiki syntax. So far there is no such notion built right in - though .it > could be implemented with macros). The reason I used article as an overall wrapper for the "main content" (the stuff with the white background), according to the html5 specs: > > "The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content." ( http://html5doctor.com/the-article-element/) I thought this is appropriate since the entire "main content" is the self contained part of the page that can be independent of the other parts (like menu, asides, sidebars etc.) The use of section I thought is appropriate because each gadgets is in a way a section/part of the overall article, and of the sidebar. > > "The section element represents a generic document or application section" (http://html5doctor.com/the-section-element/) These are just my thoughts on the components of a webpage of xwiki, however. Do you think this is not the correct interpretation of the xwiki parts? Thanks for looking into the code! Jonathan Solichin

13 years, 2 months

3
2
0 0

Re: [xwiki-devs] [GSoC] Responsive Skin

by Jonathan Solichin

Hello friends, > But actually I wouldn't advise to overload macros.vm, from experience it > becomes a maintenance hell over the long term. I can see how that can happen. Unfortunately, I think it was the best way to do it, because I converted the menu and sub menu system to a list instead of span to work with the css hovers. Additionally, isn't it more semantic this way, or was there a reason it is this way that I did not realize? Regarding this change, my only observation is an usability one. What are > the most common actions a user will want to do on this page? Navigate away > from the page? See comments? See informations? > IMO edit action should not be the last in the menu. Maybe you could move > edit and export to be more visible or closer to the content. A quick > solution would be to put the items in the beginning of the list and not at > the end. This way the user doesn't need to scroll all the way down for > them. Makes sense. The change has been made in the implementation (xo5) There are, actually, a couple of mandatory files XWiki will look for (like > view.vm, edit.vm, etc. all those that are referenced from struts actions > in > java) ; but if they aren't found, XWiki will look for them upstream : in > the parent skin (if there is one), then in templates/ folder. So nothing > really is mandatory for a skin to implement, you just override what you > need to. If you look into Lyrebird you'll there are far less templates > than > in colibri. It's due both to the fact that for some feature the skin just > uses the colibri version (because it works fine) and the fact some > templates in lyrebird aggregates what is several templates in colibri, to > make it simpler. This is a good explanation, and confirmed what I thought. Thanks! All those are legitimate questions :) it takes some getting used to and > some experience to grasp the whole skin architecture. For lyrebird I knew > where I wanted to go, so I implemented that by either : > * adapting (CSS tweaks, reuse of velocity macros, etc.) colibri features > (ex: breadcrumb), or > * re-writing the feature entirely (ex: top navigation bar, edit mode > controls/inputs) > But I'm a bit biased since I know the whole structure of colibri well > enough to arbitrate this quickly. Thanks for the insights No you're right fundamentally you don't need a maven build since for now > skins can't be distributed as extensions (but will in the future). But it > makes things easier anyway for releasing (creating a SCM tag with an > associated version), for creating the zip, etc. > Practically, the build could also permit to minify JS and CSS files, > filter > out some resources, or do some other operation required before > distribution. Ok, I will keep this is mind as I progress further. Progress: a lot of the skin has been implemented (enough to work mostly?). I am still having a bit of issues that I got stuck on, however. - The biggest head scratchier I have right now is the historyinline.vm that I am putting in the sidebar. All the other components of docextra.vm seems to be working fine. But when I turn on the line that pulls in historyinline.vm, the contents in mainContentArea disappears? I tried messing with historyinline.vm, but I can't figure out what is causing it. The history ui and controls works fine, it's just the document oddly disappears. (The way I am turning it off/on is in the sidebar.vm, I put a "!" on line 22 to reverse the if-- causing history to disappear if the document asks for it. The current historyinline.vm is straight from the template). Any idea? - Second, I can't find any mention of the gadget wrappers or anything to do with gadgets in the templates? Did I miss it, or is it placed elsewhere. The reason is I want to add a <section> wrapper as per html5, since each "gadgets" are a "section" of the articles/content, correct? I will touch upon this in email regarding semantics. As always, source (for implementation) is at: https://github.com/jssolichin/xo5 Thank you again for all the help and insights! Jonathan Solichin

13 years, 2 months

2
1
0 0

[xwiki-devs] [GSoC] Solr multilingual support.

by savitha sundaramurthy

Hi devs, Here are my thoughts on the configuration for multi lingual support. Solr uses different analysers and stemmers to index wiki content. This is configured in a XML file, schema.xml. The wiki content with english language is indexed with text_en field type whereas french with text_fr field type. The language of the document is fetched and appended to the field. ( fieldName +"_"+ language : title_en, fulltext_en, space_en ). Configurations below:  <fieldType name="text_en" class="solr.TextField" positionIncrementGap="100"> <analyzer type="index"> <tokenizer class="solr.StandardTokenizerFactory"/> <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" /> <filter class="solr.SynonymFilterFactory" synonyms="index_synonyms.txt" ignoreCase="true" expand="false"/> <filter class="solr.LowerCaseFilterFactory"/> <filter class="solr.EnglishMinimalStemFilterFactory"/> </analyzer> </fieldType>  <fieldType name="text_fr" class="solr.TextField" positionIncrementGap="100"> <analyzer> <tokenizer class="solr.StandardTokenizerFactory"/>  <filter class="solr.ElisionFilterFactory" ignoreCase="true" articles="lang/contractions_fr.txt"/> <filter class="solr.LowerCaseFilterFactory"/> <filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_fr.txt" format="snowball" enablePositionIncrements="true"/> <filter class="solr.FrenchLightStemFilterFactory"/>   </analyzer> </fieldType> In the case of a document having multilingual text, say english and french. There is no way to find the list of languages used in the document. Is it good to use a language detection tool, http://code.google.com/p/language-detection/ to get the list of languages, if they are more than two use a multilingual field type ? title_ml, space_ml, fulltext_ml, ml for multilingual.  <fieldType name="text_ml" class="solr.TextField" positionIncrementGap="100"> <analyzer> <tokenizer class="solr.StandardTokenizerFactory"/>  <filter class="solr.LowerCaseFilterFactory"/> <filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_fr.txt" format="snowball" enablePositionIncrements="true"/> <filter class="solr.EnglishMinimalStemFilterFactory"/> <filter class="solr.FrenchLightStemFilterFactory"/> <filter class="solr.SpanishLightStemFilterFactory"/> </analyzer> </fieldType> The list of analysers should match the languages supported by XWik instance. Am planning to use language detection only to check whether text from multiple languages exist. Will investigate if its possible to configure the analysers on the fly based on the languages returned by the language-detection tool. Please suggest,if this is a right approach ? -- Thanks, Savitha.s

13 years, 2 months

3
5
0 0

[xwiki-devs] [GSOC] Basic Solr Implementation

by savitha sundaramurthy

Hi All, I have come up with the basic Solr Search Component. Have included features such as hit highlighting. You can find a running instance of the component here. http://ec2-50-19-181-163.compute-1.amazonaws.com:8080/xwiki/bin/view/Search… Below is the link to the documentation and the progress of the project. http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/SOLRsearchcomponent API http://dev.xwiki.org/xwiki/bin/view/Design/SOLRSearchIntegration Basic multi lingual support, and basic facet search are in progress to be implemented for the coming week. Kindly give your suggestions. -- Thanks a lot, Savitha.s

13 years, 2 months

4
6
0 0

[xwiki-devs] [VOTE] Move Chart plugin to contrib/retired

by Vincent Massol

Hi devs, I'm proposing to move the chart plugin from oldcore and to move it to contrib/retired (without moving the history). The rationale is: * It's old and I'm pretty sure it's not fully working (I doubt that the chart wizard works well for example). It has no automated tests at all actually. * It's been replaced by the XWiki Rendering Chart macro Here's my +1 Thanks -Vincent

13 years, 2 months

6
6
0 0

[xwiki-devs] [VOTE] Use document author instead of context user in wiki macro listener

by Thomas Mortagne

Hi devs, Currently the wiki macro is looking at context user when a wiki macro is modified. This is causing a lot of complexity and misunderstanding so I would like to change that to look at document author instead. * all we at at startup is document author anyway so if you restart that what XWiki will look at to register the macro so I don't see the point in not doing the same thing at runtime * context user makes more complex to make sure wiki macro are properly registered in background thread like clustering (http://jira.xwiki.org/browse/XWIKI-7318) and extension manager jobs (http://jira.xwiki.org/browse/XWIKI-8004) WDYT ? Here is my +1 -- Thomas Mortagne

13 years, 2 months

6
8
0 0

[xwiki-devs] [VOTE] Fix typo in org.xwiki.properties.PropertyDescriptor#getFied()

by Thomas Mortagne

Hi devs, There is a typo in org.xwiki.properties.PropertyDescriptor#getFied() so in order to fix it I need to deprecate it and add new getField() method. Since addinf a new method makes me add an CLIRR exclude, here is the VOTE. Note that in practice this interface is supposed to be implemented only by internal class so it's not going to break anyone. WDYT ? Here is my +1. -- Thomas Mortagne

13 years, 2 months

7
7
0 0

[xwiki-devs] [GSoc] Responsive Skin - markup semantics

by Jerome Velociter

Hi Jonathan, everyone, I've checked out the markup of the skin. I have two questions : * Would it make sense to use <aside> for the right sidebar ? * I've seen you've used <article> as an overall wrapper. Wouldn't <section> be more appropriate, with articles implemented within the content of the document ? (BTW this leads to the question of how this would translate in wiki syntax. So far there is no such notion built right in - though .it could be implemented with macros). WDYT ? Jerome -- Jérôme Velociter Winesquare http://www.winesquare.net/

13 years, 2 months

1
0
0 0

Re: [xwiki-devs] [GSoC] Responsive Skin

by Jonathan Solichin

Hello friends, > - not every entry in the toolbar should have a counter, for example Main, > History, Info is confusing to have counters. The only relevant counters > IMO > are the Comments, Annotations, Attachments; oops, copy and paste carelessness. Thanks - the .nav-icons section could work as a toolbar and every action could > take you to the appropriate anchor (for example: clicking on the > history-clock icon should take you to #history) > - when you are using the .nav-control, the items in the navigation have > counters near the type, like "Attachments 3". Would be nice to have this > counter too when manually scrolling the navigation, like have the counter > not only on .attachments-link but also on #attachments-wrapper h2 Good calls, implemented. - in recent versions of XWiki (since 4.0) Comments are merged with > Annotations - good to know that :) * I think by default Annotation and Comments UIs should be merged, just > like they are now on a standard XE. Thank you, for the notice. > - "Main" section content: "Last Modified", "Created", "Tags" can be put in > the "Information" section although the last editor could be put near the > page title somewhere in order to be able to scan rapidly; - you could have a separate "Actions" section that contains page actions: > edit, export, etc. I moved the modified/created/tags into the information-- makes more sense. I created two new icons: edit and export to keep "edit" and "export" visible and more uniform/extendable (can have more options). What do you think of this solution? Or do you think I should consolidate edit and export into "actions"? I grouped it in that way originally (or at least in the source, and visually), but I thought as a section itself it might have been too vague/doesn't really convey what "actions" are, until you click on it--so I opted to separate them so it's more apparent what the viewer can do. Let me know what your opinion is on this. - "Main" naming of the section is kind of confusing since "Main" is also > the name of a space in XWiki. If you removed the things mentioned above > you > can call it "Navigation" or something else, since it will contain table of > content, quicklinks, recent, etc. (mostly panels content) Makes sense. Thanks Just for your information, I don't know if you've read my proposal about > Collaborative Editing > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CollaborativeEditi… Thank you, seems really interesting. Beautiful graphs/statistics are super engaging. The collaborative tool I think is definitely really useful as well--I know it is a big sticking point for gdocs. Although the topic is different from your project, you can see some mockups > of another possible skin for XWiki. Is build with Twitter Bootstrap just > like Jerome's Lyrebird. Could be useful to have as inspiration or at least > to know about it. yes, it has been very useful to learn more as I integrate. First, great work overall. I think we are on the right track to make > something great out of this summer of code! Thank you. Definitely great support from you and the community. Learning a lot in the process. I think the next step is to start integrating with XWiki. We'll probably > hit more real world problems doing this :) I agree, I have started doing this, but am already running into a few problems. The last couple days I was cleaning up the code/optimizing to prepare for this. I now tested the codes in firefox/chrome/opera/safari & android/wp/ blackberry(minor issue with it's inability to rotate text--thinking of a solution). The code also now implements html5 elements. You can create a repo on your github account or we can create one in > xwiki-contrib if you prefer. What you be great would be to have a pom.xml > for it, you can take inspiration from the one I've made for Lyrebird for > example. I can help you with that if you need. Here is the github for the implementation: https://github.com/jssolichin/xo5 I have a question about this. I know pom.xml is used to build for maven, but is it necessary for a skin/what other purpose does it serve? At the moment I'm just dropping files into: "webapps\xwiki\skins\"--since when I build Lyrebird, i get the xar (which i uploaded through the admin--something I don't see is needed yet since they are just configuration files for the skin right?) and the zip (which i unzip into the skins directory). Sorry If I am missing something big. Also, here is my understanding of xwiki skin, correct me if I'm wrong ( http://platform.xwiki.org/xwiki/bin/view/DevGuide/Skins seems to mostly be overriding than an overall change--is there another guide I am not seeing?). XWIKI sees the skin folder and looks for .vm files. If a .vm is not found in that skin's folder, it goes to the .vm in the templates folder. .vm calls on other .VMs for parts. My questions are: *Is there a way to see which .vm something is coming from? like a developer view or sth, that shows where all the parts are coming from (presently I am just ctrl+f the folder for a markup nearby to the things I want to change/add--doesn't seem to be very efficient.) *Is there a list of default .VMs that xwiki looks for? (this maybe over simplifying it, but like in wordpress, a skin has a core of index.php(main landing page), single.php(each post), archive.php (search/archive) etc. and they call on arbritary .php parts (eg. header.php, footer.php etc.)). Or am I thinking about this the wrong way? *I know this sounds a little bit vague, but what was your workflow in implementing bootstrap? I have to admit, I'm a little bit lost, and I'm afraid that I am going about this all the wrong way. *A more specific question, which you may not have time to answer, but presently I am stuck in coding the global breadcrumb section. So the way I am seeing it, it is being pulled from the menuview.vm, which calls upon macros.vm. I am changing the macros.vm (say to remove the down triangle ▼ ), but it seems that it is not changing the skin at all. Am I doing this incorrectly?/is there a cache not clearing? (this is in the repo xo5) On Code Style (http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle): *If I click the velocity, it leads me to an editor and not an article? Couple of random remarks : > * we need to think how the "search suggest" (search results as you type) > will integrate what if it replaces the main content area (where the article is for that page)? > * you can also start to think about the "edit" mode (say with the WYSIWYG > editor to begin with). Ok! Sorry if this all sounds really basic/there is an article that I am not reading (or I am missing/didn't see). If you could point me in the right direction, that would be sweet. Thank you again for all the patience and support! Best, Jonathan Solichin

13 years, 2 months

3
3
0 0

[xwiki-devs] [Proposal] Roadmap for XWiki 4.2

by Vincent Massol

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

13 years, 2 months

5
10
0 0

[xwiki-devs] [Proposal] Macro parameter name spaces.

by Andreas Jonsson

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

13 years, 2 months

1
0
0 0

Re: [xwiki-devs] [xwiki-users] Announcing Curriki-1.11

by Paul Libbrecht

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

13 years, 2 months

1
0
0 0

[xwiki-devs] Announcing Curriki-1.11

by Paul Libbrecht

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

13 years, 2 months

3
3
0 0

[xwiki-devs] [Video] XWiki-G3 demo - Distributed XWiki cluster storing native Java objects

by Caleb James DeLisle

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

13 years, 2 months

4
5
0 0

[xwiki-devs] Fwd: [ANN] Apache FOP 1.1rc1 Released

by Sergiu Dumitriu

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

13 years, 2 months

1
0
0 0

[xwiki-devs] [GSOC][doubt] Solr Search Component

by savitha sundaramurthy

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

13 years, 2 months

6
12
0 0

[xwiki-devs] [GSoC] please share xwiki data to test intensively the solr implementation

by Paul Libbrecht

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

13 years, 2 months

1
0
0 0

[xwiki-devs] [VOTE] Clirr excludes for 'ChartModel' in xwiki-platform-chart

by Andreas Jonsson

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

13 years, 2 months

3
4
0 0

[xwiki-devs] [Video] XWiki-G3 demo - XWiki cluster storing native Java objects in Cassandra distributed store.

by Caleb James DeLisle

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

13 years, 2 months

1
1
0 0

Re: [xwiki-devs] [GSoC] Responsive Skin

by Jonathan Solichin

Hello friends, Just wanted to say, I figured out the issue with my changes not loading. the macros.vm was getting cached. I put the following lines in xwiki.properties to stop it. velocity.properties = file.resource.loader.cache = false velocity.properties = velocimacro.library.autoreload = true I hope this is the best solution. Thanks JS

13 years, 2 months

2
1
0 0

[xwiki-devs] Fwd: [GSoc] XDroid Platform

by sasinda rukshan

---------- Forwarded message ---------- From: sasinda rukshan <sasindarukshan(a)gmail.com> Date: Mon, Jun 18, 2012 at 2:56 PM Subject: Re: [xwiki-devs] [GSoc] XDroid Platform To: XWiki Developers <devs(a)xwiki.org> Hi Thomas, Thanks for the explanations. The methods toXML , toEmbedXML are wrong.It was just an idea that came up without much thinking. I will use a separate model converter.(xwikitTosimpleModelConverter implements ModelConverter like thing). So the model objects don't know about it at all. By what you ment by "user" I think it is the client app developer is it? you did not mean end user. I never reveal the xml representations to end users. I came up with a simpler design. I will post diagram later tomorrow. To give a brief on it, XObject : has protected property List<XProperty> |__XPoperty :<< all objects that can be added as a property of an objects should extend this. Has an attribute list. cancels the | property list of XObject | |_____XString : |__Abstract XDocObject :<< all documents should have an object of this. This is the pages class. Has a object List<XObject> | |____XBlog :<< all documents which are blogs should have a object of this. This determines the class of the object. | but this data is not posted anywhere in <link rel="...../class"> . It is just kept for type checks. That is like | this page should include XBlogPost objects. |__XBlogPost : <<the BlogPostClass object. In my view I assume every page has an object of some class. And this object holds the objects which you can get under .../pages/BlogPg1/objects/ [ an added advantage: I think we can make a ViewEngine to generate android View components from the above model. Since the objects in the page carry rendering descriptions.We can make a general model like a browser to brows xwiki using generated the views. But the problem is some features in specific spaces like blog do not seem to be totally defined by the XWiki Object model behind them. Also this is just an idea (not suggesting I do for the GSoc).Making it a usable reality is a little challenge. ] So as you said if a document (I think it equivalent to a page) can have many class types my assumption fails. Why should a document be of multiple classes. I was thinking a page belongs to a class. And the page is an instance of that class. If page can have multiple classes my understanding should be wrong. Isn't it? Thanks Best Regards Sasinda. > >>>> >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne > >>>> >>>> > <thomas.mortagne(a)xwiki.com>wrote: > >>>> >>>> > > >>>> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan > >>>> >>>> >> <sasindarukshan(a)gmail.com> wrote: > >>>> >>>> >> > Hi, > >>>> >>>> >> > I am studying ORM Lite these days. > >>>> >>>> >> > Please It would be comforting if you can confirm whether it > is > >>>> worth > >>>> >>>> >> > the > >>>> >>>> >> > overhead to use ORM Lite. > >>>> >>>> >> > > >>>> >>>> >> > >>>> >>>> >> > >>>> > http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projec… > >>>> >>>> >> > http://ormlite.com/ > >>>> >>>> >> > ORM Lite features: > >>>> >>>> >> > Automatically Creates standard DAOs for an annotated entity. > >>>> >>>> >> > Coding will be lot easier. > >>>> >>>> >> > >>>> >>>> >> Remember it's a framework for a mobile platform so it has to > >>>> remain > >>>> >>>> >> light and have good performances. I can see that Android > version > >>>> of > >>>> >>>> >> ormlite is very small but I never used it so I don't know if > >>>> it's good > >>>> >>>> >> or not. At least it seems petty active which is a good point > so I > >>>> >>>> >> don't have anything against it. > >>>> >>>> >> > >>>> >>>> >> > > >>>> >>>> >> > Can you suggest how to name the entities. > >>>> >>>> >> > I am going to go with, > >>>> >>>> >> > <entity> org.xwiki.xdroid.data.User --> <table> C_USER > >>>> >>>> >> > >>>> >>>> >> Note that there is already a package name prefix and group id > >>>> defined > >>>> >>>> >> for the framework and it's org.xwiki.android as you can see on > >>>> >>>> >> https://github.com/xwiki-contrib/android-client. Why do you > >>>> want to > >>>> >>>> >> change it ? It's more consistent with > >>>> >>>> >> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I > >>>> would > >>>> >>>> >> prefer to keep it that way unless you can give arguments. The > >>>> goal is > >>>> >>>> >> not to redo something completely but complete and improve the > >>>> existing > >>>> >>>> >> framework. > >>>> >>>> >> > >>>> >>>> >> Also as far as I can see there is already several things > called > >>>> >>>> >> "xdroid" on Google play among which an application developer > >>>> >>>> >> (https://play.google.com/store/apps/developer?id=x-droid) > and an > >>>> >>>> >> application ( > >>>> >>>> >> > >>>> >>>> >> > >>>> > https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdro… > >>>> >>>> >> ). > >>>> >>>> >> > >>>> >>>> >> > > >>>> >>>> >> > Thanks, > >>>> >>>> >> > Best Regards > >>>> >>>> >> > > >>>> >>>> >> > Sasinda. > >>>> >>>> >> > > >>>> >>>> >> > > >>>> >>>> >> > > >>>> >>>> >> > > >>>> >>>> >> > > >>>> >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan > >>>> >>>> >> > <sasindarukshan(a)gmail.com>wrote: > >>>> >>>> >> > > >>>> >>>> >> >> Hi, > >>>> >>>> >> >> > >>>> >>>> >> >> I am commiting my work to my fork > >>>> >>>> >> >> https://github.com/sasinda/android-client. > >>>> >>>> >> >> I ll request to pull it to xwiki-contrib later. > >>>> >>>> >> >> > >>>> >>>> >> >> I was running in a wrong path these days. Wanted to save > login > >>>> >>>> >> >> history > >>>> >>>> >> and > >>>> >>>> >> >> suggest login. I was going to do it using an xml file > (login > >>>> >>>> >> attempts.xml). > >>>> >>>> >> >> Now it seems database is better. > >>>> >>>> >> >> Any way before I go wrong again I will say what I am going > to > >>>> do. > >>>> >>>> >> >> I am going to enforce following conventions.These are not > yet > >>>> >>>> >> >> needed, > >>>> >>>> >> >> considered the small scale.But when the system grows it > would > >>>> be > >>>> >>>> >> >> nice to > >>>> >>>> >> >> have them to avoid confusions. > >>>> >>>> >> >> *Database prefixes for:* > >>>> >>>> >> >> *Platform tables (can begin with appropriate prefix)* > >>>> >>>> >> >> AD_ //application dictionary : don't know when it will be > >>>> needed ;-) > >>>> >>>> >> >> C_ //core functionality > >>>> >>>> >> >> *Client Applications.* > >>>> >>>> >> >> X<App name prefix> ex: XBLOG_ for Blog app// All client > >>>> add in > >>>> >>>> >> modules > >>>> >>>> >> >> must begin with table prefix X(for xwiki and ordering) + > App > >>>> name. > >>>> >>>> >> This is > >>>> >>>> >> >> for my blog. > >>>> >>>> >> >> > >>>> >>>> >> >> I will create > >>>> >>>> >> >> C_User for user data. > >>>> >>>> >> >> C_LoginAttempt for saving login attempts. > >>>> >>>> >> >> > >>>> >>>> >> >> From C_LoginAttempt I can filter uniqe login combinations > and > >>>> give > >>>> >>>> >> >> suggestions in the login UI component. Also save the > history. > >>>> >>>> >> >> > >>>> >>>> >> >> All saved data for blog app will be linked to a perticular > >>>> login : > >>>> >>>> >> >> User, > >>>> >>>> >> >> XWiki server. > >>>> >>>> >> >> But only a single user will be most probably using his > >>>> personal > >>>> >>>> >> >> device. > >>>> >>>> >> So > >>>> >>>> >> >> above will be relevant only when he has multiple wikis. > >>>> >>>> >> >> > >>>> >>>> >> >> Best Regards, > >>>> >>>> >> >> Sasinda Rukshan. > >>>> >>>> >> >> > >>>> >>>> >> >> > >>>> >>>> >> >> > >>>> >>>> >> >> > >>>> >>>> >> >> > >>>> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe < > >>>> >>>> >> chamikaw(a)gmail.com>wrote: > >>>> >>>> >> >> > >>>> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter < > >>>> >>>> >> jerome(a)winesquare.net > >>>> >>>> >> >>> >wrote: > >>>> >>>> >> >>> > >>>> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne > >>>> >>>> >> >>> > <thomas.mortagne(a)xwiki.com> wrote: > >>>> >>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan > >>>> >>>> >> >>> > > <sasindarukshan(a)gmail.com> wrote: > >>>> >>>> >> >>> > >> Hi all, > >>>> >>>> >> >>> > >> I am starting this thread for my XWiki Android > Platform > >>>> >>>> >> >>> > >> Project. > >>>> >>>> >> >>> > >> > >>>> >>>> >> >>> > >> Please check whether following are OK. > >>>> >>>> >> >>> > >> [1] INFO > >>>> >>>> >> >>> > >> I tried to start my new modules with the > >>>> >>>> >> >>> de.akquinet.android.archetypes: > >>>> >>>> >> >>> > >> android-quickstart:1.0.8. (added eclipse plugins > m2e, > >>>> >>>> >> >>> > >> m2e-android[a.k.a *Android > >>>> >>>> >> >>> > >> Configurator* ]). But this seems buggy in eclipse. > >>>> >>>> >> >>> > >> Any way the earlier project has not followed the > above > >>>> >>>> >> >>> > >> archtype > >>>> >>>> >> >>> either. > >>>> >>>> >> >>> > So > >>>> >>>> >> >>> > >> I am going to write pom.xml manually for my each > module. > >>>> >>>> >> >>> > >> > >>>> >>>> >> >>> > >> [2] ADVICE NEEDED > >>>> >>>> >> >>> > >> xwiki-rest-model module contains 2 submodules > >>>> >>>> >> >>> > >> |-- xwiki-rest-model-gson ( gson should be > corrected > >>>> to > >>>> >>>> >> >>> > >> json) > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > No the g is not a mistake, it's a model to be used > with > >>>> the > >>>> >>>> >> >>> > > gson > >>>> >>>> >> >>> > > library (http://code.google.com/p/google-gson/). See > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > >>>> >>>> >> > >>>> >>>> >> > >>>> > http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#… > >>>> >>>> >> >>> > . > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > >> |-- xwiki-rest-model-simplexml > >>>> >>>> >> >>> > >> I think the xwiki-rest-model-gson is redundant. The > >>>> classes > >>>> >>>> >> >>> > >> in xwiki-rest-model-simplexml is added with simple > xml > >>>> >>>> >> annotations, > >>>> >>>> >> >>> > >> otherwise both modules have same classes. There is no > >>>> problem > >>>> >>>> >> >>> > >> with > >>>> >>>> >> >>> the > >>>> >>>> >> >>> > >> added annotations for using the same model objects > for > >>>> Json > >>>> >>>> >> >>> > >> REST > >>>> >>>> >> web > >>>> >>>> >> >>> > >> services. And I intend to add my JPA (ORMLite library > >>>> for > >>>> >>>> >> >>> persistence) > >>>> >>>> >> >>> > >> annotations on top of it. > >>>> >>>> >> >>> > >> Shall I re-factor them to a single module > >>>> xwiki-rest-model. > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > No keep them separated, the idea is that both are > useful > >>>> tool > >>>> >>>> >> >>> > > to be > >>>> >>>> >> >>> > > used by someone else that might be moved to > >>>> xwiki-platform at > >>>> >>>> >> >>> > > some > >>>> >>>> >> >>> > > point along with the current xwiki-rest-model (to be > >>>> renamed to > >>>> >>>> >> >>> > > xwiki-rest-model-jaxb). > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > Chamika initially started with gson and since XWiki > REST > >>>> JSON > >>>> >>>> >> >>> > > representation had some limitation he moved to XML > >>>> >>>> >> >>> > > representation. > >>>> >>>> >> >>> > > Maybe at some point Android will have native support > for > >>>> jaxb > >>>> >>>> >> >>> > > which > >>>> >>>> >> >>> > > would obviously be the easier for us (embedding jaxb > is > >>>> not an > >>>> >>>> >> option > >>>> >>>> >> >>> > > in mobile world where size it still pretty important > >>>> especially > >>>> >>>> >> >>> > > on > >>>> >>>> >> >>> > > phones). Maybe it's already the case on most recent > >>>> versions > >>>> >>>> >> >>> > > like > >>>> >>>> >> 4.0 > >>>> >>>> >> >>> > > I don't know. > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > There's also Jackson that could be tried for JSON > >>>> >>>> >> >>> > deserialization, if > >>>> >>>> >> >>> > said limitations are actually GSON limitations. > >>>> >>>> >> >>> > > >>>> >>>> >> >>> GSON wasn't the limitation. > >>>> >>>> >> >>> It was XWiki RESTful API which doesn't support JSON in > some > >>>> cases. > >>>> >>>> >> >>> So > >>>> >>>> >> it's > >>>> >>>> >> >>> safe to go with xml. > >>>> >>>> >> >>> > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > Having full JAXB support sound a bit overweight for > such an > >>>> >>>> >> >>> > "embedded > >>>> >>>> >> >>> > API", even if one day it is natively supported by > Android. > >>>> What's > >>>> >>>> >> >>> > important is to have an easy and fast deserialization, > IMO. > >>>> >>>> >> >>> > The only advantage I can see of going JAXB would be in > >>>> re-using > >>>> >>>> >> >>> > the > >>>> >>>> >> >>> > exact representations and body readers/writers from > XWiki > >>>> core. > >>>> >>>> >> >>> > But > >>>> >>>> >> >>> > you probably don't even want to do that since it would > mean > >>>> >>>> >> >>> > dragging > >>>> >>>> >> >>> > XWiki core with you :) > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > Jerome > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > >> > >>>> >>>> >> >>> > >> [3] INFO > >>>> >>>> >> >>> > >> I had to change some pom.xml s. As the current > project > >>>> at: > >>>> >>>> >> >>> > >> > https://github.com/xwiki-contrib/android-client.gitdoes not > >>>> >>>> >> build. > >>>> >>>> >> >>> > Error > >>>> >>>> >> >>> > >> with parent pom.xml coordinates. > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > You probably did not setup you maven install properly > >>>> since > >>>> >>>> >> >>> > > what's > >>>> >>>> >> on > >>>> >>>> >> >>> > > > https://github.com/xwiki-contrib/android-client.gitbuild > >>>> >>>> >> perfectly > >>>> >>>> >> >>> as > >>>> >>>> >> >>> > > you can see on > >>>> >>>> >> http://ci.xwiki.org/view/All/job/xwiki-android-client/ > >>>> >>>> >> >>> > > which run a build every time something changes on the > git > >>>> >>>> >> repository.. > >>>> >>>> >> >>> > > You should look at > >>>> >>>> >> >>> > > > http://dev.xwiki.org/xwiki/bin/view/Community/Building. > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > >> > >>>> >>>> >> >>> > >> > >>>> >>>> >> >>> > >> Thank you > >>>> >>>> >> >>> > >> Best Regards. > >>>> >>>> >> >>> > >> Sasinda Rukshan > >>>> >>>> >> >>> > >> _______________________________________________ > >>>> >>>> >> >>> > >> devs mailing list > >>>> >>>> >> >>> > >> devs(a)xwiki.org > >>>> >>>> >> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > -- > >>>> >>>> >> >>> > > Thomas Mortagne > >>>> >>>> >> >>> > > _______________________________________________ > >>>> >>>> >> >>> > > devs mailing list > >>>> >>>> >> >>> > > devs(a)xwiki.org > >>>> >>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > -- > >>>> >>>> >> >>> > Jérôme Velociter > >>>> >>>> >> >>> > Winesquare > >>>> >>>> >> >>> > http://www.winesquare.net/ > >>>> >>>> >> >>> > _______________________________________________ > >>>> >>>> >> >>> > devs mailing list > >>>> >>>> >> >>> > devs(a)xwiki.org > >>>> >>>> >> >>> > http://lists.xwiki.org/mailman/listinfo/devs > >>>> >>>> >> >>> > > >>>> >>>> >> >>> _______________________________________________ > >>>> >>>> >> >>> devs mailing list > >>>> >>>> >> >>> devs(a)xwiki.org > >>>> >>>> >> >>> http://lists.xwiki.org/mailman/listinfo/devs > >>>> >>>> >> >>> > >>>> >>>> >> >> > >>>> >>>> >> >> > >>>> >>>> >> > _______________________________________________ > >>>> >>>> >> > devs mailing list > >>>> >>>> >> > devs(a)xwiki.org > >>>> >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs > >>>> >>>> >> > >>>> >>>> >> > >>>> >>>> >> > >>>> >>>> >> -- > >>>> >>>> >> Thomas Mortagne > >>>> >>>> >> _______________________________________________ > >>>> >>>> >> devs mailing list > >>>> >>>> >> devs(a)xwiki.org > >>>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs > >>>> >>>> >> > >>>> >>>> > _______________________________________________ > >>>> >>>> > devs mailing list > >>>> >>>> > devs(a)xwiki.org > >>>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs > >>>> >>>> > >>>> >>>> > >>>> >>>> > >>>> >>>> -- > >>>> >>>> Thomas Mortagne > >>>> >>> > >>>> >>> > >>>> >> > >>>> >> > >>>> >> > >>>> >> -- > >>>> >> Thomas Mortagne > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > Thomas Mortagne > >>>> > >>>> > >>>> > >>>> -- > >>>> Thomas Mortagne > >>>> > >>> > >>> > >> > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne >

13 years, 2 months

2
10
0 0

[xwiki-devs] Fwd: [ANNOUNCE] Apache Solr 4.0-alpha released.

by Vincent Massol

So that we know what we'll get in the future… -Vincent Begin forwarded message: > From: Robert Muir <rmuir(a)apache.org> > Subject: [ANNOUNCE] Apache Solr 4.0-alpha released. > Date: July 3, 2012 3:11:19 PM GMT+02:00 > To: dev(a)lucene.apache.org, solr-user(a)lucene.apache.org, Lucene mailing list <general(a)lucene.apache.org>, announce <announce(a)apache.org> > > 3 July 2012, Apache Solr™ 4.0-alpha available > The Lucene PMC is pleased to announce the release of Apache Solr 4.0-alpha. > > Solr is the popular, blazing fast, open source NoSQL search platform from > the Apache Lucene project. Its major features include powerful full-text > search, hit highlighting, faceted search, dynamic clustering, database > integration, rich document (e.g., Word, PDF) handling, and geospatial search. > Solr is highly scalable, providing fault tolerant distributed search > and indexing, > and powers the search and navigation features of many of the world's > largest internet sites. > > Solr 4.0-alpha is available for immediate download at: > http://lucene.apache.org/solr/mirrors-solr-latest-redir.html?ver=4.0a > > See the CHANGES.txt file included with the release for a full list of > details. > > Solr 4.0-alpha Release Highlights: > > The largest set of features goes by the development code-name “Solr > Cloud” and involves bringing easy scalability to Solr. See > http://wiki.apache.org/solr/SolrCloud for more details. > * Distributed indexing designed from the ground up for near real-time > (NRT) and NoSQL features such as realtime-get, optimistic locking, and > durable updates. > * High availability with no single points of failure. > * Apache Zookeeper integration for distributed coordination and > cluster metadata and configuration storage. > * Immunity to split-brain issues due to Zookeeper's Paxos distributed > consensus protocols. > * Updates sent to any node in the cluster and are automatically > forwarded to the correct shard and replicated to multiple nodes for > redundancy. > * Queries sent to any node automatically perform a full distributed > search across the cluster with load balancing and fail-over. > > Solr 4.0-alpha includes more NoSQL features for those using Solr as a > primary data store: > * Update durability – A transaction log ensures that even uncommitted > documents are never lost. > * Real-time Get – The ability to quickly retrieve the latest version > of a document, without the need to commit or open a new searcher > * Versioning and Optimistic Locking – combined with real-time get, > this allows read-update-write functionality that ensures no > conflicting changes were made concurrently by other clients. > * Atomic updates - the ability to add, remove, change, and increment > fields of an existing document without having to send in the complete > document again. > > There are many other features coming in Solr 4, such as > * Pivot Faceting – Multi-level or hierarchical faceting where the top > constraints for one field are found for each top constraint of a > different field. > * Pseudo-fields – The ability to alias fields, or to add metadata > along with returned documents, such as function query values and > results of spatial distance calculations. > * A spell checker implementation that can work directly from the main > index instead of creating a sidecar index. > * Pseudo-Join functionality – The ability to select a set of > documents based on their relationship to a second set of documents. > * Function query enhancements including conditional function queries > and relevancy functions. > * New update processors to facilitate modifying documents prior to indexing. > * A brand new web admin interface, including support for SolrCloud. > > This is an alpha release for early adopters. The guarantee for this > alpha release is that the index > format will be the 4.0 index format, supported through the 5.x series > of Lucene/Solr, unless there > is a critical bug (e.g. that would cause index corruption) that would > prevent this. > > Please report any feedback to the mailing lists > (http://lucene.apache.org/solr/discussion.html) > > Happy searching, > > Lucene/Solr developers

13 years, 2 months

1
0
0 0

[xwiki-devs] Fwd: [ANNOUNCE] Apache Lucene 4.0-alpha released.

by Vincent Massol

So that we know what we'll get in the future… -Vincent Begin forwarded message: > From: Robert Muir <rmuir(a)apache.org> > Subject: [ANNOUNCE] Apache Lucene 4.0-alpha released. > Date: July 3, 2012 3:09:13 PM GMT+02:00 > To: dev(a)lucene.apache.org, Lucene mailing list <general(a)lucene.apache.org>, java-user <java-user(a)lucene.apache.org>, announce <announce(a)apache.org> > > 3 July 2012, Apache Lucene‚ 4.0-alpha available > The Lucene PMC is pleased to announce the release of Apache Lucene 4.0-alpha > > Apache Lucene is a high-performance, full-featured text search engine > library written entirely in Java. It is a technology suitable for nearly > any application that requires full-text search, especially cross-platform. > > This release contains numerous bug fixes, optimizations, and > improvements, some of which are highlighted below. The release > is available for immediate download at: > http://lucene.apache.org/core/mirrors-core-latest-redir.html?ver=4.0a > > See the CHANGES.txt file included with the release for a full list of > details. > > Lucene 4.0-alpha Release Highlights: > > * The index formats for terms, postings lists, stored fields, term > vectors, etc > are pluggable via the Codec api. You can select from the provided > implementations or customize the index format with your own Codec > to meet your needs. > > * Similarity has been decoupled from the vector space model (TF/IDF). > Additional models > such as BM25, Divergence from Randomness, Language Models, and > Information-based models > are provided (see > http://www.lucidimagination.com/blog/2011/09/12/flexible-ranking-in-lucene-4). > > * Added support for per-document values (DocValues). DocValues can be > used for custom > scoring factors (accessible via Similarity), for pre-sorted Sort > values, and more. > > * When indexing via multiple threads, each IndexWriter thread now > flushes its own segment > to disk concurrently, resulting in substantial performance improvements > (see http://blog.mikemccandless.com/2011/05/265-indexing-speedup-with-lucenes.ht…). > > * Per-document normalization factors ("norms") are no longer limited > to a single byte. > Similarity implementations can use any DocValues type to store norms. > > * Added index statistics such as the number of tokens for a term or > field, number of postings > for a field, and number of documents with a posting for a field: > these support additional > scoring models (see > http://blog.mikemccandless.com/2012/03/new-index-statistics-in-lucene-40.ht…). > > * Implemented a new default term dictionary/index (BlockTree) that > indexes shared prefixes > instead of every n'th term. This is not only more time- and space- > efficient, but can > also sometimes avoid going to disk at all for terms that do not > exist. Alternative term > dictionary implementions are provided and pluggable via the Codec api. > > * Indexed terms are no longer UTF-16 char sequences, instead terms > can be any binary > value encoded as byte arrays. By default, text terms are now encoded as UTF-8 > bytes. Sort order of terms is now defined by their binary value, > which is identical > to UTF-8 sort order. > > * Substantially faster performance when using a Filter during searching. > > * File-system based directories can rate-limit the IO (MB/sec) of merge > threads, to reduce IO contention between merging and searching threads. > > * Added a number of alternative Codecs and components for different > use-cases: "Appending" > works with append-only filesystems (such as Hadoop DFS), "Memory" > writes the entire > terms+postings as an FST read into RAM (see > http://blog.mikemccandless.com/2011/06/primary-key-lookups-are-28x-faster-w…), > "Pulsing" inlines the postings for low-frequency terms into the > term dictionary (see > http://blog.mikemccandless.com/2010/06/lucenes-pulsingcodec-on-primary-key.…), > "SimpleText" writes all files in plain-text for easy > debugging/transparency (see > http://blog.mikemccandless.com/2010/10/lucenes-simpletext-codec.html), > among others. > > * Term offsets can be optionally encoded into the postings lists and > can be retrieved > per-position. > > * A new AutomatonQuery returns all documents containing any term > matching a provided > finite-state automaton (see > http://www.slideshare.net/otisg/finite-state-queries-in-lucene). > > * FuzzyQuery is 100-200 times faster than in past releases (see > http://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is-100-times-fast…). > > * A new spell checker, DirectSpellChecker, finds possible corrections > directly against the > main search index without requiring a separate index. > > * Various in-memory data structures such as the term dictionary and > FieldCache are represented > more efficiently with less object overhead (see > http://blog.mikemccandless.com/2010/07/lucenes-ram-usage-for-searching.html). > > * All search logic is now required to work per segment, IndexReader > was therefore refactored to > differentiate between atomic and composite readers > (see http://blog.thetaphi.de/2012/02/is-your-indexreader-atomic-major.html). > > * Lucene 4.0 provides a modular API, consolidating components such as > Analyzers and Queries > that were previously scattered across Lucene core, contrib, and > Solr. These modules also > include additional functionality such as UIMA analyzer integration > and a completely reworked > spatial search implementation. > > Please read CHANGES.txt and MIGRATE.txt for a full list of new > features and notes on upgrading. > Particularly, the new apis are not compatible with previous version of > Lucene, however, file > format backwards compatibility is provided for indexes from the 3.0 series. > > This is an alpha release for early adopters. The guarantee for this > alpha release is that the index > format will be the 4.0 index format, supported through the 5.x series > of Apache Lucene, unless there > is a critical bug (e.g. that would cause index corruption) that would > prevent this. > > Please report any feedback to the mailing lists > (http://lucene.apache.org/core/discussion.html) > > Happy searching, > > Apache Lucene/Solr Developers

13 years, 2 months

1
0
0 0

[xwiki-devs] Clover TPC values for Commons/Rendering/Platform/Enterprise

by Vincent Massol

Hi devs, I've finally spent the time to measure our TPC (Test Percentage Coverage) using Clover. The reports are very interesting and show where we need to spend our efforts in testing (be them automated or manual). Here are the raw top level results: =========================== All results: http://maven.xwiki.org/site/clover/20120701/ * Only Commons (this means unit tests and integration tests in the commons repository only): 62.4% * Only Rendering: 75.5% * Only Platform: 36.8% * Commons+Rendering (ie Rendering tests exercise also Commons code): 72.1% * Commons+Rendering+Platform: 47.4% * Commons+Rendering+Platform+Enterprise: So our code is roughly tested at X% (note that 100% TPC doesn't mean the code is working, it means each line of code has been tested in some way but it doesn't mean all combinations have been tested!). A good value is between 70-80%. We're actually better than I thought (I had 50% or lower in mind) :) However there are huge disparity with code having 90+% and code having 0% coverage (402 classes have 0% coverage!). Quick high level analysis: ==================== * Commons is missing quite a lot of unit tests * Wikimodel in Rendering is dragging the TPC down, I think we were above 80% before we included WikiModel) * Platform has a very low level of unit tests which means it's easy to break stuff in platform and it's hard to verify that what we add in platform works well in general (means going through longer stabilization phases than needed) * Our functional tests are quite effective (even though they take a very very long time to execute) since they make the TPC go from 47% to 63% for Commons+Rendering+Platform. The bad TPC for Platform is probably improved by the functional tests. Next steps ========= * IMO all developers need to look in details at the results and familiarize themselves with the Clover reports * Each dev should look at stuff he has coded and ensure that they have a good level of unit tests * All new code should get at the very minimum between 70-80% unit test coverage. For example the new diff module in commons only has only 43.4% coverage which is far from enough * Spend time to automate the generation of these reports. We need a dedicated agent for this since it "contaminates" the local repository with clovered jars. The overall generation time is around 4-5 hours. * Dig more around the reports to identify functional areas of XWiki missing automated tests. These areas must be covered by manual testing at each release. * Decide if we want a more rigorous strategy for new code, and how to get alerts for modules missing coverage. WDYT? Let's share your analysis in this thread so that we can brainstorm about what to do with these reports Thanks -Vincent

13 years, 2 months

1
3
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