April 2013 - xwiki-devs@xwiki.org

[xwiki-devs] Two skins, one DB?
by Paul Libbrecht 02 Apr '13

02 Apr '13

Hello fellow developers, has anyone tried running two XWiki instances on the same DB? I think everyone doing clustering does this, with the addition of the observation module for emptying caches when appropriate. Has anyone tried running this same configuration (two servers simultaneously) but with two different URLs and two different skins? (but the same core)? It looks just as doable to me. Or? Thanks for hints. Paul

3 4

[xwiki-devs] [Retrospective] Big slippage on all aspects for 5.0M2 - Chance to learn
by Vincent Massol 02 Apr '13

02 Apr '13

Hi devs, I'd just like to point out that 5.0M2 seems to be a very bad release WRT the roadmap we had defined, although a lot of hard work has been done. It's been a long time since we've diverged that much actually. Let's take this as a chance to learn and do a quick retrospective. Roadmap: http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome Misses from Roadmap: * SOLR implementation missing the scheduler and thus cannot replace the default search. Main reason: Edy is sick currently. * AppWithinMinutes work * Scalable import/export * Home page improvements (XE) and usability improvements in general * Horizontal Menu management (add, remove pages) * XEM Homepage / Portal investigation * New Activity Stream Investigation Hits: * EM upgrade of subwikis. Mostly done but still missing a few things * virtual=1 by default * WYSIWYG Editor improvements * 60% of listed important bugs * General Flavours Investigation And WRT dates we're slipping by 10 to 15 days…. Other miss: the build stability. The whole build has been down for over 10 days and there are still failing modules. There has been a lot of stuff done of course but they were not planned (i.e not on the roadmap). This is our biggest miss and what I want to point out: we've not followed the defined roadmap and instead we've done other stuff like putting the new security module on by default which took us very long. We need to learn from what happened to handle it better next time and we now need to get back on track and go back to following our defined roadmap. IMO the following should have been done better (and that's what we should learn for next time): * Discuss replacing some items from the roadmap by others from the beginning. For ex don't take the task of setting the new security as the default without putting it in the roadmap * Setting the new security module should have been done on a branch and the tests/code fixed there before merging it on master. As a general rule nobody should commit anything on master knowing that it would break the build. Because that impacts everyone and prevents everyone from working on what they have to work on. * Similarly, if a commit is done and we realize afterwards that it breaks a lot of stuff, we should revert and put on a branch (I have the JUnit 4.11 upgrade in mind, which changed test order) * Removing xwiki/1.0 syntax by default with the breakage of several tests should also not have been committed directly without fixing the tests first, either locally or on a branch if we want to share the workload WDYT? Do we agree about handling it this way for next time? Since I wasn't there during most of this timeframe (holiday for 1 week and then conference for another week) I may have missed some other stuff an I may even be wrong about what happened. Please correct me or add what I missed. Thanks -Vincent

1 0

Re: [xwiki-devs] [xwiki-notifications] xwiki-platform Quality Checks - Build # 210 - Failure!
by Sergiu Dumitriu 01 Apr '13

01 Apr '13

On 04/01/2013 03:20 PM, Jenkins wrote: > [WARNING] Insufficient code coverage for INSTRUCTION: 9.47% < 9.48% Happened again... -- Sergiu Dumitriu http://purl.org/net/sergiu

1 0

[xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
by Denis Gervalle 01 Apr '13

01 Apr '13

Hi devs, We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg: xwiki.authentication.rightsclass=org.xwiki.security.authorization.internal.XWikiCachingRightService (Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.authorization.AuthorizationManager. But leave this for a later proposal.) So this vote is about changing the default in xwiki.cfg before 5.0M2. pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones - possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki. - may exhibit some other minor differences compare to existing implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1 WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

9 28

[xwiki-devs] [Idea] Add similar issue feature to our JIRA
by Vincent Massol 01 Apr '13

01 Apr '13

Hi guys, I'd like to add the "similar issues" features of http://www.plugenta.com/suggestimate/jira/tour.html You can see it in action at https://jira.exoplatform.org/browse/CRASH-114 for example. I've asked plugenta for a free open source license. Hope this is fine with you all. Let me know if you have any issue with this. Thanks -Vincent

2 2

[xwiki-devs] [VOTE] Retire the old WYSIWYG editor
by Sergiu Dumitriu 01 Apr '13

01 Apr '13

Hi devs, Related to the other vote about disabling the xwiki/1.0 syntax [1], I'd like to retire the old WYSIWYG editor. Although there aren't any obvious benefits, on the contrary it, removes an important feature, the advantages for doing this are: - fewer bugs (there are known bugs that we've decided not to fix since we agreed not to maintain it anymore) - less code (the .vm templates that support the editor are really crappy and I'd be very happy to get rid of them completely) - strongly encourages (developer) users to migrate to the new syntax - less non-valid, non-accessible code (standards compliance) - fewer places where XSS holes can hide (security) Personally I'd like to remove it completely, but there's also the option of putting it in a -legacy- module, still enabled in the final releases. This makes two options: A) Move the editor in a xwiki-contrib retired module B) Move the editor in xwiki-platform-legacy-web and leave it enabled My +1 goes for A. [1] http://xwiki.markmail.org/thread/6damxrncgohtk4oc -- Sergiu Dumitriu http://purl.org/net/sergiu/

5 4

[xwiki-devs] [VOTE] Disable (hide) the xwiki/1.0 syntax
by Sergiu Dumitriu 01 Apr '13

01 Apr '13

Hi devs, It's been a (long) while since the introduction of the xwiki/2.0 syntax and the new rendering engine (introduced in 1.5, declared "usable" in 1.8, set as default in 1.9). This means that since ~2008, most of the development and maintenance effort has gone into the new rendering engine and the new WYSIWYG, and this left the xwiki/1.0 syntax and old WYSIWYG editor mostly unmaintained. All the platform and XE documents have been migrated away, but there are still XEM documents using the old syntax. I'm proposing to hide the xwiki/1.0 syntax by default, so that it's no longer easy to create a new document in that syntax (unless a template is used) or to select it as the new syntax for an existing document. It will continue to be available for existing documents. +1 from me. (I guess the 72h rule won't be applied since the next 72 hours are holidays for lots of developers) -- Sergiu Dumitriu http://purl.org/net/sergiu/

7 6