xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

by Ludovic Dubost

Hi Bruce, Nice to meet you. The first test you need to do is start XWiki with an empty database connected to the Firebird database. In xwiki.cfg you should setup "xwiki.superadminpassword=toto" that will activate the "superadmin" user with password "toto" which will be able to setup rights. From there you should be able to access an empty wiki and create some pages to see if everythings works. Features to test are: 1/ Pages 2/ Attachments 3/ Versions One of the key features needed is the support for large text fields (without size limits). Oracle can't do this (except in the latest versions) and required some specific hibernate hacks. Converting the default Database to Firebird might be more complex. You can download the default DB on Sourceforge. It is a zipped SQL file exported from Mysql. However I think it is quite full of specific MySQL sql. I think there are some improvement in MySQL 4.1 to the export with allows for "compatible" export so you might need to import/export in MySQL to create a more compatible file. Ludovic Bruce Bacheller a écrit : >Thanks for the Quick response. > >I am on the Firebird Foundation (FirebirdSQL.org) and will get you any support needed from our THE FirebirdSQL side to get it working. > >I will host it on my site which is FirebirdXML.info or Infodes.org. >That is Linux/Apache/Tomcat. > >We are having hosting our user conference in germany next Month May 15th and I would like to have it operational for that event. I will make sure that XWiki gets good exposure to the Firebird Community as well. > >We are pretty close to Oracle in syntax. > >Can you send me a copy of the SQL code in MySQL (table creation) so I can review it and set up test. > >Looks like XWiki has developed A VERY NICE piece of Open Source Software. > >Regards, >Bruce > >-----Original Message----- >From: Ludovic Dubost [mailto:ludovic@xwiki.org] >Sent: Wednesday, April 20, 2005 3:54 PM >To: Bruce Bacheller; xwiki-dev(a)objectweb.org >Subject: Re: Database Support > > >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

20 years, 1 month

Re: Database Support

by Ludovic Dubost

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

20 years, 1 month

Cruise Control

by Ludovic Dubost

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

20 years, 1 month

Chinese Character not encoded as UTF-8 in web page

by Patrick Lee

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

20 years, 1 month

Not able to compile from the svn source

by Patrick Lee

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

20 years, 1 month

TOC numbering

by Jiri Luzny

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.

20 years, 1 month

RE: [VOTE] Moving some directories in SVN

by Vincent Massol

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:developers-bounces@xwiki.org] > 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

20 years, 1 month

XWiki syntax future direction

by Jiri Luzny

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.

20 years, 1 month

RE: [VOTE] Moving some directories in SVN

by Vincent Massol

> -----Original Message----- > From: developers-bounces(a)xwiki.org [mailto:developers-bounces@xwiki.org] > 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

20 years, 1 month

RE: [SVN] Change of directory structure... hold your breath!

by Vincent Massol

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:vincent@massol.net] > 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

20 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs