xwiki-devs February 2013

xwiki-devs@xwiki.org

30 participants
79 discussions

[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, 9 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

11 years, 10 months

[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

[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

[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

[xwiki-devs] [Discussion] Set virtual=1 by default and deprecate the virtual mode API

by Eduard Moraru

Hi devs, According to the Roadmap of 5.0 [1][2] we will be deprecating the virtual mode API and moving to a virtual-by-default mode instead. The idea is that the multiwiki environment should be the default and, anyone wanting to use the single-wiki mode (as XE was doing in the past), will simply not create any subwiki. It is just pointless to have 2 products for such a simple fact and it also confuses users that have downloaded and started to use one product and later on realise that they needed the other. Also, when installing the wiki-manager and/or workspace extension(s) (because you might want to create subwikis/workspaces), there will be no need to stop the wiki, enable-virtual mode and restart it; all will be doable in the browser. Therefore, I`m sending this mail to ask your opinion about this topic, in case you might have something to say against it, and also to brainstorm on the required changes and implications on existing code so that the transition is as smooth and invisible as possible. Proposed changes: - Remove "xwiki.virtual" from xwiki.cfg(.vm) -- remove the usage of the "$xwikiCfgVirtual" maven property from xwiki-platform (, xwiki-enteprise and xwiki-manager) - Deprecate boolean com.xpn.xwiki.XWiki.isVirtualMode() (and the api.XWiki version) -- change its code to ((getVirtualWikisDatabaseNames(context).size() == 1) ? true : false) until it is removed by the deprecation process. Possibly needed changes: - Add main wiki default descriptor to xwiki-enterprise-ui (so that getVirtualWikisDatabaseNames includes the main wiki and also to avoid DNS issues (?) caused by how we handle virtual mode) -- or have it generated programmatically at startup if it does not exist (might be safer this way, since people might be using a different UI than xwiki-enterprise-ui) I will start working on this locally and see if I can spot other issues, but please share your thoughts. Thanks, Eduard ---------- [1] http://markmail.org/message/o6adfbscpidnn7zr [2] http://jira.xwiki.org/browse/XWIKI-8822

12 years, 1 month

[xwiki-devs] [Notice] For contrib developers

by Vincent Massol

Hi guys, I've just added explanations on how to publish a contrib extension on extensions.xwiki.org here: http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HPublishingonextension… Hope it helps, -Vincent

12 years, 1 month

[xwiki-devs] [Brainstorming] XWiki Flavors

by Ecaterina Moraru (Valica)

Hi, XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc. Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions. So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custo… Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.). After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies. I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility. So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavo… If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them. Just some ideas. Thanks, Caty [1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv

12 years, 1 month

[xwiki-devs] [VOTE] Name for Entity classes in the new model

by Vincent Massol

Hi devs, As you may have seen, I've been working on the new model in a branch. We need to decide on the naming of the Entity classes (wiki, space, document, object, object definition, etc). We have several possibilities I know of for naming them: 1) Wiki, Space, Document, Object, ObjectDefinition 2) WikiEntity, SpaceEntity, DocumentEntity, ObjectDefinitionEntity 3) Wiki, Space, Document, XObject, XObjectDefinition (or simply ObjectDefinition) 4) XWiki, XSpace, XDocument, XObject, XObjectDefinition 5) Some other name for objects. Some concerns: * Using Object as in 1) is a bit of a pain since there's java.lang.Object which forces to use the FQN name when coding in Java. Which is why I've put proposals 2) and 3) * In proposal 3) there's a bit of an inconsistency with the X in XObject which is not present in the other entity names, hence proposal 4 and 2) * In proposal 1) there can be some other clashes. For example Document can clash with the DOM Document object My personal vote goes to 2), even though it makes the entity names a bit longer. Cast your votes! Thanks -Vincent

12 years, 1 month

[xwiki-devs] [Proposal] XWiki memory requirements increase...

by Vincent Massol

Hi devs, Right now we recommend this on http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation#HPrerequis… : "A minimum of 300MB of heap memory and 96MB of permGen. Recommended values are above 512MB for the heap and 128MB for the permGen (-Xmx512m -XX:MaxPermSize=128m)" I've discovered on http://ci.xwiki.org/job/xwiki-enterprise-test-extension/org.xwiki.enterpris… that we had an OOM and it seems to happen more and in more in our functional tests on CI. Something we've done must have increased our permgen memory. I've done some measurements with yourkit and here's what I found: * After XWiki is started and before any page is called we already use 64MB of permgen * After calling the home page, the permgen used goes to 101MB * After calling a page using the code macro, the permgen goes to 132MB So it seems that your default value of 96MB and recommended value of 128MB are not enough… BTW forcing garbage collection reduces from 132MB to 130MB (not much). We need to either find what is taking all our permgen memory or if it's legit increase our recommendations and the default value we use in start_xwiki.sh/bat Any idea? My hunch tells me the Extension Manager could be the cause. Thanks -Vincent

12 years, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2013