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
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:
<!-- We don't relocate the following packages since they cause runtime issues:
- javax.xml
- org.w3c
- org.apache.xerces
-->
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
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
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.
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
