July 2008 - xwiki-devs@xwiki.org

[xwiki-devs] [ANN] XWiki Enterprise Manager 1.3 Release Candidate 1 released
by Thomas Mortagne 28 Jul '08

28 Jul '08

The XWiki development team is pleased to announce the release of XWiki Enterprise Manager 1.3 Release Candidate 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download First release candidate for the 1.3 version. The main changes are: * Upgrade XE/Core dependency from 1.4.1 to 1.5 * Improve wiki descriptor editor For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM13RC1 Thanks -The XWiki dev team

1 0

[xwiki-devs] [GSoC]how to implement a class as a plexus component
by Wang Ning 28 Jul '08

28 Jul '08

Hi, I want to change some class to plexus component. I see some code of xwiki. I have 2 questions. 1. Only adding "String ROLE = **.class.getName()" in a class, can change a normal class to plexus component? Should I write some plexus config file in somewhere? 2. How to get a plexus components? Use a componentManagement.getComponent(ROLE) can get a component, but I don't know how to get the componentManagement. Forget me if those two question is too stupid. Thanks. Wang Ning

2 1

[xwiki-devs] [VOTE] XWiki 2.0 formal syntax definition - Bold & Link
by Vincent Massol 27 Jul '08

27 Jul '08

Hi, I think I've finished enough in the new rendering implementation so that we should now start defining formally the new XWiki 2.0 syntax. However before we do that let me highlight one important limitation due to the underlying frameworks we use (wikimodel in this case): Wikimodel is using a JavaCC grammar and thus is not able to do look ahead and backtracking (ANTLR can do it, but even if JavaCC could do it it would still be too expensive to use). This means that wikimodel is not able to support the following example: This is a * that is not a bold. When wikimodel sees one of XWiki's special char (like the star for bold) it'll put everything that comes after as bold, till it find another star or till the end of the document. There are 2 solutions out of this: * We don't allow users to enter non-escaped star for example. * Or better we change our syntax for bold so that it uses a 2 chars. For example **. It's less likely people will use 2 stars in their content and this is the reason most wikis use 2 chars. This is also consistent with our other syntaxes for underline, strikethrough, italics, etc. Note that this is also inline with the creole syntax: http://www.wikicreole.org/ The same problem exists for links. We're currently using single brackets which means people cannot use brackets in their text. I'd also propose to use double brackets for links as in: [[This is a link]]. Again this is consistent with the rest. There are several other topics to address but let's start with Bold and Link syntaxes right now. Once we agree on them, I'll do the following: * Create a XWiki 2.0 syntax page on xwiki.org and put Bold and Linkj syntax there * Send change requests to wikimodel for the changes we decide * Adapt the new rendering module code * Send other emails for remaining syntax elements To summarize the vote here is about: * Using ** for bold in the new XWiki 2.0 syntax * Using [[ for links in the new XWiki 2.0 syntax Here's my +1 to both. Thanks -Vincent

7 9

[xwiki-devs] [XEM][VOTE] Release XEM 1.3RC1
by Thomas Mortagne 27 Jul '08

27 Jul '08

Hi all, As XE 1.5 just been released I would like to follow with XEM 1.3. It's mainly XE dependency upgrade fro 1.4.1 to 1.5 and wiki descriptor editor improvements. You can see complete release note at http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM13RC1 Here is my +1 -- Thomas Mortagne

5 5

[xwiki-devs] unable to compile XWiki Workspace 1.1 - milestone 1
by neel seer 27 Jul '08

27 Jul '08

I am building XWiki Workspace from the source. i made a change to XWiki core and built it fine. I see it being installed to the local repository as well. However, when i try to build the Workspace web module I always see the old xwiki-core-1.4.1.jar being picked up from elsewhere instead of pikcing the one from my local repository. Can someone tell me what I am doing wrong. Are there any dependency issues? Your help is greatly appreciated. /ns

2 1

[xwiki-devs] [GSOC][WEBDAV] Status - Refactoring Completed.
by Asiri Rathnayake 26 Jul '08

26 Jul '08

Hi Ludovic and all, I have completed refactoring xwiki-webdav code base. *Benefits:* 1. Code is easy to read & understand (still missing javadoc though). 2. Increased modularity. 3. Very easy to extend (Add new views, types etc). *Features :* 1. True parent-child navigations is possible (wasn't possible before). 2. Add / Remove child pages into / from pages. 3. Edit Wiki content of pages. 4. Delete child pages / Attachments. 5. (Adding attachments is one step ahead - need 1.6 core) 6. Add / Remove pages into / from spaces. 7. Add / Remove spaces - partially done. Ludovic, please have a look at the new code and let me know what you think :) *Missing :* 1. Copy / Move operations. 2. Locking & Versionning. *Questions / Concerns :* 1. What should be the content-length of collection resources (currrently 0) 2. Is it meaning full to have GET / HEAD methods on collection resources (as this would mean downloading a directory hierarchy, which is not possible AFAIK) 3. LIBRARY_VIEW : I didn't implement this view (yet) because i don't understand how we can upload a directory hierarchy into a server as mentioned on the design<http://dev.xwiki.org/xwiki/bin/view/Design/WebDAVService>. Can someone please explain what exactly 'uploading a directory' means ? 4. Deleting collection resources seems to present few complications : i) Some clients (nautilus) uses a recursive delete procedure. Some clients (dav explorer) does not allow deleting collection resources. ii) If a page is deleted recursively, all child pages are deleted before the parent is removed :( 5. attachments / orphans views, should we allow pages to be added / deleted on this views ? *What's Next :* I will start to write test cases for xwiki-webdav using jakarta slide<http://jakarta.apache.org/slide/>for next week to come (but i don't have much of an idea what it would be like). It would be nice to have some comments on the current code base and possibly answers to above questions :) Thanks. - Asiri

2 2

[xwiki-devs] Fwd: [GSOC][WEBDAV] Status (Integration Testing)
by Asiri Rathnayake 26 Jul '08

26 Jul '08

---------- Forwarded message ---------- From: Asiri Rathnayake <asiri.rathnayake(a)gmail.com> Date: Sat, Jul 26, 2008 at 11:48 AM Subject: Re: [GSOC][WEBDAV] Status (Integration Testing) To: Ludovic Dubost <ludovic(a)xwiki.org> Hi Ludovic, On Sat, Jul 26, 2008 at 4:10 AM, Ludovic Dubost <ludovic(a)xwiki.org> wrote: > > Asiri, > > The integration tests are really looking good. This is great to have tests > like that to see the webdav server working. > Yes I think you should replicate them on the different view. > > The more tricky part is going to replicate the behavior of clients that are > doing some complex things, like trying to save temporary files > (.wiki.txt.swp like vi does) > Yes, this is going to be challenging. But if the editor is aware of the fact that it is handling a dav file, it might resolve to some other technique to store swap files, but we cannot depend on that, true. > > Make sure you verify that your tests are really testing by introducing an > error in your webdav code. > Well, i encountered few bugs in the code while writing the tests and fixed them along .. :P > > Once you have decent testing, the most important will be to have the > Windows and Mac webdav client behave properly especially with standard > applications (Notepad, MS Word on Windows, TextEdit, OpenOffice on Mac) Yeah, as i mentioned in one of my previous mails, some editors (ex: notepad) doesn't even know what is DAV. I mean it complains that it is an invalid protocol or something, there is not a single request listed on the server. I doubt whether we can fix such issues. Anyway, i will look into it bit thoroughly. Thanks. - Asiri > > > Ludovic > > > Asiri Rathnayake wrote: > >> Hi Ludovic, >> >> I have setup the pom file to allow integration tests. Also, plain old >> junit tests can be added if required (**/*TTest.java : unit-tests, >> **/*ITest.java : integration-tests). Also, I have added integration tests >> for basic operations on spaces and pages. I was thinking if i should >> replicate these tests across different views ? WDYT ? >> >> To run the tests, simply execute `mvn clean integration-test` >> >> Thanks. >> >> - Asiri >> > > > -- > Ludovic Dubost > Blog: http://blog.ludovic.org/ > XWiki: http://www.xwiki.com > Skype: ldubost GTalk: ldubost > >

1 0

[xwiki-devs] [GSOC][WEBDAV] Status (Integration Testing)
by Asiri Rathnayake 25 Jul '08

25 Jul '08

Hi Ludovic, I have setup the pom file to allow integration tests. Also, plain old junit tests can be added if required (**/*TTest.java : unit-tests, **/*ITest.java : integration-tests). Also, I have added integration tests for basic operations on spaces and pages. I was thinking if i should replicate these tests across different views ? WDYT ? To run the tests, simply execute `mvn clean integration-test` Thanks. - Asiri

2 1

[xwiki-devs] [Proposal] new "/plain/" and "/feed/" actions mapped to plain.vm template
by Jerome Velociter 25 Jul '08

25 Jul '08

Hello devs, Yesterday I've applied Marius's XWIKI-2149 patch "Extend the FeedPlugin to allow the creation of RSS/Atom feeds from any source". New RSS urls with this revamped mechanism are of the type "/xwiki/bin/view/Space/DocRss?xpage=plain" (while the current way is /xwiki/bin/view/Space/DocRss?xpage=rdf"). I propose we add an action that return the "plain.vm" velocity template as entry point to render the document, and map a new "/feed/" action to it. This would allow us for example to have a blog feed URL like this : "/xwiki/bin/feed/Main/BlogRss" when the blog will actually use this new mechanism for its feed. I would also like to map an action with a more generic name to it, like "/plain/". "xpage=plain" is for example used when we create pseudo-REST web services (for example, all the AJAX/gridview features in XE do use URLs of that type). I believe it would be nice to have in the service request URL only parameters linked to the actual service. Thus I would propose we have something like "/xwiki/bin/plain/XWiki/MyService?myparam1=myvalue&..." I am +1 for doing this, WDYT ? Now, I have a working version of this on my computer, but I'm not very happy how it is done. basically, I followed the way the "attach" action works : I added a PlainAction in com.xpn.xwiki.web that just returns "plain" on render, and added the following action in struts-config action mappings : <action path="/feed/" type="com.xpn.xwiki.web.PlainAction" name="feed" scope="request"> <forward name="feed" path="/templates/plain.vm"/> </action> Is there a nicer way of doing this with struts ? (At first, I tried to use "global-forwards" like <forward name="feed" path="/templates/plain.vm"/>, but without success.) Thanks, Jerome.

2 1

[xwiki-devs] build-break: invalid jar in repository
by rssh 25 Jul '08

25 Jul '08

Good day. Now exist problem with default build of sources from repository: we have invalid xwiki-core-1.5-SNAPSHOT.jar (which breaks default build, becouse skinx require such snapshot) (i, e. jar -tf /home/rssh/.m2/repository/com/xpn/xwiki/platform/xwiki-core/1.5-SNAPSHOT/xwiki-core-1.5-SNAPSHOT.jar show something like: com/xpn/xwiki/pref/api/XWikiPrefService.class com/xpn/xwiki/pref/impl/xwiki/XWikiPrefServiceImpl.class com/xpn/xwiki/XWikiCompatibilityAspect.class java.util.zip.ZipException: invalid stored block lengths at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164) at java.util.zip.ZipInputStream.read(ZipInputStream.java:163) at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:109) at sun.tools.jar.Main.list(Main.java:885) at sun.tools.jar.Main.run(Main.java:230) at sun.tools.jar.Main.main(Main.java:1044) [rssh@localhost skinx]$ P.S. java is OpenJDK -- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua

1 0