Hi All,
The Cruisecontrol build server is now setup and the build currently passes.
Currently tests failures don't make the build fail because there are
some tests that fail for cruisecontrol setup reasons.
See results at http://build.xpertnet.biz
LDAP fails because there is no LDAP server setup. The Servlet
authentication fail because there is a issue when running these tests on
the Linux build machine (on Windows it works). This must be due to a
cookie issue in the test environnement. Other tests need to be looked at.
Builds are only redone if there are SVN changes.
email notifications to the developers list are not yet setup. This
should be the case pretty soon.
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,
Here is a summary of UBS's evaluation of XWiki versus other wiki tools.
I've responded to them.
It's very interesting for us to have other people's view on XWiki.
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,
I am one of the ObjectWeb webmaster. For info, It seems that the xwiki
svnroot repository is currently corrupted for some reason:
> svn co svn://svn.forge.objectweb.org/svnroot/xwiki/trunk
svn: Berkeley DB error while opening 'nodes' table for filesystem
/svnroot/xwiki/db:
Cannot allocate memory
I am currently trying to recover the repository using "svnadmin recover" and
will try to modifiy the defaut berkeley db config (maybe it would be better
to switch to fsfs backend?).
See: http://subversion.tigris.org/faq.html#bdb-cannot-allocate-memory
I have a backup of whole repository until revision 485 in any case.
Sorry for the inconvience,
regards,
--
Mathieu Peltier
ObjectWeb Consortium - INRIA
E-mail: mathieu.peltier(a)inrialpes.fr
Phone: +33 4 76 61 55 25
JabberID: mpel(a)jabber.fr
One thing I'm planning to do, is liberate the special characters in
document names. I've had too many problems not accepting accents in wiki
page names, even though for european accents they are converted to
non-accentued characters automatically when used in a link. The problem
is that this cannot be made general because some languages have special
characters that do not have a "non-special" fallback..
So I'm thinking of letting any character being chosen in Wiki page
names, using the URL encoding conversion of course.
Doing this is not too much a problem. One other thing is what to do with
white spaces.
Currently if you type
[new page]
the link created is
newpage
I've had some complaints about it because when we show page searches it
shows a concatenated text string instead of a nice page name.
Another problem is that it makes it very difficult to search
automatically for backlinks in the database since the white space could
be anywere in the database.
Backlinks would be usefull for displaying and for moving pages and
automatically updating links.
What I propose is to now default to
new%20page
for this link which one exception when the page 'newpage' already exists
(this treatment could be an option). This way there would be backwards
compatibility.
Linked with the change for non alphanumerical characters it would free
page naming.
What do you think ?
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,
as I'm working on the TOC stuff which will allow automatic numbering
I would like to discuss an aspect that would influence how the
numbering is realized. In particular, I'm interested in knowing what
is the typical document structure you guys use and how you apply the
headings into document sections. What I have seen on xwiki.org is a
mixture of various patterns like:
1 title
1.1 chapter1
1.1.1 subchapter1
1.1 chapter2
or
1.1 title
1.1.1 chapter1
1.1.1.1 subchapter1
1.1.1 chapter2
or
1 chapter1
1.1 subchapter1
1 chapter2
or
1.1 chapter1
1.1.1 subchapter1
1.1 chapter2
In our team we used to use this pattern:
1 title
1.1 chapter1
1.1.1 subchapter1
1.1 chapter2
The problem is that generated numbered TOC than would look like:
1 title
1.1 chapter1
1.1.1 subchapter1
1.2 chapter2
which is not consistent with our company's standard Word documentation
structure (a common document structure, IMHO) which has this natural
TOC:
title
1. chapter1
1.1 subchapter1
2. chapter2
...
My question is whether you think it would be good idea to treat a
document title as a specific part of document and introduce a new tag
like {title} or 0 ... and have its own CSS item. In Confluence the
document title is equal to physical wiki document name and rendered
separately on top of the page.
Another possibility which would solve the generation of TOC issue is
to add an option to the TOC tag what initial heading level it should
start the generation at.
I would personally prefer to treat document title specifically as I
consider the mentioned TOC option as a kind of hack, IMHO.
Jiri.
Luis,
You need to try using the SVN move command instead of deleting and adding.
That will preserve the history of files and it'll be lighter on the commit
diffs too.
Thanks
-Vincent
> -----Original Message-----
> From: Luis Arias [mailto:kaaloo@users.forge.objectweb.org]
> Sent: mercredi 20 avril 2005 22:21
> To: xwiki-commits(a)objectweb.org
> Subject: [xwiki-commits] r469 - in xwiki/trunk/src: . main main/com
> main/com/xpn main/com/xpn/xwiki main/com/xpn/xwiki/api
> main/com/xpn/xwiki/atom main/com/xpn/xwiki/atom/lifeblog
> main/com/xpn/xwiki/cache main/com/xpn/xwiki/cache/api
> main/com/xpn/xwiki/cache/impl
>
> Author: kaaloo
> Date: 2005-04-20 22:20:54 +0200 (Wed, 20 Apr 2005)
> New Revision: 469
>
> Added:
> xwiki/trunk/src/main/
> xwiki/trunk/src/main/com/
> xwiki/trunk/src/main/com/xpn/
> xwiki/trunk/src/main/com/xpn/xwiki/
> xwiki/trunk/src/main/com/xpn/xwiki/XWiki.java
[snip]
Hello all,
I've been busy this afternoon doing some housecleaning in the code base:
- seperate folders for
src/main - core java
src/test - unit tests
src/test-cactus - integration tests
I've been building against the latests stable jars I could find,
including hibernate 3.0.1 for which I had to change a lot of imports
and some stuff in the configuration files.
I just commited the version numbered jars because we are going to be
playing with Maven 2 tomorrow night at the OSSGTP and I figured it
might be easier to write the dependencies that way.
I also ported the RSS macro to Rome 0.6 because it broke on the latest
commons-digester. Rome sure is a sweet API ! We're going to be doing
some other interesting things with Rome.
So all of this stuff is still on my machine while I continue unit
tests (actually these are quite long because a lot of them are
actually integration tests and bring up hibernate (with showSql = true
:( ) etc...), but since cruise control is coming back up, I'm going to
just make sure the build runs and ant release works.
I've been working on tests for my lifeblog stuff, and I definitely
like running them one at a time directly in eclipse, even the server
tests through Jetty. So I have to see how to refactor that so the
other tests benefit and for it all to be ant and ide compatible. I
bet you have a lot of ideas on that one Vincent ! ;)
My concern, is what to do about your diffs and how changes to the src
hierarchy could affect your current work. I hope that doesn't cause
you too much pain. Please let me know if you have any ideas on this
issue because I'm a bit stumped. Actually maybe I can just tell you
when I start to commit and when its done and then you can move your
sources in the right place (easy to do) and update.
Cheers,
--
Luis Arias
http://www.xwiki.comhttp://www.innover-entreprendre.net
+33 6 14 20 87 93 mobile
