xwiki-devs January 2016

xwiki-devs@xwiki.org

18 participants
42 discussions

by vincent＠massol.net

Hi committers (and devs in general), I’m submitting to you this idea, to try to improve the xwiki open source project and to give it a new dynamism. I believe the topics discussed below are made even more important since we’re soon going to develop the notion of flavors in XWiki. Note that this proposal obsoletes the http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move of some extensions in the xwiki github organization), which itself was obsoleting http://markmail.org/message/ppw2slpgqou2ihai Issues to solve =============== * The scope of the code maintained by the XWiki Dev Team (== the xwiki github organization) is increasing but the team stays relatively small * The more stuff we move into the repos of the xwiki github organization, the less easy it is for non-“XWiki Dev Team” committers to participate and we want more contributions Proposed solution ================= Executive summary: * Reduce the scope of all the code located in the xwiki github organization by only keeping “core” modules * A “core" module is defined by being a generic transversal module (i.e. that can be used in lots of XWiki flavors, if not all). This is opposed to “vertical” modules which are modules specific of a usage of XWiki. ** Examples of “core" modules: logging module, configuration module, distribution wizard, statistics application, annotations, active installs, one base flavor (the “XWiki” flavor), etc ** Example of “vertical” modules: meeting manager application, blog application, FAQ application, flavors (except the base flavor), etc Some consequences: * We need a new location for several modules that would go out of the xwiki github organization repos * It would be good to separate sandbox extensions from 1st class extensions that are maintained and developed following best practices. We need some way to maintain the quality of important extensions Detailed Implementation: * The “xwiki” github organization’s description becomes “XWiki Core” (it’s too complex to rename the org to “xwiki-core” IMO) * “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in there are called “XWiki Core Committers”). * “xwiki-contrib” is split into 2 github organizations (technically we rename it to “xwiki-contrib-sandbox”): ** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed extensions or abandoned extensions are located ** “xwiki-contrib-extensions”, where maintained extensions are located. * These 2 organizations are commonly referred to as “XWiki Contrib" * Same as now, anyone requesting a repo in xwiki-contrib-sandbox would be granted one and he/she’d be given write access to all repos in the xwiki-contrib-sandbox organization. * We define some rules for graduating from xwiki-contrib-sandbox to xwiki-contrib-extensions. For example: ** The extension should have been in xwiki-contrib-sandbox at least 6 months (this gives time to see if the extension is maintained during that time and will survive the test of time - most extensions will die in the first months) ** The extension should have had more than 2 releases and be published on extensions.xwiki.org(http://extensions.xwiki.org) with documentation ** The extension should work with the latest LTS version of XWiki + the latest stable version of XWiki (right now that would be 5.4.5 + 6.3). Note that if the extension has to use new API it’s ok that it doesn’t work on the latest LTS. ** Generally follow the practices defined at http://dev.xwiki.org * Each extension in xwiki-extensions has a leader/maintainer. He/she’s the one proposing to move the extension from xwiki-sandbox to xwiki-extensions. He/she’s responsible for ensuring that the extension gets regular releases and is maintained in general. He/she defines initially the list of committers in his email proposal for moving the extension. * We create a PMC (Project Management Committee) for XWiki Contrib, generally in charge of both xwiki-contrib-sandbox and xwiki-contrib-extensions (voting new extensions in xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I would send a mail on devs@ asking who’s interested to be part of this committee. I expect some core committers + some contrib committers to stand up. * Contrib extensions keep using the org.xwiki.contrib package name and groupid as currently defined at http://contrib.xwiki.org Note: The idea is that xwiki core is developed as a team maintaining all code in there, xwiki contrib is developed extension by extension (each extension is an island). This allows anyone to propose extensions in XWiki Contrib without the need for everyone to support them. WDYT? Thanks -Vincent

8 years, 7 months

[xwiki-devs] [Brainstorming] Migration tool for Nested Pages

by Guillaume "Louis-Marie" Delhumeau

Hello everyone. I am working on a tool to help the user migrating from an XWiki instance without the Nested Pages feature to a new version (7.4.x) handling it. This tool would be an extension that the administrator can install and execute *after* the XWiki upgrade have been done. After its execution, users should be able to create children to every existing pages (that was previously terminal, obviously). But the old hierarchy based on the parent/child relationship, and all the preferences and rights, should be preserved. The URL should not be broken neither. I have started a design document with the use-cases I had in mind. I've also suggested some implementations and drew some mock-ups. The results is here: http://design.xwiki.org/xwiki/bin/view/Proposal/UpgradeToNestedPages I've started this document before talking here in order to not come with nothing, but feel free to add other use-cases, ideas, and edge-cases that I haven't listed. We should also identify any blocking point from XWiki Enterprise that we could fix in a 7.4.x version. Do you have any question in mind that we should discuss here? Do you have an opinion on this? You help is warmly welcome, Thanks, -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years, 7 months

Re: [xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling

by vincent＠massol.net

Hi Thomas and all, On 15 Jan 2016 at 17:53:04, Thomas Mortagne (thomas.mortagne@xwiki.com(mailto:thomas.mortagne@xwiki.com)) wrote: > What about making possible to enable/disable as a {{velocity}} macro > parameter (disabled by default) ? It’s a very good idea but it raises questions for migrating existing code to this strategy. I think we could do better with the proposal below. Wanted behavior: Mandatory: * Throw Exceptions from script APIs. * Easily handle raised exceptions from Velocity. * Early exception-raising if exception is not handled, i.e. if we have 2 statements in Velocity and the first one raises an exception we don’t want the second one to execute, unless the velocity code tests for it. Nice to have: * Ability to modify existing script APIs so that they all throw exceptions without having to touch client scripts using those script APIs Let’s see some examples. * UC1: Server code is currently catching exception and calling code is in a velocity macro (or in a template) ** Example of what we have now: Server: public Object something() { try { … } catch (…) { return null; } } Calling code: {{velocity}} #set ($result = $var.something()) #if ($result) ... {{/velocity}} ** Example of what we want to move to: Server: public Object something() throws Exception { … } Calling code: The same code as now ** How it could work: The Exception Catching uberspector catches the exception raised by something(), stores it into a velocity binding and returns null. Thus the calling code doesn’t need to be modified, we’re good. * UC2: Server code is currently throwing exception and calling code is in a velocity macro (or in a template) ** Example of what we have now: Server: public Object something() throws Exception { ... } Calling code: {{velocity}} #set ($result = $var.something()) ... {{/velocity}} ** Example of what we want to move to: Server: The same code as now Calling code: The same code as now ** How it could work: Currently if the calling code is in a velocity macro then the velocity macro will throw the Exception and the MacroTransformation will catch it and display an error box. If the calling code is in a template then it’s captured with the #try directive and displayed. With the Exception Catching uberspector, it’s caught and doesn’t bubble up. One solution for this use case is to wrap the captured Exception into an ExceptionResult object such as: ExceptionResult { Exception getException(); boolean hasException(); boolean isHandled(); } And when getException() is called then isHandled() returns true. Then modify: * VelocityMacro so that if an ExceptionResult object exists in the Velocity Context and isHandled() is false then raise the exception. And thus MacroTransformation will also get it and will display an error box as before. * Similarly, modify the Template Manager code to also throw an exception if an unhandled exception is found This let the script writer to decide if he wants to handle the exception or let it bubble up. * UC3: Several consecutive lines with an exception in calling code ** Example of what we have now: Server code: Any code Calling code: {{velocity}} #set ($result = $var.something1()) <— throws an Exception #set ($result = $var.something2()) ... {{/velocity}} ** Example of what we want to move to: Server: The same code as now Calling code: The same code as now ** How it could work: Right now the velocity macro or template will display the first Exception that happens in an error box and the second line (something2()) will not get called. We need to do the same. The idea is simply to check in the Exception-catching uberspector is an unhandled exception exists and if so, then raise it. * Conclusion: I think this strategy would not require to configuration at the level of the velocity macro and that it could work for all cases. Do you see a case where it would not work? WDYT of it? Thanks -Vincent FTR (and as a backup for me ;)) before I start modifying the code here are what I had so far for TryCatchDirective and ExceptionCatchingUberspector: * https://gist.github.com/vmassol/ec3c407f264091eeb4b3 and https://gist.github.com/vmassol/83db5df84a4041ec018f * https://gist.github.com/vmassol/c887cb92f76afa5fba4d > On Fri, Jan 15, 2016 at 5:41 PM, vincent(a)massol.net wrote: > > I need to think more about this because it means velocity macros won’t show an error box anymore in case of error…. > > > > Thanks > > -Vincent > > > > > > On 15 Jan 2016 at 17:20:21, vincent(a)massol.net (vincent@massol.net(mailto:vincent@massol.net)) wrote: > > > >> Ok I’ve finished the implementation and will be committing soon. > >> > >> > >> Note that this could change slightly what the user sees. > >> > >> For example in the past if you had this velocity script: > >> > >> {{velocity}} > >> $someclass.someMethodThrowingException() > >> … rest of the script here... > >> {{/velocity}} > >> > >> > >> The user would see a stack trace on his screen before upgrading to 8.0 and after upgrading to 8.0 he’ll see something different which depends on what the “… rest of the script here…” does. > >> > >> What I don’t like too much is that this could lead to unwanted side effects. For example, imagine that we have the following: > >> > >> > >> {{velocity}} > >> #set ($docReference = $someclass.someMethodComputingTheReferenceButThrowingException()) > >> … > >> $xwiki.getDocument($docReference).save() > >> ... > >> {{/velocity}} > >> > >> Then if an exception is raised in someMethodComputingTheReferenceButThrowingException() it used to display an exception but will now do something else. It happens that in this case it’ll report a NPE (AFAICS in the code) but we could imagine it would create a wrong document in the wiki, etc. > >> > >> Any thoughts about this? Should I still go ahead (I think so). > >> > >> Thanks > >> -Vincent > >> > >> > >> On 15 Jan 2016 at 13:37:39, vincent(a)massol.net (vincent@massol.net(mailto:vincent@massol.net)) wrote: > >> > >> > > >> > > >> > > >> > > >> > > >> > On 15 Jan 2016 at 13:26:08, vincent(a)massol.net (vincent@massol.net(mailto:vincent@massol.net)) wrote: > >> > > >> > > > >> > > On 15 Jan 2016 at 13:23:07, vincent(a)massol.net (vincent@massol.net(mailto:vincent@massol.net)) wrote: > >> > > > >> > > > Forget what I’ve said regarding the #try directive. > >> > > > > >> > > > Actually the way to use it is: > >> > > > > >> > > > #try() > >> > > > … wrap some script snipper, one or several calls… > >> > > > #end > >> > > > .. here only you can access the $exception binding. > >> > > > > >> > > > Thus: > >> > > > > >> > > > * Wrapping the whole content to evaluate won’t work > >> > > > * The Exception Catching Uberspector is really what we need. It’s more fine-grained than the #try directive (or it’s equivalent if you use #try() for each line of script calling methods). > >> > > > > >> > > > In addition: > >> > > > > >> > > > * We provide script APIs in xwiki-commons too so if we want this best practice of throwing exceptions in script APIs, we also need to make this work in xwiki-commons when used outside of XWiki. Thus we need a solution there too. > >> > > > ** A) One solution would be to use XWiki’s Context and make the last exception available with $xcontext.lastVelocityException but it’s not very natural, I hope we can find a better solution > >> > > > ** B) Another solution is to move VelocityManager to commons in xwiki-commons-velocity, offer a basic impl without skin support and override it in xwiki-platform to add the platform-specific stuff. > >> > > > > >> > > > I’ll start exploring B). Let me know if you don’t agree or if you have a better idea. > >> > > > >> > > Actually VelocityManager is already in commons, it’s the impl that is in platform. So right now it will work for us; it just won’t work for users who use just commons. Like if you use the Rendering in standalone mode. > >> > > >> > Actually forget that, I don’t need to use VelocityManager in practice (and it would be costly to do so). I just need to use the Execution component: > >> > > >> > VelocityContext vcontext = > >> > (VelocityContext) this.execution.getContext().getProperty( > >> > VelocityExecutionContextInitializer.VELOCITY_CONTEXT_ID); > >> > > >> > > >> > Thanks > >> > -Vincent > >> > > >> > Ps: Sorry for the live design noise... > >> > > >> > > > >> > > Thanks > >> > > -Vincent > >> > > > >> > > > Thanks > >> > > > -Vincent > >> > > > > >> > > > > >> > > > On 15 Jan 2016 at 12:15:41, vincent(a)massol.net (vincent@massol.net(mailto:vincent@massol.net)) wrote: > >> > > > > >> > > > > > >> > > > > [snip] > >> > > > > > >> > > > > > > > > > >> > Hi devs, > >> > > > > > > > > > >> > > >> > > > > > > > > > >> > Right now our strategy is for script services and script APIs in general > >> > > > > > > > > > >> > to catch exceptions, store them and offer a getLastError() method to get > >> > > > > > > > > > >> > them (see > >> > > > > > > > > > >> > http://extensions.xwiki.org/xwiki/bin/view/Extension/Script+Module#HBestPra… > >> > > > > > > > > > >> > ) > >> > > > > > > > > > >> > > >> > > > > > > > > > >> > However it would be much nicer to: > >> > > > > > > > > > >> > * Let our script services generate exceptions > >> > > > > > > > > > >> > * Offer a velocity script service to get the last exception raised by a > >> > > > > > > > > > >> > java call from velocity > >> > > > > > > > > > >> > * Implement this uberspector to catch the exceptions and to set them in > >> > > > > > > > > > >> > the execution context > >> > > > > > > > > > >> > > >> > > > > > > > > > >> > That should be quite easy to implement IMO. > >> > > > > > > > > > >> > > >> > > > > > > > > > >> > WDYT? > >> > > > > > > > > > >> > > >> > > > > > > > > > >> > >> > > > > > > > > > >> +1, it's a pain to call setLastError() everywhere there can be an exception > >> > > > > > > > > > >> thrown, and we almost always forget to do it (for this reason). > >> > > > > > > > > > >> > >> > > > > > > > > > >> Note that we also have the #try() directive now. > >> > > > > > > > > > > > >> > > > > > > > > > > Yes, I should have mentioned that there’s indeed also this possibility: > >> > > > > > > > > > > * Have script API throw Exceptions > >> > > > > > > > > > > * Force velocity script users to wrap their code with the try directive when they need to catch exceptions > >> > > > > > > > > > > > >> > > > > > > > > > > I still believe that the use of the Exception-catching uberspector is better. > >> > > > > > > > > > > > >> > > > > > > > > > > WDYT? > >> > > > > > > > > > > >> > > > > > > > > > Does it mean you plan to get rid of new #try directive ? Because it > >> > > > > > > > > > will be broken with this new uberspector. > >> > > > > > > > > > >> > > > > > > > > That’s a good point, I had not thought about the implementation at this stage. > >> > > > > > > > > > >> > > > > > > > > I think this could still work. When the #try directive is used I’d just have to setup some flag somewhere in Velocity and in the uberspector I could check if this flag is set and if so then don’t catch the exception. > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > Actually, thinking more, I think you’re right and that the #try directive plays exactly the same role as an Exception-catching uberspector and I don’t see the need for the #try directive if we provide an uberspector. > >> > > > > > > > > >> > > > > > > > So I’m proposing to deprecate it but still keep it for backward compatibility for now (probably a full cycle). > >> > > > > > > > > >> > > > > > > > WDYT? > >> > > > > > > > >> > > > > > > Note that I’d like to change a bit the proposal and instead of making the exception available from a script service, I’d prefer to make it available as a known velocity binding such as $lastException. There’s no reason to use a script service since that would mean it would work for all scripts and in this case we only want it to work for Velocity. > >> > > > > > > > >> > > > > > > Since there’s no way to get the Velocity Context from within an uberspector, I’ll get it by using our Component Manager and get the VelocityManager component and call getVelocityContext()… If you know a better way, let me know. > >> > > > > > > >> > > > > > hmm… this would mean that I’d need to put this new uberspector in xwiki-platform since VelocityManager is in platform ATM… (@Thomas: our discussion of yesterday ;)). > >> > > > > > >> > > > > > >> > > > > There’s an alternative, which is to modify our implementation of VelocityEngine.evaluate() and decorate the source with a #try() directive so that it’s always called (and make sure that calling it nested won’t affect it for backward compat). > >> > > > > > >> > > > > This could be simpler to implement and doesn’t force us to move some velocity code to platform. > >> > > > > > >> > > > > WDYT? > >> > > > > > >> > > > > Thanks > >> > > > > -Vincent > >> > > > > > >> > > > > [snip]

8 years, 7 months

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

by Eduard Moraru

Hi devs, Today is BFD#91: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays This is the first BFD of the year. The last BFD was about 3 months ago and, since then, some bugs started piling up. Our current status for the 1 year period is 91 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#91 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13594 Thanks and enjoy your bug fixing day! -Eduard

8 years, 7 months

[xwiki-devs] [Proposal] Add a new JIRA project for ideas

by vincent＠massol.net

Hi devs, Since we’ve decided that the xwiki github organization will contain only core extensions and that we want to move non-core extensions outside (most likely to the contrib github organization), and since in contrib each project has its own jira project, I think we need a jira project for people to propose ideas. Of course we could also have installed the Idea app (http://extensions.xwiki.org/xwiki/bin/view/Extension/Ideas) on xwiki.org but since we manager our issues with JIRA we’d have to copy them to jira anyway. So my proposal is to create a top level JIRA project called “Ideas” and to document it on http://dev.xwiki.org/xwiki/bin/view/Community/Contributing. This will also allow us to move issues such as http://jira.xwiki.org/browse/XWIKI-1103 (Bookmarks feature), which are currently in the XWIKI JIRA project to the Ideas project and can be used as a place where contributors or GSOC students can get ideas from. Of course if someone suggest an idea that is something core, we’d move it to the XWIKI Jira project ourselves. WDYT? Thanks -Vincent

8 years, 7 months

[xwiki-devs] [Contrib] Repository request for a structured data api

by Yann Flory

Hello devs, I'd like a repository on xwiki-contrib for a new "Structured data API" extension. The purpose of this extension is to provide developers a way to access data of an application in XWiki. The objective is to provide a unified way of using the API from both server-side and client-side (Velocity, Groovy, JavaScript, REST). Details about the application can be found here: http://design.xwiki.org/xwiki/bin/view/Proposal/ExtensibleAPIforaccessingst… Name of the repo : api-structured-data I'd also like a jira project for this extension. Thanks, Yann

8 years, 7 months

[xwiki-devs] [Brainstorming] Edit menu and content editors

by Marius Dumitru Florea

Hi devs, I'm working on integrating CKEditor in XWiki and I'm wondering how the Edit menu should reflect the fact that there are multiple editors available. I see two options: (A) List all the available content editors in the Edit menu (note that the menu is visible only for advanced users). E.g. Wiki, GWT WYSIWYG, CKEditor PROS: * easier to implement (because there is already an UIX for this) * easier to discover new content editors (e.g. after an admin installs an extension that provides a content editor) * ability to try a different content editor than the one configured (i.e. without updating the configuration) CONS: * the (advanced) user might not know, at first, which content editor to choose from the Edit menu * once the user has a preferred editor the other content editor entries become noise (the user may want to hide them) (B) List only the edit modes in the Edit menu. E.g. Wiki, WYSIWYG PROS: * easier to choose the edit mode (wiki/source vs. WYSIWYG) * less crowded Edit menu (easier to scan, no noise) CONS: * the user needs to edit his profile to discover the available editors for Wiki/WYSIWYG modes * harder to try the new content editors (you need to update the configuration) Let's see what we need for each option: (A) Needs: * UIX in the Edit menu (already available) * 1 configuration option ("editing.content.defaultEditor") to configure the default editor (at farm/wiki/space/user level). We can probably extend the "Default editor to use" preference from the user profile to show all the available content editors. (B) Needs: * 3 configuration options: ** default edit mode (Wiki vs. WYSIWYG), already available in the user profile ** default Wiki mode editor (only one editor for now so we can skip it) ** default WYSIWYG mode editor (GWT-based vs. CKEditor) I'm leaning towards option (A). WDYT? Thanks, Marius

8 years, 8 months

[xwiki-devs] [VOTE] Retire Colibri skin

by Thomas Mortagne

Hi devs, Following http://markmail.org/message/fb2tsh2gwu44xsua (Drop support for Colibri Skin in 7.x) I would like to propose to move colibri to https://github.com/xwiki-contrib/ in 8.0 branch. Here is my +1, -- Thomas Mortagne

8 years, 8 months

[xwiki-devs] [Proposal] Bundle a Dashboard Gadget with Apps as a best practice

by vincent＠massol.net

Hi devs, On http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… we list some app dev best practices. I’m proposing to add one more bullet point which is that apps bundle one or several (but at least one) Dashboard Gadget (technically a Macro) so that users can easily add a view of the app on the home page (in their dashboard). For example: * FAQ app already provides a {{faq}} gadget to list all entries for a given FAQ app * Index app already provides a {{document}} gadget to list all documents matching some criteria * Blog app doesn’t currently provide such a gadget (it provides a velocity macro but that’s not a gadget) * Forum app should provide a {{forums}} gadget too to list all forums and a {{forum}} one to list entries from a given forum * etc WDYT? Thanks -Vincent

8 years, 8 months

[xwiki-devs] Multi instances of tomcat installed but web uses one database.

by Noman Nisar

i have created multiple instances of tomcat and made changes to hibernate.cf.xml file for my application in tomcat instance 1 and also for tomcat instance 2 but they uses only one database. like in my case i have set different ports but still they use same database. in tomcat1 webapps http://localhost:8081/wiki/bin/view/Main/ in tomcat2 webapps http://localhost:8082/simple/ plz help me what to do.i have set different db like wikidb for wiki application and simpledb for simple.

8 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs January 2016