xwiki-devs November 2014

xwiki-devs@xwiki.org

24 participants
52 discussions

[xwiki-devs] [ANN] XWiki 6.3 Release Candidate 1 Released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki 6.3 Release Candidate 1. This release comes with 16 new Flamingo themes adapted from Bootswatch and a new application to manage them. The document index tree and the Navigation panel have been greatly improved by using a new tree widget which is exposed as a wiki macro. The developers will be interested by the new WebJar integration features. This, along with 17 improvements and 33 bug fixes, makes this release worth trying. 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/ReleaseNotesXWiki63RC1 Thanks -The XWiki dev team

10 years, 1 month

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

by Eduard Moraru

Hi devs, As you probably already know, today is BFD#69: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 93 bugs behind. See: http://jira.xwiki .org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-Resolved-Chart/10470 Here's the BFD#69 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12698 Thanks and enjoy your bug fixing day! -Eduard

10 years, 1 month

[xwiki-devs] [Proposal] Release XWiki 6.2.4

by vincent＠massol.net

Hi devs, We have already 28 issues fixed in 6.2.4: http://jira.xwiki.org/browse/XWIKI-191?filter=13410 6.2.3 was released on the 28th of October. I propose to plan 6.2.4 for Monday the 10th of November (roughly 2 weeks after 6.2.3), just before the 6.3 final release. If we agree I’ll try to perform the release myself (hoping I feel good enough at that time). WDYT? Thanks -Vincent

10 years, 1 month

[xwiki-devs] Compare different format dates in an XWQL query

by Katsushiro

Hello! Is there any way to compare two dates formatted differently in one XWQL query? Here is my query: /FROM doc.object('$xcontext.macro.params.parentSpaceClass') AS page WHERE :validDate >= $currDate ORDER BY $ordCol $xcontext.macro.params.orderDirection/ validDate - variable, which contains date formatted like this (page content): /01/10/2014 14:47:08/ $currDate - variable, which contains date formatted like this (from XWili $xwiki.getDate()): /Thu Nov 06 11:09:40 EET 2014/ If there is some way I can do this, please, answer me, I'll be incredibly thankful for it. If there isn't, I'll filter gained data with Velocity. Thank you for all your answers, Katsu -- View this message in context: http://xwiki.475771.n2.nabble.com/Compare-different-format-dates-in-an-XWQL… Sent from the XWiki- Dev mailing list archive at Nabble.com.

10 years, 1 month

[xwiki-devs] [Discussion] About Icon Themes

by Guillaume "Louis-Marie" Delhumeau

Hi. In XWiki 6.2, we have introduced the Icon Theme Application [1]. The idea was to be able to use Font Awesome in the Applications Panel without breaking all extensions. So we have a mapping between silk icons (that the extensions used until now) and the font awesome equivalents [2]. But, of course, the mapping is currently incomplete. For 2 reasons: 1/ It takes time to make it perfect (so feel free to improve it, directly on the wiki page! [2]) 2/ Some silk icons have no equivalent. Where a silk equivalent is missing, the Icon Theme Application automatically failbacks to the Silk icon, so something appears. Of course, it does not look very good when all icons are monochromatic except only one [3]. When there is no equivalent, we could have a strategy to not failback on Silk but instead using the most similar icon in Font Awesome. For example http://www.xwiki.org/xwiki/resources/icons/silk/flag_blue.png and http://www.xwiki.org/xwiki/resources/icons/silk/flag_green.png can both be mapped to http://fortawesome.github.io/Font-Awesome/icon/flag/ . But it would be problem if an extension use both icons to represent 2 different actions. In my opinion, we should not do this and let the failback-process happens. But actually, having this mapping should be only used for backward compatibility. What I want to propose is about the future. We should not use the silk icons anymore with the hope that it will be correctly mapped in other icon themes. What I want to create, is our own list of icons. The XWiki icon set. But I am not talking about drawing new icons. I am talking about create an official mapping for the icons we support and that have a mapping in all existing icon themes. For example, I have create the "wiki" icon, which is mapped to http://www.xwiki.org/xwiki/resources/icons/silk/world.png in silk and on http://fortawesome.github.io/Font-Awesome/icon/globe/ in font-awesome. I believe we need to create that list and create a documentation about it somewhere (maybe in a page integrated in XE, but at least on the extension page). So when a user create an application, she no longer chose an icon from the Silk collection but from our own list. If we agree on that principle, we also need to agree on a convention about the name of our icons. I propose: 'some-name' which means everything in lower case and words separated by '-'. I hope you'll like the idea. Thanks, [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Icon+Theme+Application (The Icon Theme Application) [2] http://design.xwiki.org/xwiki/bin/view/Proposal/IconSet (The mapping) [3] http://tof.canardpc.com/view/debc907e-d1ee-4e01-baff-dc740801e68d.jpg (Problem) -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

10 years, 1 month

Re: [xwiki-devs] Semester of Code

by vincent＠massol.net

Hi Scott, This is a great idea, I love it! :) Speaking for myself, I’d really like to see the XWiki project participating to it. What do we need to do to participate? Thanks a lot -Vincent On 14 Jul 2014 at 18:36:15, Scott Wilson (scott.bradley.wilson@gmail.com(mailto:scott.bradley.wilson@gmail.com)) wrote: > Hi everyone, > > I'm working with an initiative similar to Google Summer of Code, called Semester of Code, and I think it would be great to have students work on XWiki. Below is more detailed information, but basically its like GSoC, except students are involved as part of their courses or industrial placements, so receive academic credit rather than money for their work. > > Hopefully this is of interest to the XWiki community! > > If any questions aren't answered by the FAQ[1] or invitation below, feel free to ask. > > All the best, > > - Scott > > ~~~ > > The VALS Semester of Code [1] project is working with European universities and FOSS communities to give students real-world experience working in open source software projects while receiving academic credit. The benefit to your projects will be valuable and hopefully ongoing contributions. VALS will also benefit the wider sector by helping to produce graduates with the skills and experience needed to engage with open development. > > Our first Semester of Code will involve approximately 75 student placements, starting in September. We would like to invite your organisation to participate in this pilot by offering mentored placements within your projects. > > If you have participated in Google Summer of Code before, you will find our process similar; we will seek placements for student projects, and will use the a system similar to Google's Melange platform to manage placements. However, VALS differs from Summer of Code in that instead of receiving money for their participation, students will receive academic credit. For this reason the mentors from your project will need to liaise with the student's academic tutor. The VALS project will support this process to ensure it runs as smoothly as possible. We also ensure the admin overhead is minimal. > > The VALS initiative is a partnership of European universities and SMEs who have been working for several months to plan the pilot of Semester of Code, which will run during the next academic year. We have now reached the stage where we are signing up FOSS projects who are willing to provide mentors. We have already seen interest from smaller, single-company projects to larger software foundations, and would like to see more. > > If you'd be willing to provide one or more mentored projects, we’d love to talk to you about joining Semester of Code. In return, you’ll get an enthusiastic student providing a valuable contribution to your project. The VALS team will be on hand throughout the project to answer any questions and help unblock communication issues between mentors, students and academic supervisors. > > To join in the Semester of Code or to simply find out more you can email mark.johnson(a)it.ox.ac.uk, or you can sign up to our mailing list directly by using the web form [1]. > > More detail about the Semester of Code are available on our FAQ page [2]. If you have any other questions, don’t hesitate to ask on the mailing list, and one of the VALS team will get back to you! > 1: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=VALS-SOC&A=1 > 2: http://semesterofcode.com/?p=22 > > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

10 years, 1 month

[xwiki-devs] [Contrib] Hide-Show Panels extension

by Paul-Catalin Cojan

Hello devs! I created an extension that allows to hide and show the left and the right panel column. It have only one document XWiki.PanelsShowHide with one jsx and one ssx object. I need a repository on github. The name can be : panels-showhide-extension or application-showhide-panels or if you have any suggestion. Thank you!

10 years, 1 month

[xwiki-devs] [Brainstorming] Add Export UI for space-level + homogenisation

by vincent＠massol.net

Hi devs, <bad idea but kept for the sake of the discussion> Now that I’ve implemented http://jira.xwiki.org/browse/XWIKI-11337 I was wondering if it would be a good idea to have 2 menu entries (they would be visible only for admins by I think): - Export Space (in the Space menu of the navbar) - Export Wiki (in the Wiki menu of the navbar) When you click on them they would open a popup similar to the one that opens when you click on Export Page but with 2 options only ATM: XAR and HTML (since these are the 2 that support exporting at space and wiki levels). Now when the multipage export UI is ready, click on any Export (page level, space level or wiki level) would open that UI with a preselection (current page, current space or current wiki selected). We would also need to decide what to do with the Export screen of the Admin UI: Would it be dropped in favor of the “Export Wiki” menu action? </bad idea but kept for the sake of the discussion> <more thinking happened here… :)/> <better idea> More generally speaking we need to think about Admin actions and where we want them. I don’t think it’s a good idea to start putting more and more admin actions in menus. Actually what we should probably do is generalize the concept of the Admin UI at all levels: Page level, Space level and Wiki level. Thus I think I’d prefer the following: - Add an Export admin UI screen at the space level for exporting only a space as XAR - Introduce an admin UI screen at page level too and start moving features in there. I can think of at least 2: Export Page, Page level rights </better idea> WDYT? Thanks -Vincent

10 years, 1 month

[xwiki-devs] inside {{html}} macro?

by Paul Libbrecht

Hello fellow developers, do I have a way to know if I am inside an html macro or not? E.g. using a velocity variable? That would be really cool. thanks in advance. Paul

10 years, 1 month

[xwiki-devs] [Discussion] Problems with the way we release extensions done by the XWiki Dev Team

by Eduard Moraru

= Problem = Extensions managed by the XWiki dev team (in xwiki-platform) are limited to always depending on the latest version of XWiki. A user with an older XWiki instance can not install a newer/latest version of an extension *without upgrading to the newer/latest version of XWiki, even if that extension runs perfectly on his older version. Extensions on contrib do not have this problem, because they can easily specify the (possibly older) XWiki version they depend on even if they are developed and run perfectly on the latest version. As an analogy, imagine Android market where apps are developed with a minimum supported OS version of 2.2 (the most wide spread) and run perfectly and are developed on the latest Android 5.0. We need to be able to do that too, specially with "official" extensions. == Historical details == We have introduced this problem when we moved from the old repository layout where each module/extension was versioned individually. At each release, we would have to make sure that the xwiki-enterprise web contained the latest versions and it was a PITA. Now, each module/extension has the same version as xwiki-platform/xwiki-enterprise and we don`t hav to do that anymore, however we might have went a bit too far with the dependencies. = One Solution = In xwiki-platform, extensions keep using as parent the latest version in order to access the latest tools and configurations and to benefit from a smooth release process where we can release everything at the same version (XWiki's version). However, inside each extenion's pom, they will need to use the oldest compatible XWiki version possible for their dependencies and stop using ${project.version} or ${platform.version}. E.g. "[4.3,)" meaning from 4.3 to the latest = Problems with the solution = == Migrations == When migrating/upgrading to a fixed version (e.g. the new war corresponds to an XWiki 5.4 release) we want the distribution wizard to get the xar for 5.4 and we want o ensure that all the xar's dependencies are 5.4 versions (the ones corresponding to the 5.4 release) and not the latest (e.g 6.3). If the user wants to upgrade some individual extensions to the latest version, he can do that either in the current step (in the install plan to override the xar's default dependencies versions and specify either a manual one or 'latest') or in a diferent step (Add extension or Extension Updater sections in Administration). === Example === We want: xwiki-enterprise-ui-mainwiki (5.4) > xwiki-enterprise-ui-common (5.4) > xwiki-platform-administration-ui (5.4) > xwiki-platform-rendering-macro-velocity (5.4) Instead of: xwiki-enterprise-ui-mainwiki (5.4) > xwiki-enterprise-ui-common (5.4) > xwiki-platform-administration-ui (5.4) > xwiki-platform-rendering-macro-velocity ([4.3,) which is resolved to 6.3) === Possible solution to this problem === Have the distribution xar ensure that its dependencies' transitive dependencies are not the ones specified by the direct dependencies, but the ones corresponsing to the distrubution xar's XWiki version. We could probably achieve this by listing in xwiki-enterprise-ui-mainwiki all the transitive dependencies that are XWiki artefacts and use ${project.version} for all of them. Perhaps we can automate this with a maven plugin instead of manually having to maintain this list. Even if we end up maintaining a list, it will not be something that changes very often. == LTS environment encapsulation leaks == After the migration is complete and the user is now using 5.4, he might want, at some point to upgrade some of his extensions to benefit from minor bugfixes. Considering that his current 5.4 version is a LTS version, he might not want to upgrade to the *latest* (6.3) version of an extension, but he would like instead to remain in the 5.4 LTS version range and get only 5.4.1, 5.4.x versions, even 5.x versions as they come, but not go to 6.x or newer/unsafe versions. This problem should be addressed by the Extension Updater UI and, possibly allowing the user to specify if he wants a specific/manual version (regardless of LTS or latest) or the latest version (a. from the current cycle, i.e. LTS or b. the latest one available, i.e. 6.3+) WDYT? Thanks, Eduard

10 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs November 2014