April 2005 - xwiki-devs@xwiki.org

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 19 Apr '05

19 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

Fwd: Moving some directories in SVN
by Patrick Lee 15 Apr '05

15 Apr '05

---------- Forwarded message ---------- From: Patrick Lee <patrickl.mo(a)gmail.com> Date: Fri, 15 Apr 2005 14:32:34 +0800 Subject: Re: [xwiki-dev] RE: [VOTE] Moving some directories in SVN To: Vincent Massol <vincent(a)massol.net> Hi Vincent I totally agree with your directory structure althought I am not a xwiki developer nor a committer, at least not yet ... Patrick On 4/15/05, Vincent Massol <vincent(a)massol.net> wrote: > 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 > > > > -- > You receive this message as a subscriber of the xwiki-dev(a)objectweb.org mailing list. > To unsubscribe: mailto:[email protected] > For general help: mailto:[email protected]?subject=help > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws > > >

1 0

Cool JS demos that could be of interest for XWiki Editing
by Ludovic Dubost 15 Apr '05

15 Apr '05

Here are really cool Javascript demos that combined with AJAX techniques ( http://www.ajaxian.com) would be really interesting to use to get better wysiwyg editing in XWiki. If there are any people interested to work on this don't hesitate to drop in the discussion. The slide shot sorter is quite nice and would look good for the S5 XWiki module.. 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

3 3

Mock objects (was RE: Subversion migration done)
by Vincent Massol 15 Apr '05

15 Apr '05

Hi Luis (switching list) > -----Original Message----- > From: developers-bounces(a)xwiki.org [mailto:[email protected]] > On Behalf Of Luis Arias > Sent: vendredi 15 avril 2005 08:38 > To: XWiki.org Developers Mailing List > Subject: Re: Subversion migration done [snip] > P.S. I have some questions about using MockObjects in my LifeblogTest. > The problem being that it seems to me that most existing tests go > through cactus and require a container. So I'm getting null pointers > and stuff because the XWiki object is not set up right. So per your > suggestion I'm going to try to do this through jmock and mockobjects > (I need both right ?). I didn't see jdk5 jars in the mockobjects tar > file so I suppose I should use the 1.4 j2ee 1.3 ones. > > I'm going through the doc and I'll post some detailed questions later > on if I need too. JMock dynamically generate the mocks for you so there's no need to have any mock class anywhere. JMock/EasyMock/DynaMock all use what is called dynamic mocks as opposed to static mocks that was done by the mockobjects.jar jar before. Check the JMock getting started guide: http://jmock.codehaus.org/getting-started.html [snip] Thanks -Vincent

1 0