February 2011 - xwiki-devs@xwiki.org

[xwiki-devs] Bug Fixing Day: Thursday, February 10
by Sergiu Dumitriu 08 Feb '11

08 Feb '11

Hi community, This Thursday we'd like to do a Bugfixing Day, and everyone is welcome to participate with bug reporting or patching. (Sorry, forgot to announce this earlier) -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 2

[xwiki-devs] Coarse dates for the 3.x cycle
by Vincent Massol 08 Feb '11

08 Feb '11

Hi devs, I've put on http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap coarse dates for the 3.x releases. I've followed our past rules and rhythm, which is about 2.5 months for each release and a total of about 1 year for a Cycle. This gives: * 3.0: March 2011 * 3.1: May 2011 * 3.2: July 2011 * 3.3: September 2011 * 3.4: November 2011 * 3.5: January 2012 The reason why I thought it would be good to be visible on our Roadmap page is to provide additional visibility to our users so that they can plan ahead their installations/upgrades of XE. Link: * Definition of Release Cycle: http://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices Let me know if this doesn't correspond to your idea. Thanks -Vincent

1 0

[xwiki-devs] [VOTE] Adding a third milestone to XE 3.0 release cycle (i.e. extending it by 3 weeks)
by Vincent Massol 08 Feb '11

08 Feb '11

Hi devs, I'd like to propose adding a XE 3.0M3 to the XE 3.0 release. The reason is that we're lagging on the following features and it would be good to have them in a final 3.0 release: * Dashboard/Gadgets * Extension Manager (XAR handling) In addition we need a bit more time for the following features to ensure they're of good quality: * User statuses (Sergiu is working on them for 3.0M2 but it's tight) * Attachment storage on the filesystem Moreover, 3.0 is the right time to perform cleanup of the source code. Thus the new dates would be: * 3.0M2: 7th of Feb (not changed) * 3.0M3: 28th of Feb * 3.0RC1: 14th of March * 3.0 Final: 28th of March (instead of 7th of March) Here's my +1 Thanks -Vincent

7 7

Re: [xwiki-devs] [xwiki-notifications] r34465 - platform/core/trunk
by Marius Dumitru Florea 07 Feb '11

07 Feb '11

Hi Thomas, On 02/07/2011 06:36 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2011-02-07 17:35:24 +0100 (Mon, 07 Feb 2011) > New Revision: 34465 > > Modified: > platform/core/trunk/pom.xml > Log: > XWIKI-5964: Upgrade to Jython 2.5.2rc3 Version 2.5.2rc3-xwiki is missing from http://maven.xwiki.org/externals/org/python/jython-standalone/ . Can you fix this? Thanks, Marius > > Modified: platform/core/trunk/pom.xml > =================================================================== > --- platform/core/trunk/pom.xml 2011-02-07 16:19:52 UTC (rev 34464) > +++ platform/core/trunk/pom.xml 2011-02-07 16:35:24 UTC (rev 34465) > @@ -61,7 +61,7 @@ > <dependency> > <groupId>org.python</groupId> > <artifactId>jython-standalone</artifactId> > -<version>2.5.2rc2-xwiki</version> > +<version>2.5.2rc3-xwiki</version> > </dependency> >  > <dependency> > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

2 3

Re: [xwiki-devs] [xwiki-notifications] r34450 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/internal/macro
by Thomas Mortagne 07 Feb '11

07 Feb '11

On Mon, Feb 7, 2011 at 12:53, vmassol <platform-notifications(a)xwiki.org> wrote: > Author: vmassol > Date: 2011-02-07 12:53:01 +0100 (Mon, 07 Feb 2011) > New Revision: 34450 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/internal/macro/WikiMacroExecutionEventListener.java > Log: > XWIKI-5928: ID macros generated from HTML anchors are not properly closed Should be XWIKI-5957: New permission check introduced in 2.5 forbids macros which need programming rights in subwikis > > * Fixed checkstyle error > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/internal/macro/WikiMacroExecutionEventListener.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/internal/macro/WikiMacroExecutionEventListener.java 2011-02-07 11:27:36 UTC (rev 34449) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/internal/macro/WikiMacroExecutionEventListener.java 2011-02-07 11:53:01 UTC (rev 34450) > @@ -76,9 +76,15 @@ > @Requirement > private DocumentAccessBridge documentAccessBridge; > > + /** > + * Temporarily used to resolve the user as a valid document reference. > + */ > @Requirement > private DocumentReferenceResolver<String> resolver; > > + /** > + * Temporarily used to serialize a document reference pointing to a user as a String. > + */ > @Requirement > private EntityReferenceSerializer<String> serializer; > > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications > -- Thomas Mortagne

1 0

[xwiki-devs] [proposal] Move com.xpn.xwiki.store.jcr to contrib/retired
by Caleb James DeLisle 07 Feb '11

07 Feb '11

As I understand, jcrstore is unused, untested, and suspected to be non functional or incomplete. I would like to move it to contrib/retired and remove references to it from com/xpn/xwiki/plugin/query/QueryPluginApi.java and com/xpn/xwiki/plugin/query/QueryPlugin.java From what I can see, this will have no effect on the query plugin itself. WDYT? Caleb

6 5

[xwiki-devs] [Idea] xwiki-sanity module/application
by Vincent Massol 04 Feb '11

04 Feb '11

Hi devs, I'd like to explore the idea of having a xwiki-sanity module which would be in charge of making verifications in a running XE/XEM instance and reporting issues/making fixes were needed. We could also have a counterpart xwiki-sanity application (XAR). Here are some potential use cases (I'm sure we can find lots of others): * Check DB version and perform migrations of the schema accordingly (our current migration system which is currently located in xwiki-core) * Perform various checks on DB settings, cache settings, etc * Perform deprecation call checks in velocity (the current deprecated uberspector) * More specific checks. For example: intercept the call to the velocity macro and add a check on: if the page where the velocity is executed is called Blog.BlogSheet and the content of the velocity contains "#getEntryDate($entryDoc $entryObj $entryDate)" and the platform version is >= 3.0M1 then don't execute the macro but instead display the message "The Blog application is not compatible with this version of XE, please upgrade to the latest Blog application". WDYT? Thanks -Vincent

2 1

[xwiki-devs] Problems noticed while upgrading myxwiki farm to 3.0M1
by Vincent Massol 04 Feb '11

04 Feb '11

Hi devs, I've noticed 3 problems we might want/need to fix before the final 3.0 release: 1) The wiki manager app generates a velocity error on CreateNewWiki page: http://myxwiki.org/xwiki/bin/view/WikiManager/CreateNewWiki 2) If you create a new wiki, create a new user, remove the Admin user, you cannot add the new user for the admin group since when you remove the Admin user that group disappears in the UI. Caleb says he knows the problem and will be working on a fix over the week end 3) Previous blog application fails on XE 3.0M1 with: org.xwiki.rendering.macro.MacroExecutionException: Failed to evaluate Velocity Macro for content [{{html clean="false" wiki="true"}} ## ## ## #showBlogInfo($doc) #if($context.action != 'inline') #printBlog($doc) #end {{/html}}] at org.xwiki.rendering.internal.macro.velocity.VelocityMacro.evaluateString(VelocityMacro.java:124) at org.xwiki.rendering.internal.macro.velocity.VelocityMacro.evaluateString(VelocityMacro.java:47) at org.xwiki.rendering.macro.script.AbstractScriptMacro.evaluateBlock(AbstractScriptMacro.java:298) at org.xwiki.rendering.macro.script.AbstractScriptMacro.execute(AbstractScriptMacro.java:190) at org.xwiki.rendering.macro.script.AbstractScriptMacro.execute(AbstractScriptMacro.java:57) at org.xwiki.rendering.internal.transformation.macro.MacroTransformation.transformOnce(MacroTransformation.java:184) at org.xwiki.rendering.internal.transformation.macro.MacroTransformation.transform(MacroTransformation.java:129) at org.xwiki.rendering.internal.transformation.DefaultTransformationManager.performTransformations(DefaultTransformationManager.java:72) at com.xpn.xwiki.doc.XWikiDocument.performSyntaxConversion(XWikiDocument.java:7471) at com.xpn.xwiki.doc.XWikiDocument.performSyntaxConversion(XWikiDocument.java:7420) at com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:835) at com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:783) at com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:878) at com.xpn.xwiki.api.Document.getRenderedContent(Document.java:545) at sun.reflect.GeneratedMethodAccessor1038.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280) at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:567) at org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71) at org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:106) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:196) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:161) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:116) at com.xpn.xwiki.XWiki.evaluateTemplate(XWiki.java:1894) at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1832) at com.xpn.xwiki.api.XWiki.parseTemplate(XWiki.java:860) at sun.reflect.GeneratedMethodAccessor899.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:369) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) at org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:216) at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:311) at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:106) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:196) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:161) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:116) at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1942) at com.xpn.xwiki.XWiki.evaluateTemplate(XWiki.java:1864) at com.xpn.xwiki.web.Utils.parseTemplate(Utils.java:154) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:226) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:117) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:129) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:152) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.xwiki.container.servlet.filters.internal.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:218) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.xwiki.container.servlet.filters.internal.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:595) Caused by: org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id [ludovic:Blog.WebHome] at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:205) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:161) at org.xwiki.rendering.internal.macro.velocity.VelocityMacro.evaluateString(VelocityMacro.java:117) ... 96 more Caused by: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'formatDate' in class com.xpn.xwiki.api.XWiki threw exception java.lang.NullPointerException at ludovic:Blog.WebHome[line 324, column 29] at org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:243) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:187) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280) at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:567) at org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71) at org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) at org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:420) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) at org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:216) at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:311) at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) at org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:216) at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:311) at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) at org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:196) ... 98 more Caused by: java.lang.NullPointerException at com.xpn.xwiki.XWiki.formatDate(XWiki.java:5965) at com.xpn.xwiki.XWiki.formatDate(XWiki.java:5970) at com.xpn.xwiki.api.XWiki.formatDate(XWiki.java:2098) at sun.reflect.GeneratedMethodAccessor953.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173) ... 121 more Any taker to analyze problems 1) and 3)? Thanks -Vincent

2 8

[xwiki-devs] Upgrade Hudson to Jenkins 1.396?
by Vincent Massol 03 Feb '11

03 Feb '11

Hi devs, As you probably know by now, Hudson has been split in 2: * Jenkins: Kohsuke and all other committers forked and renamed Hudson since there were trademarks issues with Oracle * Hudson: continuing work by Oracle Some more info: http://jenkins-ci.org/content/whos-driving-thing One thing to note is that Sonatype has sided with Oracle: http://www.sonatype.com/people/2011/02/our-focus-on-advancing-hudson-and-ma… Now we need to pick a version: Jenkins or Hudson (community or Oracle). Personally I'm more tempted to follow Jenkins for the time being since: 1) it's the community after all and they're the one who've been doing the work all these past years 2) they're not going to change how jenkins works whereas my understand is that the hudson architecture will be changed (at least that's what Sonatype wants). So in the short period if we want to continue using stable versions the Jenkins path is the safest one. We can then review our choice when Hudson releases new versions. The first official release of Jenkins is out (1.396). See changelog at http://jenkins-ci.org/changelog Since we're using 1.367 it's a good time to upgrade IMO. Note that Jenkins is simply a find/replace of Hudson to Jenkins and it's a drop in replacement (see http://wiki.jenkins-ci.org/display/JENKINS/Upgrading+from+Hudson+to+Jenkins) WDYT? Thanks -Vincent

7 6

[xwiki-devs] [PROPOSAL] Required right meta data in pages that needs it
by Jerome Velociter 03 Feb '11

03 Feb '11

Hi developers, I've setup and worked on a couple of wiki farms recently, and my feedback is that the PR issue has become for me a major PITA. It's worst than before, because we've introduced a lot of pages that requires it : annotations style and script, plus the wiki macros for activity, tag cloud, space, etc. (OK, it's not really PR, it's edit right of the last person who did edit it, but it's the same issue mostly : you need to have it saved by someone with sufficient rights). Importing not as back-up (meaning all pages imported from the XAR are saved by the user doing the import) is not sufficient answer, for several reason : * User might not have programming rights * When user has programming rights, it's a BAD practice in terms of security (it means every page of the wiki initially has the PR right OK) * Wiki creation is also done by template wiki copy, which is not covered by this * This problem is not just an import/creation problem, we need generally a way to know which pages require PR, and which are missing this PR (users can be deleted, their rights can change, etc.). OK, that looks like sufficient complaining :) Here what I propose, tell me what you think : 1. We define a XWiki class, like XWiki.RequiredRightClass, with a field that describe the required right the user saving the document must have for it to behave properly (for example it will be "edit" for wiki macros with a "wiki" scope, and "programming" for pages that uses privileged APIs, or JSR scripts, or always use SSX, etc.) 2. We make a simple UI (for example in the administration section of the admin app) that list all of them, and their current status. Plus a button to fix the status if there is something to fix (a missing PR for example) and if the user seeing the page has the required rights of course. That's what I propose for now. In the future, we could imagine that : 3. Programming right can only be granted on a page that requires it explicitly. This would be a non-backward compatible change. Let me know what you think. If we agree I volunteer to implement this in 3.0 M2. Jerome.

7 18