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

Re: Database Support
by Ludovic Dubost 20 Apr '05

20 Apr '05

Hi, We haven't made any tests, but XWiki uses hibernate and JDBC so there is a good chance that it works. You will need to try. We are open to requests in case of problems. Ludovic Bruce Bacheller a écrit : > Do you have plans to Support Firebird the Open Source DBMS ? > > > -- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic

1 0

Cruise Control
by Ludovic Dubost 20 Apr '05

20 Apr '05

Hi All, I'm currently setting-up cruise control 2.2.1 to setup a continious build on the latest SVN source. It will compile XWiki and run tests everytime there are changes in SVN, including the cactus based tests. Results will be published on a web site: http://build.xpertnet.biz and a notification email will be sent either to the dev list or the commit lists. Any comments about the choice: dev or commit list ? I might automatically publish the artifacts to one of the xwiki.com production machines. The build machine is running Mandrake Linux. Ludovic -- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic

2 1

Chinese Character not encoded as UTF-8 in web page
by Patrick Lee 20 Apr '05

20 Apr '05

Hi Ludovic Thanks for the help. I can now compile the svn source. On 4/19/05, Ludovic Dubost <ludovic(a)pobox.com> wrote: > > Hi Patrick, > > I think it is just that you need junit.jar in your ant installation. > > Ludovic > I now have the following questions: 1. the version # is now Version 0.9.500, smaller than the previous downloadble war file ( 0.9.543). Is this correct? 2. I have attempt to save some chinese character on a new page then try to edit it again using the default (html ) editor. Both the html page source and the editable version still show 大 etc for a chinese character, just like the previous version (0.9.543). Besides, the page source shows the following: <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <meta name="language" content="en" /> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> I suppose that the xml/html file is encoded in ISO-8859-1 instead of UTF-8. Is there anywhere I could change the default? And it is the same no matter I choose the page/document language as en or zh. 3. I have also try to export this to PDF and the result supprise me. Please check the attachment. The three encoded chinese characters have been truncated to only one code with some left over of the first and last character. I will take a look at the svn revision 452 about the uft-8 changes set soon and try to find out the problem. Thanks in advance. Patrick Lee

2 2

Not able to compile from the svn source
by Patrick Lee 20 Apr '05

20 Apr '05

Hi all I have checked out the source from object web and try to compile it but without any success. error message is as follow: BILD FAILED /usr/local/src/xwiki/build.xml:127: taskdef A class needed by class org.apache.cactus.integration.ant.CactusTask cannot be found: junit/framework/Test I have looked into build.xml and at line 127, the following was found:  <taskdef resource="cactus.tasks"> <classpath> <pathelement location="${lib.dir}/cactus-1.6dev.jar"/> <pathelement location="${lib.dir}/cactus-ant-1.5.jar"/> <pathelement location="${lib.dir}/commons-httpclient-2.0-rc2.jar"/> <pathelement location="${lib.dir}/commons-logging.jar"/> <pathelement location="${lib.dir}/aspectjrt-1.1.1.jar"/> </classpath> </taskdef> Notice that all the above mentioned library except commons-httpclient-2.0-rc2.jar were found in the lib directory. commons-httpclient-2.0.1.jar were found in lib directory instead. I have tried to change the above to commons-httpclient-2.0-1.jar but still got the above message. What have I missed. Any help is appreciated. Patrick Lee

2 2

TOC numbering
by Jiri Luzny 19 Apr '05

19 Apr '05

Hi, I'm working on a design of Table of Contents feature and I need a help of some XWiki expert ;-) As an optional feature the {toc} tag should allow to specify if both TOC and the actual headings should be automatically numbered (the same how it works in Word). To add the numbering into items in TOC section during a processing of a TOC velocity macro is simple but to add the number just before a text of heading in the actual content means to change the existing content in the middle of rendering. I was thinking of modifying filter.heading.print Radeox filter (BTW an easy way for adding an anchor into headings) to encapsulate the heading text by a velocity macro (which will then share the same numbering logic/variables with the TOC macro) and then let it process by VelocityRenderer. Unfortunately it doesn't work because VelocityRenderer is called before RadeoxRenderer in the chain of renderers. So, is it possible to change content of document being rendered from within a velocity or groovy macro? If not, is there other flexible way of this kind of changing of existing document content during rendering phase than to modify an existing renderer or create a new one? Thx, Jiri.

2 1

RE: [VOTE] Moving some directories in SVN
by Vincent Massol 18 Apr '05

18 Apr '05

Hi everyone, (switching list) I really don't understand what is the problem with the: xwiki/ xwiki-plugins/ directory structure. Do you put all your files in a single directory on your machine? I believe not. I'm sure you're using folders. xwiki/ plugin1/ plugin2/ ... pluginN/ will work well *only* if we have very few plugins (and I don't think that's the plan! :-)). In addition it's not balanced with the xwiki/ directory. We could also have xwiki-core/, xwiki-plugin-manager/, xwiki-persistence/, etc at the top level but we don't. Why? Because it's better organized to have them under xwiki/ as they all are about the xwiki engine proper. The same applies for the plugins. They are all plugins. Also there are other things than plugins. Imagine some other extensions or other applications built on top of xwiki. Say an issue tracker for example. It would then go in: xwiki/ xwiki-plugins/ xwiki-tracker/ [...] It would really be a mess to mix all the plugins at the top level with other things. I don't understand what's your issue with multiple level directories. I guess you haven't seen a Maven directory structure yet too! ;-) Once and if we migrate to Maven, I can tell you that the structure inside xwiki/ is going to contain *lots* of directories! :-) I hope I have convinced you a little more... Thanks -Vincent > -----Original Message----- > From: developers-bounces(a)xwiki.org [mailto:[email protected]] > On Behalf Of Luis Arias > Sent: jeudi 14 avril 2005 19:50 > To: XWiki.org Developers Mailing List > Subject: Re: [VOTE] Moving some directories in SVN > > Hi All, > > +1 for this structure which seems real clean and extensible. Don't > like the two level hierarchy for the plugins Vincent proposed in his > later post too much. > > Looking forward to participating in this community ! > > Luis. > > On 4/14/05, Jiri Luzny <jiri.luzny(a)seznam.cz> wrote: > > > [REPOROOT]/ > > > |_ xwiki/ > > > |_ trunk/ > > > |_ branches/ > > > |_ tags/ > > > |_ xwiki-plugin1/ > > > |_ trunk/ > > > |_ branches/ > > > |_ tags/ > > > |_ xwiki-plugin2/ > > > |_ trunk/ > > > |_ branches/ > > > |_ tags/ > > > > [+1] > > IMHO it's more flexible and at the root level I would also add other > > tools that are not XWiki plugins like xwiki-scripts, > > xwiki-eclipse-client etc.. in future. > > > > >PS: Ludovic, I'm still working on the email notification thing. Hope to > > >get a working version ready this week. > > > > cool, cannot wait for it! The simple email notification workaround > > (http://www.xwiki.org/xwiki/bin/view/Dev/RecentChangesNewsletter) we > > use at my company is quickly reaching its limits ;-) > > > > Jiri. > > > > On Wed, 13 Apr 2005 18:08:41 +0200, you wrote: > > > > >Hi all, > > > > > >just read through the mails of the last days - this really seems to > > >become a high traffic list now :-) > > > > > >On Wed, Apr 13, 2005 at 05:04:20PM +0200, Vincent Massol wrote: > > >[..] > > >> This is not right. I'd like to transform it into: > > >> > > >> [REPOROOT]/ > > >> |_ xwiki/ > > >> |_ trunk/ > > >> |_ branches/ > > >> |_ [branchname] > > >> |_ tags/ > > >> |_ [tagname] > > > > > >+1 for this one. > > > > > >> And then if we want want to add a xwiki-plugins project later on we > would > > >> have: > > >> > > >> [REPOROOT]/ > > >> |_ xwiki/ > > >> |_ trunk/ > > >> |_ branches/ > > >> |_ tags/ > > >> |_ xwiki-plugins/ > > >> |_ trunk/ > > >> |_ branches/ > > >> |_ tags/ > > >> > > >> This follows the standard SVN directory structure defined in > > >> http://tinyurl.com/4dhja. > > >> > > >> One reason is that the release lifecycle of xwiki/ and xwiki-plugins/ > will > > >> probably be different (you can release a newer version of a plugin > even if > > >> the core is not released again). > > > > > >here I would vote for each plugin having it's own set of > > >trunk/branches/head directories. I think different plugins will have > > >different development cycles, and imho one would not want to branch all > > >plugins just because one plugin is undergoing major changes. > > > > > >so I would suggest an architecture like this: > > > > > > [REPOROOT]/ > > > |_ xwiki/ > > > |_ trunk/ > > > |_ branches/ > > > |_ tags/ > > > |_ xwiki-plugin1/ > > > |_ trunk/ > > > |_ branches/ > > > |_ tags/ > > > |_ xwiki-plugin2/ > > > |_ trunk/ > > > |_ branches/ > > > |_ tags/ > > > > > > > > >Greetings, > > >Jens > > > > > >PS: Ludovic, I'm still working on the email notification thing. Hope to > > >get a working version ready this week. > > > > _______________________________________________ > > Developers mailing list > > Developers(a)xwiki.org > > http://www.xwiki.org/mailman/listinfo/developers > > > > > -- > Luis Arias > http://www.xwiki.com > http://www.innover-entreprendre.net > +33 6 14 20 87 93 mobile > _______________________________________________ > Developers mailing list > Developers(a)xwiki.org > http://www.xwiki.org/mailman/listinfo/developers ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran�ais ! Yahoo! Mail : http://fr.mail.yahoo.com

3 2

XWiki syntax future direction
by Jiri Luzny 15 Apr '05

15 Apr '05

Hi, I would like to start a discussion about a concept of future extending of XWiki syntax. I already had a short email conversation with Ludovic about this topic and I would like to know your opinion. There are some missing things in XWiki syntax that prevent us to have XWiki documents as the standard documentation form in the department I work. I would like to extend the syntax with features such as Table of Content, cross-references (smarter linking inside one document), headers and footers, bookmarks in PDF output etc... There are currently two approaches how it can be done in XWiki: 1. to extend it using Radeox macros 2. to use Velocity macros and variables for it Here are a couple of examples how a document writer would then use each variant: Table Of Content: 1. {toc} 2. #toc() or ${doc.getToc()} Anchor: 1. {anchor|anchor_name} 2. #anchoe(anchor_name) Link to internal anchor: 1. [#anchor_name] 2. [${doc.fullname}#anchor_name] Include other document: 1. {icludePage:page_name} 2. #includeTopic("page_name") Ludovic tends to prefer the Velocity approach due its easier way of integrating and deploying, however I personally have a little problem with adding such basic, pure document related tags as Velocity macros. The biggest issue I see is the mixing of those two approaches without a clear separation of purpose. Most of our end-users like a Project Managers, Requirements Analysts and Testers are not skilled programmers and they treat XWiki as a Word editor for web based knowledge collaboration. It is now confusing and hard to explain to them why sometimes they should use {macro} and sometimes #macro() (I'm not even talking about explaining what ${doc.fullname} means ;-)). Both snipsnap and confluence using only radeox macros which is not that flexible as XWiki velocity macros but it is a consistent for both end-user and developer extending it. On the other hand, Velocity macros (together with Groovy) are excellent for *programming* of documents, adding fancy staff to it like the Blog macros, IM macros etc.. I would personally vote for using Radeox macros for the basic document editing and formatting capabilities and Velocity for the more advanced stuff. Jiri.

3 5

RE: [VOTE] Moving some directories in SVN
by Vincent Massol 15 Apr '05

15 Apr '05

> -----Original Message----- > From: developers-bounces(a)xwiki.org [mailto:[email protected]] > On Behalf Of Jiri Luzny > Sent: jeudi 14 avril 2005 06:09 > To: XWiki.org Developers Mailing List > Subject: Re: [VOTE] Moving some directories in SVN [snip] > BTW: Does anybody have any experience with Subeclipse? The current CVS > support in Eclipse is excellent so I'm curious what I would loose/gain > when switching to SVN. [snip] I'm using subclipse. The level of support is not as good as CVS but getting close. You'll probably have some issues when using svn+ssh protocol. I really recommend reading http://www.tmate.org/svn/subclipse.html. In practice I use both TortoiseSVN and subclipse. TortoiseSVN really works great if you're on windows. -Vincent

2 1

RE: [SVN] Change of directory structure... hold your breath!
by Vincent Massol 15 Apr '05

15 Apr '05

Ok, I've done the move for the trunk. The full URL for checking out the trunk is now: [svn|svn+ssh]://svn.forge.objectweb.org/svnroot/xwiki/xwiki/trunk I'll be doing the same for branches and tags now. Thanks -Vincent > -----Original Message----- > From: Vincent Massol [mailto:[email protected]] > Sent: vendredi 15 avril 2005 11:23 > To: 'xwiki-dev(a)objectweb.org' > Subject: [SVN] Change of directory structure... hold your breath! > > Hi there, > > As agreed by everyone, I'm going to make the change from trunk/xwiki to > xwiki/trunk (and from branches/xwiki and tags/xwiki to xwiki/branches and > xwiki/tags). > > Thanks > -Vincent

2 1

[SVN] Change of directory structure... hold your breath!
by Vincent Massol 15 Apr '05

15 Apr '05

Hi there, As agreed by everyone, I'm going to make the change from trunk/xwiki to xwiki/trunk (and from branches/xwiki and tags/xwiki to xwiki/branches and xwiki/tags). Thanks -Vincent

1 0