January 2013 - xwiki-devs@xwiki.org

Re: [xwiki-devs] [xwiki-notifications] xwiki-enterprise - Build # 9763 - Still Failing!
by Vincent Massol 07 Jan '13

07 Jan '13

This is a false positive. I had an error in my regex. It's fixed now. Thanks -Vincent On Jan 7, 2013, at 6:37 PM, Jenkins <build.noreply(a)xwiki.org> wrote: > Check console output at http://ci.xwiki.org/job/xwiki-enterprise/9763/ to view the results. > > Failed tests: > All tests passed > > Last build logs: > Started by upstream project "xwiki-platform" build number 3118 > Building remotely on agent-2 in workspace /home/hudsonagent/hudson_root/workspace/xwiki-enterprise > Checkout:xwiki-enterprise / /home/hudsonagent/hudson_root/workspace/xwiki-enterprise - hudson.remoting.Channel@8ca882:agent-2 > Using strategy: Default > Last Built Revision: Revision ed8777156f8c896ce9ff21d6dd37bcc18ca6e54e (origin/master) > Fetching changes from 1 remote Git repository > Fetching upstream changes from git://github.com/xwiki/xwiki-enterprise.git > ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway > hudson.plugins.git.GitException: Command "/usr/bin/git fetch -t git://github.com/xwiki/xwiki-enterprise.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: > stdout: > stderr: github.com[0: 207.97.227.239]: errno=Connection timed out > fatal: unable to connect a socket (Connection timed out) > > at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:897) > at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:858) > at hudson.plugins.git.GitAPI.fetch(GitAPI.java:200) > at hudson.plugins.git.GitAPI.fetch(GitAPI.java:1105) > at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:813) > at hudson.plugins.git.GitSCM.access$100(GitSCM.java:72) > at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1018) > at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:986) > at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2236) > at hudson.remoting.UserRequest.perform(UserRequest.java:118) > at hudson.remoting.UserRequest.perform(UserRequest.java:48) > at hudson.remoting.Request$2.run(Request.java:326) > at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > ERROR: Could not fetch from any repository > FATAL: Could not fetch from any repository > hudson.plugins.git.GitException: Could not fetch from any repository > at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1025) > at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:986) > at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2236) > at hudson.remoting.UserRequest.perform(UserRequest.java:118) > at hudson.remoting.UserRequest.perform(UserRequest.java:48) > at hudson.remoting.Request$2.run(Request.java:326) > at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

2 2

[xwiki-devs] [Proposal] XWiki 5.x cycle theme
by Vincent Massol 07 Jan '13

07 Jan '13

Hi everyone, We're getting close to the end of the 4.x cycle (only one more release, 4.5, which should be out at the end of January) and thus we need to start thinking about 5.x (see http://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices ) As a reminder here are our past themes: * 3.x: Theme 1: "Building Apps and Distributing them" (This means for example that the Extension Manager in progress is a key element of XE 3.x. It also means making it easier to create applications in XE.), Theme 2: "Polishing" * 4.x: Theme 1 (top priority): Ease of use, Theme 2: Quality Internally at XWiki SAS we've had a brainstorming meeting with everyone to discuss what could be the main themes for XWiki 5.x The result is the following: Theme: Speed and Simplicity ----------------------------------------- Mission: Improve XWiki's usage for new and regular users by improving Usability and Usage Speed in order to make XWiki simpler and faster both from a pure performance point of view and from are user interface point of view. Technical details: - Individual Feature Improvement from a Usability perspective including speed of access (real time updates, commenting in activity stream) - General Usability Improvements on XE and XEM for simplicity - Technical Rewrite of certain features (activity stream) for performance or architecture reasons - General Performance Improvement of XWiki (page loading, rendering time) - Bug Fixing in general WDYT? Thanks -Vincent

9 10

[xwiki-devs] [VOTE] ASM 3.x vs 4.x choice
by Vincent Massol 07 Jan '13

07 Jan '13

Hi devs, We have a problem ATM since we bundle both ASM 3.1 and 4.0 at the same time in XWiki. See http://jira.xwiki.org/browse/XE-1269 We have to take some decisions: 1) We say that we don't support indexing .class files in attachments at the moment (we open a jira for it so that we don't forget to fix it later on) and we open an issue on the tika parser tracker to migrate to ASM 4.X. We follow that issue and when they add support for it we upgrade to it. 2) I put back pegdown 1.0.2 (we're on 1.2.1) but that means changing code and removing features since they have implemented new features since 1.0.2 (they have released 3 versions since then). I don't like this. 3) We modify Tika parser sources so that it works with ASM 4.0 and we publish in our maven repo. It's like 1) but we do the work. Personally I think that 3) is too much work for the benefits so I would go for 1). WDYT? Any other idea? I'm voting 1 (i.e. ASM 4.0) Thanks -Vincent

4 5

[xwiki-devs] [VOTE] Merge new Markdown branch from Guillaume Laforge
by Vincent Massol 07 Jan '13

07 Jan '13

Hi devs, I've been working with Guillaume Laforge on reimplementing our support of Markdown. The current version we have relies on Pegdown's HTML serializer which we then read with our HTML parser. This causes several issues, amongst which: * http://jira.xwiki.org/browse/XRENDERING-237 * http://jira.xwiki.org/browse/XRENDERING-236 So Guillaume and I have completely rewritten it, this time mapping the AST events generated by Pegdown to XWiki Rendering events. The work can be seen here: https://github.com/glaforge/xwiki-rendering/tree/master/xwiki-rendering-syn… It fully passes our CTS. I'm this proposing to integrate this work in 4.5M1 since it fixes existing bugs. There's a small risk that it's going to cause other bugs elsewhere but I think it's worth it, especially seen that our markdown support is quite new. Here's my +1 Thanks -Vincent

5 4

[xwiki-devs] [ANN] XWiki 4.4 released
by Vincent Massol 07 Jan '13

07 Jan '13

1 1

[xwiki-devs] [VOTE] Start using Mockito instead of JMock
by Vincent Massol 06 Jan '13

06 Jan '13

Hi devs, This week end I've been (at last) experimenting with Mockito (http://docs.mockito.googlecode.com/hg/latest/org/mockito/Mockito.html) and it's been successful so far :) I've converted a first test to use it as a demonstrator of its power (http://jira.xwiki.org/browse/XCOMMONS-316) https://github.com/xwiki/xwiki-commons/commit/7b45b48de1c6915294736dfddda74… I'd like to propose to start using it and start writing our tests with it since: * It's very easy to use. I was able to very simply migrate an existing test to it * It makes our tests much more readable to read and maintain IMO because 1) there's less boilerplate code, 2) it provides default values for mocks and 3) no more of ugly expectations syntax * It's powerful, just see http://docs.mockito.googlecode.com/hg/latest/org/mockito/Mockito.html * It's actively maintained and developed, see http://code.google.com/p/mockito/downloads/list and http://code.google.com/p/mockito/source/list and http://code.google.com/p/mockito/people/list After we've written/converted a few tests (let's say in 1 month or so) we can really decide if we like it and make it our official mocking tool or if we should go back to JMock (but I have little doubts ;)). WDYT? Thanks -Vincent

7 7

[xwiki-devs] [Idea] Conference Talk about XWiki Rendering + Rendering REST framework
by Vincent Massol 06 Jan '13

06 Jan '13

Hi guys, Just got an idea about a talk I could give at a conference: Building a wiki, with XWiki Rendering and AngularJS. The ideas are: * Demonstrate XWiki Rendering through a use case which is to build a simple wiki * Use a recent/modern framework like AngularJS to draw people to the talk ;) * Talk about XWiki * Get people to use xwiki rendering and grow the developer base for xwiki rendering I think we're close to be able to implement this but it's missing one thing: ability to call XWiki Rendering from REST. Thus I think it would be a good idea to move our REST framework into XWiki Commons and then in XWiki Rendering add a REST module to expose rendering operations through REST. WDYT? Thanks -Vincent

4 8

[xwiki-devs] Maven build dependency problems: edu.emory.mathcs.util
by xwiki.mexon＠spamgourmet.com 04 Jan '13

04 Jan '13

Hi. I'm new to XWiki and haven't done much with Java and Maven, so apologies for the dumb question... I'm trying to build from the git repositories. I'm starting with xwiki-commons and just naively typing "mvn" to see what happens. It seems to get quite a long way through the build, but then dies with: [WARNING] The POM for edu.emory.mathcs.util:emory-util-classloader:jar:2.1 is missing, no dependency information available [ERROR] Failed to execute goal on project xwiki-commons-classloader-api: Could not resolve dependencies for project org.xwiki.commons:xwiki-commons-classloader-api:jar:4.5-SNAPSHOT: Failure to find edu.emory.mathcs.util:emory-util-classloader:jar:2.1 in http://repo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced -> [Help 1] Interpreting the various .pom files, it looks like it expects to find all necessary dependencies on maven.xwiki.org. Looking through the hierarchy there, seems like there's org. and com. hierarchies, but nothing under edu. at all. Am I supposed to configure other repositories myself before this build will work? Or is it just an oversight that edu.emory.mathcs.util isn't already included on maven.xwiki.org? Thanks for any help!

3 4

[xwiki-devs] [Roadmap] XWiki 4.5 update
by Vincent Massol 03 Jan '13

03 Jan '13

Hi devs, We've already defined the 4.5 roadmap along with the dates: http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome However, could all devs please ensure that the issues that need to fix are listed on http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome ? Thanks -Vincent

1 0

[xwiki-devs] [Contrib] Repository request: multipagepdfexport-application-spaceexport
by Anca Luca 02 Jan '13

02 Jan '13

Hi all, I am about to contribute an application I made to provide an UI for multipage pdf export ( http://extensions.xwiki.org/xwiki/bin/view/Extension/Multipage+PDF+Export ) to help export pages in a space, displayed in a hierarchy like UI (using the hierarchy macro), and, after long reflection, I decided to put this application in its own repository (another option would have been to put it in the multipagepdfexport repository already existing). The choice is motivated mainly by the need to version it independently. Repository name: multipagepdfexport-application-spaceexport User name: lucaa Thanks a lot, Anca Luca

2 2