May 2009 - xwiki-devs@xwiki.org

Re: [xwiki-devs] [xwiki-notifications] r20329 - in platform/core/trunk/xwiki-rendering/xwiki-rendering-xwiki/src/main: java/org/xwiki/rendering/internal/renderer resources resources/META-INF
by Sergiu Dumitriu 23 May '09

23 May '09

vmassol (SVN) wrote: > Author: vmassol > Date: 2009-05-23 17:08:55 +0200 (Sat, 23 May 2009) > New Revision: 20329 > > Added: > platform/core/trunk/xwiki-rendering/xwiki-rendering-xwiki/src/main/java/org/xwiki/rendering/internal/renderer/XWikiLinkLabelGenerator.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-xwiki/src/main/resources/META-INF/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-xwiki/src/main/resources/META-INF/component-overrides.txt > Log: > XWIKI-3892: Make XWiki Rendering usable standalone as a library independent of XWiki Core/XWiki Enterprise > > * Added leftovers > > Added: platform/core/trunk/xwiki-rendering/xwiki-rendering-xwiki/src/main/java/org/xwiki/rendering/internal/renderer/XWikiLinkLabelGenerator.java > =================================================================== Missing svn:keywords > + * @version $Id: DefaultLinkLabelGenerator.java 19713 2009-05-11 21:36:01Z sdumitriu $ Wrong @since > + * @since 1.6M1 -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 3

[xwiki-devs] Setting up a annotation prototype enabled wiki
by lucien.pereira＠xwiki.com 23 May '09

23 May '09

Hi all, Since annotation prototype seems to be stable enough, I'm proposing you to add it to myxwiki.org in order to test it and to get feed back about bugs and UI improvements. *Annotation location retrieval system* We chose to use a typographic alteration system in order to map a selection from html document to the xwiki source which had generated it. So, each non alphanumeric character is deleted whereas others becomes uppercase. After matching the altered selection in the altered source, we are enable to deduce real ''offsets'' from ''altered'' offsets (having previously filled a hash map). *Rendering* In order to produce an annotated html code we inject in the document xwiki source marks and render it. Then we replace marks by span markups. In order to avoid ''tag crossing'' (<c><d></c></d>) annotation zone can be splited in several span tags. *Architecture and Installation* This feature implementation can be divided in three modules : http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-plugin-annotation/ This plugin provide the logic side of the feature: - determining annotation location - adding annotation to the document - rendering and injection of span it require a standard plugin installation process. http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-rest-annotation/ This module provide a rest interface in order to communication with plugin. Communication is done using this rest resource : http://{host}/xwiki/rest/wikis/xwiki/spaces/{space}/pages{page}/annotation A GET request returns generated and annotated html and the set of annotations in the page. A PUT request aims to add an annotation to resource. To install it, web.xml must be modified:  <servlet> <servlet-name>RestletServlet</servlet-name> <servlet-class> org.xwiki.rest.XWikiRestletServlet </servlet-class> <init-param> <param-name>resources</param-name> <param-value> ... com.xpn.xwiki.rest.annotation.AnnotationService; </param-value> </init-param> ... http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-application-annotation/ This is the client side of the feature, it use rest interface in order to request an annotation, retrieve html annotated content and put in the DOM. it's a xar package which must be imported. *Prototype usage* Just select a non dynamique data in page content, an annotation edition box should appear, fill it and validate. To display annotation just click on Annotations > Show annotations menu item. Lucien Pereira.

5 10

[xwiki-devs] [ANN] XWiki Enterprise 1.8.4 and XWiki Enterprise Manager 1.6.4 Released
by Thomas Mortagne 22 May '09

22 May '09

The XWiki development team is pleased to announce the release of XWiki Enterprise 1.8.4 and XWiki Enterprise Manager 1.6.4. This release contains 55 bugfixes and enhancements. Most of the modifications are targeting the general replacement of old 1.0 code and content by 2.0 syntax and architecture and the stabilization of XWiki. Summary of changes since XWiki Enterprise 1.8.3 : * Many WYSIWYG bugs fixed and improvements * Many 2.0 syntax bugs fixed * Many 1.0 to 2.0 conversion bugs fixed * Several PDF export bugs fixed and improvements * Improvements for the Office Importer * A few bug fixes in many other places For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise184 and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM164 Thanks -The XWiki dev team

5 4

[xwiki-devs] [Ideas/Proposal] Thoughts on the Wiki Import feature for GSOC
by Vincent Massol 22 May '09

22 May '09

Hi (Arun), I've thought a bit and here are some ideas: 1) Have a xwiki-importer module in platform/core/ Note that later on we could move the XAR importer as a submodule in there too. This module will contain all the java code to perform input parsing + import into wiki pages. 2) Have a xwiki-importer application in platform/applications/ This application would provide an "Import" icon in the Admin page. When you click on that icon you would get to a second page with several icons: - Import Application (that's the current XAR import) - Import from Confluence - Import from Mediawiki ... 3) Each "Import from ..." will have its own UI since the import methods differ from wiki to wiki Arun, you need to look at all wikis for which we want to offer an importer for (MediaWiki and Confluence to start with) and see what options they offer: - could be an export in the form of XML files in a zip - could be accessing them through a REST/XMLRPC/other api online For a first version I think we should offer only 1 way of importing and I'd suggest the zip containing XML if that's supported by the wiki. 4) (this is a second step) Write Link parsers for the different wiki syntaxes (since right now we only have XWiki 2.0 link parser). We'll need 1 for mediawiki and 1 for confluence. 5) (this is a third step) Deal with macros. For example confluence offers lots of macros which when imported will not work. We can convert them to XWiki macros that do something similar. We'll need to identify simple macros that we don't have to add them. Of course for macros that we don't have, they wouldn't be converted. 6) We need a Roadmap/planning * Do this in the sandbox for now * Prepare a planning with milestones. * Each milestone shouldn't be longer than 2 weeks. * Make sure you don't slip dates * Always have something that work. This means that after the first milestone you *MUST* have something that can be demonstrated and that is working (even if it's not doing much) * Corollary: always start by doing the integration work first so that you can have a working chain. More specifically, after your first milestone, I should be able to drop the xwiki-import JAR in my xwiki's WEB-INF/lib + import the xwiki- import XAR and be able to click on "Import from Mediawiki" and be able to have the pages imported in xwiki 2.0 syntax (no options for the first version). The first milestone could be 3 weeks since you need to set up the plumbery. Let me know what you think. All: let us know also what you think about this. Guillaume: Let us know if you're ok with the UI ideas above. Thanks -Vincent

2 3

[xwiki-devs] XE 1.9 RC1 postponed to Monday 25
by Vincent Massol 20 May '09

20 May '09

Hi, Since it's a bank holiday tomorrow and our release manager is on holidays till Sunday night we're postponing the 1.9RC1 release to next Monday. This means committers can still commit non risky *bug fixes* on the 1.9 branch for the coming few days and thus progress on the work that needs to be done for 1.9RC2. 1.9RC2 release date is maintained to 1st of June. Note that 1.9RC2 == 1.9 final. Thanks -Vincent

1 0

[xwiki-devs] [VOTE] Enable XWiki syntax 2.0 by default in 1.9 final
by Vincent Massol 20 May '09

20 May '09

Hi, I'd like to propose that we enable by default the 2.0 syntax in 1.9 final (i.e do this in RC2). Here's my +1 Thanks -Vincent

10 11

[xwiki-devs] [Proposal] Choosing a new format for serializing a document's name
by Vincent Massol 19 May '09

19 May '09

Hi, We need to choose a new format for serializing a document name for several reasons: - the current format is ambiguous and doesn't allow too many characters to be entered - it doesn't support nested spaces I'd like to propose the following format: a URL. <wiki>://<space1>/<space2>/.../<spaceN>/<page>?<params>#anchor Examples: * Page * Space/Page * mywiki://Space/Page * mywiki://some/nested/Space/Page * Page?param=value * Page#anchor + the ability to escape chars. For example if the user wants to have the "/" char in a page name he would have: Special~/Page (we can decide what escape char to use) Of course, it'll be the role of the serializer to escape chars as required. Pros of using a URL format: * easy to code since we can reuse the JDK's URL class * URL friendly. It's easy to copy paste the URL of a document into a link. No more needing to translate "." into "/" * it's JCR friendly since JCR also uses "/" for the path to a Node * it's a well known format and users are used to it WDYT? Thanks -Vincent

4 4

[xwiki-devs] XWikiAllGroup implicit behavior
by Ludovic Dubost 19 May '09

19 May '09

Hi, As part of the Curriki development, since Curriki is growing big (more than 60000 users), the XWiki.XWikiAllGroup is not scalable and this can lead to bad things. I've proposed a patch to make XWiki.XWikiAllGroup implicit. We have tested it and this seems to work well (see http://jira.xwiki.org/jira/browse/CURRIKI-738 for the patch). The only issue I see is the fact that once you have activated this, the counter of number of users for the group all group in the administration and the ability to edit the group makes no sense. Finally the adding the the AllGroup in registration has not yet been deactivated which would be necessary to make the registration not be impacted by the number of users. The Curriki team would like to see this patch make it in the XWiki Core. WDYT ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

5 4

Re: [xwiki-devs] [xwiki-notifications] r20119 - platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest
by Vincent Massol 19 May '09

19 May '09

On May 19, 2009, at 7:52 PM, fmancinelli (SVN) wrote: > Author: fmancinelli > Date: 2009-05-19 19:52:09 +0200 (Tue, 19 May 2009) > New Revision: 20119 > > Modified: > platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/ > ComponentsObjectFactory.java > Log: > [Minor] Use component descriptors in order to check whether a > component has a PER_LOOKUP instantiation strategy. > > Modified: platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/ > rest/ComponentsObjectFactory.java > =================================================================== > --- platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/ > ComponentsObjectFactory.java 2009-05-19 17:47:18 UTC (rev 20118) > +++ platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/ > ComponentsObjectFactory.java 2009-05-19 17:52:09 UTC (rev 20119) > @@ -25,6 +25,7 @@ > import org.restlet.ext.jaxrs.InstantiateException; > import org.restlet.ext.jaxrs.ObjectFactory; > import org.xwiki.component.annotation.InstantiationStrategy; > +import org.xwiki.component.descriptor.ComponentDescriptor; > import org.xwiki.component.descriptor.ComponentInstantiationStrategy; > import org.xwiki.component.manager.ComponentLookupException; > import org.xwiki.component.manager.ComponentManager; > @@ -65,6 +66,8 @@ > XWikiRestComponent component = > (XWikiRestComponent) > componentManager.lookup(XWikiRestComponent.class, clazz.getName()); > > + ComponentDescriptor componentDescriptor = > componentManager.getComponentDescriptor(XWikiRestComponent.class, > clazz.getName()); > + > /* > * Retrieve the releasable component list from the > context. This is used to store component instances that > * need to be released later. > @@ -79,11 +82,8 @@ > } > > /* Only add components that have a per-lookup > instantiation stategy. */ > - InstantiationStrategy is = > component.getClass().getAnnotation(InstantiationStrategy.class); > - if (is != null) { > - if > (is.value().equals(ComponentInstantiationStrategy.PER_LOOKUP)) { > - releasableComponentReferences.add(component); > - } > + > if > (componentDescriptor > .getInstantiationStrategy > ().equals(ComponentInstantiationStrategy.PER_LOOKUP)) { you could write: if (componentDescriptor.getInstantiationStrategy() == ComponentInstantiationStrategy.PER_LOOKUP) -Vincent > > + releasableComponentReferences.add(component); > } > > /*

2 1

[xwiki-devs] [Discussion] Officeimporter remote OpenOffice server
by Asiri Rathnayake 19 May '09

19 May '09

Hi Devs, Currently OfficeImporter requires an OpenOffice server to be present in the same computer as XE. I have been searching about adding support for a remote OpenOffice server but the results are not very promising: http://groups.google.com/group/jodconverter/browse_thread/thread/f4f0e8328d… Even though this is the case, I think we can settle on a compromise with the following approach: * We develop a stand-alone servlet (probably under xwiki-tools just like the root-web-app) * The purpose of this servlet is to: 1. Accept incoming office documents 2. Convert them into html (results in multiple files) 3. Zip the results together 4. Stream the zipped content back to the client * And the client would be any xwiki instance that is configured to consume this converter-servlet. This way, multiple XWiki instances would be able to share a central OpenOffice server via the converter-servlet. The downside of this approach is that there has to be a servlet container on the remote computer which is hosting the OpenOffice server. Please let me know what you think about this idea. Thanks. - Asiri

2 2