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

[Coding rules] Author/Creator information
by Vincent Massol 01 Jun '05

01 Jun '05

Hi everyone, Do you really want to keep the following which is part of most file headers: * Created by * User: Ludovic Dubost * Date: 26 nov. 2003 * Time: 13:52:39 This seems to me information that can be retrieved from the SCM. And if we want to store SCM information in the file then it is only fair that whoever modifies the file should also get credit there. In addition usually we would use the @author tag for storing this kind of information. Having it in an undefined format like above is a bit strange... ;-) So I think there are 2 options: Option 1: --------- - We do not store author information in the file - We have a credits Wiki page that lists all contributors and what they have done. Something like: - http://jakarta.apache.org/cactus/participating/contributors.html - http://cargo.codehaus.org/Credits - It's still a good idea to have a @version tag in the file, as in: * @version $Id: Container.java 348 2005-04-26 23:03:22Z vmassol $ The content of this tag is generated automatically by the SCM upon commit. Option 2: --------- - We save author information in the file using @author tags. For example @author <a href="mailto:...@...">Ludovic Dubost</a> @author <a href="mailto:...@...">Vincent Massol</a> [...] There have been *lots* of debates (which I'll spare you here but you can google it) between these 2 options and the one chosen @ Apache is option 1. I have done the same for Cargo. I don't mind the chosen solution but I think the current option is not good enough. Thanks -Vincent _____________________________________________________________________________ D�couvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vid�os ! Cr�ez votre Yahoo! Mail sur http://fr.mail.yahoo.com

3 2

[API Refactoring] Modify XWiki constructor
by Vincent Massol 01 Jun '05

01 Jun '05

Hi, I'm trying to fix some unit tests and by doing so I'm working my way in the XWiki API. I have thousands of ideas to improve the design but honestly I don't know where to start from; it's a bit overwhelming ;-) We need to start somewhere, so we might as well start with the XWiki class constructor. ATM, the constructor is: public XWiki(String xwikicfgpath, XWikiContext context) public XWiki(String xwikicfgpath, XWikiContext context, XWikiEngineContext engine_context, boolean noupdate) public XWiki(InputStream is, XWikiContext context, XWikiEngineContext engine_context) The first parameter is used to pass a location of a config file. Actually this parameter is only used to create a XWikiConfig object. I believe we should delegate the creation of a XWikiConfig object to the XWikiConfig object itself so that our API can resist to change. Imagine that tomorrow I want to store a XWiki config in a database. Today the API would not cope with this because it's rigid and unflexible. It violates IOC. Here's my proposal for the XWiki class: - Deprecate the current constructors - add 2 new constructors: public XWiki(XWikiConfig config, XWikiContext context) public XWiki(XWikiConfig config, XWikiContext context, XWikiEngineContext engine_context, boolean noupdate) Thus the "user" must start by creating a XWikiConfig, then a XWikiContext, possibly an EngineContext and then only he can create a XWiki object. The idea is that the creation of a config should be left to the config object and NOT to the Wiki class (it's not its role). This leads to a better design. In addition to being more flexible this will allow for easier unit testing as we will not need a xwiki.cfg file anymore (it will still be used for functional testing though). Obviously the next step would be to transform XWikiConfig into an interface. What do you think? Thanks -Vincent _____________________________________________________________________________ D�couvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vid�os ! Cr�ez votre Yahoo! Mail sur http://fr.mail.yahoo.com

2 1

Displaying pages in plain formatting
by aprotogerellis＠mailsnare.net 01 Jun '05

01 Jun '05

Hello, I am trying to use XWiki in conjunction with Selenium to enable any user to write application tests through xwiki and run them on selenium. I have been quite succesful but require a way of accessing an xwiki page in completelly plain formatting. I.e. without the side bars, google add bar etc. What would be a good way of doing this? I've attempted using skins but to limited effect. Thanks Alex

2 1

Pb in unit tests with my refactoring...
by Vincent Massol 31 May '05

31 May '05

Hi, I'm still struggling to fix the tests that I have broken with my last refactoring (the generation of the hibernate config file tests.build.dir and its retrieval through the classpath). Sorry about that... I'm not sure what's the reason. Here's attached the test report of a test class that now fails. If you have any idea let me know. Also, I've noticed that the test/wiki.cfg file has: xwiki.store.hibernate.path=hibernate-test.cfg.xml Is that used anywhere? I thought that the config file was passed by the Java classes. Thanks -Vincent

2 3

RE: [xwiki-dev] [Build] About to move tests
by Vincent Massol 31 May '05

31 May '05

> -----Original Message----- > From: Vincent Massol [mailto:[email protected]] > Sent: mardi 31 mai 2005 09:58 > To: 'xwiki-dev(a)objectweb.org' > Subject: RE: [xwiki-dev] [Build] About to move tests > > Hi, > > It seems that the tests are generating some files during their execution. > They seem to generate: > > - test/velocity.log > - test/xwiki.log > - test/hibernate-test.cfg.xml > - test/rcs/Test/* > > Could someone tell me how I can update the test files so that these > generated files go into the build/ directory instead of going into a > source directory? This is pre-requisite before I can make any modification to the directory structure. Actually what should be done is remove the dependency on paths. ATM, I've noticed that several tests are using path to find test resources. I believe this is not right and should be improved by using the classpath to locate the test resources. In other words, instead of doing something like: public static final String hibpath = "hibernate-test.cfg.xml"; XWikiHibernateStore hibstore = new XWikiHibernateStore(hibpath); We should be doing: public static final String hibLocation = "/hibernate-test.cfg.xml"; URL hibURL = getClass().getResource(hibLocation); XWikiHibernateStore hibstore = new XWikiHibernateStore(hibURL); And we add src/test/resources to the JUnit execution CP. What's wrong with paths? - they are system dependent - they can be absolute or relative and the result will depend from where you execute the code. Thus they are brittle WDYT? I don't know the code well so I would need your help in fleshing out the places where paths are used. I've noticed one in AllTests.java (see attached "patch" - I've also added some other comments). Once we don't rely any more on paths then we'll be able to move /test in src/test/resources. Thanks for your help -Vincent > > Thanks > -Vincent > > > -----Original Message----- > > From: Vincent Massol [mailto:[email protected]] > > Sent: mardi 31 mai 2005 09:47 > > To: xwiki-dev(a)objectweb.org > > Subject: [xwiki-dev] [Build] About to move tests > > > > Hi developers, > > > > This is a heads up as I'm about to move test sources and resources as > > planned in a previous email (see also XWIKI-12). > > > > The following changes will happen: > > > > - trunk/test will go in src/test/resources > > - trunk/src/test will go in src/test/java > > - trunk/src/test-cactus will go in src/test/cactus > > > > This means that you'll need to add the src/test/resources directory to > > your > > execution classapath in your IDE project files. You'll also need to > change > > src/test to src/test/java and src/test-cactus to src/test/cactus. > > > > Please shout if you have an issue with this. I'll be doing it in about 1 > > hour. > > > > Thanks > > -Vincent > > > > > > > > > > > > > > > __________________________________________________________________________ > > ___ > > Dicouvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos > > mails, photos et vidios ! > > Criez votre Yahoo! Mail sur http://fr.mail.yahoo.com

2 1

[Build] About to move tests
by Vincent Massol 31 May '05

31 May '05

Hi developers, This is a heads up as I'm about to move test sources and resources as planned in a previous email (see also XWIKI-12). The following changes will happen: - trunk/test will go in src/test/resources - trunk/src/test will go in src/test/java - trunk/src/test-cactus will go in src/test/cactus This means that you'll need to add the src/test/resources directory to your execution classapath in your IDE project files. You'll also need to change src/test to src/test/java and src/test-cactus to src/test/cactus. Please shout if you have an issue with this. I'll be doing it in about 1 hour. Thanks -Vincent _____________________________________________________________________________ D�couvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vid�os ! Cr�ez votre Yahoo! Mail sur http://fr.mail.yahoo.com

1 1

Re: [xwiki-users] xWiki in multi languages
by Stéphane Laurière 30 May '05

30 May '05

Hi Xavier, everybody, After an upgrade to XWiki 0.9.793, I actually faced the same problem as you. Strangely, I never faced the problem when running the previous release of XWiki. The problem is related to the fact that JRCS is not configured for supporting UNICODE. I have changed the "ArchiveParser.jj" file for enabling UNICODE streams (see below), and I have regenerated the parser with JavaCC, now it works better. I have uploaded the updated jars to this page: http://www.xwiki.org/xwiki/bin/view/Dev/CharactersSets org.apache.commons.jrcs.rcs.ArchiveParser.jj file: JAVA_UNICODE_ESCAPE=false; // RCS files are plain ASCII [snip] UNICODE_INPUT=false; changed to: JAVA_UNICODE_ESCAPE=true; // RCS files are plain ASCII [snip] UNICODE_INPUT=true; I have also commented out following lines of "com.xpn.xwiki.web.Utils.java", because content.length() does not return the UTF-8 encoded content length, which shortens the pages... Or converting the string to UTF-8 encoded bytes works fine, but is it absolutely necessary to set the content length of the response? if (context.getResponse() instanceof XWikiServletResponse) { response.setContentLength(content.length()); } I send the message to dev list too, as I assume the discussion should continue on that list. Stéphane Xavier MOGHRABI wrote: > Hello > > I configure as stephane explained me. I have the good character sets in > mysql : > | character_set_client | utf8 > | > | character_set_connection | utf8 > | > | character_set_database | utf8 > | > | character_set_results | utf8 > | > | character_set_server | utf8 > | > | character_set_system | utf8 > | > | character_sets_dir | /usr/share/mysql/charsets/ > | > | collation_connection | utf8_general_ci > | > | collation_database | utf8_general_ci > | > | collation_server | utf8_general_ci > | > > However, it still doesn't work. > I have an error like this : > Caused by: org.apache.commons.jrcs.rcs.TokenMgrError: Lexical error at line > 37, column 2. Encountered: "\u606f" (24687), after : > "@\n\n\nMain\nTest2\n\nen\n0\n\nXWiki.XWikiGuest\n1117191196650\n1117191218887\n1.2\nJe > parle chinois !\n\u4fe1" > at > org.apache.commons.jrcs.rcs.ArchiveParserTokenManager.getNextToken(ArchiveParserTokenManager.java:800) > > I can see well my chinese characters. It looks like there was an error where > tomcat reads them. > > I start Tomcat with java option : -Dfile.encoding=UTF-8 > my LANG variable is fr_FR.UTF-8 (I also test en_US.UTF-8) > I change encoding in web.xml and xwiki.cfg. > > > >>It might be worth checking whether all character-set-* variables are >>correctly set to "utf8" in the MySQL variables tables. I copy below what >>I get when running a "SHOW VARIABLES" against a MySQL 4.1 server that I >>

2 1

How do I change a page's title?
by Vincent Massol 30 May '05

30 May '05

Hi, I'd like to change the page's title for http://mavenbook.xwiki.com/xwiki/bin/view/Main/WebHome. It says "Wiki - Web - WebHome". How can I do that easily? Thanks -Vincent _____________________________________________________________________________ D�couvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vid�os ! Cr�ez votre Yahoo! Mail sur http://fr.mail.yahoo.com

2 2

RE: [xwiki-dev] [build] Test not better than before...
by Vincent Massol 30 May '05

30 May '05

> -----Original Message----- > From: Vincent Massol [mailto:[email protected]] > Sent: dimanche 29 mai 2005 21:27 > To: 'xwiki-dev(a)objectweb.org' > Subject: RE: [xwiki-dev] [build] Test not better than before... [snip] > Only a few tests are failing now. The LDAP one seems to be blocking (it's > been stuck there for several minutes - I hope it'll timeout). It did after 388 seconds... hrmmm... Something needs to be done there. I think we should exclude all tests that are not working in the default build (they can run on the CC install). There are 12 test failures and 1 test error when using the default build setup (i.e. nothing installed). I'm only talking about the client side tests. [snip] -Vincent _____________________________________________________________________________ D�couvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vid�os ! Cr�ez votre Yahoo! Mail sur http://fr.mail.yahoo.com

2 1

RE: [xwiki-dev] [build] Test not better than before...
by Vincent Massol 29 May '05

29 May '05

Ok, the issue was that I had a clover jar in my anthome/lib dir and the xwiki build does a little bit too much of automagic... ;-) It auto-discovers clover and uses it but the tests do not run with clover on... I think we should not auto-discover clover but rather have a target or a property to use it when required. Only a few tests are failing now. The LDAP one seems to be blocking (it's been stuck there for several minutes - I hope it'll timeout). Thanks -Vincent > -----Original Message----- > From: Vincent Massol [mailto:[email protected]] > Sent: dimanche 29 mai 2005 21:07 > To: 'xwiki-dev(a)objectweb.org' > Subject: RE: [xwiki-dev] [build] Test not better than before... > > > > > -----Original Message----- > > From: Ludovic Dubost [mailto:[email protected]] > > Sent: dimanche 29 mai 2005 21:02 > > To: xwiki-dev(a)objectweb.org > > Subject: Re: [xwiki-dev] [build] Test not better than before... > > > > > > Do you have some info in the test reports files about the failure.. > > I had already sent those files but I have sent them again to Luis. Here > they are for everyone's benefit. > > Thanks > -Vincent _____________________________________________________________________________ D�couvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vid�os ! Cr�ez votre Yahoo! Mail sur http://fr.mail.yahoo.com

1 0