xwiki-devs August 2014

xwiki-devs@xwiki.org

29 participants
65 discussions

[xwiki-devs] XWiki Day: what do you want?

by vincent＠massol.net

Hi, What XWiki Day would you like to have today? See ideas at http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HIdeasofXWikiDays Thanks -Vincent

10 years

[xwiki-devs] [Proposal] Velocity Tools refactoring

by Eduard Moraru

Hi devs, = Introduction = With the recent addition of the CookieTool [1] as a velocity tool and the recent upgrade to velocity-tools 2.0 [2] we`ve been having some issues with the build. More precisely, the usage of CookieTool requires servlet-api to be used as dependency for xwiki-commons-velocity and requires that all modules that use it to specify servlet-api as a dependency as well. This has the negative impact of making xwiki-rendering depend on servlet-api and we don`t want that. We had this dependency before, since the pom of velocity-tools 1.4 was empty and we would only be hit by this problem if we tried to use some class from inside it that needed servlet-api in a non-web environment. For 2.0 the pom [4] is correct so either way (1.4 or 2.0) we can not fully say that xwiki-rendering does not depend on servlet-api. = Current state = Now that we added this cookietool, our current manual handling of velocity tools is to get all the registered tools, create a context, instantiate all the tools and set them into this cotext (key -> instance) and then reuse this context as base for every new Velocity context we create. This way we cache the tools across velocity contexts. This works well for singleton tools (stringtool, escapetool, etc), but not so well for per-request tools (like this cookietool is). = Proposal details = Velocity tools 2.0 has done a lot of rewriting regarding configuration and tool management so now it offers a tool manager that handles your tool instances (cached and instantiated when first needed, not a priori). Also it defines 3 scopes (application, request and session) to support various types of tools, like explained previously. Initially wanting to fix our problem with the servlet-api runtime dependency, I had hoped that this new tool manager instantiates tools only when they are first used, so it will not fail for example when xwiki-rendering uses xwiki-commons-velocity to do its job, but without calling the cookietool, even if it does not have servlet-api set up as dependency. I integrated it in XWiki [5][6] (not on master), but when I got the chance to test it, it turns out that the tool manager does a deep verification of each configured tool to see if it is properly configured and if it can be used (instantiated) so if cookietool is configured and servlet-api is not present, we still end up with a runtime exception. Not wanting to throw away the work I already did, I came up with a (not too nice) hack (line 78 [7] to 133) that basically entirely skips the verification of the configuration and takes it as it is. Of course, at runtime it would fail if it is used without the dependency, but this was intended. Now, in the meantime, Vincent came up with a workaround [8] for the problem the cookietool was causing to the xwiki-rendering build (tests actually) by simply not using the tool in the default tool configuration if (the class needed from) servlet-api was not present in the classpath. = Actual proposal = So we should end up with: 1) The current system where all tools are global (i.e. similar to tools 2.0's "application" scope) and a few tools (e.g. cookietool) might behave unexpectedly, but to fix the xwiki-rendering runtime problem: 1.1) With Vincent's less ugly fix that just does not include cookietool in the list of default tools OR 2) My refactoring that adds the benefits of velocity tools 2.0's tool manager with scopes, tool configuration and instance handling, but to fix the xwiki-rendering runtime problem: 2.1) With my ulgy fix that does not perform configuration validation 2.2) With Vincent's less ugly fix that just does not include cookietool in the list of default tools Some things to consider is whether or not we *want* to: - support *full*/*standard* velocity tool configuration. Maybe we just want to pass the tool's key and class like we do now? - support tool scopes. Maybe we just want to use singleton tools? - go ahead with velocity tools and support additional ones or just focus more on using script services instead? In our case, we can simply not use the standard cookietool and make our own script service for the things we need. However, this proposal is at xwiki-commons level so maybe it's not *only* about what we do with it in XWiki but maybe in other environments as well. I know this is a bit too much for maybe a not-that-important subject, but I`d appreciate your opinion on where we should take this. Thanks, Eduard ---------- [1] http://jira.xwiki.org/browse/XCOMMONS-627 [2] http://jira.xwiki.org/browse/XWIKI-5347 [3] http://repo1.maven.org/maven2/velocity-tools/velocity-tools/1.4/velocity-to… [4] http://repo1.maven.org/maven2/org/apache/velocity/velocity-tools/2.0/veloci… [5] https://github.com/xwiki/xwiki-commons/compare/master...velocity-tools-refa… [6] https://github.com/xwiki/xwiki-platform/compare/master...velocity-tools-ref… [7] https://github.com/xwiki/xwiki-commons/compare/master...velocity-tools-refa… [8] https://github.com/xwiki/xwiki-commons/commit/6f8509e0ac3d5250331a6d2073300…

10 years

[xwiki-devs] Build failure in platform: flamingo as default skin

by vincent＠massol.net

For GuillaumeD, At http://ci.xwiki.org/job/xwiki-platform/5926/ Commit: - XE-1404: Switch to Flamingo Skin by default. (commit: 12cc92071aedc51a906889ba2a3368abdb1336fd) (detail) Caused 8 tests to start failing: - org.xwiki.index.test.ui.AllDocsTest.recycleBinTab - org.xwiki.index.test.ui.AllDocsTest.treeViewTabWithSpecialCharactersInEntityNames - org.xwiki.index.test.ui.AllDocsTest.tableViewTabActions - org.xwiki.ircbot.test.ui.IRCBotTest.testBot - org.xwiki.panels.test.ui.PanelTest.verifyApplicationsPanelEntry - org.xwiki.panels.test.ui.PanelTest.limitPanelViewRight - org.xwiki.watchlist.test.ui.WatchThisPageAndWholeSpaceTest.testWatchThisPageAndWholeSpace - org.xwiki.watchlist.test.ui.WatchlistMacroTest.testWatchAndRemoveEntries Thanks -Vincent

10 years

[xwiki-devs] Should we remove "Bundled with Extension Manager" on eco?

by vincent＠massol.net

Hi devs, Now that we don’t release XEM any more, I propose that we remove “Enterprise Manager” from http://extensions.xwiki.org/xwiki/bin/view/EXOExtensionCode/ExtensionClass WDYT? Thanks -Vincent

10 years

[xwiki-devs] Request a Nexus account

by Jean SIMARD

Hi devs, I need a Nexus account in order to be able to release new applications (new version of Ideas Application is probably coming). Thanks. -- Jean SIMARD <jean.simard(a)xwiki.com>

10 years

[xwiki-devs] [Contrib] Redmine-Macro

by O.J. Sousa Rodrigues

Hi there! As described in (http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome) i should ask here to get an account for the nexus on http://nexus.xwiki.o <http://nexus.xwiki.org/>rg in order to be able to a macro. The extension / macro i want to release can be found here: https://github.com/4F2E4A2E/xwiki-redminemacro After the release i will create the documentation at extension.xwiki.org. XWiki username: vfzevaze Github username: 4F2E4A2E Best regards, OJ, Sousa Rodrigues

10 years

[xwiki-devs] [Discussion] The way we display events in Activity Stream

by Eduard Moraru

Hi devs, As some of you might have already seen, as part of the AS investigation for 6.2, I have made a small analysis on the way we display events. As this document [1] shows, we have 2 issues here: 1) What events do we display in AS (user generated, application generated, messages, etc...) 2) How do we display the events (Page focused, User focused, Timeslot focused) Please let me know on your opinions, as I consider it is a good time to review our initial choices and maybe end up with a clearer and consistent mechanism of handling user-level events in XWiki overall. Thanks, Eduard ---------- [1] http://design.xwiki.org/xwiki/bin/view/Proposal/AcitvityStreamRefactoring62…

10 years

[xwiki-devs] [Proposal] Postpone 6.2-M2

by Guillaume "Louis-Marie" Delhumeau

Hi devs. Since 6.2-M1 will be released today and since most of the developers will be on holidays next week, I propose to postpone the release of 6.2-milestone-2 for 1 week. New dates: - 6.2M2: 25th Aug - 6.2RC1: 1 sep (no change) - 6.2Final: 15 sep (no change) Here is my +1. Thanks, Guillaume

10 years

[xwiki-devs] [XWikiDay] BFD#61

by Eduard Moraru

Hi devs, Today is Bug Fixing Day #61. We're currently at +3 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 We`ll need to update the period shortly after. Here's the BFD#61 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12590 Happy BFD! -Eduard

10 years

[xwiki-devs] Playing with Sonar Rules

by vincent＠massol.net

FYI I’m playing with defining the rules we wish to apply in Sonar. I’ve just enabled all quality rules available in Sonar and I’m going to remove one by one those that don’t make sense for us or don’t work. I’ll then send a proposal to this list. See http://design.xwiki.org/xwiki/bin/view/Proposal/DefineSonarRules Thanks -Vincent

10 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs August 2014