xwiki-devs February 2015

xwiki-devs@xwiki.org

21 participants
63 discussions

by Eduard Moraru

Hi devs, Today is BFD#79: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 69 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#79 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13093 Thanks and enjoy your bug fixing day! -Eduard

9 years, 10 months

[xwiki-devs] Search inside page source

by walid yaich

Hi XWIKI Team, Please, is there any way to make a search inside page sources. I need to search for a word inside page sources in the Space "Main". Even by a query on the database. Thanks in advance. Best Regards, Walid YAICH

9 years, 10 months

[xwiki-devs] [ANN] XWiki 6.4.1 released

by Ecaterina Moraru (Valica)

The XWiki development team is proud to announce the availability of XWiki Enterprise 6.4.1. This is a stabilization release that fixes important bugs discovered in the previous 6.4 version, while also providing an integration of the new Tree Widget with the Index Application and the WYSIWYG Editor. 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/ReleaseNotesXWiki641 Thanks -The XWiki dev team

9 years, 10 months

[xwiki-devs] [Brainstorming] New Group API?

by vincent＠massol.net

Hi devs, I need to code some stuff for the new mail sender API (ability to send mails to all users of several groups) and I’ve noticed 5 issues with the current group API (XWikiGroupService): 1) It’s not implemented as components (you need to get the XWiki object and call getGroupService() to get an instance) 2) The APIs uses String to reference groups (instead of an EntityReference/DocumentReference). Note that ideally we should have a Java interface to represent a Group and a Group Reference since we could want to implement Groups differently than as wiki pages in some future (for example, by using JAAS, LDAP, etc) but this is probably for later and for now having an EntityReference/DocumentReference is probably good enough 3) The API to return all users of a group (getAllMembersNamesForGroup) return a Collection<String> and takes as input an offset and a number of users to return. This is a very DB-oriented way to scale an API but it’s not easy to use in Java when you want to get all users of a group (you need to maintain a cursor). What is useful in Java is an API that return an Iterator<DocumentReference>. 4) The getAllMembersNamesForGroup() API doesn’t seem to handle subgroups... 5) I’ve also noticed that we have **lots** of group-related APIs in a RightsManager class (which is javadoc-ed as being internal BTW but used elsewhere…), used by the RightsManagerPluginApi. I don’t see why we have users or group-related APIs in a an API related to permissions/rights (i.e. authentication)… This API suffers from another problem: even though is has a resolveUsers(String userOrGroup, XWikiContext context) method to extract users from a list of users or group references, it doesn’t scale! Indeed it doesn’t accept any offset/count parameters and it returns a Collection<DocumentReference>... Thus, I have 2 options: A) do the conversion between String <-> DocumentReference on my side (in the mail sender api) + handle subgroups in the mail sender api + maintain cursor in the mail sender code B) Start quickly a new component-based Group API which would have just the method I need for now (and would be marked unstable). For B) I‘m thinking about something like: Option 1: ========= GroupManager |_ Iterator<DocumentReference> getAllUsers() (in the future we would also have a getMatchingUsers(…)) By default the impl would retrieve batches of user references from the group (say 100 at a time) However, if you want to get just 1 user for example, this is a bit overkill to get 100 DB results. But is that a real use case? So we also have option 2: Option 2: ========== GroupManager |_ GroupResultSet getAllUsers() Where: GroupResultSet |_ Iterator<DocumentReference> iterator() - default to batch size of 100 |_ Iterator<DocumentReference> iterator(int batchSize) |_ Collection<DocumentReference> get(int nb, int offset) (do we really need this api?) I’d prefer to not use option 2 if possible but there may be use cases I don’t see right now that would require 2 and it has the nice advantage of being able to add new methods to GroupResultSet without impacting backward compatibility. Note that this discussion between option 1 and 2 is interesting more generally speaking since we would need to decide what’s our best practices in all our APIs when we require to return large collections of values. So far a lot of our old APIs use the (int nb, int offset) solution, which is versatile but not easy to use IMO and I don’t find it nice that we mix business parameters with technical ones. Last question would be where to put this new code. I can see 2 choices: i) in a new xwiki-platform-group module ii) in a new xwiki-platform-user/xwiki-platform-user-api module where we would put both APIs for both Users and Groups option ii) seems better IMO. WDYT? Thanks -Vincent

9 years, 10 months

[xwiki-devs] [ANN] XWiki 7.0 Milestone 1 released

by Eduard Moraru

The XWiki development team is proud to announce the availability of XWiki 7.0 Milestone 1. This is the first milestone release of the 7.x cycle. It features a Document Index Tree Finder for the Index Application, integration of the new Tree Widget with the WYSIWYG editor and some usability improvements. Developers have a new Finder Plugin for the Tree Widget and the old Lucene search module was finally retired to Contrib. 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/ReleaseNotesXWiki70M1 Thanks -The XWiki dev team

9 years, 10 months

[xwiki-devs] Open the dev document in xwiki.org wrong

by /xin蜗牛

Hi,‍ Open some dev document in xwiki.org error。 Writing XWiki Rendering Macros‍ 、Skin eXtensions‍ and so on。

9 years, 10 months

[xwiki-devs] [Proposal] XWiki 7.0 and the 7.x cycle

by vincent＠massol.net

Hi devs, This is exciting times as we’re starting a new cycle for XWiki: XWiki 7.x! :) Here are some proposals below that I have discussed with committers from XWiki SAS already. For all other committers (thinking about Denis, Sergiu, Clemens, Andreas or other), feel free to add other stuff you’d like to do in 7.0. Cycle Dates ============ I’d like to propose the following cycle dates: - 7.0: March (Feb-Mar ) - 7.1: May (Apr-May ) - 7.2: July (Jun-Jul) - 7.3: September (Aug-Sep) - 7.4: November (Oct-Nov ) This leaves us one month for adjustment, for the almost impossible possibility that we’d be late in one of these major releases :) XWiki 7.0 Dates =============== - 7.0M1: 9 Feb - 7.0M2: 2 march - 7.0RC1: 16 march - 7.0Final: 30 march Wiki 7.0 Content ================ - Improve upgrade tools - Improve DW - Dev: Marius - Continue performance improvements - Dev: Thomas - Flavor mechanism - Dev: Thomas - Notifications improvements (e.g. Immediate mail notif in watchlist + immediate notif in comment) - Dev: Edy - Full integration of new technologies (less, bootstrap) in XWiki so that they can be fully used for client projects - it can also be only documentation - Dev: Guillaume - Implement the “XWiki Core” strategy as defined in http://markmail.org/message/keo7cs6u3fuf676w - Dev: Vincent Some important JIRAs (several of them should be taken up when defining what to implement from the general list above): - Extension Manager add extension search should suggest only compatible versions - XWIKI-9920 - Sometimes rights changes don't apply without a server restart (confidential, FOR 6.4.x) - XWIKI-11355 - Add a simulation feature to the distribution wizard - XWIKI-11502 - Notify Wiki owners by email when users [request to] join their wiki - XWIKI-11096 - Support LESS in SSX objects - XWIKI-11394 - Presentation Office documents (.ppt files) aren't displayed with LibreOffice 4.3.5.2 - XWIKI-11611 - Know who has installed an extension and when - XWIKI-10027 - Add a reload button for changing the CAPTCHA message at registration - XWIKI-9879 - Do not display a very long title in the wiki's header - XWIKI-11234 - Remove the need for the "Finalize" button at the end of the process of wiki creation from template (FOR 6.4.x?) - XWIKI-11527 - Renaming a page changes the creation date - XWIKI-9425 - Exporting/Replaying the upgrade log - XWIKI-11504 XWIKI-11505 XWIKI-11074 Investigations: - Better WYSIWYG editor - CKEditor investigation (1 Week) - Marius - Better captcha module - Edy Let me know if there are any concerns. Thanks a lot -Vincent

9 years, 10 months

[xwiki-devs] [XWiki Day] BFD#78

by Eduard Moraru

Hi devs, Today is BFD#78: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 66 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#78 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13091 Thanks and enjoy your bug fixing day! -Eduard

9 years, 10 months

[xwiki-devs] [XWiki Day] BFD#76

by Eduard Moraru

Hi devs, Today is BFD#76: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 61 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Some of you have already started, cool! Here's the BFD#76 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13001 Thanks and enjoy your bug fixing day! -Eduard

9 years, 10 months

[xwiki-devs] [Proposal] Fail the build if some unit test output content to stdout or stderr

by vincent＠massol.net

Hi devs, I don’t recall if we had already agreed to this proposal or not so now that I’ve progressed with its implementation I’m sending this mail to ensure we all agree. Rationale: * The build logs should not be polluted with “normal” stack traces, or any message. Anything that the test produces should be contained and asserted in the test itself. * If some logs go through it means they’ve not been captured and not been asserted in the test. * It makes the test writer more aware of what the code being tested outputs and thus what the test writer needs to do about these. Implementation details: * Fail the build if some unit test output content to stdout or stderr. * By default any code that outputs log will send content to stdout (since by default slf4j/logback will use a Console Appender that logs to stdout). * Thus when code output logs, the test need to capture those logs. I’m introduced a new rule (@AllLogRule - see https://gist.github.com/vmassol/d6357901fca25db74783) which captures all logs. * The @AllLogRule rule will fail the test if the captured logs are not asserted (it can be asserted for its content or the test can explicitly say it doesn’t care about it). * There will be a custom RunListener (CaptureConsoleRunListener - see https://gist.github.com/vmassol/f3b7496b5bd3a9693fc2) plugged into the Maven Surefire plugin that fails the build if there’s content sent to stdut/stderr * Our Maven build will perform the check by default and we’ll start by disabling it in the modules that currently fail. * The idea is that slowly over time we remove the disabling in those modules as we fix the tests and that for new modules we apply the new rule (which will be enabled by default) Example of capturing/asserting logs: @Rule public AllLogRule logRule = new AllLogRule(); … assertEquals("Error getting resource [bad resource] because of invalid path format. Reason: [invalid url]", this.logRule.getMessage(0)); Example of ignoring a log: … assertNotNull(this.logRule.getMessage(0)); WDTY? Thanks -Vincent

9 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2015