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

[xwiki-devs] [Proposal] Roadmap for XE 2.4
by Vincent Massol 15 Jun '10

15 Jun '10

Hi devs, It's time for roadmap again in order to define what we want to work on for XE 2.4 (as usual this list doesn't include bugs that we have to fix). Here's a proposal that takes into account past stuff that we had planned for XE 2.3 and that haven't been done: * Work on improving performances in general (could be a cache macro, object handling improvements, etc). Any taker? * Finish xwiki-localization. Suggestion: Sergiu + Thomas * Lucene as main search engine in XE: Thomas * Fix some security issues. Sergiu + others? * Edit Mode UI Changes: JV/Sergiu/Marta * Continue the Model Reference refactoring - Vincent * Office preview - Asiri * Invitation Manager - Caleb * Rights UI improvement to make rights easy to use at last - Suggestion: Caty + Sergiu * Support for component versioning and claddloader isolation (prereq for the extension manager) - Vincent * Integration of xwiki-portlet in sandbox into the platform - Marius Nice to have: * Livetable macro - Asiri * Selective Export UI - Any taker ? * Continue work on Model. Suggestion: Vincent * Office Export - Asiri Proposed dates: * XE 2.4M1: 24 May 2010 * XE 2.4M2: 14 June 2010 * XE 2.4RC1: 28 June 2010 * XE 2.4 RC2 (if needed): 5 July 2010 * XE 2.4 Final: 12 July 2010 WDYT? Please everyone confirm if what is put next to your name is ok with you or if you have other ideas or wish to work on something else. I'll then update http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap Thanks a lot -Vincent

6 11

[xwiki-devs] [Proposal] XWiki Portlet Integration
by Marius Dumitru Florea 15 Jun '10

15 Jun '10

Hi devs, You can find here http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration a draft regarding the portlet integration. We need to decide what's the best approach. For short term I think the loosely-coupled integration solution is the best as it requires less changes to the core. The current implementation is in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ and I propose to move it to platform/xwiki-portlet before 2.4M2. For long term, when we'll have the new model in place, we might consider the tightly-coupled integration solution as it seems to be more clean and it follows the component way. It won't be easy to implement though. WDYT? Thanks, Marius

5 9

[xwiki-devs] [Proposal] Use JMX for XWiki Management + xwiki-management module in platform/core
by Vincent Massol 14 Jun '10

14 Jun '10

Hi devs, We need to introduce some ways to manage XE instances by exposing management data and operations. For example exposing the content of the xwiki caches, operation to flush them, etc. Even the ability to view/modify XWiki's configuration data at runtime. I propose to use a standard to do this: JMX. The concept is easy: - you write a MBean java bean - you register it against an MBean server Note that all containers support JMX. I've tried it with Jetty and it's enabled by default which means that you can try it by starting XWiki with jetty then open another shell and type "jconsole" (it's part of the JDK since 1.5). JConsole is a JMX console. Then go to the MBeans tab and you'll Mbeans already registered. You'll see for example the JBoss caches since JBoss Caches exposes some MBeans by default. I have written a POC already in the Velocity module to expose the velocity engines, the template namespaces and the macros registered in each template. I'm ready to commit it as a first step in the direction of using JMX. I'd also like to introduce a xwiki-management module which will contain some generic code related to JMX management. Right now I have a JMXBeanRegistration component to perform registration of XWiki MBean. That component will be used by any module wanting to register a MBean. WDYT? Thanks -Vincent

4 5

[xwiki-devs] Build failed
by Bogdan Flueras 14 Jun '10

14 Jun '10

Hello guys, It's been a long time since I've done a build on the *platform* module. However, doing an update on this module and invoking the maven command: *mvn clean package -Pdev -Dtest=none -DfailIfNoTests=false * in the main directory (*/platform/trunks*) fails due to a typo in the *foxwiki*'s *pom.xml*. The parent pom (*tools*) has version 2.4-SNAPSHOT while the child has the 2.3-SNAPSHOT version for the parent. Fixed that. Now a hard one: Issuing the same mvn command in the *platform/trunks/core *dir fails when compiling the *XWiki Platform - Core - Annotations - REST Services* with the following error: *DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory**.* *Please find the stacktrace err message in the following link: http://pastebin.com/4zC4KPUf* * * Before posting this mail I double checked the *.m2/settings.xml* file and also did the same steps using another machine, a new checkout and an empty mvn repo, just to be sure. Still this problem persists. As XWiki has a continuous build system, perhaps I have mis-configured something and I would highly appreciate some feedback. Best regards! Ps: The problem seems to be a class cast exception due to the fact that 2 versions of xercesImpl jar are used in the project (one with compile scope,while the other with runtime scope). In the latter case, the version 2.9.1 is used and I suspect this as the root cause of the problem.

1 0

[xwiki-devs] [proposal] Establish/Codify a best practice of putting all javascript in the <head> of the document.
by Caleb James DeLisle 14 Jun '10

14 Jun '10

I would like to see a (written) best practice of putting all javascript content into the head of the XHTML document. Reason 1: Moving all script into the head makes it easier to find and makes impossible bad (and often non WCAG compliant) practices such as attaching script to xml attributes. It makes it less of a jungle. Reason 2: If we have no script in the body of any documents then users can implement filters which remove any script after the </head> tag. This would make script injection certifiably impossible. WDYT? Caleb

3 3

[xwiki-devs] [Proposal] How about extending EscapeTool to add XWiki 1.0 and 2.0 escaping? Re: [xwiki-users] XWiki/1.0 and XWiki/2.0 escaping
by Caleb James DeLisle 14 Jun '10

14 Jun '10

Right now $escapetool is included via velocity configuration. I don't see any reason why we couldn't change to a VelocityContextInitializer which adds an extension of escapetool which has: $escapetool.xwiki1(String) $escapetool.xwiki2(String) Although it would be cleaner I'm resistant to: $escapetool.xwiki.syntax20(String) or the like because vulnerability is easier than security so we should make security as easy (to type) as possible. I'm not sure when I'll have time to do this but I don't think it'd take more than a few hours. WDYT? Caleb Marius Dumitru Florea wrote: > On 06/13/2010 11:43 AM, Marius Dumitru Florea wrote: >> On 06/12/2010 04:26 PM, Ivan Levashew wrote: >>> Hello! >>> >>> Yet another problem I'm encountering is lack of >>> proper escaping tools. I have noticed it when I >>> decided to use [ and ] in page titles. >>> «My Recent Modifications» became broken because >>> XWiki parsed [ and ]. Currently I have added >>> {pre} and {/pre} at both ends, but it is just a >>> krunch. What is the proper way? I have checked >>> $escapetool and $xwiki.get*Encoded APIs. There is >>> no common API to escape [, ], =, {, etc. > >> You haven't checked >> http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HEscapes ;) > > This doesn't fix your problem. What about > http://platform.xwiki.org/xwiki/bin/download/DevGuide/API/xwiki-core-2.3.1-… > ? > >> Hope this helps, >> Marius >> >>> >>> _______________________________________________ >>> users mailing list >>> users(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/users >> _______________________________________________ >> users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users

5 7

[xwiki-devs] [Vote][Proposal] Rights Management
by Ecaterina Valica 11 Jun '10

11 Jun '10

Hi, For a while we've been discussing how the new Rights Management UI is gonna look like. After 5 prototype versions, we may have reached a conclusion. Please take a look at: *Prototype* http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space *Explanations* http://incubator.myxwiki.org/xwiki/bin/view/Improvements/RightsProposal Please cast your vote if this is gonna be the final Rights representation, so that we may start the implementation. my +1 Any feedback is welcomed and we can still added improvements to this version. The current version is a collaborative work done by me, Denis Gervalle, Raluca Stavro, Alex Busenius, Roman Muntyanu and many others (Guillaume, Sergiu, Vincent, Thomas). Thanks everyone for participating in the process. Thanks, Caty p.s: former discussion about mocking process can be seen at [Proposal] Rights Management UI http://markmail.org/thread/zgzufskvhe6xt6ey

7 17

[xwiki-devs] The Social Networking Mess: Why we need the Social Web
by Story Henry 11 Jun '10

11 Jun '10

Hi, I put a new (10 min) video together that gives an overview of why we need the Social Web based on Web IDs. http://www.yovisto.com/play/17147 This is an overview of what the point of http://webid.myxwiki.org/ is. Btw, we are now working on creating OSGI compliant libs for the java code at http://github.com/bblfish/foafssl-java Henry Social Web Architect http://bblfish.net/

1 0

[xwiki-devs] [Proposal] Documentation Standard Document & Call to Vote
by Sorin Burjan 11 Jun '10

11 Jun '10

Hello. Silvia and me have created a DRAFT for XWiki.org Documentation Standard found at : http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiOrgDocumentationStandard In order to move towards the final version, we need your input on 2 issues. - For which project version we create & maintain documentation - Which skins we are going to support in the documentation (latest/all) Although, these issues were discussed in December 2009, no final result came out of them. http://markmail.org/message/ou7hgdiiwgayghku#query:+page:1+mid:ou7hgdiiwgay… 1. the project version (XE version for ex) for which the documentation is created/updated/maintained. We have several choices: a) We make the documentation only for the latest version. b) We make the documentation only for the latest version, and we export the pages at release time and make it available as a zipped HTML export so that people using the older version can refer to them. c) We make the doc work the last 2 releases. That would be 2.3 and 2.4. Note: If option b) is chosen then we need to add a step to the release process. (export for every release) 2. The skin used for documenting steps. This also includes the screenshots. Again we have several choices: a) Document only for the latest default skin. b) Document for all supported skins. Right now that would be Toucan + Colibri (not sure about Albatross, I don't think we've officially said it wasn't supported). Note: If option b) is chosen, this would mean 2 screenshots for the same feature (one for each skin) The vote content was mostly taken from the markmail link above. If you have any other suggestions regarding this draft, please reply and state your opinion. We need as much feedback as possible in order to create a solid documentation standard.

4 4

Re: [xwiki-devs] [xwiki-notifications] r29399 - in platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src: main/java/org/xwiki/configuration/internal test/java/org/xwiki/configuration/internal
by Vincent Massol 11 Jun '10

11 Jun '10

On Jun 10, 2010, at 5:43 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2010-06-10 17:43:32 +0200 (Thu, 10 Jun 2010) > New Revision: 29399 > > Modified: > platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/main/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSource.java > platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/test/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSourceTest.java > Log: > XWIKI-5264: Cannot get the value of a property stored in the space preferences using the configuration module > Fix important regression: when using a peace of enityreference to create another one it should be cloned otherwise it's breaking the initial reference Thanks for the fix Thomas. [snip] > Modified: platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/test/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSourceTest.java > =================================================================== > --- platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/test/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSourceTest.java 2010-06-10 14:14:50 UTC (rev 29398) > +++ platform/core/trunk/xwiki-configuration/xwiki-configuration-default/src/test/java/org/xwiki/configuration/internal/SpacePreferencesConfigurationSourceTest.java 2010-06-10 15:43:32 UTC (rev 29399) > @@ -55,15 +55,19 @@ > ConfigurationSource source = getComponentManager().lookup(ConfigurationSource.class, "space"); > > final DocumentReference webPreferencesReference = new DocumentReference("wiki", "space", "WebPreferences"); > + final DocumentReference currentDocument = new DocumentReference("wiki", "space", "page"); > + > mockery.checking(new Expectations() {{ > allowing(bridge).getCurrentDocumentReference(); > - will(returnValue(new DocumentReference("wiki", "space", "page"))); > + will(returnValue(currentDocument)); > oneOf(bridge).getProperty(webPreferencesReference, webPreferencesReference, "key"); > will(returnValue("value")); > }}); > > String result = source.getProperty("key", String.class); > + > Assert.assertEquals("value", result); > + Assert.assertEquals(currentDocument.getName(), currentDocument.getParent().getChild().getName()); This last line is going to be very hard to remember in the future (ie why we've written that). IMO it's not the right place for this test. If you want to keep it at least it needs to be heavily commented (but this indicates IMO that it's not the right place). Thanks -Vincent

2 1