xwiki-devs December 2012

xwiki-devs@xwiki.org

25 participants
57 discussions

[xwiki-devs] [VOTE] Move all lucene plugin classes to internal

by Jerome Velociter

Hello, Right now all code in the lucene plugin is exposed as API while almost none of it is actual API. I would like to move all lucene plugin classes to an internal package, except for "LucenePluginApi". For the non API "LucenePlugin", I'm not sure, since moving it would break users conf (xwiki.cfg). WDYT ? My +1, Jerome

11 years, 10 months

[xwiki-devs] [VOTE] Stop shading Rendering Standalone

by Vincent Massol

Hi devs, I'd like to propose that we stop shading Rendering Standalone. The reasons are: 1) It's far from perfect. For example we have at least 3 libs we cannot shade:  2) As we added some libs to our deps we forgot to relocate them so right now we don't shade (to cite a few): com.steadystate.css, javax.validation, ant, aspectj, slf4j, etc 3) There are lots of resources coming from dependent jars and those are not shaded. For example: 283 Tue Dec 04 18:50:42 CET 2012 javacc.class 286 Tue Dec 04 18:50:42 CET 2012 jjdoc.class 235 Tue Dec 04 18:50:42 CET 2012 jjtree.class 0 Tue Dec 04 18:50:42 CET 2012 org/xwiki/shaded/javacc/ or 3783 Tue Dec 04 18:50:42 CET 2012 org/xwiki/shaded/javacc/utils/JavaFileGenerator.class 3693 Tue Dec 04 18:50:42 CET 2012 templates/CharStream.template 15990 Tue Dec 04 18:50:42 CET 2012 templates/JavaCharStream.template 867 Tue Dec 04 18:50:42 CET 2012 templates/MultiNode.template 1317 Tue Dec 04 18:50:42 CET 2012 templates/Node.template 5962 Tue Dec 04 18:50:42 CET 2012 templates/ParseException.template 12711 Tue Dec 04 18:50:42 CET 2012 templates/SimpleCharStream.template 3227 Tue Dec 04 18:50:42 CET 2012 templates/SimpleNode.template 4005 Tue Dec 04 18:50:42 CET 2012 templates/Token.template 368 Tue Dec 04 18:50:42 CET 2012 templates/TokenManager.template 4244 Tue Dec 04 18:50:42 CET 2012 templates/TokenMgrError.template 48 Tue Dec 04 18:50:42 CET 2012 version.properties So I'd like to keep a standalone distribution to make it easy to test XWiki Rendering but without any shading. Here's my +1 Thanks -Vincent

11 years, 10 months

[xwiki-devs] Bug Fixing Day #8 has started!

by Vincent Massol

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

11 years, 10 months

[xwiki-devs] [Brainstorming] Minimal supported resolution?

by Vincent Massol

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

11 years, 10 months

[xwiki-devs] [Proposal] Remove old info boxes/warnings for XWiki 1.x and 2.x

by Vincent Massol

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

11 years, 10 months

[xwiki-devs] [Contrib] XWiki Object Sort

by crocket

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.

11 years, 10 months

[xwiki-devs] Handling of property values indexing in Solr

by Jerome Velociter

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

11 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs December 2012