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

[xwiki-devs] [VOTE] Add xwiki-platform-wiki-manager-api as a dependency for XE - Pull request "Add REST APIs for creating wikis and importing XARs"
by Fabio Mancinelli 01 Nov '12

01 Nov '12

Hi everybody, I will try to go forward in committing REST API improvements made by Ludovic and me. Looking at the discussion about the pull request I opened https://github.com/xwiki/xwiki-platform/pull/68 Thomas pointed out the fact that it brings "xwiki-platform-wiki-manager-api" as a dependency in XE, and this might require a vote. xwiki-platform-wiki-manager-api is something that was bundled only in XEM and not in XE. I added it as a dependency because I use its code for performing wiki creation and XAR importing. Thomas' comment is here: https://github.com/xwiki/xwiki-platform/pull/68#discussion_r1335333 So the vote is about the bundling of xwiki-platform-wiki-manager-api in XE for merging this pull request. I am +1, of course. Thanks, Fabio

3 5

[xwiki-devs] [VOTE] Merge feature-localization branch to master
by Thomas Mortagne 01 Nov '12

01 Nov '12

Hi devs, I would like to merge the https://github.com/xwiki/xwiki-platform/tree/feature-localization branch to master. Here is a summary of what it contains: * new localization module API following what described in http://markmail.org/message/blynasgz53ys345i * implementation of this API for ApplicationResources resources and document bundles listed in the preferences * implementation of this API for dynamically registered wiki document translations as described on http://markmail.org/message/bcmbhpwxnbagma3g Here is my +1. Thanks, -- Thomas Mortagne

7 7

[xwiki-devs] [VOTE] Property declarations for the execution context
by Andreas Jonsson 01 Nov '12

01 Nov '12

Hi Everyone, I would like you to vote on merging the feature-execution-context branches of commons and platform before the release of 4.3M2: https://github.com/xwiki/xwiki-commons/compare/master...feature-execution-c… https://github.com/xwiki/xwiki-platform/compare/master...feature-execution-… Explanation of the feature: The execution context is a simple map that binds a string to an object. This can be compared to how variables are handled by scripting languages such as bash, where an assignment brings the variable into existance: $ my_variable="some value" In the case of the execution context, the syntax is: context.setProperty("my_variable", "some value"); This feature is about adding property declarations, where a property can be associated with attributes that controls how the execution context and execution context manager handles the property. The general idea can, once again, be compared to bash and how it is possible to declare variables there: $ declare -ru my_variable="read only, forced upper case" Of course, the set of attributes that are interesting to us is different from bash. Currently the feature branch have support for declaring properties with these attributes: * Final - The value may not be updated within the the execution context. Default: false. * Inherited - The property will be inherited from the current context when replacing the execution context within the current scope. Default: false. * Cloned value - Also clone the value when the execution context is cloned. Default: false. * Type - The class of the value, for typechecking when setting the value. Default: null (unchecked). * Non-null - The value may not be null, checked when setting the value. Default: false. Example declaration: ExecutionContextProperty property = new ExecutionContextProperty("my_variable"); property.setValue("some value"); property.setType(String.class); property.setInherited(true); context.declareProperty(property); The property value may be updated and the property may be removed and redeclared, unless declared 'final': context.setProperty("my_variable", "some new value"); context.removeProperty("my_variable"); Additional attributes may be added later. This feature is also backwards compliant, in that implicit declaration by just setting a value is allowed. (Although we might want to make explicit declarations mandatory in the future.) Within the scope of a request, or the life time of a thread executing some administrative task (e.g., the lucene index updater) the basic life cycle of the execution context is the following: @Inject Execution execution; @Inject ExecutionContextManager ecm; ExecutionContext context = new ExecutionContext(); ecm.initialize(context); try { // Do work } finally { ecm.removeContext(); } Within the life cycle of the "root" execution context, we may push a new execution context, which may either be a clean context, or a clone of the current context: // Pushing a clone ExecutionContext context = ecm.clone(execution.getContext()); execution.pushContext(context); try { // Do work } finally { execution.popContext(); } // Pushing a clean context ExecutionContext context = new ExecutionContext(); execution.pushContext(context); try { // Do work } finally { execution.popContext(); } Component authors that needs to place a value in the execution context provides an initializer that declares the variable and sets an initial value. The attributes 'final', 'cloned value', and 'inherited' lets component authors control how the value is managed during the lifecycle of the root execution context. The attributes 'type' and 'non-null' provides some runtime assertions to catch some errors earlier. So to summarize, this feature: 1. is a convenient mechanism for managing properties in the execution context, 2. provides some validation of the property values, 3. improves performance slightly by avoiding unnecessary cloning. For more information, see the proposal thread: http://xwiki.475771.n2.nabble.com/PROPOSAL-Execution-context-property-decla… Best Regards, /Andreas

4 7

Re: [xwiki-devs] Remove or change menu
by Geo Du 30 Oct '12

30 Oct '12

Can anybody shed any lights on this topic? from the default standard deployment of the xwiki, it has the menus like Add, Wiki, Space, Page, I need to change or remove these kind menus as I described in the question. Thanks David On Fri, Oct 26, 2012 at 9:20 PM, Geo Du <dddu88(a)gmail.com> wrote: > Hi all, > > I like to remove some of the menu items based on the user logged in, for > example for one type of users, I need to remove the Add menu, or change > Wiki, Space or Page menus to my own menus, I checked the users rights, it > has View, Comment, Edit, Delete, Register, Program, they seem not designed > for that, any suggestions? I checked menuview.vm, that is where to control > the menus, it seems I need to change this file. > > Thanks for your suggestions in advance. > > David >

1 0

[xwiki-devs] JAR Duplicates in 4.3 Milestone 1 and SNAPSHOT
by Sorin Burjan 30 Oct '12

30 Oct '12

Hello everybody, After the release of 4.3 Milestone 1, I wanted to start testing the new features but I ran into an issue ( http://jira.xwiki.org/browse/XWIKI-8365 ) when starting and accessing the Wiki based on 4.3 M1. After Marius helped me figure out the cause, it seemed that we had a jar duplication of Xalan in our Manager package. I have tested this on another machine and wasn't able to reproduce. Fabio also tested, without success, but the duplication is clear - I had 2 Xalan jars in my /lib folder (even on the machine where I had no errors). After that, I started to look for other duplicates in my /lib folder. Below are my findings. Checked these 2 XWiki packages to be sure it's not package dependant: * xwiki-manager-jetty-hsqldb * xwiki-manager-jetty-mysql Found the following JAR duplicates: 1) activation-1.1.1.jar activation-1.1.jar 2) commons-lang3-3.1.1jar commons-lang-2.6.jar 3) jdom-1.0 jdom-1.1.jar 4) plexus-utils-2.0.6.jar plexus-utils-2.0.7.jar 5) rome-0.9.jar rome-1.0.0.jar rome 1.0.jar 6) vorbis-java-core-0.1.jar vorbis-java-core-0.1-tests.jar 7) xercesImpl-2.9.1.jar xercesImpl-2.8.1.jar After the release of 4.3 M1 I have also downloaded a 4.3-SNAPSHOT build (xwiki-manager-jetty-hsqldb-4.3-20121025.181227-95.zip). Besides the duplicates from above, I have also found a lot of XWiki jars duplicated. Note, the list if far from being complete ! xwiki-commons-classloader-api-4.3-20121024.173322-34.jar xwiki-commons-classloader-api-4.3-SNAPSHOT.jar xwiki-commons-classloader-protocol-jar-4.3-20121024.173330-34.jar xwiki-commons-classloader-protocol-jar-4.3-SNAPSHOT.jar xwiki-commons-component-observation-4.3-20121024.173347-34.jar xwiki-commons-component-observation-4.3-SNAPSHOT.jar xwiki-commons-configuration-api-4.3-20121024.173413-34.jar xwiki-commons-configuration-api-4.3-SNAPSHOT.jar xwiki-commons-context-4.3-20121024.173359-34.jar xwiki-commons-context-4.3-SNAPSHOT.jar xwiki-commons-diff-api-4.3-20121024.173722-33.jar xwiki-commons-diff-api-4.3-SNAPSHOT.jar xwiki-platform-bridge-4.3-20121025.165136-181.jar xwiki-platform-bridge-4.3-20121025.174305-182.jar xwiki-platform-cache-api-4.3-20121025.165403-177.jar xwiki-platform-cache-api-4.3-20121025.174540-178.jar xwiki-platform-cache-infinispan-4.3-20121025.165428-177.jar xwiki-platform-cache-infinispan-4.3-20121025.174606-178.jar xwiki-rendering-transformation-icon-4.3-20121024.193826-57.jar xwiki-rendering-transformation-icon-4.3-SNAPSHOT.jar xwiki-rendering-transformation-linkchecker-4.3-20121024.193846-57.jar xwiki-rendering-transformation-macro-4.3-20121024.193051-57.jar xwiki-rendering-transformation-macro-4.3-SNAPSHOT.jar xwiki-rendering-transformation-wikiword-4.3-20121024.193833-57.jar xwiki-rendering-transformation-wikiword-4.3-SNAPSHOT.jar Items statistics: /lib folder on SNAPSHOT : 126.6 MB - 445 Items /lib folder on Milestone 1: 126.3 MB - 392 Items The odd thing is that I do not get any warnings, errors, stacktraces when starting the 4.3-SNAPSHOT. I wrote this mail to report the issue, because IMO this can cause serious issues. Regards, Sorin B.

5 7

[xwiki-devs] [VOTE] Create a XWiki Debug (IntelliJ) Idea project in the XWiki organization page
by Fabio Mancinelli 30 Oct '12

30 Oct '12

Hi guys, I spent some time trying to port the great work Thomas did for Eclipse (https://github.com/xwiki/xwiki-debug-eclipse) to IntelliJ Idea. So I have something working to commit. I've already written the documentation: http://localhost:8080/xwiki/bin/view/Community/XWikiDebugIdea This mail is to ask if I can commit it in the main XWiki repository by creating a xwiki-debug-idea project. Here is my +1 -Fabio

6 17

[xwiki-devs] [Brainstorming] French translation for "Distribution Wizard"
by Silvia Rusu 26 Oct '12

26 Oct '12

Hello, I'd like to get your opinion on what French translation we should use for "Distribution Wizard". So far I've received the following suggestions: * Gestionnaire de distributions * Assistant d'installation * Assistant de distribution Do you prefer one of the above suggestions? Do you have other ideas? Please reply to the present thread with your opinion. Thanks, Silvia

9 11

[xwiki-devs] [Business] Looking for XWiki web developers for XWiki SAS
by Vincent Massol 26 Oct '12

26 Oct '12

Hi fellow XWiki developers, The company I work for, XWiki SAS (see http://bit.ly/SEl2yY for details on the relationship between XWiki SAS and the open source project), is currently in the phase of discussing several new development projects for customers. We are expecting some activity growth pretty quickly in 2013 and beyond and therefore we are looking for front-end developers to work for our Client Development Team in priority (but also in the Core Development Team). We're considering both new hires and sub-contractors, so if you feel there can be a match between your interests and the mission we're proposing send us an email at jobs(a)xwiki.com: * http://www.xwiki.com/xwiki/bin/view/Company/DeveloperOpenPosition * http://www.xwiki.com/xwiki/bin/view/Company/CoreWebDeveloperOpenPosition Looking forward to hearing from you on jobs(a)xwiki.com ! -Vincent Massol XWiki SAS CTO

1 0

[xwiki-devs] [VOTE] Retire old userdirectory plugin
by Vincent Massol 24 Oct '12

24 Oct '12

Hi devs, I'd like to propose to remove the old userdirectory plugin (com.xpn.xwiki.plugin.userdirectory.*) from oldcore and move it to xwiki-contrib/retired I've checked and it's not used anywhere in our code and since it's not been touched for a very long time it's probably not even working. Also it has some concept of group invitation but we've implemented that in the invitation module. Here's my +1 Thanks -Vincent

8 7

[xwiki-devs] [Contrib] I'd like to move xwiki realtime editor to xwiki-contrib
by Caleb James DeLisle 24 Oct '12

24 Oct '12

Hi, Since I've got the realtime editor in a working state and it's hosted as an extension, I'd like to move it to xwiki-contrib so we can take advantage of the jira project and not have issues lost in githubland. WDYT? Thanks, Caleb

4 4