Re: [xwiki-devs] [XWiki Day] BFD#144

[Alexandru Cotiuga]

Hello,

The results of this week's BFD are available at
http://www.xwiki.org/xwiki/bin/view/Blog/Bug%20Fixing%20Day%20144.

Thanks to all participants!

Alex

On Thu, Jun 8, 2017 at 11:49 AM, Vincent Massol  wrote:

> Hello devs,
>
> Today is BFD#144:
> http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays
>
> Our current status is:
>
> * -49 bugs over 120 days (2 months), i.e. we need to close 49 bugs to have
> created bugs # = closed bugs #
> * -5 bugs over 365 days (1 year).
> * -51 bugs over 500 days (between 1 and 2 years)
> * +13 bugs over 1600 days (4.3 years)
> * -633 bugs since the beginning of XWiki
>
> See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
>
> It would be great if today we could at least fix 5 bugs to be even on the
> 365 day period. But more generally we’ve accumulating some lag recently
> with -49 bugs over 120 days. So we need to start catching up a bit.
>
>
> Here's the BFD#143 dashboard to follow the progress during the day:
> https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13896
>
> Happy BugFixing Day,
> -Vincent

Re: [xwiki-devs] [GSoC] More extension repositories [Bintray / Artifactory]

[Thomas Mortagne]

On Fri, Jun 9, 2017 at 6:08 PM, Krzysiek Płachno
 wrote:
> Bintray JCenter may be connected even today using Maven Connector.
>
> Maven Connector does not allow for searching, but in the case of JCenter
> that stores in the vast major non-xwiki extensions searching is
> unnecessary.

I don't think you understood the main goal of this project. The point
is not to install XWiki stuff, Extension Manager can install any JARs
and JCenter is full of useful JARs.

Keep in mind that you can use any JAR you installed in scripts macros
like Groovy.

> What's more - as I described on design page - bintray
> searching api allows only for searching matching search pattern with custom
> 'name' and 'description' given when uploading package - (see screenshot:
> https://image.ibb.co/m8wJqv/bintray.png)

Everything on https://bintray.com/bintray/jcenter seems to have name
and description and according to your screenshot the name is mandatory
so this looks good enough to me.

>
> So the real advantage for XWiki will be integration with Artifactory.

I don't know any public reference instance of Artifactory used by many
open source projects to release artifacts like Bintray JCenter is. So
no, supporting Artifactory add far less value for me.

>
> Of course I can still prepare extension resolving artifacts and versions of
> packages from Bintray via it's rest api, leaving space for future feature
> of searching when Bintray's API will be richer. The question is what's more
> usefull or needed.

If it does not support search then it's useless.

>
> Best,
> Krzysztof
>
> 2017-06-09 15:23 GMT+02:00 Thomas Mortagne :
>
>> Very surprising, I really tough Bintray was a cloud of Artifactory
>> instances...
>>
>> Since the main use case is to support Bintray jcenter I think you
>> should concentrate on Bintray APi support only and skip Artifactory
>> for now.
>>
>> On Fri, Jun 9, 2017 at 3:12 PM, Krzysiek Płachno
>>  wrote:
>> > I've investigater Artifactory and Bintray APIs. They are totally
>> different.
>> >
>> > I updated desing page:
>> > http://design.xwiki.org/xwiki/bin/view/Proposal/
>> MoreextensionrepositoriesArtifactoryBintray
>> >
>> > 2017-06-08 11:35 GMT+02:00 Krzysiek Płachno :
>> >
>> >> Ok - I got it (I confused in my mind ExtensionRepositorySource
>> >> with ExtensionRepository)
>> >>
>> >> I'll compare in detail the apis of Artifactory and Bintray - if they're
>> >> (almost) the same - it makes sense to do it as you described.
>> >>
>> >> KP
>> >>
>> >> 2017-06-08 11:26 GMT+02:00 Thomas Mortagne :
>> >>
>> >>> On Thu, Jun 8, 2017 at 11:05 AM, Krzysiek Płachno
>> >>>  wrote:
>> >>> > Ok - then.
>> >>> >
>> >>> > So:
>> >>>
>> >>> > 1. Do I understand well that the advantage of Rest connection over
>> >>> native
>> >>> > Maven connection is that when using maven we cannot search repo?
>> >>>
>> >>> Yes you don't have live search in standard Maven repository. In some
>> >>> repository you can download an index but that's all.
>> >>>
>> >>> > 2. The goal would be to produce an extension with two components
>> >>> > ExtensionRepositoryFactory:  'bintray' and 'artifactory' which
>> sharing
>> >>> the
>> >>> > same logic will allow to connect Bintray and Artifactory? Or just
>> >>> > one ExtensionRepositoryFactory with name 'artifactory' to be used
>> also
>> >>> for
>> >>> > both? This naming is a bit important since in xwiki.properties whilst
>> >>> > giving url to external repo user also gives type of repo. (As
>> >>> > regards ExtensionRepositorySource components - they are completely
>> >>> hidden
>> >>> > so it may be one for both Artifactory and Bintray)
>> >>>
>> >>> If Bintray use Artifactory REST API then there should be only one
>> >>> 'artifactory' ExtensionRepositoryFactory.
>> >>>
>> >>> ExtensionRepositorySource point is to provide default repository (for
>> >>> example extensions.xwiki.org or nexus.xwiki.org) so it only make sense
>> >>> for Bintray jcenter (unless jcenter does not expose REST API). I
>> >>> totally skipped the fact that anyone was able to create a Bintray
>> >>> instance and I was actually only thinking about jcenter.
>> >>>
>> >>> >
>> >>> > KP
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > 2017-06-07 10:12 GMT+02:00 Thomas Mortagne <
>> thomas.morta...@xwiki.com>:
>> >>> >
>> >>> >> Some comments:
>> >>> >>
>> >>> >> The difference between Artifactory and Bintray you are describing
>> >>> >> don't really matter for your use case IMO.
>> >>> >>
>> >>> >> The only thing you should deal with are:
>> >>> >>
>> >>> >> * downloading artifacts
>> >>> >> * searching for artifacts (that is actually the only feature brought
>> >>> >> by this extension since as you said you can download artifacts
>> through
>> >>> >> Maven access)
>> >>> >>
>> >>> >> and AFAIK those two features have the same API in both cases since
>> >>> >> Bintray is 

Re: [xwiki-devs] JIRA, JQL and Release Notes

[Vincent Massol]

Hi again,

See below

> On 9 Jun 2017, at 17:56, Vincent Massol  wrote:
> 
> Hi devs,
> 
> Almost all our filters on jira.xwiki.org were wrong (all bugs for xwiki 
> committers, all issues for xwiki committers, etc) because they were only 
> filtering on the “top level” category (id = 1) and thus were forgetting 
> the contrib extensions that we bundled in XE.
> 
> Thus I’ve renamed the "top level projects” category into “XWiki Enterprise” 
> (and soon we’ll rename it with the name of the flavor replacing it). I’ve 
> also moved the conrib extensions that we bundled into that category. See 
> https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=1
> 
> As a consequence this fixed 
> https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 for example, 
> which is now correct.
> 
> However this leads to a problem: All JQL we wrote that were using things like 
> “category in (“Top Level Projects”)” instead of “category = 1” are now 
> broken. For example we use this in our Relaese  Notes for bug fix releases. 
> I’ve fixed all of them using the Release Application but not old ones yet.
> 
> Also, in our RN for bug fix releases we need to specify all projects one by 
> one along with versions. Writing the following (as can be seen in 
> http://www.xwiki.org/xwiki/bin/edit/ReleaseNotes/Data/XWiki/9.3.1/WebHome?editor=wiki)
>  is wrong for example: 
> 
> category = 1 AND fixVersion in ("9.3.1") AND resolution in (Fixed) and 
> component not in ("Development Issues only”)
> 
> FTR in the RN for 8.4.2 I wrote:
> 
> category = 1 and fixVersion = "8.4.2" and resolution = Fixed and 
> component != "Development Issues only" OR project = "CKEditor Integration" 
> and fixVersion = "1.10" and resolution = Fixed OR project = "Tour 
> Application" and fixVersion = "1.1" and resolution = Fixed
> 
> But even that is not correct anymore and we now need to write instead:
> 
> project IN ("XCOMMONS", "XRENDERING", "XWIKI", "XE") AND fixVersion = "8.4.2" 
> AND resolution = Fixed and component != "Development Issues only" OR project 
> = "CKEDITOR" AND fixVersion = "1.10" AND resolution = Fixed OR project = 
> "TOUR" AND fixVersion = "1.1" AND resolution = Fixed
> 
> So we need to review:
> * The filters and dashboard in jira.xwiki.org and fix them (for example GD, 
> in the RN for 9.4 we point to 
> https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13894 which is 
> broken now since its filter uses “Top Level Projects” but I can’t fix it 
> since I don’t own it in jira…)
> * The JQL statements used in xwiki.org and especially in the RNs. We should 
> probably create some scripts/tools to help us write those JQL.
> 
> Any comment? Any other idea?

Actually I have a better idea:

* We should use the RN Application for all our releases and thus including the 
extensions bundled in XE too (Tour, Templates, Help Center, CK)
* We should introduce the notion of Release Dependencies in the RN Application 
(see https://jira.xwiki.org/browse/RN-33)
* Find ways to use the {{releasenotechanges/}} macro even for bugfix releases. 
Maybe by introducing a different type of “Change” which would contain the jira 
list (and we would add a new “Other” in addition to “user”, “admins” and “devs” 
for a change target).

WDYT?

Thanks
-Vincent

> Thanks
> -Vincent
> 

Re: [xwiki-devs] [GSoC] More extension repositories [Bintray / Artifactory]

[Krzysiek Płachno]

Bintray JCenter may be connected even today using Maven Connector.

Maven Connector does not allow for searching, but in the case of JCenter
that stores in the vast major non-xwiki extensions searching is
unnecessary. What's more - as I described on design page - bintray
searching api allows only for searching matching search pattern with custom
'name' and 'description' given when uploading package - (see screenshot:
https://image.ibb.co/m8wJqv/bintray.png)

So the real advantage for XWiki will be integration with Artifactory.

Of course I can still prepare extension resolving artifacts and versions of
packages from Bintray via it's rest api, leaving space for future feature
of searching when Bintray's API will be richer. The question is what's more
usefull or needed.

Best,
Krzysztof

2017-06-09 15:23 GMT+02:00 Thomas Mortagne :

> Very surprising, I really tough Bintray was a cloud of Artifactory
> instances...
>
> Since the main use case is to support Bintray jcenter I think you
> should concentrate on Bintray APi support only and skip Artifactory
> for now.
>
> On Fri, Jun 9, 2017 at 3:12 PM, Krzysiek Płachno
>  wrote:
> > I've investigater Artifactory and Bintray APIs. They are totally
> different.
> >
> > I updated desing page:
> > http://design.xwiki.org/xwiki/bin/view/Proposal/
> MoreextensionrepositoriesArtifactoryBintray
> >
> > 2017-06-08 11:35 GMT+02:00 Krzysiek Płachno :
> >
> >> Ok - I got it (I confused in my mind ExtensionRepositorySource
> >> with ExtensionRepository)
> >>
> >> I'll compare in detail the apis of Artifactory and Bintray - if they're
> >> (almost) the same - it makes sense to do it as you described.
> >>
> >> KP
> >>
> >> 2017-06-08 11:26 GMT+02:00 Thomas Mortagne :
> >>
> >>> On Thu, Jun 8, 2017 at 11:05 AM, Krzysiek Płachno
> >>>  wrote:
> >>> > Ok - then.
> >>> >
> >>> > So:
> >>>
> >>> > 1. Do I understand well that the advantage of Rest connection over
> >>> native
> >>> > Maven connection is that when using maven we cannot search repo?
> >>>
> >>> Yes you don't have live search in standard Maven repository. In some
> >>> repository you can download an index but that's all.
> >>>
> >>> > 2. The goal would be to produce an extension with two components
> >>> > ExtensionRepositoryFactory:  'bintray' and 'artifactory' which
> sharing
> >>> the
> >>> > same logic will allow to connect Bintray and Artifactory? Or just
> >>> > one ExtensionRepositoryFactory with name 'artifactory' to be used
> also
> >>> for
> >>> > both? This naming is a bit important since in xwiki.properties whilst
> >>> > giving url to external repo user also gives type of repo. (As
> >>> > regards ExtensionRepositorySource components - they are completely
> >>> hidden
> >>> > so it may be one for both Artifactory and Bintray)
> >>>
> >>> If Bintray use Artifactory REST API then there should be only one
> >>> 'artifactory' ExtensionRepositoryFactory.
> >>>
> >>> ExtensionRepositorySource point is to provide default repository (for
> >>> example extensions.xwiki.org or nexus.xwiki.org) so it only make sense
> >>> for Bintray jcenter (unless jcenter does not expose REST API). I
> >>> totally skipped the fact that anyone was able to create a Bintray
> >>> instance and I was actually only thinking about jcenter.
> >>>
> >>> >
> >>> > KP
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > 2017-06-07 10:12 GMT+02:00 Thomas Mortagne <
> thomas.morta...@xwiki.com>:
> >>> >
> >>> >> Some comments:
> >>> >>
> >>> >> The difference between Artifactory and Bintray you are describing
> >>> >> don't really matter for your use case IMO.
> >>> >>
> >>> >> The only thing you should deal with are:
> >>> >>
> >>> >> * downloading artifacts
> >>> >> * searching for artifacts (that is actually the only feature brought
> >>> >> by this extension since as you said you can download artifacts
> through
> >>> >> Maven access)
> >>> >>
> >>> >> and AFAIK those two features have the same API in both cases since
> >>> >> Bintray is essentially a public Artifactory instance.
> >>> >>
> >>> >> So unless I really missing something here you should IMO work on two
> >>> >> extensions (on just two component in the same extension):
> >>> >> * an ExtensionRepositoryFactory for Artifactory
> >>> >> * a ExtensionRepositorySource which automatically register Bintray
> >>> >> with the type "artifactory"
> >>> >>
> >>> >> On Mon, Jun 5, 2017 at 12:05 PM, Krzysiek Płachno
> >>> >>  wrote:
> >>> >> > Hey!
> >>> >> >
> >>> >> > I investigated a bit Binatray and Artifactory and uploaded
> relatively
> >>> >> short
> >>> >> > raport:
> >>> >> > http://design.xwiki.org/xwiki/bin/view/Proposal/
> >>> >> MoreextensionrepositoriesArtifactoryBintray
> >>> >> >
> >>> >> > Any comments, ideas, relfections - highly appreciated.
> >>> >> >
> >>> >> >
> >>> >> > Best,
> >>> >> > Krzysztof Płachno
> >>> >>
> >>> 

[xwiki-devs] JIRA, JQL and Release Notes

[Vincent Massol]

Hi devs,

Almost all our filters on jira.xwiki.org were wrong (all bugs for xwiki 
committers, all issues for xwiki committers, etc) because they were only 
filtering on the “top level” category (id = 1) and thus were forgetting the 
contrib extensions that we bundled in XE.

Thus I’ve renamed the "top level projects” category into “XWiki Enterprise” 
(and soon we’ll rename it with the name of the flavor replacing it). I’ve also 
moved the conrib extensions that we bundled into that category. See 
https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=1

As a consequence this fixed 
https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 for example, 
which is now correct.

However this leads to a problem: All JQL we wrote that were using things like 
“category in (“Top Level Projects”)” instead of “category = 1” are now 
broken. For example we use this in our Relaese  Notes for bug fix releases. 
I’ve fixed all of them using the Release Application but not old ones yet.

Also, in our RN for bug fix releases we need to specify all projects one by one 
along with versions. Writing the following (as can be seen in 
http://www.xwiki.org/xwiki/bin/edit/ReleaseNotes/Data/XWiki/9.3.1/WebHome?editor=wiki)
 is wrong for example: 

category = 1 AND fixVersion in ("9.3.1") AND resolution in (Fixed) and 
component not in ("Development Issues only”)

FTR in the RN for 8.4.2 I wrote:

category = 1 and fixVersion = "8.4.2" and resolution = Fixed and component 
!= "Development Issues only" OR project = "CKEditor Integration" and fixVersion 
= "1.10" and resolution = Fixed OR project = "Tour Application" and fixVersion 
= "1.1" and resolution = Fixed

But even that is not correct anymore and we now need to write instead:

project IN ("XCOMMONS", "XRENDERING", "XWIKI", "XE") AND fixVersion = "8.4.2" 
AND resolution = Fixed and component != "Development Issues only" OR project = 
"CKEDITOR" AND fixVersion = "1.10" AND resolution = Fixed OR project = "TOUR" 
AND fixVersion = "1.1" AND resolution = Fixed

So we need to review:
* The filters and dashboard in jira.xwiki.org and fix them (for example GD, in 
the RN for 9.4 we point to 
https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13894 which is broken 
now since its filter uses “Top Level Projects” but I can’t fix it since I don’t 
own it in jira…)
* The JQL statements used in xwiki.org and especially in the RNs. We should 
probably create some scripts/tools to help us write those JQL.

Any comment? Any other idea?

Thanks
-Vincent

Re: [xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?

[Thomas Mortagne]

So here is the current situation

= Proposition which don't annoy people enough to get a veto

* "Default XWiki Flavor" (+3)
* "Standard XWiki Flavor" (+2)

= Someone gave a veto on those

* "Base XWiki Flavor"
* "Classic XWiki Flavor" (good success for this one until it hits Edy
and Vincent)
* "Raw XWiki Flavor"
* "Starter XWiki Flavor"
* "XWiki Flavor”
* "Generic XWiki Flavor"

Anyone want to change his votes ?

I don't really have a preference between "Default" and "Standard".

On Fri, Jun 9, 2017 at 4:18 PM, Vincent Massol  wrote:
> So I’ve read this thread and here’s my POV:
>
> * "Base XWiki Flavor” -1 (same reason as Thomas)
> * “Classic XWiki Flavor” -1 (same reason as Edy, it means there’s a non 
> classic and *better* one and we don’t have one so it doesn’t make sense)
> * “Raw XWiki Flavor” -1 (not enough meaning IMO and a bit deprecatory)
> * “Starter XWiki Flavor” -1 (would mean there’s another flavor which isn’t 
> the case)
> * "Default XWiki Flavor” +1
> * "Generic XWiki Flavor” +1
> * “Standard XWiki Flavor” +1 (makes the most sense IMO)
> * "XWiki Flavor”. Here it’s hard to understand that “XWiki” actually means 
> “developed by the XWiki project” and it would work only if other flavors 
> don’t have “XWiki” in the name. This is why I’m -1 ATM for it. IMO it’s not 
> easy enough to differentiate and understand what it means compared to other 
> listed flavors such “Procedure Flavor” from XWiki SAS or “Demo Flavor” from 
> contrib.
>
> Thanks
> -Vincent
>
>> On 24 May 2017, at 11:51, Thomas Mortagne  wrote:
>>
>> Hi devs,
>>
>> I'm getting closer to finish with the hard work around new platform
>> flavor which is going to replace XE.
>>
>> Need to decide what user will see in the Flavor picker when installed XWiki 
>> now.
>>
>> As a reminder we decided that this would be a generic flavor, not tied
>> to any specific use case (so forget about "Knwonledge Base Flavor"
>> :)).
>>
>> Here is a few ideas gathered in previous mails:
>> * "XWiki Flavor"
>> * "Default XWiki Flavor"
>> * "Generic XWiki Flavor"
>> * "Base XWiki Flavor"
>>
>> "Generic" is probably a way too technical term.
>>
>> "Base" would be misleading IMO since it's not really a base flavor.
>> Its primary goal is not to be used as a dependency (of course it's
>> fine to have it as dependency if you just want to add pre installed
>> extensions to the default flavor). It's a -1 for me.
>>
>> Frankly I would simply go for "XWiki Flavor". I know, it's not going
>> to be the only flavor for XWiki but it's obvious when you actually see
>> severals of those in the picker anyway and I find it nicer than
>> "Default XWiki Flavor" which basically means the same thing since the
>> XWiki core project does not plan to provide any other flavor. I'm also
>> fine with "Default XWiki Favor" if others think it's a better name.
>>
>> WDYT ?
>>
>> --
>> Thomas Mortagne
>



-- 
Thomas Mortagne

Re: [xwiki-devs] [PROPOSAL] Rename downloadable packages while releasing them

[Eduard Moraru]

On Fri, Jun 9, 2017 at 4:53 PM, Thomas Mortagne 
wrote:

> My only fear is that naming it "xwiki-9.5.zip" might make it look like
> the recommended package while it's quite the opposite in practice.
>

Just putting it out there:
* "xwiki-local-9.5.zip"
* "xwiki-server-9.5.war" / "xwiki-hosted-9.5.war"

Though I`m not sure we really need to go into these details, since the file
extension says enough IMO and the download page will clarify this as well.

Not to mention that an admin should know already the difference and that
we`re not really addressing end-users nor even XWiki admin users here, but
more sysadmins. Desktop users will surely go for the zip, and that`s our
goal anyway.

I`d keep it simple (i.e. "xwiki-9.5.zip").

Thanks,
Eduard


> On Fri, Jun 9, 2017 at 3:50 PM, Marius Dumitru Florea
>  wrote:
> > +1. I prefer xwiki-9.5.zip
> >
> > Thanks,
> > Marius
> >
> > On Fri, Jun 9, 2017 at 1:25 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > wrote:
> >
> >> Hi xwikiers,
> >>
> >> Eduard hard the idea of dynamically rename the files names of the
> >> packages we publish on http://www.xwiki.org/xwiki/bin/view/Download/
> >> page and use the refactoring to move XE features to a new platform
> >> flavor as a good opportunity for this change.
> >>
> >> In more details the proposal is the following:
> >> * name "xwiki-demo-9.5.zip" or "xwiki-9.5.zip" the standard
> >> jetty/hsqldb package (the one which let you choose the flavor you want
> >> to install)
> >> * name "xwiki-9.5.war" the standard war package
> >> * name "xwiki-classic-9.5.xip" the offline package containing XWiki
> >> Classic flavor
> >>
> >> WDYT ? Other ideas ?
> >>
> >> +1 with a preference for "xwiki-demo-9.5.zip" over "xwiki-9.5.zip" to
> >> make it more clear it's not a production oriented package.
> >>
> >> --
> >> Thomas Mortagne
> >>
>
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?

[Vincent Massol]

So I’ve read this thread and here’s my POV:

* "Base XWiki Flavor” -1 (same reason as Thomas)
* “Classic XWiki Flavor” -1 (same reason as Edy, it means there’s a non classic 
and *better* one and we don’t have one so it doesn’t make sense)
* “Raw XWiki Flavor” -1 (not enough meaning IMO and a bit deprecatory)
* “Starter XWiki Flavor” -1 (would mean there’s another flavor which isn’t the 
case)
* "Default XWiki Flavor” +1
* "Generic XWiki Flavor” +1
* “Standard XWiki Flavor” +1 (makes the most sense IMO)
* "XWiki Flavor”. Here it’s hard to understand that “XWiki” actually means 
“developed by the XWiki project” and it would work only if other flavors don’t 
have “XWiki” in the name. This is why I’m -1 ATM for it. IMO it’s not easy 
enough to differentiate and understand what it means compared to other listed 
flavors such “Procedure Flavor” from XWiki SAS or “Demo Flavor” from contrib.

Thanks
-Vincent

> On 24 May 2017, at 11:51, Thomas Mortagne  wrote:
> 
> Hi devs,
> 
> I'm getting closer to finish with the hard work around new platform
> flavor which is going to replace XE.
> 
> Need to decide what user will see in the Flavor picker when installed XWiki 
> now.
> 
> As a reminder we decided that this would be a generic flavor, not tied
> to any specific use case (so forget about "Knwonledge Base Flavor"
> :)).
> 
> Here is a few ideas gathered in previous mails:
> * "XWiki Flavor"
> * "Default XWiki Flavor"
> * "Generic XWiki Flavor"
> * "Base XWiki Flavor"
> 
> "Generic" is probably a way too technical term.
> 
> "Base" would be misleading IMO since it's not really a base flavor.
> Its primary goal is not to be used as a dependency (of course it's
> fine to have it as dependency if you just want to add pre installed
> extensions to the default flavor). It's a -1 for me.
> 
> Frankly I would simply go for "XWiki Flavor". I know, it's not going
> to be the only flavor for XWiki but it's obvious when you actually see
> severals of those in the picker anyway and I find it nicer than
> "Default XWiki Flavor" which basically means the same thing since the
> XWiki core project does not plan to provide any other flavor. I'm also
> fine with "Default XWiki Favor" if others think it's a better name.
> 
> WDYT ?
> 
> -- 
> Thomas Mortagne

Re: [xwiki-devs] [PROPOSAL] Rename downloadable packages while releasing them

[Thomas Mortagne]

My only fear is that naming it "xwiki-9.5.zip" might make it look like
the recommended package while it's quite the opposite in practice.

On Fri, Jun 9, 2017 at 3:50 PM, Marius Dumitru Florea
 wrote:
> +1. I prefer xwiki-9.5.zip
>
> Thanks,
> Marius
>
> On Fri, Jun 9, 2017 at 1:25 PM, Thomas Mortagne 
> wrote:
>
>> Hi xwikiers,
>>
>> Eduard hard the idea of dynamically rename the files names of the
>> packages we publish on http://www.xwiki.org/xwiki/bin/view/Download/
>> page and use the refactoring to move XE features to a new platform
>> flavor as a good opportunity for this change.
>>
>> In more details the proposal is the following:
>> * name "xwiki-demo-9.5.zip" or "xwiki-9.5.zip" the standard
>> jetty/hsqldb package (the one which let you choose the flavor you want
>> to install)
>> * name "xwiki-9.5.war" the standard war package
>> * name "xwiki-classic-9.5.xip" the offline package containing XWiki
>> Classic flavor
>>
>> WDYT ? Other ideas ?
>>
>> +1 with a preference for "xwiki-demo-9.5.zip" over "xwiki-9.5.zip" to
>> make it more clear it's not a production oriented package.
>>
>> --
>> Thomas Mortagne
>>



-- 
Thomas Mortagne

Re: [xwiki-devs] [PROPOSAL] Rename downloadable packages while releasing them

[Marius Dumitru Florea]

+1. I prefer xwiki-9.5.zip

Thanks,
Marius

On Fri, Jun 9, 2017 at 1:25 PM, Thomas Mortagne 
wrote:

> Hi xwikiers,
>
> Eduard hard the idea of dynamically rename the files names of the
> packages we publish on http://www.xwiki.org/xwiki/bin/view/Download/
> page and use the refactoring to move XE features to a new platform
> flavor as a good opportunity for this change.
>
> In more details the proposal is the following:
> * name "xwiki-demo-9.5.zip" or "xwiki-9.5.zip" the standard
> jetty/hsqldb package (the one which let you choose the flavor you want
> to install)
> * name "xwiki-9.5.war" the standard war package
> * name "xwiki-classic-9.5.xip" the offline package containing XWiki
> Classic flavor
>
> WDYT ? Other ideas ?
>
> +1 with a preference for "xwiki-demo-9.5.zip" over "xwiki-9.5.zip" to
> make it more clear it's not a production oriented package.
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [GSoC] More extension repositories [Bintray / Artifactory]

[Thomas Mortagne]

Very surprising, I really tough Bintray was a cloud of Artifactory instances...

Since the main use case is to support Bintray jcenter I think you
should concentrate on Bintray APi support only and skip Artifactory
for now.

On Fri, Jun 9, 2017 at 3:12 PM, Krzysiek Płachno
 wrote:
> I've investigater Artifactory and Bintray APIs. They are totally different.
>
> I updated desing page:
> http://design.xwiki.org/xwiki/bin/view/Proposal/MoreextensionrepositoriesArtifactoryBintray
>
> 2017-06-08 11:35 GMT+02:00 Krzysiek Płachno :
>
>> Ok - I got it (I confused in my mind ExtensionRepositorySource
>> with ExtensionRepository)
>>
>> I'll compare in detail the apis of Artifactory and Bintray - if they're
>> (almost) the same - it makes sense to do it as you described.
>>
>> KP
>>
>> 2017-06-08 11:26 GMT+02:00 Thomas Mortagne :
>>
>>> On Thu, Jun 8, 2017 at 11:05 AM, Krzysiek Płachno
>>>  wrote:
>>> > Ok - then.
>>> >
>>> > So:
>>>
>>> > 1. Do I understand well that the advantage of Rest connection over
>>> native
>>> > Maven connection is that when using maven we cannot search repo?
>>>
>>> Yes you don't have live search in standard Maven repository. In some
>>> repository you can download an index but that's all.
>>>
>>> > 2. The goal would be to produce an extension with two components
>>> > ExtensionRepositoryFactory:  'bintray' and 'artifactory' which sharing
>>> the
>>> > same logic will allow to connect Bintray and Artifactory? Or just
>>> > one ExtensionRepositoryFactory with name 'artifactory' to be used also
>>> for
>>> > both? This naming is a bit important since in xwiki.properties whilst
>>> > giving url to external repo user also gives type of repo. (As
>>> > regards ExtensionRepositorySource components - they are completely
>>> hidden
>>> > so it may be one for both Artifactory and Bintray)
>>>
>>> If Bintray use Artifactory REST API then there should be only one
>>> 'artifactory' ExtensionRepositoryFactory.
>>>
>>> ExtensionRepositorySource point is to provide default repository (for
>>> example extensions.xwiki.org or nexus.xwiki.org) so it only make sense
>>> for Bintray jcenter (unless jcenter does not expose REST API). I
>>> totally skipped the fact that anyone was able to create a Bintray
>>> instance and I was actually only thinking about jcenter.
>>>
>>> >
>>> > KP
>>> >
>>> >
>>> >
>>> >
>>> > 2017-06-07 10:12 GMT+02:00 Thomas Mortagne :
>>> >
>>> >> Some comments:
>>> >>
>>> >> The difference between Artifactory and Bintray you are describing
>>> >> don't really matter for your use case IMO.
>>> >>
>>> >> The only thing you should deal with are:
>>> >>
>>> >> * downloading artifacts
>>> >> * searching for artifacts (that is actually the only feature brought
>>> >> by this extension since as you said you can download artifacts through
>>> >> Maven access)
>>> >>
>>> >> and AFAIK those two features have the same API in both cases since
>>> >> Bintray is essentially a public Artifactory instance.
>>> >>
>>> >> So unless I really missing something here you should IMO work on two
>>> >> extensions (on just two component in the same extension):
>>> >> * an ExtensionRepositoryFactory for Artifactory
>>> >> * a ExtensionRepositorySource which automatically register Bintray
>>> >> with the type "artifactory"
>>> >>
>>> >> On Mon, Jun 5, 2017 at 12:05 PM, Krzysiek Płachno
>>> >>  wrote:
>>> >> > Hey!
>>> >> >
>>> >> > I investigated a bit Binatray and Artifactory and uploaded relatively
>>> >> short
>>> >> > raport:
>>> >> > http://design.xwiki.org/xwiki/bin/view/Proposal/
>>> >> MoreextensionrepositoriesArtifactoryBintray
>>> >> >
>>> >> > Any comments, ideas, relfections - highly appreciated.
>>> >> >
>>> >> >
>>> >> > Best,
>>> >> > Krzysztof Płachno
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Thomas Mortagne
>>> >>
>>>
>>>
>>>
>>> --
>>> Thomas Mortagne
>>>
>>
>>



-- 
Thomas Mortagne

Re: [xwiki-devs] [GSoC] More extension repositories [Bintray / Artifactory]

[Krzysiek Płachno]

I've investigater Artifactory and Bintray APIs. They are totally different.

I updated desing page:
http://design.xwiki.org/xwiki/bin/view/Proposal/MoreextensionrepositoriesArtifactoryBintray

2017-06-08 11:35 GMT+02:00 Krzysiek Płachno :

> Ok - I got it (I confused in my mind ExtensionRepositorySource
> with ExtensionRepository)
>
> I'll compare in detail the apis of Artifactory and Bintray - if they're
> (almost) the same - it makes sense to do it as you described.
>
> KP
>
> 2017-06-08 11:26 GMT+02:00 Thomas Mortagne :
>
>> On Thu, Jun 8, 2017 at 11:05 AM, Krzysiek Płachno
>>  wrote:
>> > Ok - then.
>> >
>> > So:
>>
>> > 1. Do I understand well that the advantage of Rest connection over
>> native
>> > Maven connection is that when using maven we cannot search repo?
>>
>> Yes you don't have live search in standard Maven repository. In some
>> repository you can download an index but that's all.
>>
>> > 2. The goal would be to produce an extension with two components
>> > ExtensionRepositoryFactory:  'bintray' and 'artifactory' which sharing
>> the
>> > same logic will allow to connect Bintray and Artifactory? Or just
>> > one ExtensionRepositoryFactory with name 'artifactory' to be used also
>> for
>> > both? This naming is a bit important since in xwiki.properties whilst
>> > giving url to external repo user also gives type of repo. (As
>> > regards ExtensionRepositorySource components - they are completely
>> hidden
>> > so it may be one for both Artifactory and Bintray)
>>
>> If Bintray use Artifactory REST API then there should be only one
>> 'artifactory' ExtensionRepositoryFactory.
>>
>> ExtensionRepositorySource point is to provide default repository (for
>> example extensions.xwiki.org or nexus.xwiki.org) so it only make sense
>> for Bintray jcenter (unless jcenter does not expose REST API). I
>> totally skipped the fact that anyone was able to create a Bintray
>> instance and I was actually only thinking about jcenter.
>>
>> >
>> > KP
>> >
>> >
>> >
>> >
>> > 2017-06-07 10:12 GMT+02:00 Thomas Mortagne :
>> >
>> >> Some comments:
>> >>
>> >> The difference between Artifactory and Bintray you are describing
>> >> don't really matter for your use case IMO.
>> >>
>> >> The only thing you should deal with are:
>> >>
>> >> * downloading artifacts
>> >> * searching for artifacts (that is actually the only feature brought
>> >> by this extension since as you said you can download artifacts through
>> >> Maven access)
>> >>
>> >> and AFAIK those two features have the same API in both cases since
>> >> Bintray is essentially a public Artifactory instance.
>> >>
>> >> So unless I really missing something here you should IMO work on two
>> >> extensions (on just two component in the same extension):
>> >> * an ExtensionRepositoryFactory for Artifactory
>> >> * a ExtensionRepositorySource which automatically register Bintray
>> >> with the type "artifactory"
>> >>
>> >> On Mon, Jun 5, 2017 at 12:05 PM, Krzysiek Płachno
>> >>  wrote:
>> >> > Hey!
>> >> >
>> >> > I investigated a bit Binatray and Artifactory and uploaded relatively
>> >> short
>> >> > raport:
>> >> > http://design.xwiki.org/xwiki/bin/view/Proposal/
>> >> MoreextensionrepositoriesArtifactoryBintray
>> >> >
>> >> > Any comments, ideas, relfections - highly appreciated.
>> >> >
>> >> >
>> >> > Best,
>> >> > Krzysztof Płachno
>> >>
>> >>
>> >>
>> >> --
>> >> Thomas Mortagne
>> >>
>>
>>
>>
>> --
>> Thomas Mortagne
>>
>
>

Re: [xwiki-devs] Error in code. :/

[Thomas Mortagne]

On Fri, Jun 9, 2017 at 1:17 PM, Sarthak Gupta  wrote:
> Hello,
> This error occurs when I enter the word "Hello" in the textbox, and then
> press the "add glossary" button.
> The $newGlossaryReference is not null. It prints "xwiki:Glossary.Hello".
>
> The code is located in a design sheet "Glossary.GlossarySheet". I have
> linked the sheet to the main class "Glossary.GlossaryClass" and added the
> "Glossary.GlossaryClass" object on the home page of the application
> 'Glossary.WebHome'.

So that's your mistake. Every time a glossary entry is displayed your
code is executed since the sheet is executed.

You should not use the same sheet for the home page and the entries.

>
> I expect that when a user enters a text(say hello) in the textbox and press
> "Add Glossary" button then it should create a new page with the
> title 'hello' using GlossaryTemplate in the Glossary Space.
>
> Thanks
>
> On Fri, Jun 9, 2017 at 3:35 PM, Thomas Mortagne 
> wrote:
>
>> Where is this code located ? In "Glossary.Hello" page ?
>>
>> Are you sure $newGlossaryReference contains what you expect ? Did you
>> print it ? If it was null you would get exactly this behavior.
>>
>> On Fri, Jun 9, 2017 at 11:56 AM, Sarthak Gupta
>>  wrote:
>> > Hello all,
>> >
>> > It's been 2 days that I am stuck in a stupid error.
>> > I have a "add glossary" button in my application, and when I click that
>> > button, the browser gives me the error: "This page isn’t working,
>> 127.0.0.1
>> > redirected you too many times."
>> >
>> > Now this is a redirect loop. And it's caused by the statement
>> > $response.sendRedirect($xwiki.getURL($newGlossaryReference, 'inline',
>> > "$!{request.queryString}=${escapetool.url($glossaryItem)}")) in my
>> > code I guess. I am not able to figure out why this is looping even if
>> there
>> > is no loop. I have tried certain things but there is no progress.
>> >
>> > Moreover, my title bar appear like this:
>> > http://127.0.0.1:8080/xwiki/bin/inline/Glossary/Hello?
>> parent=Glossary.WebHome=Glossary.GlossaryTemplate&
>> createGlossary=true=Hello=
>> Hello=Hello=Hello=Hello=Hello=
>> Hello=Hello=Hello=Hello=Hello=
>> Hello=Hello=Hello=Hello=Hello=
>> Hello=Hello=Hello=Hello=Hello=Hello
>> >
>> > Here is my complete code: https://pastebin.com/p95DeHMg
>> >
>> > Could someone please take some time and help me out?
>> >
>> > IRC:sarthakg
>> >
>> > Thanks
>> > Sarthak Gupta
>>
>>
>>
>> --
>> Thomas Mortagne
>>



-- 
Thomas Mortagne

Re: [xwiki-devs] Error in code. :/

[Sarthak Gupta]

Hello,
This error occurs when I enter the word "Hello" in the textbox, and then
press the "add glossary" button.
The $newGlossaryReference is not null. It prints "xwiki:Glossary.Hello".

The code is located in a design sheet "Glossary.GlossarySheet". I have
linked the sheet to the main class "Glossary.GlossaryClass" and added the
"Glossary.GlossaryClass" object on the home page of the application
'Glossary.WebHome'.

I expect that when a user enters a text(say hello) in the textbox and press
"Add Glossary" button then it should create a new page with the
title 'hello' using GlossaryTemplate in the Glossary Space.

Thanks

On Fri, Jun 9, 2017 at 3:35 PM, Thomas Mortagne 
wrote:

> Where is this code located ? In "Glossary.Hello" page ?
>
> Are you sure $newGlossaryReference contains what you expect ? Did you
> print it ? If it was null you would get exactly this behavior.
>
> On Fri, Jun 9, 2017 at 11:56 AM, Sarthak Gupta
>  wrote:
> > Hello all,
> >
> > It's been 2 days that I am stuck in a stupid error.
> > I have a "add glossary" button in my application, and when I click that
> > button, the browser gives me the error: "This page isn’t working,
> 127.0.0.1
> > redirected you too many times."
> >
> > Now this is a redirect loop. And it's caused by the statement
> > $response.sendRedirect($xwiki.getURL($newGlossaryReference, 'inline',
> > "$!{request.queryString}=${escapetool.url($glossaryItem)}")) in my
> > code I guess. I am not able to figure out why this is looping even if
> there
> > is no loop. I have tried certain things but there is no progress.
> >
> > Moreover, my title bar appear like this:
> > http://127.0.0.1:8080/xwiki/bin/inline/Glossary/Hello?
> parent=Glossary.WebHome=Glossary.GlossaryTemplate&
> createGlossary=true=Hello=
> Hello=Hello=Hello=Hello=Hello=
> Hello=Hello=Hello=Hello=Hello=
> Hello=Hello=Hello=Hello=Hello=
> Hello=Hello=Hello=Hello=Hello=Hello
> >
> > Here is my complete code: https://pastebin.com/p95DeHMg
> >
> > Could someone please take some time and help me out?
> >
> > IRC:sarthakg
> >
> > Thanks
> > Sarthak Gupta
>
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [PROPOSAL] Rename downloadable packages while releasing them

[Sergiu Dumitriu]

+1.

I'm not a big fan of "demo", though, people will get confused.

On 06/09/2017 06:42 AM, Eduard Moraru wrote:
> The idea boils down to removing technical details
> ("platform-distribution-war", "platform-distribution-flavor-xip",
> "platform-distribution-jetty-hsqldb") from the published artifact and
> simplifying it to:
> "xwiki--."
> 
> Here's my +1.
> 
> Thanks,
> Eduard
> 
> On Fri, Jun 9, 2017 at 1:25 PM, Thomas Mortagne 
> wrote:
> 
>> Hi xwikiers,
>>
>> Eduard hard the idea of dynamically rename the files names of the
>> packages we publish on http://www.xwiki.org/xwiki/bin/view/Download/
>> page and use the refactoring to move XE features to a new platform
>> flavor as a good opportunity for this change.
>>
>> In more details the proposal is the following:
>> * name "xwiki-demo-9.5.zip" or "xwiki-9.5.zip" the standard
>> jetty/hsqldb package (the one which let you choose the flavor you want
>> to install)
>> * name "xwiki-9.5.war" the standard war package
>> * name "xwiki-classic-9.5.xip" the offline package containing XWiki
>> Classic flavor
>>
>> WDYT ? Other ideas ?
>>
>> +1 with a preference for "xwiki-demo-9.5.zip" over "xwiki-9.5.zip" to
>> make it more clear it's not a production oriented package.
>>
>> --
>> Thomas Mortagne
>>


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/

Re: [xwiki-devs] [PROPOSAL] Rename downloadable packages while releasing them

[Ecaterina Moraru (Valica)]

much simpler +1, so I prefer "xwiki-9.5.zip"

Thanks,
Caty

On Fri, Jun 9, 2017 at 1:38 PM, Vincent Massol  wrote:

> Hi,
>
> > On 9 Jun 2017, at 12:25, Thomas Mortagne 
> wrote:
> >
> > Hi xwikiers,
> >
> > Eduard hard the idea of dynamically rename the files names of the
> > packages we publish on http://www.xwiki.org/xwiki/bin/view/Download/
> > page and use the refactoring to move XE features to a new platform
> > flavor as a good opportunity for this change.
> >
> > In more details the proposal is the following:
> > * name "xwiki-demo-9.5.zip" or "xwiki-9.5.zip" the standard
> > jetty/hsqldb package (the one which let you choose the flavor you want
> > to install)
> > * name "xwiki-9.5.war" the standard war package
> > * name "xwiki-classic-9.5.xip" the offline package containing XWiki
> > Classic flavor
> >
> > WDYT ? Other ideas ?
> >
> > +1 with a preference for "xwiki-demo-9.5.zip" over "xwiki-9.5.zip" to
> > make it more clear it's not a production oriented package.
>
> Sounds good to me. I prefer the format: xwiki- name>-.
>
> Thanks
> -Vincent
>
> > Thomas Mortagne
>
>

Re: [xwiki-devs] [PROPOSAL] Rename downloadable packages while releasing them

[Eduard Moraru]

The idea boils down to removing technical details
("platform-distribution-war", "platform-distribution-flavor-xip",
"platform-distribution-jetty-hsqldb") from the published artifact and
simplifying it to:
"xwiki--."

Here's my +1.

Thanks,
Eduard

On Fri, Jun 9, 2017 at 1:25 PM, Thomas Mortagne 
wrote:

> Hi xwikiers,
>
> Eduard hard the idea of dynamically rename the files names of the
> packages we publish on http://www.xwiki.org/xwiki/bin/view/Download/
> page and use the refactoring to move XE features to a new platform
> flavor as a good opportunity for this change.
>
> In more details the proposal is the following:
> * name "xwiki-demo-9.5.zip" or "xwiki-9.5.zip" the standard
> jetty/hsqldb package (the one which let you choose the flavor you want
> to install)
> * name "xwiki-9.5.war" the standard war package
> * name "xwiki-classic-9.5.xip" the offline package containing XWiki
> Classic flavor
>
> WDYT ? Other ideas ?
>
> +1 with a preference for "xwiki-demo-9.5.zip" over "xwiki-9.5.zip" to
> make it more clear it's not a production oriented package.
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [PROPOSAL] Rename downloadable packages while releasing them

[Vincent Massol]

Hi,

> On 9 Jun 2017, at 12:25, Thomas Mortagne  wrote:
> 
> Hi xwikiers,
> 
> Eduard hard the idea of dynamically rename the files names of the
> packages we publish on http://www.xwiki.org/xwiki/bin/view/Download/
> page and use the refactoring to move XE features to a new platform
> flavor as a good opportunity for this change.
> 
> In more details the proposal is the following:
> * name "xwiki-demo-9.5.zip" or "xwiki-9.5.zip" the standard
> jetty/hsqldb package (the one which let you choose the flavor you want
> to install)
> * name "xwiki-9.5.war" the standard war package
> * name "xwiki-classic-9.5.xip" the offline package containing XWiki
> Classic flavor
> 
> WDYT ? Other ideas ?
> 
> +1 with a preference for "xwiki-demo-9.5.zip" over "xwiki-9.5.zip" to
> make it more clear it's not a production oriented package.

Sounds good to me. I prefer the format: xwiki--.

Thanks
-Vincent

> Thomas Mortagne

[xwiki-devs] [PROPOSAL] Rename downloadable packages while releasing them

[Thomas Mortagne]

Hi xwikiers,

Eduard hard the idea of dynamically rename the files names of the
packages we publish on http://www.xwiki.org/xwiki/bin/view/Download/
page and use the refactoring to move XE features to a new platform
flavor as a good opportunity for this change.

In more details the proposal is the following:
* name "xwiki-demo-9.5.zip" or "xwiki-9.5.zip" the standard
jetty/hsqldb package (the one which let you choose the flavor you want
to install)
* name "xwiki-9.5.war" the standard war package
* name "xwiki-classic-9.5.xip" the offline package containing XWiki
Classic flavor

WDYT ? Other ideas ?

+1 with a preference for "xwiki-demo-9.5.zip" over "xwiki-9.5.zip" to
make it more clear it's not a production oriented package.

-- 
Thomas Mortagne

[xwiki-devs] Error in code. :/

[Sarthak Gupta]

Hello all,

It's been 2 days that I am stuck in a stupid error.
I have a "add glossary" button in my application, and when I click that
button, the browser gives me the error: "This page isn’t working, 127.0.0.1
redirected you too many times."

Now this is a redirect loop. And it's caused by the statement
$response.sendRedirect($xwiki.getURL($newGlossaryReference, 'inline',
"$!{request.queryString}=${escapetool.url($glossaryItem)}")) in my
code I guess. I am not able to figure out why this is looping even if there
is no loop. I have tried certain things but there is no progress.

Moreover, my title bar appear like this:
http://127.0.0.1:8080/xwiki/bin/inline/Glossary/Hello?parent=Glossary.WebHome=Glossary.GlossaryTemplate=true=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello=Hello

Here is my complete code: https://pastebin.com/p95DeHMg

Could someone please take some time and help me out?

IRC:sarthakg

Thanks
Sarthak Gupta

Re: [xwiki-devs] [VOTE] Move the WebDAV feature to xwiki-contrib

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Thu, Jun 8, 2017 at 4:18 PM, Vincent Massol  wrote:

> Hi devs,
>
> With https://jira.xwiki.org/browse/XE-1527 (http://markmail.org/message/
> t7khe7ufdtlsf5gl) we’ve removed the WebDAV feature by default in XE.
>
> I’d like to propose to go one step further and consider the webdav feature
> as non-core and move it outside of the xwiki github organization and into
> xwiki-contrib. I’d also propose that the XWiki Core Dev Team stops
> supporting it.
>
> Rationale:
> * We haven’t touched it in a long long time
> * It’s not a feature requested by our users anymore
> * If any contributor is interested in working on it one day, it’s simpler
> in xwiki-contrib and it can be released independently of XWiki
>
> Here’s my +1
>
> Please cast your vote
>
> Thanks
> -Vincent
>
>
>
>

Re: [xwiki-devs] [VOTE] Move the WebDAV feature to xwiki-contrib

[Krzysiek Płachno]

+1
Seems reasonable even for person not very experienced in XWiki :)

KP

2017-06-09 9:59 GMT+02:00 Thomas Mortagne :

> +1
>
> On Fri, Jun 9, 2017 at 1:50 AM, Sergiu Dumitriu  wrote:
> > +1.
> >
> > On 06/08/2017 09:18 AM, Vincent Massol wrote:
> >> Hi devs,
> >>
> >> With https://jira.xwiki.org/browse/XE-1527 (
> http://markmail.org/message/t7khe7ufdtlsf5gl) we’ve removed the WebDAV
> feature by default in XE.
> >>
> >> I’d like to propose to go one step further and consider the webdav
> feature as non-core and move it outside of the xwiki github organization
> and into xwiki-contrib. I’d also propose that the XWiki Core Dev Team stops
> supporting it.
> >>
> >> Rationale:
> >> * We haven’t touched it in a long long time
> >> * It’s not a feature requested by our users anymore
> >> * If any contributor is interested in working on it one day, it’s
> simpler in xwiki-contrib and it can be released independently of XWiki
> >>
> >> Here’s my +1
> >>
> >> Please cast your vote
> >>
> >> Thanks
> >> -Vincent
> >>
> >>
> >>
> >
> >
> > --
> > Sergiu Dumitriu
> > http://purl.org/net/sergiu/
>
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [VOTE] Move the WebDAV feature to xwiki-contrib

[Thomas Mortagne]

+1

On Fri, Jun 9, 2017 at 1:50 AM, Sergiu Dumitriu  wrote:
> +1.
>
> On 06/08/2017 09:18 AM, Vincent Massol wrote:
>> Hi devs,
>>
>> With https://jira.xwiki.org/browse/XE-1527 
>> (http://markmail.org/message/t7khe7ufdtlsf5gl) we’ve removed the WebDAV 
>> feature by default in XE.
>>
>> I’d like to propose to go one step further and consider the webdav feature 
>> as non-core and move it outside of the xwiki github organization and into 
>> xwiki-contrib. I’d also propose that the XWiki Core Dev Team stops 
>> supporting it.
>>
>> Rationale:
>> * We haven’t touched it in a long long time
>> * It’s not a feature requested by our users anymore
>> * If any contributor is interested in working on it one day, it’s simpler in 
>> xwiki-contrib and it can be released independently of XWiki
>>
>> Here’s my +1
>>
>> Please cast your vote
>>
>> Thanks
>> -Vincent
>>
>>
>>
>
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/



-- 
Thomas Mortagne