- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [ANN] XWiki Enterprise 1.8 Release Candidate 1 Released
by Jean-Vincent Drean 18 Feb '09

18 Feb '09

The XWiki development team is pleased to announce the release of XWiki Enterprise 1.8 Release Candidate 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download First release candidate of the XWiki Enterprise 1.8 version. Main changes: * WYSIWYG improvements: macro support implemented, default browser list support overridden. * Various improvements on XWiki REST service. * Various bugs fixed in XWiki 2.0 syntax rendering. * Upgrade to groovy 1.6 RC3. Important bug fixes: * XWIKI-3208: getSpaceDocsName does not work with postgresql Fixed. Patch submitted by Dave Burklund. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise18RC1 Note that general goals for XWiki Enterprise 1.8 are: * Office Importer * New Blog * REST API * Finish new rendering/syntax * Finish new WYSIWYG * French XE * MediaWiki import Thanks, - The XWiki dev team

1 0

[xwiki-devs] [ANN] XWiki Enterprise Manager 1.5.1 released
by Jean-Vincent Drean 18 Feb '09

18 Feb '09

The XWiki development team is pleased to announce the release of XWiki Enterprise Manager 1.5.1. This release is based on XWiki Enterprise 1.7.2. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download Main changes since XWiki Enterprise Manager 1.5: * XEM now support virtual wikis using path urls and not host urls * XEM is now using XWiki Enterprise 1.7.2 For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM151 Thanks -The XWiki dev team

1 0

[xwiki-devs] [ANN] XWiki Enterprise 1.7.2 Released
by Jean-Vincent Drean 18 Feb '09

18 Feb '09

The XWiki development team is pleased to announce the release of XWiki Enterprise 1.7.2. This is a bugfix release following XE 1.7.1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download Important bugs fixed * XWIKI-3119: URLFactory does not work properly with an invalid request in the context * XWIKI-3208: getSpaceDocsName does not work with postgresql Syntax and WYSIWYG 2.0 Bugs fixed * XWIKI-3114: Backspace is ignored at the beginning of a list item if the previous list item is on a lower level * XWIKI-2734: Cannot edit the outer list item * XWIKI-3112: Cannot indent a list item after undo step * XWIKI-3089: Cannot move cursor after table * XWIKI-3090: Cannot move cursor before table * XWIKI-3110: Cannot unbold a bold word selected with double-click * XWIKI-3170: Custom parameter ending syntax characters are not escaped inside xwiki/2.0 custom parameter values * XWIKI-3104: Erroneous rendering of links to page anchors * XWIKI-3109: Headers generated from wiki syntax look and behave differently * XWIKI-3071: Hitting enter at the end of the paragraph moves the cursor at the beginning of the next unit in IE * XWIKI-3098: If a macro throw a NullPointerException it breaks the whole rendering process * XWIKI-3122: If macro contains format block the macro is printed in XWiki syntax with empty custom parameters before it * XWIKI-2993: Insert horizontal line on a selection of unordered list. * XWIKI-3113: New list item is on the same line after undo step * XWIKI-3096: NullPointerException when using toc macro without any section * XWIKI-3061: Overwrite the default list support * XWIKI-3115: Pressing Tab in the last table cell should generate a new table row * XWIKI-3143: Quotes are not escaped inside xwiki/2.0 custom parameter values * XWIKI-3072: Special characters in tables are not escaped by XWIKI renderer * XWIKI-3105: Use the same Range implementation for all browsers * XWIKI-3159: WYSIWYG 2.0 Editor Stylesheet Problem * XWIKI-3138: WYSIWYG 2.0 Preview Error * XWIKI-3053: When a HR is inserted at the beginning of a paragraph an extra empty paragraph is generated before that HR * XWIKI-3103: XHTML parser does not support macro with parameters but without content * XWIKI-3195: underscores in links not recognized in new wysiwyg editor For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise172 Thanks -The XWiki dev team

1 0

[xwiki-devs] embedding XWiki?
by Allen Rohner 18 Feb '09

18 Feb '09

I'm starting a webapp project in Clojure (http://clojure.org) and I'm looking for a wiki engine to embed. I want to control the look and feel of my application, and use the wiki engine as a backend only. i.e. on wiki pages I will have my own menus and other content around the wiki text. Is XWiki a good candidate for this? >From reading the source code, I think I can figure out how to start an embedded XWiki inside my app. Is this a good idea? The dev documentation was not very helpful in this area, which makes me ask: is this a "supported configuration"? Thanks, Allen

3 2

[xwiki-devs] [VOTE] Release XE 1.7.2 and XE 1.8RC1
by Jean-Vincent Drean 17 Feb '09

17 Feb '09

Hi devs, 1.8RC1 is planned for today and I'd like to suggest the following: - release XE 1.7.2. - release XE 1.8RC1. - create 1.8 branch and make trunk 1.9. - delete the 1.7 branch since our rule is to maintain only 2 branches at the same time. I'll try to do it as quickly as my failing laptop will allow. Here's my +1. Thanks, JV.

5 5

[xwiki-devs] [VOTE] Add new XWiki API: public String getURL(String fullname, String action, String queryString, String anchor, XWikiContext context)
by Vincent Massol 16 Feb '09

16 Feb '09

Hi, There's currently an API for: public String getURL(String fullname, String action, XWikiContext context) it's passing null to the underlying call to the URL factory for query string and anchor. I'm thus proposing to add the following API in XWiki.java: public String getURL(String fullname, String action, String queryString, String anchor, XWikiContext context) In the future we'll need to rationalize all this of course. I need this because I'd like to remove the throws XWikiException in DocumentAccessBridge.getURL() since getting a URL for a document should never raise an exception. Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

5 5

[xwiki-devs] [VOTE] Remove begin/endError events in the new rendering
by Vincent Massol 16 Feb '09

16 Feb '09

Hi devs, I introduced these events initially in order to be able to have inline error reporting in a generic manner. However there are some problems: * it currently works only for macros, if you wrap other blocks with an error block you'll get to see the output of what is wrapped. * there's no block other than the MacroBlock that can raise an error so there's no need to have a generic way of reporting an inline error Thus I propose the following (suggested by Marius): 1) We remove the begin/endError events 2) When macros fail to execute we output the exact same content as is currently output by the begin/endError events but generated as the macro content. Since we have macro marker block around it, it'll work just fine. Here's my +1 Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

5 5

[xwiki-devs] My first try to compile
by Hoani Cross 15 Feb '09

15 Feb '09

Hi ! Since a few days, I'm trying to compile the latest source code of xwiki fetching it from the SVN. Following the tutorial from the xwiki website first, I encounter major problems (like the TestCase class cannot be found !) but it resolves as magic a few days after by just updating the code. My last try was tomorrow, because I wanted to look at the last XWiki GWT impl. It took 2 hours to resolve problems and have the core module compiled and installed through maven. Here are the problems I encountered : - the sablecc plugin from the xwiki-core-query-jpql-parser module give me some trouble especially having the generated classes available for the test classes, my solution was to disable tests for this module (I wanted to go as fast as possible), - the project xwiki-core-query-xwql had problems in test cases getting some classes from the previous project : disabling the test was also my solution, - the xwiki-core tests fails at this test : public void testGetLinkedPages10() { this.mockXWiki.stubs().method("exists").will(returnValue(true)); this.document .setContent("[TargetPage][TargetLabel>TargetPage][TargetSpace.TargetPage][TargetLabel>TargetSpace.TargetPage?param=value#anchor][ http://externallink][mailto:mailto]"); List<String> linkedPages = this.document.getLinkedPages(getContext()); assertEquals(Arrays.asList("Space.TargetPage", "Space.TargetPage", "TargetSpace.TargetPage", "TargetSpace.TargetPage"), linkedPages); } As you may noticed, I just adapt the assertEquals() line, even if the expected result is not exact : I want to have the product installed, point. Then I re-run maven from the root, let it go and went to bed. This morning I even get another test failed on xwiki-plugin-spacemanager... :( What do you suggests me ? Deactivating the tests for all the modules as a env. var ? I don't want to spend hours just for compiling xwiki... Thx in advance ! -- Hoani CROSS Globotraders Tahiti Founder [http://globotraders-tahiti.com]

3 8

[xwiki-devs] [VOTE] Port the REST subsystem to JAX-RS
by Fabio Mancinelli 13 Feb '09

13 Feb '09

Dear all, this is more a RFC than a vote... Currently the REST subsystem is written using Restlet and its API and there is a layer based on the XWiki Component manager written by me that is used to declare and configure resources and components for providing representations in a more dynamic way. During the last weekend I spent some time experimenting with the JAX- RS API and as a test I tried to port the current implementation to this API. I was able to do so without too much effort and the result was also a drastic reduction in code complexity. In fact all the plumbing I wrote is already handled by the JAX-RS API implementation. Actually the JAX-RS API provides also more powerful mechanisms wrt the ones I wrote because it takes into account representations in responses (GET), representations in requests (PUT and POST) and exception mappings (i.e., the possibility of capturing and representing all kind of exceptions, checked or unchecked). One consequence of these features is that I was able to write methods to handle requests that use our data model without having to deal with complicated try/catch blocks for adjusting the response wrt to exception thrown. Conversions from objects of our data model to representations and viceversa (text/plain, text/xml, etc.) are handled by the framework, and exceptions as well. The problem was the implementation to use. I tried both Jersey and Restlet and both of them were fine. Jersey misses some features such as authentication handling (I had to wrote a basic authentication handler by hand) and is not flexible as Restlet. Restlet, on the contrary, is very powerful and has a very good support for JAX-RS but it lacks automatic generation of the WADL description of the application. Coming to a conclusion, I would like to switch to JAX-RS + Restlet because we can have the best of the two worlds. If we need, in fact, we can still leverage the Restlet API if the JAX-RS is not suitable for implementing a resource. We will have to give up the WADL support for the moment, but I don't think this is a big deal with respect to the gain we have in code maintainability (no more plumbing and easier resource declaration) and reduced code complexity overall. And WADL for JAX-RS will be eventually implemented so it's just a question of time. Here it is my +1 WDYT? Regards, Fabio

4 4

[xwiki-devs] [VOTE] Remove moderate style filtering option from office importer
by Asiri Rathnayake 13 Feb '09

13 Feb '09

Hi Devs, Currently officeimporter application has three levels of style filtering options: 1. Strict: Remove all the styles presented in the original document except for those that can be mapped directly into xwiki syntax 2. None: Keep all the styles (no filtering what so ever) 3. Moderate: Only keep those styles without which the output would be drastically different from the original document (ex: alignments, image widths etc.) As you can see the third option (was my idea) is kind of hard to define and can be confusing to the user as well. The first too options make a lot of sense to the user and after discussing with vincent I decided to ask for a vote to remove it. Plus this is consistent with the officeimporter wysiwyg plugin which only allows either to keep all the styles or remove everything. Also, if we decide to remove the moderate filtering option, we can represent the options by a checkbox (Filter Styles). Which should be the default filtering criterion? I'm thinking it should be not to filter any styles so that the output looks more or less like the original document. Here's my +1. WDYT? Thanks.

5 13