xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

Re: [xwiki-devs] [Reminder] BFD#43 (RESULT)

by Vincent Massol

This was a disappointing BFD: http://www.xwiki.org/xwiki/bin/view/Blog/Bug+Fixing+Day+43 Let's make sure the next one is better! Thanks -Vincent On Thu, Nov 7, 2013 at 8:51 AM, Vincent Massol <vincent(a)massol.net> wrote: > Hi devs, > > Today is Bug Fixing Day 43. > > We're currently at -121 bugs for the 1600 days period: > http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 > > Let's reduce this gap... > > Here's the BFD#43 dashboard to follow the progress during the day: > *http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11793 > <http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11793>* > > Thanks > -Vincent >

11 years, 2 months

[xwiki-devs] [Proposal] Release XWiki 5.2.1 tomorrow

by Vincent Massol

Hi devs, I'd like to release XWiki 5.2.1 tomorrow since it contains lots of important regressions... Thanks -Vincent

11 years, 2 months

[xwiki-devs] Regarding editing the breadcrumb in Xwiki

by Prachi Maheshwari

Hey everyone, I want to edit the default breadcrumb for Xwiki. Can anyone please help me with it? I have created apps using app within minutes, but I don't want the breadcrumb showing it. It should directly go from Xwiki to my created app instead. Is there any way of doing it?? Thanks in advance. Prachi -----Original Message----- From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On Behalf Of devs-request(a)xwiki.org Sent: Thursday, November 07, 2013 11:16 AM To: devs(a)xwiki.org Subject: devs Digest, Vol 77, 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: Postpone 5.3M2 by 3 days (Marius Dumitru Florea) 2. Re: Postpone 5.3M2 by 3 days (Vincent Massol) 3. [Proposal] Adding a Contrib top level project in commons (Vincent Massol) 4. Re: [Proposal] Adding a Contrib top level project in commons (Thomas Mortagne) 5. Re: [Proposal] Adding a Contrib top level project in commons (Sergiu Dumitriu) 6. Re: [Proposal] Adding a Contrib top level project in commons (Vincent Massol) 7. Re: [Proposal] Adding a Contrib top level project in commons (Sergiu Dumitriu) ---------------------------------------------------------------------- Message: 1 Date: Thu, 7 Nov 2013 16:40:44 +0200 From: Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> To: XWiki Developers <devs(a)xwiki.org> Subject: Re: [xwiki-devs] Postpone 5.3M2 by 3 days Message-ID: <CALZcbBbSN0h_YzB2Wm4kb3ruvoQzUivxJN8bpzVdH0Sp9FNcCg(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 6, 2013 at 6:53 PM, Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com> wrote: > Hi. > > Vincent and Thomas has started reviewing my work for the new Wiki API. > > Some changes: > - do not store the membershipType in the descriptor, but as a > configuration object in the subwiki. > - having the option Local Users, Global users, Local + Global users > instead of enableLocalUsers(), because we need the 3 uses cases: > - global users only: the workspaces use-case > - local users only: a farm like xwiki cloud, where each wiki should > not know anything about the main wiki > - global + local users: myxwiki.org use case. > > + some changes to do in the UI. > > Because of that, I won't be able to reach the M2 deadline. Moreover, I > can't work until the 12th. So I propose to postpone it. > > 5.3M2: 14th november (was 11) > 5.3RC1: 21th november (was 18) > 5.3 final: 2st decembre (was 25th november). > > WDYT? Both 14th and 21th are Thursday so BFDs. Also, I think there is too much time between RC1 and final. 5.3 M2: 14th November (was 11th) 5.3 RC1: 20th November (was 18th) 5.3 final: 27th November (was 25th). Thanks, Marius > > Thanks, > Louis-Marie > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs ------------------------------ Message: 2 Date: Thu, 7 Nov 2013 15:49:28 +0100 From: Vincent Massol <vincent(a)massol.net> To: XWiki Developers <devs(a)xwiki.org> Subject: Re: [xwiki-devs] Postpone 5.3M2 by 3 days Message-ID: <CAK2AU7tt-gi8-WjqHON+ibUtfvS+AerGEdWkX1pUMxXic1=0qg(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi Guillaume, On Wed, Nov 6, 2013 at 5:53 PM, Guillaume "Louis-Marie" Delhumeau < gdelhumeau(a)xwiki.com> wrote: > Hi. > > Vincent and Thomas has started reviewing my work for the new Wiki API. > > Some changes: > - do not store the membershipType in the descriptor, but as a > configuration object in the subwiki. > - having the option Local Users, Global users, Local + Global users > instead of enableLocalUsers(), because we need the 3 uses cases: > - global users only: the workspaces use-case > - local users only: a farm like xwiki cloud, where each wiki should > not know anything about the main wiki > - global + local users: myxwiki.org use case. > > + some changes to do in the UI. > > Because of that, I won't be able to reach the M2 deadline. Moreover, I > can't work until the 12th. So I propose to postpone it. > > 5.3M2: 14th november (was 11) > 5.3RC1: 21th november (was 18) > 5.3 final: 2st decembre (was 25th november). > > WDYT? > This proposal is not complete since you're proposing to change the final release date (which is always an important change) and thus you're possibly proposing to impact the end of the 5.x cycle (and hence the beginning of the 6.x one). However I still believe that we need to keep an end date of end of December for 5.4 and end of January for 5.5 so that we begin 6.0 at beginning of February 2014 and release it around end of April 2014. Our goal is still to try to catch up so that at the end of 2014 we'll release the last version of 6.x (i.e. 6.5). And thus start the new year one a new cycle. Another possibility is to skip 5.5 for the 5.x cycle and release 5.4 as the last one (barring bug fix releases such as 5.4.1, 5.4.2, etc). I think it's ok to keep 5.4 and 5.5 and to make them short stabilization releases (ie similar to bug fix releases). WDYT? I agree with the dates proposed by Marius which are better IMO. Thanks -Vincent > Thanks, > Louis-Marie > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > ------------------------------ Message: 3 Date: Thu, 7 Nov 2013 16:29:21 +0100 From: Vincent Massol <vincent(a)massol.net> To: XWiki Developers <devs(a)xwiki.org> Subject: [xwiki-devs] [Proposal] Adding a Contrib top level project in commons Message-ID: <CAK2AU7sBdmc67BreJj5UBMVpU4zGWa7SEtdx02Y0FHM2c926rw(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi devs, We need to provide a contrib top level POM for extension contributors. ATM we recommend to extend the commons top level pom on http://contrib.xwiki.orgbut it's a bad idea because contributors forget to override some pom.xml elements (such as the <developers> section) and thus the published extensions end up with wrong information (such as wrong author: "XWiki Development Team"). The reason to put it in commons: * We will have dependencyManagement in it and thus it needs to be in sync with the commons version. It'll have the same version as commons top level pom version. * Easy for us since it'll be released at the same time as commons * Easy for extension authors to choose the top level contrib version they need: they'll pick the one corresponding to the xwiki version they want to depend on Note that since some extensions may want to depend on versions of XWiki older than 5.3 we can deploy this contrib pom also for older versions using mvn deploy:deploy-file WDYT? Thanks -Vincent ------------------------------ Message: 4 Date: Thu, 7 Nov 2013 16:39:14 +0100 From: Thomas Mortagne <thomas.mortagne(a)xwiki.com> To: XWiki Developers <devs(a)xwiki.org> Subject: Re: [xwiki-devs] [Proposal] Adding a Contrib top level project in commons Message-ID: <CAPnKnLERptDa_r2fW90PmY0giYZCTzKjQnjA+SnBmZdZOQoGCQ(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 +1 On Thu, Nov 7, 2013 at 4:29 PM, Vincent Massol <vincent(a)massol.net> wrote: > Hi devs, > > We need to provide a contrib top level POM for extension contributors. > ATM we recommend to extend the commons top level pom on > http://contrib.xwiki.orgbut it's a bad idea because contributors > forget to override some pom.xml elements (such as the <developers> > section) and thus the published extensions end up with wrong > information (such as wrong author: "XWiki Development Team"). > > The reason to put it in commons: > * We will have dependencyManagement in it and thus it needs to be in > sync with the commons version. It'll have the same version as commons > top level pom version. > * Easy for us since it'll be released at the same time as commons > * Easy for extension authors to choose the top level contrib version > they > need: they'll pick the one corresponding to the xwiki version they > want to depend on > > Note that since some extensions may want to depend on versions of > XWiki older than 5.3 we can deploy this contrib pom also for older > versions using mvn deploy:deploy-file > > WDYT? > > Thanks > -Vincent > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ------------------------------ Message: 5 Date: Thu, 07 Nov 2013 10:58:05 -0500 From: Sergiu Dumitriu <sergiu(a)xwiki.com> To: XWiki Developers <devs(a)xwiki.org> Subject: Re: [xwiki-devs] [Proposal] Adding a Contrib top level project in commons Message-ID: <527BB88D.6020303(a)xwiki.com> Content-Type: text/plain; charset=UTF-8 On 11/07/2013 10:29 AM, Vincent Massol wrote: > Hi devs, > > We need to provide a contrib top level POM for extension contributors. ATM > we recommend to extend the commons top level pom on > http://contrib.xwiki.orgbut it's a bad idea because contributors > forget to override some pom.xml > elements (such as the <developers> section) and thus the published > extensions end up with wrong information (such as wrong author: "XWiki > Development Team"). > > The reason to put it in commons: > * We will have dependencyManagement in it and thus it needs to be in sync > with the commons version. It'll have the same version as commons top level > pom version. > * Easy for us since it'll be released at the same time as commons > * Easy for extension authors to choose the top level contrib version they > need: they'll pick the one corresponding to the xwiki version they want to > depend on > > Note that since some extensions may want to depend on versions of XWiki > older than 5.3 we can deploy this contrib pom also for older versions using > mvn deploy:deploy-file > > WDYT? +1. Will this be a copy of xwiki-commons-pom, or an extension that overrides a few sections? Should it include the license check plugin, which currently enforces LGPL2.1? Should we make it easier to change the license being enforced? What do we put instead of the <developers>? Do we make it a generic "XWiki community", or leave it empty so that others can fill it in? We can use the enforcer's requireProperty rule to check that mandatory sections have been filled in. I'd like to have a single xwiki.version property instead of the current commons, rendering, platform.version, so that people don't have to think which one should they use for each module. Instead of deploy-file, why not actually release older versions? Since it's a separate repository, we can do that, we don't have to sync releases with the official XWiki releases. -- Sergiu Dumitriu http://purl.org/net/sergiu ------------------------------ Message: 6 Date: Thu, 7 Nov 2013 17:10:39 +0100 From: Vincent Massol <vincent(a)massol.net> To: XWiki Developers <devs(a)xwiki.org> Subject: Re: [xwiki-devs] [Proposal] Adding a Contrib top level project in commons Message-ID: <CAK2AU7uWBL9UQRhQbqqPS7dDpxkasQAx1vHrPgLm0fuOA+ZQ+A(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 7, 2013 at 4:58 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > On 11/07/2013 10:29 AM, Vincent Massol wrote: > > Hi devs, > > > > We need to provide a contrib top level POM for extension contributors. > ATM > > we recommend to extend the commons top level pom on > > http://contrib.xwiki.orgbut it's a bad idea because contributors > > forget to override some pom.xml > > elements (such as the <developers> section) and thus the published > > extensions end up with wrong information (such as wrong author: "XWiki > > Development Team"). > > > > The reason to put it in commons: > > * We will have dependencyManagement in it and thus it needs to be in sync > > with the commons version. It'll have the same version as commons top > level > > pom version. > > * Easy for us since it'll be released at the same time as commons > > * Easy for extension authors to choose the top level contrib version they > > need: they'll pick the one corresponding to the xwiki version they want > to > > depend on > > > > Note that since some extensions may want to depend on versions of XWiki > > older than 5.3 we can deploy this contrib pom also for older versions > using > > mvn deploy:deploy-file > > > > WDYT? > > +1. > > Will this be a copy of xwiki-commons-pom, or an extension that overrides > a few sections? > > Should it include the license check plugin, which currently enforces > LGPL2.1? Should we make it easier to change the license being enforced? > > What do we put instead of the <developers>? Do we make it a generic > "XWiki community", or leave it empty so that others can fill it in? We > can use the enforcer's requireProperty rule to check that mandatory > sections have been filled in. > See a first version at https://github.com/xwiki-contrib/contrib-pom/blob/master/pom.xml > I'd like to have a single xwiki.version property instead of the current > commons, rendering, platform.version, so that people don't have to think > which one should they use for each module. > I think that's orthogonal to this discussion. > Instead of deploy-file, why not actually release older versions? Since > it's a separate repository, we can do that, we don't have to sync > releases with the official XWiki releases. > It's not a separate repository, that's the point ;) I explained above why I think it's good to have it in xwiki-commons ;) Thanks -Vincent > -- > Sergiu Dumitriu > http://purl.org/net/sergiu > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > ------------------------------ Message: 7 Date: Thu, 07 Nov 2013 11:16:25 -0500 From: Sergiu Dumitriu <sergiu(a)xwiki.com> To: XWiki Developers <devs(a)xwiki.org> Subject: Re: [xwiki-devs] [Proposal] Adding a Contrib top level project in commons Message-ID: <527BBCD9.7030808(a)xwiki.com> Content-Type: text/plain; charset=UTF-8 On 11/07/2013 11:10 AM, Vincent Massol wrote: > On Thu, Nov 7, 2013 at 4:58 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > >> On 11/07/2013 10:29 AM, Vincent Massol wrote: >>> Hi devs, >>> >>> We need to provide a contrib top level POM for extension contributors. >> ATM >>> we recommend to extend the commons top level pom on >>> http://contrib.xwiki.orgbut it's a bad idea because contributors >>> forget to override some pom.xml >>> elements (such as the <developers> section) and thus the published >>> extensions end up with wrong information (such as wrong author: "XWiki >>> Development Team"). >>> >>> The reason to put it in commons: >>> * We will have dependencyManagement in it and thus it needs to be in sync >>> with the commons version. It'll have the same version as commons top >> level >>> pom version. >>> * Easy for us since it'll be released at the same time as commons >>> * Easy for extension authors to choose the top level contrib version they >>> need: they'll pick the one corresponding to the xwiki version they want >> to >>> depend on >>> >>> Note that since some extensions may want to depend on versions of XWiki >>> older than 5.3 we can deploy this contrib pom also for older versions >> using >>> mvn deploy:deploy-file >>> >>> WDYT? >> >> +1. >> >> Will this be a copy of xwiki-commons-pom, or an extension that overrides >> a few sections? >> >> Should it include the license check plugin, which currently enforces >> LGPL2.1? Should we make it easier to change the license being enforced? >> >> What do we put instead of the <developers>? Do we make it a generic >> "XWiki community", or leave it empty so that others can fill it in? We >> can use the enforcer's requireProperty rule to check that mandatory >> sections have been filled in. >> > > See a first version at > https://github.com/xwiki-contrib/contrib-pom/blob/master/pom.xml > > >> I'd like to have a single xwiki.version property instead of the current >> commons, rendering, platform.version, so that people don't have to think >> which one should they use for each module. >> > > I think that's orthogonal to this discussion. > > >> Instead of deploy-file, why not actually release older versions? Since >> it's a separate repository, we can do that, we don't have to sync >> releases with the official XWiki releases. >> > > It's not a separate repository, that's the point ;) I explained above why I > think it's good to have it in xwiki-commons ;) > Ah, right, somehow I missed that part. -- Sergiu Dumitriu http://purl.org/net/sergiu ------------------------------ _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs End of devs Digest, Vol 77, Issue 12 ************************************

11 years, 2 months

[xwiki-devs] [Reminder] BFD#43

by Vincent Massol

Hi devs, Today is Bug Fixing Day 43. We're currently at -121 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Let's reduce this gap... Here's the BFD#43 dashboard to follow the progress during the day: *http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11793 <http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11793>* Thanks -Vincent

11 years, 2 months

[xwiki-devs] [Proposal] Wiki API

by Guillaume "Louis-Marie" Delhumeau

Hi. In this thread, I want to propose you the tiniest API that we need to handle multiwiki. All other features (users, templates, workspaces...) will be on other modules, because I think it is better for the extensibility. The new module will be based on the xwiki-platform-wiki-descriptor-api module, that I will rename to xwiki-platform-wiki-api. The WikiDescriptorManager becomes WikiManager and handle both descriptors and databases. This API will permit: * to create a wiki * to remove a wiki * to list all wikis (returning a list of descriptors) * ... You can see the code of that proposal there: https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo… The most important is to decide what the API must look like. The implementation can still be modified afterwards. I hope you like it, Louis-Marie

11 years, 2 months

[xwiki-devs] anybody attending Horizon 2020/Digital Agenda for Europe ICT 2013 Conference, Vilnius, 6-8 November 2013?

by Ricardo.Julio.Rodriguez.Fernandez＠sergas.es

It would be great to meet XWiki guys/gals there! Cheers! Ricardo -- Ricardo Rodríguez Research Management and Promotion Technician Technical Secretariat Health Research Institute of Santiago de Compostela (IDIS) http://www.idisantiago.es Nota: A información contida nesta mensaxe e os seus posibles documentos adxuntos é privada e confidencial e está dirixida únicamente ó seu destinatario/a. Se vostede non é o/a destinatario/a orixinal desta mensaxe, por favor elimínea. A distribución ou copia desta mensaxe non está autorizada. Nota: La información contenida en este mensaje y sus posibles documentos adjuntos es privada y confidencial y está dirigida únicamente a su destinatario/a. Si usted no es el/la destinatario/a original de este mensaje, por favor elimínelo. La distribución o copia de este mensaje no está autorizada. See more languages: http://www.sergas.es/aviso_confidencialidad.htm

11 years, 2 months

[xwiki-devs] Proposal to push wiki-nodes, the XWiki/Cassandra demonstration over to contrib.

by Caleb James DeLisle

Hi guys, It's been a while since this demo was created but I was looking at my github and it has not been touched so I would like to document it and put it in contrib where it's available. I have a question about technique, this demo builds on the standard version of xwiki-platform but requires a special version of xwiki-enterprise. Is it ok to have a long term branch in the xwiki-enterprise repository or should the entire repository be copied into contrib? WDYT? Caleb

11 years, 2 months

[xwiki-devs] Proposal to move REPL Console Application to xwiki-contrib.

by Caleb James DeLisle

Hi guys, I'd like to move the REPL Console Application http://extensions.xwiki.org/xwiki/bin/view/Extension/REPL+Console+Applicati… from my github account here: https://github.com/cjdelisle/xwiki-contrib-repl To the xwiki-contrib account because I'm not actively working on it and if anyone else feels like adding features or changing it, it's better that they take the lead. WDYT? Caleb

11 years, 2 months

[xwiki-devs] Invitation to connect on LinkedIn

by Flavius Olaru

LinkedIn ------------ XWiki, I'd like to add you to my professional network on LinkedIn. - Flavius Flavius Olaru Web Developer at XWiki Iasi County, Romania Confirm that you know Flavius Olaru: https://www.linkedin.com/e/3vasf0-hnlpn2rt-1m/isd/17783891139/ziS3Akov/?hs=… -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/3vasf0-hnlpn2rt-1m/9s_c-0fN05p6qjQq9meQgfVB/goo/d… (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

11 years, 2 months

[xwiki-devs] [Proposal] Crypto API - Expose Bouncy Castle, JCA or not ?

by Denis Gervalle

Hi devs, In the process of preparing signed scripts and other security improvements, I am currently refactoring the crypto API that suffer from being available during the early days of the component manager. Our objective has also changed, and some part will be deprecated in favor of a new more evolve API. In that process, I am wondering which kind of object we allow to go through our API, and I see 3 possibilities: 1) Do not use any object from either Bouncy Castle (BC), nor Java Cryptography API (JCA), and build our own, like BC does. This is obviously the most decouple solution, but it will increase the conversion between APIs. User that may also use BC or JCA on their own will also have to convert their native objects to our own, to use our API. 2) Use the JCA objects only in addition to our own. The JCA has not evolved since a while, and is therefore really stable. This seems to me a better alternative. BC provide support to use those objects, so the conversion to BC is easy. However, these objects are not as friendly as those of BC, so we may need to provide some equivalent helpers existing in BC. 3) Link us more closely with BC, and use the best alternative depending on the situation, either BC, JCA, or our own. This is more easy for us, and better for users of BC outside of our API. This will avoid having to duplicate some BC functionality that are already user friendly enough on our side, therefore limiting maintenance work as well. I am more in favor of 2) or 3), not because I am lazy, but since the initial API already use 2) and I prefer not to duplicate existing features in BC which looks to me a de-facto standard for cryptography in the open-source world. WDYT ? -- Denis Gervalle SOFTEC sa - CEO

11 years, 2 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