xwiki-devs January 2017

xwiki-devs@xwiki.org

17 participants
37 discussions

Re: [xwiki-devs] [Proposal] Changing the location of XED files

by Denis Gervalle

Sorry if my question looks late or stupid, but what is the benefit of those xed files, how are they added to the lib folder currently ? That might explains why these meta information are not integrated to the jar file, what I would have expected more than B. Thanks, -- Denis Gervalle SOFTEC sa - CEO On Fri, Jan 27, 2017 at 3:07 PM, Denis Gervalle <denis.gervalle(a)softec.lu> wrote: Sorry if my question looks late or stupid, but what is the benefit of those xed files, how are they added to the lib folder currently ? That might explains why these meta information are not integrated to the jar file, what I would have expected more than B. Thanks, -- Denis Gervalle SOFTEC sa - CEO On Wed, Jan 25, 2017 at 9:31 PM, Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> wrote: I don't have a problem with keeping the XED files in WEB-INF/lib if the spec doesn't forbid it, especially if it simplifies the implementation. Thanks, Marius On Tue, Jan 24, 2017 at 2:26 PM, Vincent Massol <vincent(a)massol.net> wrote: > Hi devs, > > In XWiki 9.0RC1 we’re putting XED files in WEB-INF/lib next to the JAR to > which they correspond. > > I have 2 issues with this: > * We’re not really supposed to use WEB-INF/lib for that. WEB-INF/lib is > meant for JAR files that are to be made available to the classloader. It’s > even possible that some servlet container would emit warnings about this. > * This is a WTF for admins when they discover this. The WAR has a spec and > it’s standardised. Thus the WTF when you see this since you’re not used to > seeing this anywhere else. > > I’m thus proposing to move the XED files to a META-INF/xwiki/ directory > inside the WAR instead since META-INF is meant to contain metadata > information and is thus meant exactly for this. > > WDTY? > > Thanks > -Vincent > >

7 years, 7 months

[xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

by Vincent Massol

Hi devs, We have plenty of existing limitations in our PDF export (table autoresize, etc) which comes from FOP and our usage of it. And it’s hard to improve it. I’d like to propose the following: * Promote the browser’s print to PDF feature instead of our PDF Export by triggering the browser’s print feature when clicking on Export > PDF in the UI. * Work on our print.css so that it has all the styles we have in view mode (right now for ex, info boxes for ex do not have a nice style). * Move our PDF Export java code out of xwiki-platform and into an optional extension that we move into xwiki-contrib. The use case for it would be when you need to generate PDF from scripts. WDYT? Thanks -Vincent

7 years, 7 months

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

by Guillaume Delhumeau

The XWiki development team is proud to announce the availability of XWiki 9.0 Release Candidate 1. This version opens the new 9.x cycle. It contains all improvements introduced in versions 8.4.1 to 8.4.4, and brings admin and developer features mostly. Among other things, XWiki deals better with big attachments now. 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/Data/XWiki/9.0RC1/ Thanks for your support -The XWiki dev team

7 years, 7 months

[xwiki-devs] [VOTE] Move all Confuence related modules to contrib

by Thomas Mortagne

Hi devs, I would like to give Confluence filter input and syntaxes modules there own life on xwiki-contrib pretty much on the same model than what I did for MediaWiki (https://github.com/xwiki-contrib/mediawiki/) since it's exactly the same use case. The main reasons are: * those modules are not embedded (for the input) or enabled (for the syntaxes) by default * those modules need to follow Confluence evolution more than XWiki WDYT ? Here is my +1 -- Thomas Mortagne

7 years, 7 months

[xwiki-devs] [Proposal] Changing the location of XED files

by Vincent Massol

Hi devs, In XWiki 9.0RC1 we’re putting XED files in WEB-INF/lib next to the JAR to which they correspond. I have 2 issues with this: * We’re not really supposed to use WEB-INF/lib for that. WEB-INF/lib is meant for JAR files that are to be made available to the classloader. It’s even possible that some servlet container would emit warnings about this. * This is a WTF for admins when they discover this. The WAR has a spec and it’s standardised. Thus the WTF when you see this since you’re not used to seeing this anywhere else. I’m thus proposing to move the XED files to a META-INF/xwiki/ directory inside the WAR instead since META-INF is meant to contain metadata information and is thus meant exactly for this. WDTY? Thanks -Vincent

7 years, 7 months

[xwiki-devs] [Proposal] New Best Practice for closing issues as Duplicate

by Manuel Smeria

Hello Devs, I would like to propose a new best practice for the way we close issues as Duplicate. As an example I've reported this issue: http://jira.xwiki.org/browse/XWIKI-13728 which was later closed as a Duplicate to http://jira.xwiki.org/browse/XWIKI-13729. >From my perspective, this is not correct since the issue I reported is valid from an user's POV. I would have preferred that my issue was renamed and that developers would have added some technical information as a comment to it if they wanted to do so. It just doesn't make any sense to me to close a perfectly valid issue as a Duplicate just to create another one that has a more technically correct summary and description. It also doesn't make sense to close the original issue as a Duplicate to a duplicate issue :) (pun intended) I see things like this: my issue's description is a use-case of the issue later reported by Edy, so if anything, Edy's issue should be closed as a Duplicate to mine and not the other way around. One scenario where I think issues dated previously should be closed as Duplicate is if the new issue has already been fixed. For example when a Developer doesn't notice an older issue and starts working on the new one instead of closing the new one as a Duplicate and work on the older one. There might be more, feel free to add them to this thread. So, what I propose is that we don't close original issues as Duplicate unless it falls into the category previously described or some other exceptions that I can't think of now and might occur. Thanks, Manuel

7 years, 7 months

[xwiki-devs] [ANN] Markdown Syntax 1.2 has been released (experimental)

by Vincent Massol

Hi Markdown lovers, Just wanted to announce that I’ve completely written XWiki support for the Markdown syntax (using flexmark-java instead of pegdown). It’s available as the “markdown/1.2” syntax inside of XWiki. See http://extensions.xwiki.org/xwiki/bin/view/Extension/Markdown+Syntax+1.2 for details. Please try it out and let me know how it goes. If you find bugs please report them at http://jira.xwiki.org/browse/MARKDOWN Thanks -Vincent

7 years, 7 months

[xwiki-devs] [Idea] Feature Index in XE

by Vincent Massol

Hi devs, I’ve had this idea this morning in order to try to make the XE features more discoverable: http://design.xwiki.org/xwiki/bin/view/Proposal/DiscoverabilityofFeatures Good idea? Bad idea? Let me know what you think. Thanks -Vincent

7 years, 7 months

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

by Alexandru Cotiuga

Hello devs, Today is BFD#135: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 2 bugs ahead. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#135 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13796 Enjoy your BugFixing Day, Alex

7 years, 7 months

[xwiki-devs] [PROPOSAL] Make extension pages author superadmin when current user have programming right

by Thomas Mortagne

Hi devs, I'm thinking since a long time that maybe we should automatically make superadmin the author of the pages when installing a XAR as long as the current user (and current author) have programming right (i.e. has the same rights than superadmin when the extension is installed). I don't really see anything against it these days and it's easy to do so why not. Basically the goal is to reduce the possibility to break extensions when you play with existing users/groups/rights. Common user case being to get rid of some old adminsys leaving the company. WDYT ? Note: to be complete we could imagine the same kind of thing for admin user but that require the introduction of a virtual admin right user like superadmin is a vitual programming right user. But let's not discuss too many thing at once. -- Thomas Mortagne

7 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs January 2017