xwiki-devs March 2015

xwiki-devs@xwiki.org

22 participants
55 discussions

[xwiki-devs] [Proposal] Plan to remove XWiki Enterprise

by vincent＠massol.net

Hi devs, I’d like to work on the following (and any help will be most welcome). What ==== 1 - Finish moving XE pages into xwiki-platform 2 - Introduce flavor concept in xwiki-platform: xwiki-platform/xwiki-platform-core/xwiki-platform-flavors/ |_ xwiki-platform-flavor-minimal/ |_ xwiki-platform-flavor-xwiki/ |_ xwiki-platform-flavor-xwiki-main/ |_ xwiki-platform-flavor-xwiki-wiki/ |_ xwiki-platform-flavor-test/ where: * minimal: the base for the “xwiki” and “test” flavors. Contains the core deps that need to be present in any xwiki runtime * xwiki: the only runtime flavor that we distribute as part of the xwiki github organization. A generic flavor with no vertical. See http://markmail.org/message/keo7cs6u3fuf676w * test: minimal + the export feature (since when writing functional tests there's is often the need to export pages as XAR) 3 - Modify the XWiki Packager Plugin: * Do not include any dep by default, instead only rely on the plugin user’s declared deps. Users of the plugin will use flavors as deps. * Split the current PackageMojo into 2 mojos: ** WarMojo: generates a WAR file (WAR distribution) ** StandalonePackageMojo: generates a standalone ZIP (Jetty+HSQLDB) 4 - Refactor functional tests in xwiki-platform to use the new StandalonePackageMojo with deps on xwiki-platform-flavor-test 5 - Introduce Distribution modules in xwiki-platform: xwiki-platform/xwiki-platform-distributions/ |_ xwiki-platform-distribution-war/ |_ xwiki-platform-distribution-standalone/ |_ xwiki-platform-distribution-installers/ |_ xwiki-platform-distribution-images/ |_ xwiki-platform-distribution-image-mysql/ |_ (more later) |_ xwiki-platform-distribution-archetype/ |_ xwiki-platform-distribution-xar/ where: * xwiki-platform-distribution-war and xwiki-platform-distribution-standalone will use the XWiki Packager Plugin’s mojos and will have a dep on xwiki-platform-flavor-xwiki in their POM * xwiki-platform-distribution-images provides Docker images (that we’ll publish to the Docker Hub: https://hub.docker.com/) * xwiki-platform-distribution-archetype is the move of xwiki-enterprise-archetype/. Its goal is to create the build for new products based on XWiki. It’s to help OEMs. * xwiki-platform-distribution-xar contains the full XARs (for the main wiki and subwikis) for those who don’t or cannot use the DW/EM and want to import them manually. 6 - Move functional tests from xwiki-enterprise to xwiki-platform. * Ideally move specific tests to the module they’re testing * Move the rest to xwiki-platform/xwiki-platform-distributions/xwiki-platform-distribution-tests/ 7 - Remove xwiki-enterprise and start advertising the new distribution (update of xwiki.org) When ===== My goal would be to achieve this in the XWiki 7.x cycle (i.e. before the end of the year). Misc ==== Previous thread on related topic: * http://markmail.org/message/n2yove6lr3rlzh6j WDYT? Thanks -Vincent

9 years, 9 months

Re: [xwiki-devs] devs Digest, Vol 93, Issue 12

by /xin蜗牛

How I Can Internationalizing ‍"Hello World"? ------------------ Original ------------------ From: "devs-request(a)xwiki.org";<devs-request(a)xwiki.org>; Date: Sun, Mar 8, 2015 08:00 PM To: "devs"<devs(a)xwiki.org>; Subject: devs Digest, Vol 93, Issue 12 Send devs mailing list submissions to devs(a)xwiki.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.xwiki.org/mailman/listinfo/devs or, via email, send a message with subject or body 'help' to devs-request(a)xwiki.org You can reach the person managing the list at devs-owner(a)xwiki.org When replying, please edit your Subject line so it is more specific than "Re: Contents of devs digest..." Today's Topics: 1. Re: How Internationalizing UIExtension Module? (Eduard Moraru) ---------------------------------------------------------------------- Message: 1 Date: Sun, 8 Mar 2015 00:40:29 +0200 From: Eduard Moraru <enygma2002(a)gmail.com> To: XWiki Developers <devs(a)xwiki.org> Subject: Re: [xwiki-devs] How Internationalizing UIExtension Module? Message-ID: <CADGDyYJAy5tz5EqUpeVmLT4ktJvKwN9iFDxs5t_xo+CxtMvEoQ(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Hi, You would need to try to be more specific in your question. What is it that you want to achieve, what did you try and did not work, etc. Thanks, Eduard On Sat, Mar 7, 2015 at 11:02 AM, /xin?? <445686910(a)qq.com> wrote: > Hi? > I want to know How Internationalizing UIExtension Module?? > Thanks? > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > ------------------------------ Subject: Digest Footer _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ------------------------------ End of devs Digest, Vol 93, Issue 12 ************************************

9 years, 9 months

[xwiki-devs] How Internationalizing UIExtension Module？

by /xin蜗牛

Hi， I want to know How Internationalizing UIExtension Module？‍ Thanks。

9 years, 9 months

[xwiki-devs] GSCO: Interested in project Javascript and AngularJS XWiki API

by kiran ps

Hi, I'm an Engineering student(computer science) pursuing my degree from Government Engineering College(Calicut University), Thrissur, India. I went through xwiki gsoc idea list.I'm interested in the project JavaScript and AngularJS XWiki API. I have good skills in JavaScript, nodejs, angular. I am looking forward for a good response from your side regarding details about the projects so that I could start contributing towards it. Skills: Languages: JavaScript, nodejs, python, HTML5, CSS3, C, C++ Libraries: jQuery, underscorejs, zeptojs, KineticJS Frameworks: Angularjs, Express, Django, Tools: Vim, Git, Grunt, bower, Yeoman Thank you, { name: "Kiran P S", email: "pskirann(a)gmail.com", github: "github.com/kiranps", google+: "plus.google.com/+kiranps1", twitter: "@pskirann" }

9 years, 9 months

[xwiki-devs] [Proposal] Split XE pages into platform modules

by Vincent Massol

Hi devs, Here's a proposal to move pages currently located in XE into platform modules: * ColorThemes/*.xml --> xwiki-platform-colorthemes * Main/Activity.xml --> xwiki-platform-activitystream-ui (move current xwiki-platform-activitytream into xwiki-platform-activitystream-api) * Main/AllDocs.xml (and XWiki.Tableview, XWiki.Treeview, XWiki.OrphanedPages, XWiki.AllAttachments*, XWiki.DeletedDocuments, XWiki.DeletedAttachments and all pages used by those) --> new xwiki-platform-navigation module * Main/RssFeeds.xml --> new xwiki-platform-help module or xwiki-platform-rss-ui module (see below) * Main/SpaceIndex.xml --> xwiki-platform-navigation * Main/Spaces.xml --> xwiki-platform-navigation * Main/UserDirectory.xml --> xwiki-platform-user-ui * Main/WebHome.xml --> xwiki-platform-dashboard-ui * Main/WebRss.xml --> new xwiki-platform-rss-ui module, we would create a xwiki-platform-rss-api module too where we will move the feed plugin * Main/Welcome.xml --> move to xwiki-platform-dashboard-ui since it's a dashboard gadget which we could consider as a default widget * Sandbox/*.xml --> xwiki-platform-sandbox module (or xwiki-platform-help module) * XWiki/XWikSyntax.xml --> xwiki-platform-help module * XWiki/AttachmentSelector.xml --> xwiki-platform-user-ui or new xwiki-platform-attachmentselector module * XWiki/ClassSheet, ClassTemplate, ObjectSheet, XWikiClasses, * XWiki/GadgetClass.xml --> xwiki-platform-dashboard-ui * XWiki/LiveTableResult*.xml --> new xwiki-platform-livetable module * XWiki/MessageStreamConfig.xml --> new xwiki-platform-messagestream-ui module (and move xwiki-platform-message in xwiki-platform-message-api module) * XWiki/RequestsStatus.xml --> xwiki-platform-administration module or remove from platform till we integrate it in the Admin as an admin tool somewhere since right now I think it's available in the Admin tools application * XWiki/RequiredRightClass.xml --> since it's used in lots of other ui modules I'd propose to move it in java code as a class created on startup. Alternatively start creating a xwiki-platform-rights-ui module (or xwiki-platform-permission-ui module) and move it there * XWiki/SharePage.xml --> not sure…. maybe in a xwiki-platform-share or xwiki-platform-sharepage module * XWiki/TemplateProvider*.xml --> xwiki-platform-administration for the moment * XWiki/WebHome.xml --> xwiki-platform-administration module * XWiki/WebPreferences.xml --> xwiki-platform-administration module WDYT? Please try to tell me if you're ok for each line if you have time ;) Thanks -Vincent

9 years, 9 months

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

by Eduard Moraru

Hi devs, Today is BFD#82: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 69 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#82 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13100 Thanks and enjoy your bug fixing day! -Eduard

9 years, 9 months

[xwiki-devs] How can we handle key renaming on l10n

by vincent＠massol.net

Hi devs, Here’s my use case: * Some keys for an XE page are currently located in platform’s ApplicationResources.properties * I’m moving the XE page to platform and I need to: ** Rename the key (since it had "xe" as prefix) ** Move it to a Translations wiki page How can I do this without loosing all the translations that already exist? Thanks -Vincent

9 years, 9 months

[xwiki-devs] [Proposal] Using Less4j by default in XWiki

by Guillaume "Louis-Marie" Delhumeau

Hi developers. I have recently implemented the ability to use LESS in SSX: http://jira.xwiki.org/browse/XWIKI-10708. This feature has pointed me out some bugs, that are reported upstream: https://github.com/less/less.js/issues/1878 https://github.com/less/less.js/issues/1968 I have tried to implement a workaround, but as a result, it is preventing us to use an important feature of LESS: .extend(). And it simply breaks the Caty work on the Menu Application. Moreover, LESS has been rewritten in version 2. But because of this refactoring, the Rhino version does not work. See: https://github.com/less/less.js/issues/2316 So we are stuck with the current version of LESS, with the bugs listed above (that I am not able to patch). But in parallel, I have worked to use LESS4j instead of the official LESS project (http://jira.xwiki.org/browse/XWIKI-11034). And today, I finally managed to make it work! The good news is that LESS4j does not have the bugs that are blocking us. I propose to commit this for 6.4M2 (before tomorrow), and we can still revert it afterwards. Advantages of LESS4j: * should be quicker (see: https://github.com/xwiki-contrib/less-vs-sass-benchmark) * does not have the bugs listed above * we can hope that the version 2 will be ported to LESS4j too. Drawbacks of LESS4j: * maintained by only one developer (but reactive when I report bugs) * not exactly the same behaviour than LESS: https://github.com/SomMeri/less4j/wiki/Differences-Between-Less.js-and-Less… * maybe the error messages are less kindly than lessjs ones. My implementation is configurable: an administrator can decide to use the LESS official version by changing a property in xwiki.properties. I just propose to have LESS4j by default. Here is my +1. Thanks, -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

9 years, 9 months

[xwiki-devs] [VOTE] New Translation property naming rules

by vincent＠massol.net

Hi devs, At the moment the VOTED rule for naming our translation properties is the one defined at http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTransla… Back in 2012 Sergiu started drafting an extended "L10N Conventions” document for best practices around writing translation properties at http://dev.xwiki.org/xwiki/bin/view/Drafts/L10N+Conventions Sergiu sent this a proposal in this mail thread: http://markmail.org/message/ofl23yorvxsqhn4x When Sergiu did this he didn’t realize we already had a VOTED rule for naming our translation properties and his proposal was in conflit with that. However, in this mail thread, several developers mentioned that even though they votes the previous naming rules they didn’t fully like it and preferred the one Sergiu was proposing. Several suggestion for improvements were also proposed. It was suggested in that thread (and Sergiu agreed) that he should resend a VOTE to change those established rules. Apparently he didn’t get the time/will to do it since I couldn’t find such a mail. In addition several developers are apparently not following the current rules (BAD! :)). For example in the xwiki-platform-icon-ui module, the Translations.xml page has the following which is NOT following the current rules: platform.icon.picker.preview=Preview with: platform.icon.picker.loading=Loading And most translation keys found in contrib apps at http://l10n.xwiki.org/xwiki/bin/view/Contrib/WebHome are also not following these rules (although we don’t enforce anything for contrib projects, when they are coded by devs from the XWiki dev team or by known contributors, it would be a good thing to follow the same rule, especially as, in the future, we want to provide a path to move from contrib sandbox to contrib extensions). For example I see the following type of naming: “polls.vote.instructions.single”. Thus, with this email I’d like to try agreeing on a new naming format and conventions. I propose to VOTE for making http://dev.xwiki.org/xwiki/bin/view/Drafts/L10N+Conventions our official practice with the following change for the property naming part: " Keys should have the following format: ##[module]*[.section]*.element[.part]*##, where: * ##module## is the name of the module or application being translated, like ##blog##, ##faq##, ##statistics##… Since a module can have submodules, there can be several module names. For example the SOLR Search UI is located in ##xwiki-platform-search/xwiki-platform-solr/xwiki-platform-solr-ui## and would have keys starting with ##search.solr.##. * zero, one or more ##section## parts that further refine the location of the string being translated; for example, a key starting with ##theme.colors.wizard.## refers to a text located in the //wizard// for the //color// part of the //theme// application (currently there are only color themes, but in the future we might add icon themes, layout themes, and so on), ##macro.python.parameter.## refers to //parameters// of the //python// //macro//, while a key starting with ##userdirectory.## belongs to the main and only section of the //user directory// application * ##element## identifies the main element being translated, but such an element could have several related parts. * ##part## identifies a text related to a main element, such as the ##label## that describes an input, the ##placeholder## found inside that input, the ##tooltip## that appears when hovering that input, the ##hint## that is displayed before the field and provides additional details about what it, the ##error.empty## or ##error.invalidFormat## displayed when there are validation errors, and so on Individual parts of the key should use **camelCase** if more than one word is needed to identify the element. “ Note that I’ve removed the ##product## part from Sergiu’s proposal (the reasoning is here: http://markmail.org/message/ocijlegslw45yedu). In short this makes it simpler to move apps around without breaking the translation keys. Of course it reduces the namespace and increases likelihood of translation clashes with user-provided extensions but I don’t think it’s going to be a problem and user-provided extensions should have a unique app name anyway. I would also point to http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTransla… for the deprecation part. The big question is what to do with existing translations and the only answer I have so far is: * Use the new rules when adding new translation keys (after, and if, it’s voted) * Don’t touch existing keys for now (since that would loose all translations) but implement the following first, and once it’s done, refactor existing translations over time: ** Add support for a deprecation section in Translations.xml’s content, honoured by l10n in the same way that we do it for ApplicationResources.properties ** Add the new key ** Move the old key to the deprecation section (in ApplicationResources.properties or in Translations.xml) ** Make the old key point to the new key, using a special syntax. For example: my.old.deprecated.key = @{new.shiny.key} Here’s my +1 Thanks -Vincent

9 years, 9 months

[xwiki-devs] [Proposal] Location of translation properties

by vincent＠massol.net

Hi Devs, Even though we don’t have listed on http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices I believe the following has already been agreed but I’d like to add it there so I’m sending it as a proposal. So I propose that: * Any java code requiring translation should put them in an ApplicationResources.properties file at the root of the JAR (not the global ApplicationResources.properties in oldcore!) * Any wiki page requiring translations should put them in a Translations page in the space for the app. Special case: * For Macro UI modules (ie containing only wiki macros), we put them in the Macros space and in this case we should use a Macros.XXXTranslations page for each module. We’ll need to decide what we want to do in the future. Also, even if some existing module is wrongly using the ApplicationResources.properties in oldcore (for example), we should still follow the rules above and start doing it in the new way. WDYT? Thanks -Vincent

9 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs March 2015