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:
<!-- Define the Cactus tasks -->
<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
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.
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
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.
> -----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
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
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
---------- 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: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
>
>
>
> --
> You receive this message as a subscriber of the xwiki-dev(a)objectweb.org mailing list.
> To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
> For general help: mailto:sympa@objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>
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
Hi Luis
(switching list)
> -----Original Message-----
> From: developers-bounces(a)xwiki.org [mailto:developers-bounces@xwiki.org]
> 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
