xwiki-devs April 2013

xwiki-devs@xwiki.org

33 participants
77 discussions

[xwiki-devs] [ANN] XWiki 5.0 Release Candidate 1 released

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 5.0 Release Candidate 1. This is mostly a stabilization release leading to 5.0 but we included a few bonus items: Distribution Wizard improvements to support multiwiki use cases and the ability to see which extensions have updates. 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/ReleaseNotesXWiki50RC1 Thanks -The XWiki dev team

11 years, 5 months

[xwiki-devs] Using the Young API @Unstable annotation

by Vincent Massol

Hi guys, We now have an @Unstable annotation and we need to use it. I see for example that the Job or Extension module APIs are regularly broken and they're not tagged as Young APIs. IMO they should. Here are some recent examples in 5.0RC1: https://gist.github.com/vmassol/5428600 If we don't use and we continue to break APIs all the time there's no point in having created this new concept of young apis. Some modules have already had several releases done and were done before we created the @Unstable annotation. We should review them and decide if we consider them young apis or not. If so then we should mark it in the release notes and add @Unstable annotations to them. WDYT? Thanks -Vincent

11 years, 5 months

[xwiki-devs] [GSoC] Interested in participation

by Rafaela Voiculescu

Hi, * My name is Rafaela. I am currently pursuing a MSc program in Computer Science at the Technical University of Denmark, after finishing my Computer Engineering BSc program at Politehnica University in Bucharest. I am planning to apply to this year's GSoC edition and, after scanning through most of the proposed projects, I have to say that the ones proposed by XWiki have definitely got my attention. The ones that I'm quite interested in are the ones about advanced e-mail integration, improving the messaging feature and translation in context. I've already cloned the xwiki-platform repository and I am starting to look over the codebase. Is there anything more I can do to get a better overview of the mentioned projects so that I can decide on which I'd like most to work on? Have a nice day, Rafaela Voiculescu *

11 years, 6 months

[xwiki-devs] Closing Lucene issues when they are fixed in the SOLR implementation

by Vincent Massol

Hi devs, Since our goal is to have the SOLR implementation be the default search and since our goal is to move the lucene impl to xwiki contrib as a retired project, I propose that whenever a JIRA issue affecting the Lucene search is closed in the current SOLR implementation, we close it as duplicate. I've just done that for http://jira.xwiki.org/browse/XWIKI-6228 Hope it's fine with you. Thanks -Vincent

11 years, 6 months

[xwiki-devs] Add Daniel Patriche as a member to XWiki-Contrib on GitHub

by Daniel Patriche

Hello everyone! Could someone with access to the XWiki-Contrib repo on GitHub ( https://github.com/xwiki-contrib) add me as a member? I'm planning on further developing the Xinit project and perhaps some of the other projects in the near future. My username is "rebelthor" (https://github.com/rebelthor ). Thanks! -- Best Regards, Daniel Patriche XWiki SAS SysAdmin

11 years, 6 months

[xwiki-devs] [Proposal][UX] Portal entry in menu and breadcrumbs

by Ecaterina Moraru (Valica)

Hi devs, A single wiki model is mostly used to demo XWiki and to test its features. In production usually we have a multiwiki model, because of its flexibility. Since 5.0M2 we also have virtual mode enabled by default, meaning that is even easier to create and manage subwikis/workspaces. No matter if you want independent wikis or workspaces, both cases share a Main Wiki. I propose to call the Main Wiki a 'Portal'. The Portal purpose is to: - both: manage the wikis/workspaces, being the point where you create new wikis/workspaces; - both: help the navigation between wikis/workspaces, by being the 'home' point for them; - workspace: manage the global users, providing access to a User Directory; - workspace: will provide a global view of users' activities in workspaces; - wikis: will provide a webhome (similar to what we have on myxwiki.org) that states the purpose of the farm. Workspace already has a custom menu in which there is present the 'Main' wiki http://incubator.myxwiki.org/xwiki/bin/download/Improvements/PortalMenu/cur… I've made a proposal for the content of the menus in http://incubator.myxwiki.org/xwiki/bin/view/Improvements/PortalMenu that we shall discuss. 'Portal' entry is present in the menu and also in the Breadcrumbs. The 'home' icon should be always present in the breadcrumbs, followed by the Wiki/Workspace WebHome and then should be user defined (according to a custom parent/child relation). By having it clearly stated in the menu and in the breadcrumb, it will improve the navigation between workspaces (and will give a home point for the wikis). In single wikis, the Portal entry is skipped. Thanks, Caty

11 years, 6 months

[xwiki-devs] Experiment with AngularJS and XWiki

by Ludovic Dubost

Hi, I've been experimenting with AngularJS and XWiki and I find the two technologies are a pretty good fit. You can see a demo of some AngularJS taking to an XWiki backend: The extension is here: http://extensions.xwiki.org/xwiki/bin/view/Extension/AngularJSDemo A demo is here: http://www.ludovic.org/xwiki/bin/view/Phones/AngularSearch What I like a lot about AngularJS is the template approach while still being able to bind dynamic behavior and the fact that there is no backend compile making it a great fit for integration in XWiki pages. The demo is a angularJS screen right in an XWiki page. The controler could have been written as a JS Extension but in the demo it is also in the same page. The controler is calling both LiveTable JSON pages and REST pages to retrieve individual documents. XWiki's current REST apis are far from optimal to quickly retrieve the needed information to display as I had to configure 3 requests to get the page information, the main object and the attachment list. However with AngularJS this was very transparent as you did not need to chain the requests. Now if would be better if we improved our REST apis with that type of framework in mind. I've long thought that our REST system lacks the flexibility we have with XWiki pages. If we want to have the same flexibility with AJAX development and use and improve our REST apis instead of writing additional APIs in XWiki pages, then we need an easy way to extend or override existing REST apis. This could be achieved using Groovy Scripts that the REST api can dynamically load. These groovy script your replace, add or extend existing APIs. The example of the LiveTable is a very good example of the lack of flexibility/speed the development of additional REST apis represent. If we had had that flexibility the livetable backend code could be written as REST apis and not as an XWiki page. This is something we need to fix in our development model if we want to be a good Javascript UI citizen. We could push this type of integration way further providing an XWiki service for AngularJS which would simplify reading XWiki data and transforming it to the right objects for using in AngularJS templates. We could also provide additional filters and features for editing. In any case I believe this is something we really need to look into more in the future as the embedding works quite well and the angular JS development model fits the XWiki one quite well. It has the same "visual" aspect as velocity development but in Javascript with the additional dynamicity. WDYT ? Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

11 years, 6 months

[xwiki-devs] property "List of users"

by Добровольский Евгений

Hi All! I am trying to solve next task: I need to compare login of current user (current session login) and login of user which is stored in the object, which is added to the page. To get first value i use next function: xwiki.getUserName(xcontext.getUser(), false) it is working good! to store second value i have created object ( which is linked to page) and added property "List of users" into it. I can input username into this object, but i cannot get back it. i try to get it via ${xwiki.getUserName(MyObject.display("ApproverList", "view"), true) but it doesn't work ( it returns link to the user profile image) i have tried other but they don't work too. Can somebody help me and explain, how to get user name from this object?

11 years, 6 months

[xwiki-devs] [Proposal] Our schema migration process is broken, we need to change it before 5.0

by Denis Gervalle

Hi devs, I have filed today a blocker issue: http://jira.xwiki.org/browse/XWIKI-9041 This serious issue is the result of our current schema migration process. Currently, managing schema changes is done at two level: 1) A automatic script is computed by hibernate, comparing the current DB schema, and the targeted schema extracted from mapping files. 2) DataMigration may change schema using liquibase (git like solution for managing schema changes) According to the Hibernate team, 1) should only be used for development purpose. The Hibernate team clearly discourage usage of 1) in production, since it does not cover every use cases. For example, it does not: - drop column, table, etc... - change datatype - add constrainst ... However, this was the first, and until 4.x, the only way we had to manage our database schema. This is why we have introduced 2) in 4.0, to be able to change more information in our schema. Since 4.3, 2) was even be splitted in two steps, one before and one after step 1) for partially solving similar issue to http://jira.xwiki.org/browse/XWIKI-9041. While 1) is an uncontrollable monolithic step, 2) is like the underlying data migration, a chronologic process, that apply change in order. These two methods does not really work well join together, since parts of step 1) may need some part of step 2) to be done, and the reverse. For example, migration of IDs from 32bits to 64bits bases its schema changes on the hibernate mapping, and need the schema to be updated by hibernate first. A new table like xwikistringlists introduced in 5.0M2 implies the creation of new constraints against existing IDs, and therefore need the change of datatype to be processed first. There is no way out of that situation, and this is the cause of http://jira.xwiki.org/browse/XWIKI-9041. Since we do not do a lot of schema updates during a release cycle, the current situation has been manageable during the 4.x cycle. But, to avoid XWIKI-9041, it implies that user must not skip a major release during migration. This is a possible option, but it may implies some refactoring of existing migration inside a given release cycle, and probably some limitations as well. After brainstorming about the situation with Thomas, we have concluded that it would be better to get rid of step 1), to control precisely the evolution of the schema. However, we do not want to cause a breakage for existing users. So here what we proposed: A) For any existing database having a version lower than 50000, apply the automatic update of schema using hibernate, but based on the mapping file of the latest 4.5.x release, and followed by B) B) Any changes in mapping file done in 5.x or later (implying schema changes) should be backed by a corresponding DataMigration that provide Liquibase changelogs to reflect those changes on the database. C) Newly created database are setup using the latest mapping file by hibernate (since we manage versioning of our database, old liquibase change logs will never be applied to these new db) D) Advanced user will be allowed to also provide liquibase file, to manage their schema updated properly (existing hidden feature), but... E) The automatic hibernate schema update script is computed after the above steps to check that it is empty, and that the DB schema is in sync with the mapping file. Optionally we may allow this step to apply more schema updates for advanced users (at their own risk) that do not provide the liquibase change log required. (keeping the existing internal custom mapping feature, as well as the logic of our dynamic mapping). The pros: - New database will no more be updated blindly, and liquibase will provide a complete history of changes (except advanced user changes and dynamic mapping) - Existing database will start to have a complete history of schema changes starting from 5.x (and a somewhat partial history for 4.x versions) - Migration test will only be needed from pre-5.x to 5.x version, future migration will be more isolated, and can be tested more locally between the release introducing the migration and the previous one - We optionally keep existing functionalities (step E) The cons: - More work to be done while changing mapping file - Advanced user may need also to be more careful about their change in .hbm file - We keep using our versioning solution (we do not really use the liquibase way), maybe a advantage as well - We need some time to put that in place and we have already a slipping RC1 However, the only alternative I see to fix http://jira.xwiki.org/browse/XWIKI-9041 would be to revert the schema changes until the above, or a similar solution is available. The bad news now. Once again, I have not planned to work on this, and my planning is already really busy. It will also require to be thoroughly tested, and Sorin will not say the opposite, migration test is time consuming. So, this will not improve our schedule to release 5.0 and I will need serious support from you guys to put that in place. WDTH ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

11 years, 6 months

[xwiki-devs] change dns-name for xwiki

by Добровольский Евгений

Hi! I have next error after changing dns-name for xwiki server: All links in email-notification contains ip-address like http://x.x.x.x/(not like http://xwiki-dns-name) Before changes all work fine and link was shown like http://xwiki-dns-name How i can fix it? I have found template for email-notification letters, it contains next function to getURL: $event.getUrl() Then i checked resolving new dns-name from server console - it works good. where must i update dns-name for xwiki ?

11 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs April 2013