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

[xwiki-devs] [Proposal] Velocity Tools refactoring
by Eduard Moraru 20 Aug '14

20 Aug '14

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…

1 0

[xwiki-devs] Build failure in platform: flamingo as default skin
by vincent＠massol.net 19 Aug '14

19 Aug '14

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

1 0

[xwiki-devs] Should we remove "Bundled with Extension Manager" on eco?
by vincent＠massol.net 19 Aug '14

19 Aug '14

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

5 5

[xwiki-devs] Request a Nexus account
by Jean SIMARD 19 Aug '14

19 Aug '14

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>

2 1

[xwiki-devs] [Contrib] Redmine-Macro
by O.J. Sousa Rodrigues 18 Aug '14

18 Aug '14

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

3 10

[xwiki-devs] [Discussion] The way we display events in Activity Stream
by Eduard Moraru 18 Aug '14

18 Aug '14

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…

2 1

[xwiki-devs] [Proposal] Postpone 6.2-M2
by Guillaume "Louis-Marie" Delhumeau 18 Aug '14

18 Aug '14

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

6 6

[xwiki-devs] [XWikiDay] BFD#61
by Eduard Moraru 18 Aug '14

18 Aug '14

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

2 4

[xwiki-devs] Playing with Sonar Rules
by vincent＠massol.net 17 Aug '14

17 Aug '14

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

1 1

[xwiki-devs] Colibri and (BootStrap) Modal
by Danilo Oliveira 16 Aug '14

16 Aug '14

Hello Devs, I am developing an application with bootstrap and XWiki 6.1, however as you mentioned before, the bootstrap is not in production yet. The jquery+bootstrap is having a very unstable behavior, after some interaction of the user with the application trying to open a modal, the xwiki returns the errors: "Uncaught TypeError: undefined is not a function" or "TypeError: $ is not a function <http://stackoverflow.com/questions/12343714/typeerror-is-not-a-function-whe…>" (firebug points to: the line 98 on the javascript.vm:" return $.noConflict();") So I decided to back to colibri, but I did not fine how to create a popup like modal bootstrap. Is there a way? Thanks. -- Danilo Amaral de Oliveira Engenheiro de Computação celular (32) 9111 - 6867

4 8