xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [GSoC] [Reminder] Mid-term evaluation deadline is June 27, 19:00 UTC

by Eduard Moraru

Hi fitz, According to GSoC`s rules, both the student and the mentor need to fill out the period evaluation form. Failure to do so on either side results in the exclusion of the student from the program. More details in the GSoC student's guide [1]. So please make sure that you don`t forget to fill in your evaluation form before the deadline (less than 4 days left)! Thanks, Eduard ---------- [1] http://write.flossmanuals.net/gsocstudentguide/evaluations/

8 years, 6 months

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

by Alexandru Cotiuga

Hi devs, This Thursday is BFD#108: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 129 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#108 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13619 Happy Bug Fixing Day! Thanks, Alex

8 years, 6 months

[xwiki-devs] [VOTE] Deprecated and remove MediaWiki parser from xwiki-rendering

by Thomas Mortagne

Hi devs, I just released as a contrib extension a new MediaWiki parser which covers the old one located on xwiki-rendering (and also fix many issues that were not even listed). The big change is that the actual parser is https://bitbucket.org/axelclk/info.bliki.wiki/wiki/Home and not done by us anymore, we just produce event from the DOM provided by bliki. So I propose to get rid of the old one and retire it in contrib organization. WDYT ? here is my +1 -- Thomas Mortagne PS: OK I already did it and then Vincent reminded me that it would be nice to have a mail about it :)

8 years, 6 months

[xwiki-devs] [VOTE] New Strategy for the XWiki Github Organization

by Vincent Massol

Hi devs, I’m transforming the brainstorming that was started in the thread http://markmail.org/message/exlndbq3tw2thmmu into a VOTE mail since this is a very important decision. So I’m asking you to vote for defining a new direction for the XWiki Core Dev Team (i.e. for the XWiki GitHub Organization). The need was triggered by the Tour and CKEditor extensions which are currently in xwiki-contrib and that we want our users to have by default. For more details see this thread: http://markmail.org/message/exlndbq3tw2thmmu So here’s the strategy: * Make XWiki Github org == minimal runtime, where minimal means “basic wiki” (page edition, history, linking, wiki markup, etc). The notion of “basic wiki” would need to be better defined but this can be done later on. * Provide a "Base Flavor" which corresponds to this “basic wiki”, as part of xwiki-platform (this would be xwiki-platform-distribution). * Provide another flavor, the "Default Flavor” which would add some hand-picked third-party extensions (i.e. from contrib) such as the Tour app and CKEditor (to start with, we could also add the markdown syntax for example which is one of the most asked syntaxes). Note that this Default Flavor would actually be a “replacement" of xwiki-enterprise. * The Default Flavor would have at least the same release cycle as the base flavor but it could have more releases (if some of the bundled third-party extensions has some important bug fixes or new features that we want to offer quickly without waiting for the next base flavor release). * The consequence is that the XWiki Dev Team would need to be a bit more careful to monitor the quality of bundled third-party extensions in contrib (check commits, do some smoke testing, etc). Note that the goal of the Default flavor would not be to offer verticals (for this there should be some contrib flavors) and thus it wouldn’t bundle a lot of third-party extensions. Basically we’ll need to validate the version of those third-party extensions that include in the flavor. My POV is that globally this would offer more flexibility for our users (they’ll be able to install extensions such as CK and Tour in older XWiki versions and they’ll get more frequent releases) at the cost of some overhead to develop extensions that work in several versions. The dev team is pretty small and thus it means developing a bit less fast but it’s probably as important, if not more important, to make the code we develop available in older xwiki versions, as XWiki gains traction. Here’s my +1 Please cast your vote. Thanks -Vincent

8 years, 6 months

[xwiki-devs] [Contrib] Tour Application dependency in XWiki

by Alexandru Cotiuga

Hello all, As it was decided already, a Homepage Tour have to be implemented. However, no option regarding the place where the Tour Application should be added as dependency was discussed. There are some possible options: 1) XWiki Enterprise 2) XWiki Platform Distribution 3) XWiki Platform Helper 4) Is there any option to have the Tour Application as a part of the Core ? What would be the best way to include the Contrib applications in XWiki? Thanks, Alex

8 years, 6 months

[xwiki-devs] [ANN] XWiki 8.2 Milestone 2 released

by Eduard Moraru

The XWiki development team is proud to announce the availability of XWiki 8.2 Milestone 2. This milestone release features a redesigned default homepage, a new application index in the drawer and minor improvements to the template providers, the Flamingo skin and Ratings. For developers, we have some welcomed Livetable macro improvements and a long overdue change of behaviour for the getRenderedContent method. 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/ReleaseNotesXWiki82M2 The following people have contributed code to this release (sorted alphabetically): Alexandru Cotiuga Clemens Robbenhaar Denis Gervalle Ecaterina Moraru (Valica) Eduard Moraru Guillaume Delhumeau Marius Dumitru Florea Pascal Bastien Thomas Mortagne Vincent Massol Thanks for your support -The XWiki dev team

8 years, 6 months

[xwiki-devs] [VOTE] Retire MEETING

by Alexandru Cotiuga

Hi devs, Currently, the Meeting Manager Application [ http://extensions.xwiki.org/xwiki/bin/view/Extension/Meeting+Manager+Applic…] is marked, with a warning, as "This application is superseded by the Meeting Application". The application is written in xwiki/1.0 syntax and is full of deprecated usages which makes it unusable at least since XWiki 6.2. Considering the above reasons I propose to retire the MEETING Jira project. Thanks, Alex

8 years, 6 months

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

by Alexandru Cotiuga

Hi devs, This Thursday is BFD#107: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 124 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#107 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13618 Happy Bug Fixing Day! Thanks, Alex

8 years, 6 months

[xwiki-devs] [UX] Page templates availability

by Ecaterina Moraru (Valica)

Hi, The Template Provider allows setting the locations where the template must be available. Some applications need/encourage their pages to be located in a particular app location. Currently, if we set such a location for a template, the template will be listed in the "Create Page" step only if the user navigates to that location and clicks on the "Add" button. One behavior could be that all templates are displayed each time the user clicks on 'Add', regardless of the initial location. This would mean splitting the current Location functionality into "Template Visibility" and "Creation location restrictions": - Ideally "Template Visibility" should not be restricted, but we would need to keep this field in order to be backward compatible with the current behavior. - "Creation location restrictions" would indicate if the page needs to be created in a particular location. The user will not be allowed to create somewhere else and be warned by an error message. This mail's purpose is to debate: A. If templates should be visible everywhere or just in a particular location? B. Should we recommend applications to restrict the creation of pages to a particular location? Let me know what you think. Thanks, Caty Related: [1] http://jira.xwiki.org/browse/XWIKI-8759 [2] http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepageTe…

8 years, 6 months

[xwiki-devs] [contrib][android-authenticator]About Releasing Android App Automatically and Securely

by fitz

Release Android App Automatically and Securely There are mainly two steps: (1) Generate the signed apk (2) Release to the google play store. Generate the signed apk automatically: 1. (Need Help) Generate keystore file Use Command Line: https://developer.android.com/studio/publish/app-signing.html#signing-manua… keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000 Or use Android studio: https://developer.android.com/studio/publish/app-signing.html#release-mode Maybe we should generate a new, secure and stable private key for the future android development and release. WDYT? 2. (Need Help) Define gradle global values: (Gradle user home: /home/hudsonagent/.gradle in jenkins)(http://stackoverflow.com/questions/18328730/how-to-create-a-releas…) To ensure the security of the keystore, we can’t directly put the key_password, key_alias, store_password values in the github source. So where do we define these values? The gradle global properties may be a good choice. First we should define some global properties for all Gradle builds in the USER_HOME/.gradle/gradle.properties. For the jenkins server, GRADLE_USER_HOME = /home/hudsonagent/.gradle. If no gradle.properties file, just create a new file and add the following properties. # android release key username and password RELEASE_STORE_FILE=F:\\xwiki\\AndroidAuthKey.jks RELEASE_STORE_PASSWORD=android RELEASE_KEY_ALIAS=authenticator RELEASE_KEY_PASSWORD=android I have no right to login and access the jenkins agent-1, so could you help me create the global gradle.properties file in /home/hudsonagent/.gradle and correctly set the four properties. Thanks in advance. :) 3. Add the following code to build.gradle if(project.hasProperty("RELEASE_STORE_FILE")) { signingConfigs { release { storeFile file(RELEASE_STORE_FILE) storePassword RELEASE_STORE_PASSWORD keyAlias RELEASE_KEY_ALIAS keyPassword RELEASE_KEY_PASSWORD } } } buildTypes { if(project.hasProperty("RELEASE_STORE_FILE")) { release { signingConfig signingConfigs.release } } } 4. Gradle clean build -> then we can generate app-release.apk signed by the keystore in jenkins. Release automatically in Google play store: 1. (Need Help) Setup for Google API access: Following this link: https://github.com/codepath/android_guides/wiki/Automating-Publishing-to-th…. Set the google api access and download the p12 key file. But I have no permission to configure API access. It shows in the google play console: <http://xwiki.475771.n2.nabble.com/file/n7599946/api_access.png> So could you help me configure the API access? Or maybe should download the p12 key file. Thank you in advance. :) 2. (Need Help) Jenkins plugin Settings: (1) Install the jenkins plugin "Google Play Android Publisher plugin" (2) Add Credentials and import the p12 key file downloaded during the first step of setting up Google API access. <http://xwiki.475771.n2.nabble.com/file/n7599946/add_credentials.png> 3. Add a post-build step to your existing Jenkins project. <http://xwiki.475771.n2.nabble.com/file/n7599946/post_build.png> That’s all I can think of right now. I have tried and generated the release apk in the jenkins server on my local computer. As I have no permission to configure the google play api, so now I haven’t tried the automated release. I don't know if this method is the best for the automated and secure release of the android open source project, but it should be feasible. What do you think? :) Thanks, Fitz -- View this message in context: http://xwiki.475771.n2.nabble.com/contrib-android-authenticator-About-Relea… Sent from the XWiki- Dev mailing list archive at Nabble.com.

8 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs