xwiki-devs August 2016

xwiki-devs@xwiki.org

13 participants
50 discussions

[xwiki-devs] [Brainstorming] Use cases for an alternative filesystem format (alternative to XAR)

by Vincent Massol

Hi, This is a follow-up on the threads: * "Designing the perfect FS representation of a wiki”: http://markmail.org/message/3yghqwetmdt5woez * "XAR source projects should allow source files”: http://markmail.org/message/432o36r4klh7yv24 It’s also a continuation of the work done here: http://design.xwiki.org/xwiki/bin/view/Design/DirectoryStructureforXWikiApp… Once we get convergence on those thread (or even if we don’t), I’ll update design.xwiki.org with the results. The goal is to define the use case for an alternate filesystem to XAR. Issues with the XAR format ====================== * XML is not an easy to edit format and doesn’t allow use a specific editor to edit content * XML also requires content to be XML-encoded and thus is really not easy to make modification (there’s a risk of breaking the XML easily) Can you see more issues? Use cases for an alternative filesystem format =================================== (some UC taken from http://design.xwiki.org/xwiki/bin/view/Design/DirectoryStructureforXWikiApp…) * UC1: the structure should be (as) easy (as possible) to navigate in an IDE style view * UC2: it should be easy to add content (a new script or attachment on an existing structure). It should allow using specific editors for different content types, e.g. if a page content is in markdown, it should be editable with a MD editor, js and css should be editable with web editors, etc. * UC3: It should be possible to build a packaged version of the sources with Maven * UC4: It should be possible to import the packaged version into a running XWiki instance * UC5: It should be possible to export a portion of a running XWiki instance in this format * UC6: This format should be able to fully replace the XAR format . The new format should support at least all features supported by the XAR format (versioned, etc). Note: XE will need to be refactor a bit so that the XAR format can be swapped out by introducing extension points/APIs. The idea would be to deprecate the XAR format and introduce this new format instead, and the 2 formats should be avle to cohabit next to each other in XWiki. * UC7: When importing in a wiki and exporting again (without making any change in the wiki), it should generate an identical structure and content, with no difference. Any more? Thanks -Vincent

8 years

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

by Alexandru Cotiuga

Hello devs, This Thursday is BFD#116: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 67 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#116 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13634 Happy Bug Fixing Day, Alex

8 years

[xwiki-devs] Crafting method to add a plugin to the CKEditor?

by Paul Libbrecht

Hello fellow developers, is there some hint to add a plugin (with a button) to the CKEditor? I've met /xwiki/bin/edit/CKEditor/EditSheet?editor=object which is probably the place to start with. I tried adding the extraConfigs variable within the configuration but it seems like this cannot load my plugin. It would be cool to have an extension mechanism for that. thanks in advance. Paul

8 years

[xwiki-devs] Cannot upgrade the CKEditor extension that is bundled by default

by Marius Dumitru Florea

Hi devs, Thomas raised this issue http://jira.xwiki.org/browse/XE-1570 . One of the reasons we decided to keep the CKEditor Integration extension in contrib, with its own release cycle, was to allow the users to upgrade it without the need to upgrade the entire XWiki distribution. There wouldn't be any problem if the CKEditor Integration extension didn't had any JAR dependencies. But it depends on the CKEditor WebJar which ends up in the XWiki WAR and thus is considered a core extension, and core extensions cannot be upgraded. Here's what happens: * xwiki-enterprise-ui-common depends on ckeditor-ui ( https://github.com/xwiki/xwiki-enterprise/blob/xwiki-enterprise-8.2.1/xwiki… ) * both xwiki-enterprise-ui-mainwiki and xwiki-enterprise-ui-wiki depend on xwiki-enterprise-ui-common * xwiki-enterprise-web depends on both xwiki-enterprise-ui-mainwiki and xwiki-enterprise-ui-wiki ( https://github.com/xwiki/xwiki-enterprise/blob/xwiki-enterprise-8.2.1/xwiki… ) in order to "transitively include all JAR dependencies in the generated WAR" So the ckeditor-webjar ends up in the XE WAR, thus it becomes a core extension. In order to fix this Thomas has proposed two solutions: (1) Build 2 XE WARs: one that bundles the transitive JAR dependencies of the UI (what we have currently) and one that doesn't bundle them. We would offer only the later for download on xwiki.org, knowing that the transitive JAR dependencies will be installed when the UI is installed (with the Distribution Wizard for instance). The first WAR would be used only for building the Jetty+HSQLDB distribution. The downside of this solution is: * we don't fix the problem for the Jetty+HSQLDB distribution * the ui-all XAR would work only with the "all" WAR (the first one that bundles the XAR dependencies) (2) Exclude the JARs we don't want as core extensions from https://github.com/xwiki/xwiki-enterprise/blob/xwiki-enterprise-8.2.1/xwiki… , one by one. This would fix the WAR-based installations but not the Jetty+HSQLDB distribution which uses the Import Mojo ( https://github.com/xwiki/xwiki-enterprise/blob/xwiki-enterprise-8.2.1/xwiki… ) to generate the distribution data folder and thus won't get the ckeditor-webjar. For this we would need to introduce a new Install Mojo and explicitly install the JAR dependecies we want (ckeditor-webjar in this case). The problem with this solution is the maintenance cost. We'll forget for sure to exclude/install the JAR in XE's pom whenever we add a new JAR dependency to one of the contrib extensions that are bundled in XE (CKEditor and Tour for the moment). Do you have any other ideas? Solution (1) seems the best so far. Thanks, Marius

8 years

[xwiki-devs] [Proposal][Urgent] Change of behavior for xproperties editor for backward compat reasons

by Vincent Massol

Hi devs, Marius has recently introduced the honoring of text editor for xproperty editing for textarea types. This is great but it’s causing a lot of backward compatibility issues. We’ve fixed several xclass to use “puretext” for code but there are plenty out there still. I’ve just found another one with XWiki.WatchListMessage. The issue is that this is a blocker. I was trying to make a change there so I was editing using the “source” mode of CKEditor. The problem is that when I saved there were a lot of changes made to the content automatically, breaking the code, see for example: https://www.evernote.com/l/AHf4KpfVtfBOK5zqcyf_up1Rty923fZOm-I The main issue is that I’m stuck. There’s nothing I can do in my wiki (without resorting to scripting, using REST, etc). I’m proposing that we do the opposite: * When no editor is specified, use the wiki editor. Apps that want WYSIWYG in xproperties should say so. This is actually more logical to me because the object editor is a technical editor. In any case we need a solution that doesn’t break backward compatiblity. Since this change of behavior (honoring the editor for xproperties in the object editor) was introduced in XWiki 8.2 we need to act fast before it becomes a problem for our users. WDYT? Thanks -Vincent

8 years

[xwiki-devs] [Proposal] Curation process for extensions on e.x.o

by Vincent Massol

Hi devs, We have a lot of entries on extensions.xwiki.org (869 as of today) and this causes some problems for our users: P1) A lot of them are not of good quality (they don’t work with the latest versions, they are complex to use, they’ve not been updated for a long time and are doing old and deprecated ways of doing things such as not providing an entry in the Applications Panel for example, they’re not just polished, etc) and this causes frustrations for our users. Note that this also reflects on the overall quality of the XWiki project and product. P2) It’s hard for users to locate good extensions among the rest. We’ve started addressing P1) by introducing ratings on e.x.o. This is not fully successful so far because we don’t have enough people voting and because those ratings are not used to display/filter extensions on the Extensions LT or inside XWiki in the EM UI. So we need to continue this effort. Note that this proposal is not addressing non-extensions such as snippets which we’ll need to move elsewhere at some point but that becomes less important with the proposal below. Proposal ======= I’d like to propose an additional strategy that, IMO, is better suited for the size of our community: curation. Curation is the process of hand-selecting the best extensions and marking them as recommended. The idea would be to list recommended extensions first on the e.x.o home page, in the EM UI in XWiki and even in extension search results. In the EM UI, an idea would also be to have a new “Recommended Extensions” filter in addition to the existing filters (core extensions, installed extensions, etc) and that would be the default filter on the “Add Extensions” UI. I propose to add a “Recommended” xproperty in the Repository app for that. We can decide whether we want this just for e.x.o or committed in the Repository app in xwiki-platform. Then we need to decide about the curation process: * The XWiki core committers are in charge (i.e. have the responsibility) of monitoring the apps that are marked “Recommended”, ie. validating that it’s done correctly. XWiki core committers have the authorization to unset an app that was marked a recommended by a community member. * We wouldn’t offer a simple way in the UI to mark an extension as recommended since we don’t want everyone who has an account on xwiki.org to start marking apps as recommended. OTOH we want to allow people from the xwiki community to help out. So the way to mark an extension as recommended would be to use the object editor (for now, we can define a better implementation mechanism later on). * We define some basic rules that extensions need to follow at minimum to be accepted as recommended. These will be our guidelines to avoid conflict of opinions (although there’s always the possibility in which case it’s resolved through a vote): - Need to work on LTS + latest XWiki version (ie. ATM that would be 7.4.x and 8.1) - Need to present a polished aspect and be easily usable - Need to follow most of the best practices defined on http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra…. Some important examples: technical pages are hidden, extension is registered in the app bar when it makes sense, extension is internationalized (if it makes sense), pages are in xwiki syntax 2.0+. WDYT? I’m willing to help do the work and mark extensions as recommended. Thanks -Vincent

8 years

Re: [xwiki-devs] 回复： XWiki-8.2.2 XWiki-8.2.2

by Eduard Moraru

Hi, (please send mails directly to the list, not to individuals) As you can see from our documentation [1], XWiki uses maven [2][3] to build its code. You can build the code using maven alone (run "mvn clean install" [4]), so Eclipse or any other IDE is optional. If you want to import *individual modules* in your IDE so that you can extend or fix them, you can do so and then you can build that individual module. There is no point in importing *all* the modules in your IDE since that would only use up your computer`s memory. Even from the IDE, to build XWiki, you need to import the correct module (e.g. xwiki-enterprise-jetty-hsqldb) and build *only that* in order to get the built package. The missing files you are referring to are not part of XWiki, but probably come from a 3rd party dependency. Also, make sure you get the correct sources, depending on what you want (the latest development sources, the stable sources, the LTS sources, version X sources, etc.). As Ecaterina mentioned, 8.2.2 is not an XWiki released version, but is an in-development bugfix version. Another good idea is to get the sources using git ("git clone ...") instead of getting a sources zip file which will lose the ability to update to the latest changes (i.e. versioning). Make sure you get up to speed with how maven and git work and that you understand what you want to achieve, since otherwise you might be wasting time in the wrong direction, trying to do something unnecessarily complex for the task you want to achieve. Hope this helps and feel free to ask for help if you get stuck. Thanks, Eduard ---------- [1] http://dev.xwiki.org/xwiki/bin/view/Community/Building [2] https://maven.apache.org/what-is-maven.html [3] https://en.wikipedia.org/wiki/Apache_Maven [4] https://maven.apache.org/guides/getting-started/maven-in-five-minutes.html On Fri, Aug 26, 2016 at 6:07 PM, 既然 M.A.R.S <464503882(a)qq.com> wrote: > I am a new XWiki developer and found XWiki just a few > days ago. I downloaded the installer for windows, > installed it in my computer and then start the XWiki > using the start icon.After i try the demo, i think XWiki > is awesome, So i want to learn and develop it .I want > to know how the XWiki works, and i want to build the all > source code myself and publish it to a server just > like the same result as the installer.So, i referred the > document from the site,followed the instruction step > by step.Step ONE,I configured the JDK,Maven,Repository.Step > TWO,I downloaded all the souce code,including common, > platform,tools,enterprise.Step THREE, I unzip the > archive and import them as maven project.The problem > occurred in Step THREE, there are some files missing in > some project(xwiki-platform-query-jpql-parser-8.2.2 ,etc), > i searched the whole repository and found no result.Import everything is > not recommended,but i want try to completely build xwiki > myself,if not import enough source code,how could to > build and generate a complete war file and publish to server? > > ---原始邮件--- > *发件人:* "Eduard Moraru"<enygma2002(a)gmail.com> > *发送时间:* 2016年8月26日 18:06:45 > *收件人:* "XWiki Developers"<devs(a)xwiki.org>; > *主题:* Re: [xwiki-devs]回复： XWiki-8.2.2 XWiki-8.2.2 > > Hi, > > Please take the time to better explain your problem (how you got to that > point, step by step, what errors did you get, what is your goal and why do > you think it should be done like that, etc.), otherwise we can not > understand how to help you. > > Also, please avoid sending the same message multiple times. > > Thanks, > Eduard > > On Fri, Aug 26, 2016 at 12:07 PM, 既然 M.A.R.S <464503882(a)qq.com> wrote: > > > but some file i can't find in the source code, especially in the > > xwiki-platform-query > > > > > > > > > > ------------------ 原始邮件 ------------------ > > 发件人: "Ecaterina Moraru (Valica)";<valicac(a)gmail.com>; > > 发送时间: 2016年8月26日(星期五) 下午5:03 > > 收件人: "XWiki Developers"<devs(a)xwiki.org>; > > > > 主题: Re: [xwiki-devs] XWiki-8.2.2 XWiki-8.2.2 > > > > > > > > 8.2.2 is not released yet and not even sure we are going to release it. > > http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ > > > > Thanks, > > Caty > > > > On Fri, Aug 26, 2016 at 3:55 AM, 既然 M.A.R.S <464503882(a)qq.com> wrote: > > > > > i can't find a file named DepthFirstAdapter in this release version of > > > 8.2.2 > > > _______________________________________________ > > > devs mailing list > > > devs(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >

8 years

[xwiki-devs] [Brainstorming] Problems for users with nested page when using references in APIs

by Vincent Massol

Hi devs, We have a known issue with users starting with XWiki and reading documentation on xwiki.org and trying out stuff. Like yesterday morning someone was following the SSX tutorial and couldn’t make it work. The issue was that the page he was creating to put his SSX xobject in, had been created as a non terminal page (our default) and the tutorial was telling him to do: $xwiki.jsx.use(‘XWiki.SkinExt”)… We’ll have this issue everywhere and starting with XWiki 7.4+ we’ve made it very hard for users to start using the programming features of XWiki because of this (without mentioning that having to suffix with “WebHome” is not nice and natural). So I was wondering if we could help our users with this. Here’s one idea: * At the store API level (or just above in XWiki.getDocument()) do the following: ** try to load the passed reference as is and if it exists return it ** if it doesn’t exist and the passed reference doesn’t end with “WebHome", try to load the reference by adding “WebHome” to it ** if it doesn’t exist, return an empty doc (isNew = true) for the original reference asked (to be as backward compatible as possible) What this means is that if a WebHome page exists it won’t be possible to create a terminal page of the same name as its space by using getDocument(). There won’t be problems for existing duplicates (ie a space and a terminal page named the same). To solve this we could either introduce a new signature for getDocument() or introduce a TerminalDocumentReference class (that extends DocumentReference) and that the current getDocument() would understand as wanting a terminal document (we could use another name). And thus we could use the new TerminalDocumentReference class for example in the Create Page UI when the “terminal” checkbox is checked, thus allowing users to be able to create both types for the same name. I have the feeling that the small downside is really small compared to the advantages it would offer. For example it would solve the issue we have now with using a reference in macro. For example: {{include reference=“A.B.C.Mypage”/}} would work when MyPage is a NestedPage (i.e. A.B.C.MyPage.WebHome). WDYT? Thanks -Vincent PS: Related to this is http://design.xwiki.org/xwiki/bin/view/Proposal/DeprecatingSpaceAndSpaceRef… but that’s a lot more complex to implement and not for just now. The goal of this mail is to brainstorm about what we can do now.

8 years

[xwiki-devs] [Problem]XWiki-8.2.2 How to build xwiki from all source to a war file and publish it to a server

by 既然 M.A.R.S

I am a new XWiki developer and found XWiki just a few days ago. I downloaded the installer for windows,installed it in my computer and then start the XWiki using the start icon.After i try the demo, i think XWiki is awesome, So i want to learn and develop it .I want to know how the XWiki works, and i want to build the all source code myself and publish it to a server just like the same result as the installer.So, i referred the document from the site,followed the instruction step by step.Step ONE,I configured the JDK,Maven,Repository.Step TWO,I downloaded all the souce code,including common,platform,tools,enterprise.Step THREE, I unzip the archive and import them as maven project.The problem occurred in Step THREE, there are some files missing in some project(xwiki-platform-query-jpql-parser-8.2.2 ,etc),i searched the whole repository and found no result.Import everything is not recommended,but i want try to completely build xwiki myself,if not import enough source code,how could to build and generate a complete war file and publish to server?

8 years

[xwiki-devs] XAR source projects should allow source files

by Paul Libbrecht

Hello fellow developers, many of you are developing XAR-packaged resources. The exchangeability of these archives is one of the precious aspects of XWiki, I believe. However, if one see all the many GitHub-contributed xar packages, the source is not there: it's in a Wiki with which one would "open it". A pity since much of the content is code. I'd like to propose to allow XARs to be built form source code which is true source that one edits. Code files with their proper syntax coloring, editors, auto-completion, search. Media-files that are edited with our tool of choice by a simple double-click and not a complex pull, edit, and replace. Thus, my proposal is to allow inclusions within the XML files. Inclusions should be of type: - text to include page content or object properties (e.g. css of cssx objects) - attachments to include attached objects My current setup is documented here:http://jira.xwiki.org/browse/XWIKI-13643 It does binaryInclude to generate base64 and textInclude to generate XML-text. Thus, I can advertise a github project which is a macro and whose complex function is in a velocity file that is in a .vm file. However, I do not need to explode everything, e.g. the text-content describing the macro or (in this case too small) translation set. What do you think? Should I rather generate complete attachment elements (name, length, modif date, ...) instead of doing a binaryInclude that just generates base64 ? Is fetching files for inclusion beyond the boundaries of the project of any use? (it is currently prohibited for safety) thanks in advance. Paul

8 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs August 2016