xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

Re: [xwiki-commits] [Issue] Commented: (XWIKI-942) Customize default cache duration

by Vincent Massol

On Mar 13, 2007, at 10:02 AM, Pablo Oliveira wrote: > On Mar 13, Sergiu Dumitriu (JIRA) wrote : >> P.S.: It's so bad that there's no better way of getting >> configuration parameters. There should be a separate component, >> accessible from anywhere. > > I really do agree here. This would be a great step towards a more > modular XWiki. Even if not related: It's really annoying to have > to pass an XWiki instance to the storage module, just so it can > retrieve some conf parameters... We'll have to take a decision here in the future: 1) either we provide a configuration per component 2) or we provide a global configuration I prefer 1) because: - a component is encapsulated completely in a JAR - a component shouldn't see by default configuration from other components. It's these other components who should offer APIs to return configuration data if required -Vincent

17 years, 8 months

Re: [xwiki-dev] [VOTE] Adopt bird names for skins

by Vincent Massol

On Mar 13, 2007, at 10:30 AM, Sergiu Dumitriu wrote: > > > On 3/13/07, Vincent Massol <vincent(a)massol.net> wrote: > > On Mar 13, 2007, at 10:19 AM, Sergiu Dumitriu wrote: > >> >> >> On 3/13/07, Marta Girdea <marta.girdea(a)gmail.com> wrote: >> Bird names is a great idea. +1 >> >> Concerning the name of the 1.0 skin, "dove" icould be ok, but, for >> some reason, it looks more like an "albatross" to me. The 0.9 is >> certainly a "dodo". >> >> >> Albatross is great. The skin is kind of blue, and a bit large. >> >> http://en.wikipedia.org/wiki/Image:Albatros_ceja_negra_- >> _paso_drake_-_noviembre_2005.jpg > > So I assume you're +1 for bird names... > > As I said once we agree on bird names I'll send a proposal for > names and we can discuss the names. > > Thanks > -Vincent > > > I already voted for bird names. Maybe you skipped that email. oh I did skip that mail :) Sorry -Vincent

17 years, 8 months

0
-1
0 0

[Proposal] Subversion configuration

by Vincent Massol

Hi committers, I propose we adopt the SVN configuration from the Maven project. Right now everyone has his own config which is a pain for several reasons: - line encodings are different. For example in Jeremi's commit all the lines of XWikiMessageTool were modified even though he only touched a few lines. - expansion of @version $Id: $ - correct mime types Here's the file I propose to use: http://maven.apache.org/developers/ svn-eol-style.txt This is from http://maven.apache.org/developers/committer- environment.html If everyone agrees, please install it in your .subversion/ directory (on unix) and somewhere in your profile under Subversion/ on windows. I'll also put it up on xwiki.org Thanks -Vincent

17 years, 8 months

Re: [xwiki-commits] r2371 - in xwiki/trunk/core: . src/main/java/com/xpn/xwiki/xmlrpc

by Vincent Massol

On Mar 11, 2007, at 11:08 AM, Vincent Massol wrote: > Author: vmassol > Date: 2007-03-11 11:08:54 +0100 (Sun, 11 Mar 2007) > New Revision: 2371 > > Modified: > xwiki/trunk/core/pom.xml > xwiki/trunk/core/src/main/java/com/xpn/xwiki/xmlrpc/Attachment.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/xmlrpc/ > ConfluenceRpcHandler.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/xmlrpc/Page.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/xmlrpc/ > PageHistorySummary.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/xmlrpc/ > PageSummary.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/xmlrpc/ > SearchResult.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/xmlrpc/ServerInfo.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/xmlrpc/Space.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/xmlrpc/ > SpaceSummary.java > Log: > XWIKI-860: Apply coding style to XML-RPC classes > > * Applied style to PageSymmary ooops that was SpaceSummary -Vincent

17 years, 8 months

[Proposal] Include Selenium app in the default wiki?

by Vincent Massol

Hi, I committed in SVN the automatic inclusion of our Functional Test suite in the default wiki. Sergiu rightly pointed that we need to discuss this before including it as it's not completely end user focused. Here are the reasons I thought it would be good to be included: 1) It's related to end users if we say that this is a feature to verify that XWiki is correctly installed. They can delete it after if they want. I strongly believe tests should extend to users in some manner, especially for an open source project. 2) This would allow users to help us discover problems in a more controlled manner. Indeed if users have this app installed, once they encounter a problem they could record a test suite proving the problem and give it to us. This would 1) increase our test suite and 2) allow us to reproduce the pb, fix it and verify the fix passes the test. In some way this is about transforming a portion of our users into contributors :) Now Sergiu says that this is increasing the size of the default Wiki. Yes this is true. It goes from 320KB to 542KB. Is it worth it? To be honest, I don't know if this will work or not but I was curious to try it out and see what we can come up with. My idea here is really to try lowering the bar for writing functional tests for everyone and for us to get better at controlling if XWiki works or not. We could have another wiki (say "wikidebug" or "wikitest") which is the default wiki + the Selenium app and let people interested use it. But it won't be as effective I think. I find it kind of cool to have our installation verification tool inside the delivered default wiki. Another idea: we could have a button in Selenium.WebHome to completely remove the space if the user doesn't want it for example. Anyway I'm curious to know what everyone thinks about this. I agree with Sergiu that it's not 100% required. At the same I'm curious with the experiment. Thanks -Vincent PS: If we decide we don't want it I'll remove it from the build so that it isn't included in the default wiki by default and I'll mark XWIKI-959 as won't fix.

17 years, 8 months

[Opinions needed] Encoding of xwiki source files

by Gilles Serasset

Hi all, While working on encodings problems, I saw that some of the source file do use non ascii chars (which is normal, especially in unit tests). But, there is currently no decision on the encoding of the source file, hence, compilers cannot correctly read the files that do use non ascii chars. This leads to tests working on single instances but not on others, only due to compilation settings. There are 2 solutions: 1. force everybody to use UTF-8 encoding for their source files (it's quite easy to st up most IDE once and for all for this...) and specify the encoding in javac parameters in ant and maven. 2. force everybody to use unicode escapes (\uXXXX) to specify a non ascii char in the sources (easily detectable on build, but harder for developpers who have to use native2ascii) Current files with non ascii chars: /Users/serasset/dev/xwiki/trunks-users/xwiki/core/src/main/java/com/ xpn/xwiki/plugin/autotag/FrenchStemmer.java /Users/serasset/dev/xwiki/trunks-users/xwiki/core/src/main/java/com/ xpn/xwiki/plugin/autotag/AutoTagPlugin.java (Both are in ISO-8859-1) /Users/serasset/dev/xwiki/trunks-users/xwiki/core/src/test/java/com/ xpn/xwiki/content/LinkTest.java (this one seems to be encoded in VISCII (vietnamese encoding) As in LinkTest.java, the test uses vietnamese characters, it's likely that ISO-8859-1 encoding is not a viable option for the xwiki source encoding. In the mean time, LinkTest.java should use \uXXXX uniocde escapes in order to run correctly in all installs. Can you please tell me which solution you prefer ? Regards, -- Gilles Sérasset GETALP-LIG BP 53 - F-38041 Grenoble Cedex 9 Phone: +33 4 76 51 43 80 Fax: +33 4 76 44 66 75

17 years, 8 months

[JIRA] New charting plugin installed

by Vincent Massol

Hi, Thanks to Raffaello we also have the JIRA charting plugin (http:// confluence.atlassian.com/display/JIRAEXT/JIRA+Charting+Plugin) installed now on jira.xwiki.org. For example go to http://jira.xwiki.org/ and check the chart. I'm attaching it here too. This is an interesting chart showing resolved issues vs new issue being created, for the past 90 days. As you can see in january of this year we've crossed a threshold where there are more issues created than we can close and this is increasing... Meaning we need to find a way to deal with this somehow... Also when in the navigator you there's now a Chart button that you can use to display charts of the current filtered issues. Last you can add several new charting portlets in your dashboards now. Thanks -Vincent

17 years, 8 months

Re: [xwiki-commits] r2368 - xwiki/branches/XWIKI_1_0/core/src/main/java/com/xpn/xwiki/web

by Vincent Massol

On Mar 9, 2007, at 6:47 PM, Vincent Massol wrote: > Author: vmassol > Date: 2007-03-09 18:47:21 +0100 (Fri, 09 Mar 2007) > New Revision: 2368 > > Modified: > xwiki/branches/XWIKI_1_0/core/src/main/java/com/xpn/xwiki/web/ > XWikiMessageTool.java > Log: > XWIKI-957: refactor XWikiMessageTool to get a translation list from > a given documentbundle > > * Fixed failing m3 build due to previous commit > > Merge from trunk (rev 2366, 2367) and also merged rev 2297 which > wasn't forgotten to be merged earlier on s/wasn't/was I'm too tired... -Vincent

17 years, 8 months

Re: [xwiki-commits] r2366 - xwiki/trunk/core/src/main/java/com/xpn/xwiki/web

by Vincent Massol

On Mar 9, 2007, at 6:36 PM, Vincent Massol wrote: > Author: vmassol > Date: 2007-03-09 18:36:14 +0100 (Fri, 09 Mar 2007) > New Revision: 2366 > > Modified: > xwiki/trunk/core/src/main/java/com/xpn/xwiki/web/ > XWikiMessageTool.java > Log: > XWIKI-957: refactor XWikiMessageTool to get a translation list from > a given documentbundle > > * Fixed failing m3 build due to previous commit ^^^^^^^^^^ wishful thinking :-) -Vincent

17 years, 8 months

Lucene plugin working?

by Vincent Massol

Hi there, As I wanted to apply to some for the lucene plugin I've tried to use it (I don't know anything about it really). However it's not been working for me and it doesn't return anything when doing a full text search. Here's what I've done: Configuration: xwiki.plugins.lucene.indexdir=/tmp/lucene/xwiki xwiki.plugins.lucene.analyzer=org.apache.lucene.analysis.standard.Standa rdAnalyzer xwiki.plugins.lucene.indexinterval=20 Usage: #set($results = $xwiki.lucene.getSearchResults("wordToLookUp", "default,en,fr")) nb found : $results.hitcount #foreach($result in $results.results) * [${result.web}.${result.name}] #if($result.filename) ($result.filename)#end : $result.score #end This works if I use the following query "name:NameOfAPage" but it doesn't with "wordToLookUp". I have even tried a reindexation by calling ($xwiki.lucene.rebuildIndex()) to no avail. Can anyone help? Is the plugin working at all? Thanks -Vincent

17 years, 8 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs