xwiki-devs March 2013

xwiki-devs@xwiki.org

31 participants
79 discussions

[xwiki-devs] [Proposal] Add CLA for contributions + Foundation

by Vincent Massol

Hi devs, I'd like to propose the following: * That we start asking for a CLA for contributions (and also for current committers) * That we keep the process lightweight in order to not make it harder to contribute to the xwiki project. For this I propose to use http://www.clahub.com/ In order to understand why we need a CLA read: * http://www.oss-watch.ac.uk/resources/cla * http://en.wikipedia.org/wiki/Contributor_License_Agreement If we agree we then need to define our CLA. I think a good starting point could be the Node.js one: http://nodejs.org/cla.html Now I don't think the CLA will have any legal value if we cannot define "the XWiki project" as a legal entity. Thus I believe we need to start by joining some foundation or creating one. I'll list some easy possibilities: * SF Conservancy: http://sfconservancy.org/members/current/ * SPI: http://www.spi-inc.org/projects/ * Create our own Not for profit association Harder possibilities (need to change license, rename project, etc): * Join ASF * Join Eclipse (and be forced to use bugzilla as the issue tracker ;)) We also need to check if OW2 could offer that service of being a legal entity for XWiki. Personally I'm tempted more by our own association (it's quite easy to create one if we don't need to accept money and a bit more complex if we want to accept money but still doable). My second choice goes to SFC. WDYT? Thanks -Vincent

11 years, 9 months

[xwiki-devs] [Idea] XWiki Project Development Flavor

by Vincent Massol

Hi devs, I've noticed Apache BloodHound (https://issues.apache.org/bloodhound/) and this reminded of this idea I've had several times in the past: Creating a Project Development Flavor of XE. I mentioned it in some other email already but I wanted to see if this excites you as much as it does for me and maybe we could brainstorm in this thread about what it could be like . Some scattered thoughts: * First, from the point of view of the XWiki project I believe it could be a game changer if we did it right since it has the potential of being adopted by projects around the world and thus making them discover xwiki as a result. And since they're developers they would be able to take advantage of XWiki's development features and contribute back to the project through extensions for example. * Ideally it would be awesome that this project be started independently of the XWiki project I think and just use XWiki as the platform since it's a full fledged project with a different goal than the XWiki project itself. * We need to finish the Flavor idea by allowing the DM to list flavors. * Some ideas of content for this Development Project flavor: ** A home page dashboard about metrics of your project. These metrics would be retried from external sources. Examples: *** Statistics about commits using Git/GitHub *** Latest emails (taken from mailman or other mailing list software, possibly by subscribing the project to a mailing list so that it gets the emails) *** Latest issues (taken from JIRA for example) *** Screenshot example: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2#… ** A Release application to help perform releases ** A forum application, for example the Mail Archive Application done by Jeremie which would need to be improved to add ability to post from it ** A Release notes application ** The Blog application ** Ability to generate a whole PDF for the project's documentation for a given version ** A modern and nice skin (either Lyrebird or the new Skin proposal: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x) ** A layout configured for the flavor ** Future: a simple issue tracker (or integrate one) for those who want an all-in-one solution. However keep the external issue tracker possibility for those already having an issue tracker ** Some predefined templates for creating well known project pages: source repository, build, hall in fame, project documentation home page, etc ** The IRC Bot application ** Bundle the JIRA macro ** Bundle the FAQ application ** A Roadmap application * Of course we should use this flavor on xwiki.org itself. And we could move some of the modules we currently have in platform and that would make more sense there (jira macro, IRC Bot application, FAQ application, etc). WDYT? Add your ideas to this email thread or, better, on http://dev.xwiki.org/xwiki/bin/view/Design/DevelopmentFlavor Thanks -Vincent

11 years, 11 months

[xwiki-devs] Redirect to a space

by Bruno Amaro Almeida

Hi How can i redirect the users after login to a space ? I`m looking at login.vm but i have no clue to do this Thanks

12 years

[xwiki-devs] [Proposal] Roadmap for XWiki 5.0

by Vincent Massol

Hi devs, With XWiki 4.x cycle coming to an end soon, it's time to prepare the roadmap for XWiki 5.0. This is a proposal that comes from some internal meetings done with XWiki committers who are working for XWiki SAS. If you're interesting in participating to this release, don't hesitate to add yourself to the list so that everyone can have some visibility of what's going to be worked on during this timeframe! If you think some work defined below doesn't go in the interest of the project also feel free to raise issues. Features: * Continue SOLR implementation - Edy * EM upgrade of subwikis + flavor concept (add Flavor type in EM/Repository) + leftover from 4.x for EM/DW - Thomas + Marius for DW UI part for flavors * AWM work from 4.x to finish (see http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome) - Marius * scalable import/export - Thomas * Home page improvements (XE) and usability improvements in general - JV * Horizontal Menu management (add, remove pages) - JV * virtual=1 by default - Edy (Edy will need to make a proposal for that since it's an important decision ;)) * l10n speed improvements - Ludovic Important JIRAs sorted by priority (most important first): * AWM Add the ability to publish an application as an extension XWIKI-7377 - Marius * AWM Add the ability to export an application XWIKI-7376 - Marius * Unable to edit a page using the WYGIWYG editor after adding a dashboard macro to it XWIKI-8495 - Need volunteer * Improve AWM for it to deal with error messages made by Client when filling the AWM form in using special chars XWIKI-8763 - Marius * Import of Office file breaks Activity Stream and Recently Modified Panel XRENDERING-261 - Need volunteer * Cannot change document title from "inline" mode XWIKI-7905 - Not sure if we want it, to be checked with Marius * When the workspace owner is changed, the new owner is not added as a member nor in the admin group XWIKI-8397 - Edy * Unable to upload a new attachment using the "All pages" tab in the WYSIWYG editor XWIKI-8465 - Marius * Workspace owner and initial members not set as members (nor in admin group) when the workspace identifier contains an underscore XWIKI-8394 - Edy Investigations: * XEM Homepage / Portal - Caty * Knowledge base Flavor - Caty/Ludovic * New Activity Stream Investigation Part 1 - JV (he's agree to become our AS champion :)) * General Flavours Investigation - Caty + input from tech Regarding dates I'm proposing the following: * 5.0M1: 4 March 2013 * 5.0M2: 25 March 2013 * 5.0RC1: 8 April 2013 * 5.0Final: 15 April 2013 Thanks -Vincent

12 years, 1 month

[xwiki-devs] [Discussion] Why drop the $msg script binding in the future?

by Eduard Moraru

Are we sure we want to drop the $msg binding in the future [1]? Compared to other services, $services.localization would be used heavily inside scripts and we would basically have 2 options: 1. use $services.localization.render('key') (you fall asleep writing this every time) 2. always declare a variable in your script like #set ($keys = $services.localization) and then do $keys.render('key') AFAIK, we have already considered in the past that a similarly used service like $services.model is already becoming a bit annoying having to write the oh-so-very-long "$services.model.createDocumentReference(wiki, space,name)"; do we want to get the same effect with the new localization module? I understand and agree that the new localization module is more powerful and flexible than the XWikiMessageTool, but I feel that those new features are not required in day to day use and unnecessarily crowd/pollute the regularly used API. This transition should IMO be smoother and with less impact than what is currently being proposed. If the new localization module can provide all the features of the XWikiMessageTool, then I propose that we simply reuse the $msg binding as it is and, in the background, transform XWikiMessageTool into a facade (as I see we have already pretty much done to preserve backwards compatibility), but agree that we *keep* $msg as the simplified translations binding, to be used in day to day operations and, for more complex tasks, the dev needs to use $services.localization instead. Basically, I`m proposing to apply the KIS(s) principle. :) WDYT? Thanks, Eduard ---------- [1] http://markmail.org/message/atrshzt3mlscfedc

12 years, 1 month

[xwiki-devs] Mobile XWiki Client and Mobile Skin repositories on xwiki-contrib

by Ludovic Dubost

As discussed a while ago, I'm finally made public the Mobile XWiki Client code I've been working on. I've transfered the repository as well as the mobile skin repository to xwiki-contrib https://github.com/xwiki-contrib/mobile-standardxwikiclient https://github.com/xwiki-contrib/skin-mobile-simple The next step for the mobile client is a rework to be: 1/ More modular to allow for additional module and UI changes to allowed by plugins. 2/ A rework of the network layer to be able to queue requests to XWiki and manager errors and retries as well as login. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

12 years, 2 months

[xwiki-devs] [ANN] Test Reporting Application

by Sorin Burjan

Hello everybody, I have created a Test Reporting Application in order to make the Manual Testing Plan more easily to follow and execute. The rationale behind this is: * Hard to update a monolith page with all the manual tests performed * When someone who is testing is updating the page, no other user can update the page * It allows existing manual cases to be marked as automated (if we have an automated tests for them) * Easier to follow, track over what has been tested and what not Since I'd like to propose this to be used in the XWiki community for our Manual Test cases, I have put a live version on Incubator along with some test cases so I can get your suggestions before putting it in actual production/usage. I'm sure you will have some cool suggestions on how to improve it even further. So give it a try. I have also added a suggestions page linked form the application homepage. Note that the application was designed to be generic, so everybody can use it in their own software project. Contrib repo: https://github.com/xwiki-contrib/application-testreporting Incubator Live version: http://incubator.myxwiki.org/xwiki/bin/view/QA/WebHome Suggestions page: http://incubator.myxwiki.org/xwiki/bin/view/QA/Suggestions Looking forward to get your feedback ! Regards, Sorin B.

12 years, 2 months

[xwiki-devs] Two skins, one DB?

by Paul Libbrecht

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

12 years, 2 months

[xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0

by Denis Gervalle

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

12 years, 2 months

[xwiki-devs] [Idea] Add similar issue feature to our JIRA

by Vincent Massol

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

12 years, 2 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs March 2013