We should separate the curriki commiters from the xwiki commiters.
We could also make the list of commiters manageable from
http://curriki.xwiki.org
We could or have to (I'm not sure if it is necessary) also move the code
to a separate svn tree
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
hi Fabio/Vincent
As you have requested, I have uploaded the sample code which uses the xwiki
parser. I have written a maven script to build the sample code. It prints
the xdom object model in to a tree structure. And it also uses the
Parser.traverse() to reprint the xwiki document to the console.
hear is the url http://svn.xwiki.org/svnroot/sandbox/xdom/
In order to undestand how the parser wokes i exaimed it with several xwiki
documents.I think there are some points needed to be clarified about the
parser.It would be greate if you can tell me the criteria which has been
used to build the xdom tree from the xwiki.
For an example consider the following xwiki
plaintext*bold~~bolditalik~~bold*
is this syntax valid?
This is the tree structure of the xdom
XDOM
---ParagraphBlock
---WordBlock
---BoldBlock
---WordBlock
---BoldBlock
---WordBlock
---BoldBlock
---WordBlock
In the above tree bolditalic part is not reflected.
Any comment on this
Thanks
-- Malaka Ekanayake
CSE UOM
Evelina Slatineanu wrote:
>
> For the new Administration application to work properly in an empty wiki
> (create users, groups, set rights etc), the following files have to be moved
> from XE to Administration:
>
> Xwiki.Admin
> Xwiki.Users
> Xwiki.XwikiUserSheet
> Xwiki.XWikiUserTemplate
> Xwiki.AdminGroup
> Xwiki.AllGroup
> Xwiki.Groups
> Xwiki.XwikiGroupSheet
> Xwiki.XwikiGroupTemplate
> Xwiki.Rights
> Xwiki.GlobalRights
> Xwiki.DefaultSkin
> Xwiki.Skins
> Xwiki.XwikiPreferences
>
Since XE will always contain Administration, I see no danger in doing this. In the end XE should
only be an empty shell with several other applications included in it.
So, +1
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On Jun 26, 2008, at 9:05 PM, tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2008-06-26 21:05:24 +0200 (Thu, 26 Jun 2008)
> New Revision: 10858
>
> Modified:
> xwiki-platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src/
> main/java/org/xwiki/cache/jbosscache/internal/
> JBossCacheCacheConfiguration.java
> xwiki-platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src/
> test/java/org/xwiki/cache/jbosscache/JBossCacheCacheTest.java
> Log:
> XWIKI-1744: Use JBoss Cache by default in XWiki
> * improve JBoss cache configuration loading
[snip]
> public void testCreateAndDestroyCacheLRUMaxEntries() throws
> ComponentLookupException, Exception
> {
> - /*CacheFactory factory = getCacheFactory();
> + CacheFactory factory = getCacheFactory();
>
> CacheConfiguration conf = new CacheConfiguration();
> LRUEvictionConfiguration lec = new LRUEvictionConfiguration();
> lec.setMaxEntries(1);
> + // Force JBoss eviction interval to the minimum
> +
> lec.put(JBossCacheCacheConfiguration.CONFX_EVICTION_WAKEUPINTERVAL,
> 1);
> conf.put(LRUEvictionConfiguration.CONFIGURATIONID, lec);
>
> Cache<Object> cache = factory.newCache(conf);
> @@ -36,19 +39,24 @@
>
> cache.set("key2", 2);
>
> + // Wait for the JBoss Eviction policy to be called
> + Thread.sleep(1000);
warning, warning, warning! (insert flashing lights here)
[snip]
> assertEquals("value", cache.get("key"));
>
> - Thread.sleep(1000);
> + // Wait for the JBoss Eviction policy to be called
> + Thread.sleep(3000);
Same, but worse... :)
This reminds me of the setSpeed() in our selenium tests that I've
removed in the RMUI tests.
Note that I'm not proposing a solution since I have no clue and
haven't read the code yet.
BTW isn't it dangerous to switch cache implementation in a RC? I'd say
it is.... I don't even think we've tested it in any real instance so
I'd be -0 to do that before testing it in real for several days/week.
WDYT?
Thanks
-Vincent
Hi everyone,
Yesterday was our third bug fixing day. The following bugs were fixed: http://tinyurl.com/6jve9d
- Sergiu
XWIKI-2498 Exporting a page with an image to PDF fails on Jetty
XWIKI-715 Arguments passed to radeox macros like {image} or {attach}
should not be rendered
XWIKI-2296 EventCalendar Exception after creating Events
XWIKI-2509 Empty StringProperty-s are loaded as null in Oracle
XWIKI-2510 Make the Link and Url filters more stable
XAPANELS-51 Context root 'xwiki' is hard coded in the search panel
- Artem
XSALBATROSS-30 Import / Export script chokes on documents with ' in
name
XWIKI-2472 Wrong mapping for stats on oracle
- Jean-Vincent
XE-256 Exception while generating lucene search RSS feed
So that's a total of 9 bugs fixed. Well done everybody and thanks to
all who participated. A special congratulations to Sergiu who's again
done more than anyone else (despite the fact that he "was busy and
wouldn't be able to do much" ;)). Another congratulations to both
Sergiu and Artem who have participated to all 3 bugfixing days so far.
Total High Score Bugs Fixed Over All BugFixingDay Sessions:
* Sergiu: 13
* Artem: 4
* Thomas: 4
* Fabio: 4
* Vincent: 2
* Jean-Vincent: 1
Let's try to beat sergiu next time ;)
Thanks
-Vincent
On Jun 26, 2008, at 7:00 PM, Evelina Slatineanu wrote:
> Hi all,
>
>
>
> For the new Administration application to work properly in an empty
> wiki
> (create users, groups, set rights etc), the following files have to
> be moved
> from XE to Administration:
>
>
>
> Xwiki.Admin
>
> Xwiki.Users
>
> Xwiki.XwikiUserSheet
>
> Xwiki.XWikiUserTemplate
>
> Xwiki.AdminGroup
>
> Xwiki.AllGroup
>
> Xwiki.Groups
>
> Xwiki.XwikiGroupSheet
>
> Xwiki.XwikiGroupTemplate
>
> Xwiki.Rights
>
> Xwiki.GlobalRights
>
> Xwiki.DefaultSkin
>
> Xwiki.Skins
>
> Xwiki.XwikiPreferences
>
>
>
> I already sent the patch to JV, we only need votes. I'm +1
+1
However we need a info box to install the Admin app when the database
doesn't contain it and when the user clicks on Administration. This is
while we wait for the Setup Wizard which should force the installation
of the admin app.
Thanks
-Vincent
Hi all,
The hsqldb standalone zip distribution for XWiki Watch 1.0 RC 1 has been
released with wrong hibernate configuration file so you should use the
.jar installer until the XWiki Watch 1.0 Release Candidate 2 will be
released with the correct configuration (which is not very far in the
future).
Regards,
the XWiki Watch development team
Hi guys,
I know the installation/update is not that complicated and I discussed that
on this list some time ago, too. Nevertheless I have an (incomplete) idea to
this topic. Maybe you had this already, maybe it's not a good idea at all,
however:
Recently I had to modify the login.vm file on the server as I found no way
to change this page within XWiki. By this time I realized that I have to
write down my modification for the next update. So I thought maybe it would
be possible to change the update process a bit.
What about a web-updater? If you would create a web-updater you could show
the troublesome files and show the differences (maybe by generating for each
and every file a MD5 hash by the time you release a version) and let the
user decide how to proceed (like in Linux when an update tries to change
grub). In addition to that you could stream important release information
into this 'update'-area (new version, security stuff, etc. and, if the user
is willing to provide them, some usage-statistics). Maybe you could even
differentiate between core and plugin updates...
Cheers,
Squirrel
On Jun 26, 2008, at 1:58 AM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2008-06-26 01:58:47 +0200 (Thu, 26 Jun 2008)
> New Revision: 10823
>
> Modified:
> xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> pdf/impl/PdfExportImpl.java
> Log:
> XWIKI-2498: Exporting a page with an image to PDF fails on Jetty
> Fixed.
>
>
> Modified: xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/
> xwiki/pdf/impl/PdfExportImpl.java
> ===================================================================
> --- xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> pdf/impl/PdfExportImpl.java 2008-06-25 23:35:34 UTC (rev 10822)
> +++ xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> pdf/impl/PdfExportImpl.java 2008-06-25 23:58:47 UTC (rev 10823)
> @@ -26,6 +26,7 @@
> import com.xpn.xwiki.objects.BaseObject;
> import com.xpn.xwiki.pdf.api.PdfExport;
> import com.xpn.xwiki.util.Util;
> +import com.xpn.xwiki.web.Utils;
> import com.xpn.xwiki.web.XWikiRequest;
> import info.informatica.doc.dom4j.CSSStylableElement;
> import info.informatica.doc.dom4j.XHTMLDocument;
> @@ -221,7 +222,15 @@
> try {
> tempdir.mkdirs();
> context.put("pdfexportdir", tempdir);
> + boolean useLocalPlaceholders = !
> Utils.arePlaceholdersEnabled(context);
> + if (useLocalPlaceholders) {
> + Utils.enablePlaceholders(context);
> + }
> String content =
> context.getWiki().parseTemplate("pdf.vm", context);
> + if (useLocalPlaceholders) {
> + content = Utils.replacePlaceholders(content,
> context);
> + Utils.disablePlaceholders(context);
> + }
Shouldn't this be done in the rendering engine code?
For example in the new rendering we don't need this so it would be
easier to integrate the new rendering if this code was only found in
the old rendering code.
WDYT?
Thanks
-Vincent
>
Hi all,
For the new Administration application to work properly in an empty wiki
(create users, groups, set rights etc), the following files have to be moved
from XE to Administration:
Xwiki.Admin
Xwiki.Users
Xwiki.XwikiUserSheet
Xwiki.XWikiUserTemplate
Xwiki.AdminGroup
Xwiki.AllGroup
Xwiki.Groups
Xwiki.XwikiGroupSheet
Xwiki.XwikiGroupTemplate
Xwiki.Rights
Xwiki.GlobalRights
Xwiki.DefaultSkin
Xwiki.Skins
Xwiki.XwikiPreferences
I already sent the patch to JV, we only need votes. I'm +1
Thanks, Evelina