January 2015 - xwiki-devs@xwiki.org

[xwiki-devs] Debugging issue in PDF export functionality.
by Karel Gardas 09 Jan '15

09 Jan '15

Hello, I'm trying to debug those two issues: http://jira.xwiki.org/browse/XPDFECA-11 http://jira.xwiki.org/browse/XPDFECA-12 to easy my debugging work, I've installed jetty-based 6.3 xwiki enterprise distro and I'm editing files directly in it (so far just velocity macros hacking). Now I'm in templates/macros.vm which looks like it is kind of processed into skins/flamingo/macros.vm -- so I'm editing directly this file and restarting xwiki server after every change. I'm testing on a page: <page code> This is a page to test pdf export facility. Let's link all the pages here: [[Page1]] [[Page2]] [[Page3]] [[Page4]] [[Page5]] Now, let's test if we're able to pdf export groovy script output. {{groovy}} println 10; println "[[Page6]]" {{/groovy}} </page code> Now, the problem is that for this testing page I get just links to Page1 to Page5. The link to Page6 is missing. I've modified includeLinks to include this code: #macro(includeLinks $page $withPageBreaks) hacked includeLinks is in effect -- 2 -- flamingo!!!! What is clevel?: $clevel #if($clevel && $clevel!=0) we are working on a page: $page #set($pageDoc = $xwiki.getDocument($page)) All links are:<br> #foreach($child in $pageDoc.getLinks()) #set($childDocName = $child.getLink()) $childDocName<br> #end so I can see all the links. So it looks like to fix that I'll need to kind of pre-render the page somehow and then obtain links from the rendered data -- or kind of that. Is there some functionality for this already presented in XWiki? If so, any hint where it is is highly appreciated here! Thanks a lot, Karel

1 2

[xwiki-devs] Howto use mvn xar:format ?
by Pascal BASTIEN 09 Jan '15

09 Jan '15

Hello, To clean and Pull Request my patch I need to launch "mvn xar:format" command but I didn't managed to use it and didn't found a simple documentation about it (notice, I didn't eat a maven book either) I don't want rebuild Xwiki package but I want only check/clean xml file (from XAR) before to pull request it on github. Here my manipulation on my debian testing:- I installed current maven package (3.0.4 version) - I create the conf file ~/.m2/settings.xml provided here: http://dev.xwiki.org/xwiki/bin/view/Community/Building#HInstallingMaven (I'm behind a http proxy, then I add http://dev.xwiki.org/xwiki/bin/view/Community/Building#HBuildingbehindaproxy parameter in ~/.m2/settings.xm) I download Xwiki source with theses commands:#Only first time cd /home/git-wiki/ git clone https://github.com/XXXX/xwiki-platform.git cd xwiki-platform/ git remote add upstream https://github.com/xwiki/xwiki-platform.git git remote -v # synchro before modify cd /home/git-wiki/xwiki-platform/ git fetch upstream git checkout master git merge upstream/master #branch creation and modif of files git checkout -B XWIKI-MaBranche vi /home/git-wiki/xwiki-platform/xwiki-platform-core/xwiki-platform-tag/xwiki-platform-tag-ui/src/main/resources/XWiki/TagCloud.xm Here my problems, I want to check TagCloud.xm with mvn xar:format:cd /home/git-wiki/xwiki-platform/xwiki-platform-core/xwiki-platform-tag/xwiki-platform-tag-ui mvn -e xar:formatI obtain the insanity that I paste at the end of this mail! To resume, howto check my tiny improvment with mvn xar:format?In the same time, I want to avoid maven download the entire world each time I launch it :-)) Thxs for yor help. Pascal B ***************************** root@buttle:/home/git-wiki/xwiki-platform/xwiki-platform-core/xwiki-platform-tag/xwiki-platform-tag-ui# mvn -e xar:format [INFO] Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building XWiki Platform - Tag - UI 6.4-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 5.962s [INFO] Finished at: Fri Jan 09 10:24:42 CET 2015 [INFO] Final Memory: 19M/228M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal on project xwiki-platform-tag-ui: Could not resolve dependencies for project org.xwiki.platform:xwiki-platform-tag-ui:xar:6.4-SNAPSHOT: Could not find artifact com.sun:tools:jar:1.5.0 at specified path /usr/lib/jvm/java-7-openjdk-amd64/jre/../lib/tools.jar -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project xwiki-platform-tag-ui: Could not resolve dependencies for project org.xwiki.platform:xwiki-platform-tag-ui:xar:6.4-SNAPSHOT: Could not find artifact com.sun:tools:jar:1.5.0 at specified path /usr/lib/jvm/java-7-openjdk-amd64/jre/../lib/tools.jar at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117) at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.project.DependencyResolutionException: Could not resolve dependencies for project org.xwiki.platform:xwiki-platform-tag-ui:xar:6.4-SNAPSHOT: Could not find artifact com.sun:tools:jar:1.5.0 at specified path /usr/lib/jvm/java-7-openjdk-amd64/jre/../lib/tools.jar at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:189) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:185) ... 22 more Caused by: org.sonatype.aether.resolution.DependencyResolutionException: Could not find artifact com.sun:tools:jar:1.5.0 at specified path /usr/lib/jvm/java-7-openjdk-amd64/jre/../lib/tools.jar at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:375) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:183) ... 23 more Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Could not find artifact com.sun:tools:jar:1.5.0 at specified path /usr/lib/jvm/java-7-openjdk-amd64/jre/../lib/tools.jar at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:538) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:216) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:358) ... 24 more Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact com.sun:tools:jar:1.5.0 at specified path /usr/lib/jvm/java-7-openjdk-amd64/jre/../lib/tools.jar at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:256) ... 26 more [ERROR] [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionExcept… *******************If I launch mvn -e xar:format from a directory without pom.xml file: [ERROR] No plugin found for prefix 'xar' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/root/.m2/repository), xwiki-plugins-snapshots (http://nexus.xwiki.org/nexus/content/groups/public-snapshots) xwiki-plugins-releases (http://nexus.xwiki.org/nexus/content/groups/public) central (http://repo.maven.apache.org/maven2) -> [Help 1] org.apache.maven.plugin.prefix.NoPluginFoundForPrefixException: No plugin found for prefix 'xar' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/root/.m2/repository), xwiki-plugins-snapshots (http://nexus.xwiki.org/nexus/content/groups/public-snapshots) xwiki-plugins-releases (http://nexus.xwiki.org/nexus/content/groups/public) central (http://repo.maven.apache.org/maven2)

3 8

[xwiki-devs] [ANN] XWiki 6.4 Milestone 3 released
by Ecaterina Moraru (Valica) 07 Jan '15

07 Jan '15

The XWiki development team is proud to announce the availability of XWiki 6.4 Milestone 3. This milestone integrates the Ratings module inside platform, providing the ability to rate extensions inside the Extension Repository and visualise them inside Extension Manager. We have also added improvements for Flamingo Skin on the responsiveness aspect, reintroduced the Wiki configuration section in Administration and done massive work in augmenting the Mail Sender API to be able to send large number of emails. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki64M3 Thanks -The XWiki dev team

1 0

[xwiki-devs] Documentation about the DB-migration?
by Paul Libbrecht 06 Jan '15

06 Jan '15

Hello fellow XWiki developers, At Curriki, we are considering more and the possibility to migrate to the file-sytem attachment, however, the current solution (which does it at boot time) is not acceptable since it would make our service unavailable for several days (there are 73756 attachments on 591000 documents, when we tried on a dev server, it took a week). Where can I read more about the DB-migration that converts the DB attachments to the file-systems' attachments? Where is the source? What modules are used? thanks in advance. Paul

2 1

[xwiki-devs] Ownership of the metadata about the subwiki
by Anca Luca 05 Jan '15

05 Jan '15

Hello devs, = Short story = Since the metadata about a subwiki (pretty name, description, users scope) are in the middle between main wiki and the subwiki (are used on both), who should have the last word about this data? Global admin of the farm of local admin of the subwiki? = Long story = while looking at http://jira.xwiki.org/browse/XWIKI-11416 , we came across a couple of questions about what is a subwiki and who "owns" (controls) the metadata about it. It all started with the fact that XWIKI-11416 would imply allowing the local admins of the subwiki (potentially local users) to edit information which is stored on the main wiki. There are 2 important things to discuss about this requirement: A. 1/ it is important that the metadata about a subwiki can be controlled by the local admin group, or another _group_ of people. The owner of the wiki is not enough, as owner is not a role and can only be fulfilled by one person, which is limiting in terms of collaboration. 2/ the wiki description and pretty name are stored on the main wiki today, in the wiki descriptor, while information about the user scope and membership are stored on the subwiki. This was changed recently, when the wiki concept was revamped and integrated with workspaces, in 5.3 (before that, everything was on the main wiki). A 2/ takes us to the main question of this mail: who is responsible / should should be responsible for the information about a subwiki? One direct consequence of this answer is the storage of this data, but the implications are larger than that because they can define the usecases that we support for the new wikis (as they are defined by the new implementation from 5.3). This question arises because this metadata is quite tricky as it represents the relation between the main wiki and the subwikis, so it could be considered that both main wiki and subwikis have priority on it. Please express your opinion about the following approaches, both as a general guideline, and in particular in the context of the 5 items from the descriptor that we're discussing: pretty name, wiki description, membership type, user scope, owner. B 1/ the global admin must be able to control the data about the subwikis, regardless of the opinion of the local admins 2/ the local admins should be free to configure the data about the subwikis, without the global admin controlling these settings. Note that this is already the case for wiki rights, by construction of the wiki, and recently this was chosen for user scope and membership type by storing them on to the subwiki in 5.3 3/ both approaches should be possible, depending on the type of farm we make (farm of wikis with subwikis with local users which don't know one about the existence of the other wikis, a la myxwiki.org or farm of wikis where users can create wikis of their own, workspaces style) 4/ both approaches should be possible, depending on the type of wiki, which should be decided by the global admin (on the same farm we could have some wikis on which global admin decides this metadata and some wikis on which local admins decide it) Note that B 3 and 4, in my opinion, have consequences on the type of wikis that we want to make _by default_ (with customization everything will be possible): UC 1 : farm where the wikis are handles as dedicated spaces for collaboration inside the same community, the users all know about the existance of all wikis (workspaces style) UC 2 : farm where the users don't know about the existance of the other wikis, where every subwiki is independent, like an XWiki instance without subwikis, they are just managed by the same farm, for various reasons ( myxwiki.org style, cloud mode, real "farm" mode, the pre-workspaces way of making subwikis). Please comment on these items, from a conceptual point of view. Thanks, Anca P.S. we also discussed a couple of implementation details today, with Denis, Eduard and Guillaume D: * allowing local admins to change data that is stored in a document on the main wiki is problematic because it would mean to code a modification a document which would bypass the rights system, which is not generally a good idea, we should model this by using the regular rights system (the users that must be able to edit the descriptor should be able to have edit rights on it) * normally storing data on the subwiki is problematic because of the performance issues that arise when using this information on the main wiki (it's not possible to fetch it with a hql query). BUT the wiki manager implementation has a cache where this data can be stored so that it's not always looked up on the subwiki when needed on the main wiki. This cache, while quite limited today, can be improved to answer whatever filtering needs.

2 2

[xwiki-devs] Release of Curriki 1.17 (CDN)
by Paul Libbrecht 05 Jan '15

05 Jan '15

The Curriki developers' team is happy to announce that Curriki 1.17 is now released and deployed to www.curriki.org . This release fixes a number of bugs and adds the support for serving the static resources (such as JS, pictures, or CSS files that are part of the webapp) from a cloud distribution network. Curriki has chosen the Amazon Web Service S3 upload and Cloudfront CDN solution. This release required a number of adjustments in the internals (a URL factory) and quite some skin adjustments, often because absolute URLs that refer to CDN resources often get caught by the wiki syntax processor. We are thrilled to bring this release to the users' community of curriki.org for a better responsiveness and to the developers of the XCLAMS-based platforms. XCLAMS, the XWiki Collaborative Learning Assets Management System, is a web-service based on the XWiki platform that enables learning resources to be exchanged, developed, and shared following the Open Educational Resources model. The source of the Curriki.org XCLAMS branch is at: https://github.com/xwiki-contrib/currikiorg/commit/72b6e963ecd9e9794bda5f8d… The commit of the release is: https://github.com/xwiki-contrib/currikiorg/ For more details about bug fixes, see the jira version: http://jira.xwiki.org/secure/ReleaseNote.jspa?projectId=10160&version=15062 More information about XCLAMS in general see http://xclams.xwiki.org . The XWiki developers' team Paul, Bob, Todd, and Felix

1 0