Re: [xwiki-devs] [Proposal] Cleaning of flickering tests
On Fri, Sep 6, 2019 at 10:46 AM Vincent Massol wrote: > > > > > On 6 Sep 2019, at 10:42, Thomas Mortagne wrote: > > > > And why do you guys think about raisin the history to 30 at least > > platform pipeline jobs? > > We need to first check if we have enough disk space first, it’s going to > consume a lot of it. ci.xwiki.org currently use 393G (total, not just Jenkins) and have 1.3T available. I check a few history entries of xwiki-platform master and the scale seems to be about 70M (90% of which is the log file) with something like 10 failing tests so I think we are safe for a little while > > Also, we would need to monitor closely for perf issues and roll it back if it > doesn’t go well. Of course but that's easy. > > Thanks > -Vincent > > > > > On Fri, Sep 6, 2019 at 10:39 AM Vincent Massol wrote: > >> > >> > >> > >>> On 6 Sep 2019, at 10:35, Thomas Mortagne > >>> wrote: > >>> > >>> On Fri, Sep 6, 2019 at 10:32 AM Vincent Massol wrote: > >>>> > >>>> Hi Simon, > >>>> > >>>>> On 6 Sep 2019, at 10:27, Simon Urli wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> On 05/09/2019 17:40, Simon Urli wrote: > >>>>>> On 05/09/2019 17:24, Thomas Mortagne wrote: > >>>>>>> On Thu, Sep 5, 2019 at 3:43 PM Simon Urli > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Hi everyone, > >>>>>>>> > >>>>>>>> reopening this thread since I started to close some flicker issues as > >>>>>>>> part of BFD and got comments for those. > >>>>>>>> > >>>>>>>> So the last mails on this threads suggested to close the flicker > >>>>>>>> issues > >>>>>>>> if we didn't manage to reproduce them locally after a repeated tests, > >>>>>>>> and that we didn't see them after a while. > >>>>>>>> > >>>>>>>> We didn't vote for those suggestion and I assumed a bit quick that I > >>>>>>>> could close some flicker issues that I personally don't remember > >>>>>>>> about > >>>>>>>> on the CI after having tested them locally. > >>>>>>>> My point for doing that is the same as for the first mail I posted on > >>>>>>>> this thread: those flickers are old, and the code did change enough > >>>>>>>> for > >>>>>>>> those to be fixed in a way or another. > >>>>>>> > >>>>>>> Being old does not always means the code leading to those failures > >>>>>>> changed that much. > >>>>>>> > >>>>>>>> > >>>>>>>> Now I might be completely wrong, and the flicker to happen again, > >>>>>>>> but I > >>>>>>>> don't think it's a problem since we can really easily open back the > >>>>>>>> issues if it's the case. > >>>>>>>> > >>>>>>>> The other solution IMO is to indeed keep the issue open and in fact > >>>>>>>> to > >>>>>>>> never really close them, because we just don't have time to > >>>>>>>> investigate > >>>>>>>> each of them properly. > >>>>>>>> > >>>>>>>> I really don't see any value of keeping things open and don't act on > >>>>>>>> them, that's why I suggest to close them after doing the checks we > >>>>>>>> suggested before: > >>>>>>>> 1. try to repeat locally the failure; > >>>>>>> > >>>>>>> This is totally useless IMO unless you make sure that your computer is > >>>>>>> made super slow some way since that's the reason for most of the > >>>>>>> flickering tests. > >>>>>>> > >>>>>>>> 2. check that we didn't encounter those flickers since last cycle. > >>>>>>> > >>>>>>> This one is enough for me but the hard part is to knowing that. > >>>>>> Ok, so the proposal is now to check only t
Re: [xwiki-devs] [Proposal] Cleaning of flickering tests
s/why/what/ Not good with mails today... On Fri, Sep 6, 2019 at 10:42 AM Thomas Mortagne wrote: > > And why do you guys think about raisin the history to 30 at least > platform pipeline jobs? > > On Fri, Sep 6, 2019 at 10:39 AM Vincent Massol wrote: > > > > > > > > > On 6 Sep 2019, at 10:35, Thomas Mortagne > > > wrote: > > > > > > On Fri, Sep 6, 2019 at 10:32 AM Vincent Massol wrote: > > >> > > >> Hi Simon, > > >> > > >>> On 6 Sep 2019, at 10:27, Simon Urli wrote: > > >>> > > >>> Hi all, > > >>> > > >>> On 05/09/2019 17:40, Simon Urli wrote: > > >>>> On 05/09/2019 17:24, Thomas Mortagne wrote: > > >>>>> On Thu, Sep 5, 2019 at 3:43 PM Simon Urli > > >>>>> wrote: > > >>>>>> > > >>>>>> Hi everyone, > > >>>>>> > > >>>>>> reopening this thread since I started to close some flicker issues as > > >>>>>> part of BFD and got comments for those. > > >>>>>> > > >>>>>> So the last mails on this threads suggested to close the flicker > > >>>>>> issues > > >>>>>> if we didn't manage to reproduce them locally after a repeated tests, > > >>>>>> and that we didn't see them after a while. > > >>>>>> > > >>>>>> We didn't vote for those suggestion and I assumed a bit quick that I > > >>>>>> could close some flicker issues that I personally don't remember > > >>>>>> about > > >>>>>> on the CI after having tested them locally. > > >>>>>> My point for doing that is the same as for the first mail I posted on > > >>>>>> this thread: those flickers are old, and the code did change enough > > >>>>>> for > > >>>>>> those to be fixed in a way or another. > > >>>>> > > >>>>> Being old does not always means the code leading to those failures > > >>>>> changed that much. > > >>>>> > > >>>>>> > > >>>>>> Now I might be completely wrong, and the flicker to happen again, > > >>>>>> but I > > >>>>>> don't think it's a problem since we can really easily open back the > > >>>>>> issues if it's the case. > > >>>>>> > > >>>>>> The other solution IMO is to indeed keep the issue open and in fact > > >>>>>> to > > >>>>>> never really close them, because we just don't have time to > > >>>>>> investigate > > >>>>>> each of them properly. > > >>>>>> > > >>>>>> I really don't see any value of keeping things open and don't act on > > >>>>>> them, that's why I suggest to close them after doing the checks we > > >>>>>> suggested before: > > >>>>>>1. try to repeat locally the failure; > > >>>>> > > >>>>> This is totally useless IMO unless you make sure that your computer is > > >>>>> made super slow some way since that's the reason for most of the > > >>>>> flickering tests. > > >>>>> > > >>>>>>2. check that we didn't encounter those flickers since last cycle. > > >>>>> > > >>>>> This one is enough for me but the hard part is to knowing that. > > >>>> Ok, so the proposal is now to check only the age since last time we > > >>>> saw them of the open flickers before closing them. > > >>>>> > > >>>>>> > > >>>>>> So first question, do we all agree on that? > > >>>>>> > > >>>>>> Then for the second check, Vincent suggested to add some tooling: it > > >>>>>> will be best, but it takes time to do. So on the meantime, as Thomas > > >>>>>> also suggested, we could add a check in the release plan to create or > > >>>>>> update all jira issues that concerns flickers. It would allow us to > > >>>>>> keep > > >>>>>> some information about the liveness of our flickers. > > >>>>>> > > >>>>>> So second question, do you agree on that? > > >>>>> > > >>>>> Depends what it exactly means. Have some dedicated jira field to > > >>>>> indicate when you saw it last ? Comment that you just saw that test > > >>>>> failing again ? > > >>>> My suggestion was about a dedicated JIRA field if possible. > > >>> > > >>> So, ok if I create a new custom field in JIRA for flickers, called > > >>> "Date of last failure for flicker”? > > >> > > >> [snip] > > >> > > >> I don’t see how it’ll help since it’ll never be up to date, and the old > > >> value will remain making us think it’s not been flickering for a long > > >> time. > > > > > > In my mind the idea is not so much to use this field as a criteria to > > > close an issue but as a criteria to not close it. > > > > ok, as long as we don’t use it for closing, I’m fine :) > > > > Thanks > > -Vincent > > > > > > > >> > > >> Thanks > > >> -Vincent > > >> > > > > > > > > > -- > > > Thomas Mortagne > > > > > -- > Thomas Mortagne -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Cleaning of flickering tests
And why do you guys think about raisin the history to 30 at least platform pipeline jobs? On Fri, Sep 6, 2019 at 10:39 AM Vincent Massol wrote: > > > > > On 6 Sep 2019, at 10:35, Thomas Mortagne wrote: > > > > On Fri, Sep 6, 2019 at 10:32 AM Vincent Massol wrote: > >> > >> Hi Simon, > >> > >>> On 6 Sep 2019, at 10:27, Simon Urli wrote: > >>> > >>> Hi all, > >>> > >>> On 05/09/2019 17:40, Simon Urli wrote: > >>>> On 05/09/2019 17:24, Thomas Mortagne wrote: > >>>>> On Thu, Sep 5, 2019 at 3:43 PM Simon Urli wrote: > >>>>>> > >>>>>> Hi everyone, > >>>>>> > >>>>>> reopening this thread since I started to close some flicker issues as > >>>>>> part of BFD and got comments for those. > >>>>>> > >>>>>> So the last mails on this threads suggested to close the flicker issues > >>>>>> if we didn't manage to reproduce them locally after a repeated tests, > >>>>>> and that we didn't see them after a while. > >>>>>> > >>>>>> We didn't vote for those suggestion and I assumed a bit quick that I > >>>>>> could close some flicker issues that I personally don't remember about > >>>>>> on the CI after having tested them locally. > >>>>>> My point for doing that is the same as for the first mail I posted on > >>>>>> this thread: those flickers are old, and the code did change enough for > >>>>>> those to be fixed in a way or another. > >>>>> > >>>>> Being old does not always means the code leading to those failures > >>>>> changed that much. > >>>>> > >>>>>> > >>>>>> Now I might be completely wrong, and the flicker to happen again, but I > >>>>>> don't think it's a problem since we can really easily open back the > >>>>>> issues if it's the case. > >>>>>> > >>>>>> The other solution IMO is to indeed keep the issue open and in fact to > >>>>>> never really close them, because we just don't have time to investigate > >>>>>> each of them properly. > >>>>>> > >>>>>> I really don't see any value of keeping things open and don't act on > >>>>>> them, that's why I suggest to close them after doing the checks we > >>>>>> suggested before: > >>>>>>1. try to repeat locally the failure; > >>>>> > >>>>> This is totally useless IMO unless you make sure that your computer is > >>>>> made super slow some way since that's the reason for most of the > >>>>> flickering tests. > >>>>> > >>>>>>2. check that we didn't encounter those flickers since last cycle. > >>>>> > >>>>> This one is enough for me but the hard part is to knowing that. > >>>> Ok, so the proposal is now to check only the age since last time we saw > >>>> them of the open flickers before closing them. > >>>>> > >>>>>> > >>>>>> So first question, do we all agree on that? > >>>>>> > >>>>>> Then for the second check, Vincent suggested to add some tooling: it > >>>>>> will be best, but it takes time to do. So on the meantime, as Thomas > >>>>>> also suggested, we could add a check in the release plan to create or > >>>>>> update all jira issues that concerns flickers. It would allow us to > >>>>>> keep > >>>>>> some information about the liveness of our flickers. > >>>>>> > >>>>>> So second question, do you agree on that? > >>>>> > >>>>> Depends what it exactly means. Have some dedicated jira field to > >>>>> indicate when you saw it last ? Comment that you just saw that test > >>>>> failing again ? > >>>> My suggestion was about a dedicated JIRA field if possible. > >>> > >>> So, ok if I create a new custom field in JIRA for flickers, called "Date > >>> of last failure for flicker”? > >> > >> [snip] > >> > >> I don’t see how it’ll help since it’ll never be up to date, and the old > >> value will remain making us think it’s not been flickering for a long time. > > > > In my mind the idea is not so much to use this field as a criteria to > > close an issue but as a criteria to not close it. > > ok, as long as we don’t use it for closing, I’m fine :) > > Thanks > -Vincent > > > > >> > >> Thanks > >> -Vincent > >> > > > > > > -- > > Thomas Mortagne > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Cleaning of flickering tests
On Fri, Sep 6, 2019 at 10:42 AM Thomas Mortagne wrote: > > And why do you guys think about raisin the history to 30 at least > platform pipeline jobs? > > On Fri, Sep 6, 2019 at 10:39 AM Vincent Massol wrote: > > > > > > > > > On 6 Sep 2019, at 10:35, Thomas Mortagne > > > wrote: > > > > > > On Fri, Sep 6, 2019 at 10:32 AM Vincent Massol wrote: > > >> > > >> Hi Simon, > > >> > > >>> On 6 Sep 2019, at 10:27, Simon Urli wrote: > > >>> > > >>> Hi all, > > >>> > > >>> On 05/09/2019 17:40, Simon Urli wrote: > > >>>> On 05/09/2019 17:24, Thomas Mortagne wrote: > > >>>>> On Thu, Sep 5, 2019 at 3:43 PM Simon Urli > > >>>>> wrote: > > >>>>>> > > >>>>>> Hi everyone, > > >>>>>> > > >>>>>> reopening this thread since I started to close some flicker issues as > > >>>>>> part of BFD and got comments for those. > > >>>>>> > > >>>>>> So the last mails on this threads suggested to close the flicker > > >>>>>> issues > > >>>>>> if we didn't manage to reproduce them locally after a repeated tests, > > >>>>>> and that we didn't see them after a while. > > >>>>>> > > >>>>>> We didn't vote for those suggestion and I assumed a bit quick that I > > >>>>>> could close some flicker issues that I personally don't remember > > >>>>>> about > > >>>>>> on the CI after having tested them locally. > > >>>>>> My point for doing that is the same as for the first mail I posted on > > >>>>>> this thread: those flickers are old, and the code did change enough > > >>>>>> for > > >>>>>> those to be fixed in a way or another. > > >>>>> > > >>>>> Being old does not always means the code leading to those failures > > >>>>> changed that much. > > >>>>> > > >>>>>> > > >>>>>> Now I might be completely wrong, and the flicker to happen again, > > >>>>>> but I > > >>>>>> don't think it's a problem since we can really easily open back the > > >>>>>> issues if it's the case. > > >>>>>> > > >>>>>> The other solution IMO is to indeed keep the issue open and in fact > > >>>>>> to > > >>>>>> never really close them, because we just don't have time to > > >>>>>> investigate > > >>>>>> each of them properly. > > >>>>>> > > >>>>>> I really don't see any value of keeping things open and don't act on > > >>>>>> them, that's why I suggest to close them after doing the checks we > > >>>>>> suggested before: > > >>>>>>1. try to repeat locally the failure; > > >>>>> > > >>>>> This is totally useless IMO unless you make sure that your computer is > > >>>>> made super slow some way since that's the reason for most of the > > >>>>> flickering tests. > > >>>>> > > >>>>>>2. check that we didn't encounter those flickers since last cycle. > > >>>>> > > >>>>> This one is enough for me but the hard part is to knowing that. > > >>>> Ok, so the proposal is now to check only the age since last time we > > >>>> saw them of the open flickers before closing them. > > >>>>> > > >>>>>> > > >>>>>> So first question, do we all agree on that? > > >>>>>> > > >>>>>> Then for the second check, Vincent suggested to add some tooling: it > > >>>>>> will be best, but it takes time to do. So on the meantime, as Thomas > > >>>>>> also suggested, we could add a check in the release plan to create or > > >>>>>> update all jira issues that concerns flickers. It would allow us to > > >>>>>> keep > > >>>>>> some information about the liveness of our flickers. > > >>>>>> > > >>>>>> So second question, do you agree on that? > > >>>>> > > >>>>> Depends what it exactly means. Have some dedicated jira field to > > >>>>> indicate when you saw it last ? Comment that you just saw that test > > >>>>> failing again ? > > >>>> My suggestion was about a dedicated JIRA field if possible. > > >>> > > >>> So, ok if I create a new custom field in JIRA for flickers, called > > >>> "Date of last failure for flicker”? > > >> > > >> [snip] > > >> > > >> I don’t see how it’ll help since it’ll never be up to date, and the old > > >> value will remain making us think it’s not been flickering for a long > > >> time. > > > > > > In my mind the idea is not so much to use this field as a criteria to > > > close an issue but as a criteria to not close it. > > > > ok, as long as we don’t use it for closing, I’m fine :) > > > > Thanks > > -Vincent > > > > > > > >> > > >> Thanks > > >> -Vincent > > >> > > > > > > > > > -- > > > Thomas Mortagne > > > > > -- > Thomas Mortagne -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Cleaning of flickering tests
On Fri, Sep 6, 2019 at 10:32 AM Vincent Massol wrote: > > Hi Simon, > > > On 6 Sep 2019, at 10:27, Simon Urli wrote: > > > > Hi all, > > > > On 05/09/2019 17:40, Simon Urli wrote: > >> On 05/09/2019 17:24, Thomas Mortagne wrote: > >>> On Thu, Sep 5, 2019 at 3:43 PM Simon Urli wrote: > >>>> > >>>> Hi everyone, > >>>> > >>>> reopening this thread since I started to close some flicker issues as > >>>> part of BFD and got comments for those. > >>>> > >>>> So the last mails on this threads suggested to close the flicker issues > >>>> if we didn't manage to reproduce them locally after a repeated tests, > >>>> and that we didn't see them after a while. > >>>> > >>>> We didn't vote for those suggestion and I assumed a bit quick that I > >>>> could close some flicker issues that I personally don't remember about > >>>> on the CI after having tested them locally. > >>>> My point for doing that is the same as for the first mail I posted on > >>>> this thread: those flickers are old, and the code did change enough for > >>>> those to be fixed in a way or another. > >>> > >>> Being old does not always means the code leading to those failures > >>> changed that much. > >>> > >>>> > >>>> Now I might be completely wrong, and the flicker to happen again, but I > >>>> don't think it's a problem since we can really easily open back the > >>>> issues if it's the case. > >>>> > >>>> The other solution IMO is to indeed keep the issue open and in fact to > >>>> never really close them, because we just don't have time to investigate > >>>> each of them properly. > >>>> > >>>> I really don't see any value of keeping things open and don't act on > >>>> them, that's why I suggest to close them after doing the checks we > >>>> suggested before: > >>>> 1. try to repeat locally the failure; > >>> > >>> This is totally useless IMO unless you make sure that your computer is > >>> made super slow some way since that's the reason for most of the > >>> flickering tests. > >>> > >>>> 2. check that we didn't encounter those flickers since last cycle. > >>> > >>> This one is enough for me but the hard part is to knowing that. > >> Ok, so the proposal is now to check only the age since last time we saw > >> them of the open flickers before closing them. > >>> > >>>> > >>>> So first question, do we all agree on that? > >>>> > >>>> Then for the second check, Vincent suggested to add some tooling: it > >>>> will be best, but it takes time to do. So on the meantime, as Thomas > >>>> also suggested, we could add a check in the release plan to create or > >>>> update all jira issues that concerns flickers. It would allow us to keep > >>>> some information about the liveness of our flickers. > >>>> > >>>> So second question, do you agree on that? > >>> > >>> Depends what it exactly means. Have some dedicated jira field to > >>> indicate when you saw it last ? Comment that you just saw that test > >>> failing again ? > >> My suggestion was about a dedicated JIRA field if possible. > > > > So, ok if I create a new custom field in JIRA for flickers, called "Date of > > last failure for flicker”? > > [snip] > > I don’t see how it’ll help since it’ll never be up to date, and the old value > will remain making us think it’s not been flickering for a long time. In my mind the idea is not so much to use this field as a criteria to close an issue but as a criteria to not close it. > > Thanks > -Vincent > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Cleaning of flickering tests
On Fri, Sep 6, 2019 at 10:27 AM Simon Urli wrote: > > Hi all, > > On 05/09/2019 17:40, Simon Urli wrote: > > > > > > On 05/09/2019 17:24, Thomas Mortagne wrote: > >> On Thu, Sep 5, 2019 at 3:43 PM Simon Urli wrote: > >>> > >>> Hi everyone, > >>> > >>> reopening this thread since I started to close some flicker issues as > >>> part of BFD and got comments for those. > >>> > >>> So the last mails on this threads suggested to close the flicker issues > >>> if we didn't manage to reproduce them locally after a repeated tests, > >>> and that we didn't see them after a while. > >>> > >>> We didn't vote for those suggestion and I assumed a bit quick that I > >>> could close some flicker issues that I personally don't remember about > >>> on the CI after having tested them locally. > >>> My point for doing that is the same as for the first mail I posted on > >>> this thread: those flickers are old, and the code did change enough for > >>> those to be fixed in a way or another. > >> > >> Being old does not always means the code leading to those failures > >> changed that much. > >> > >>> > >>> Now I might be completely wrong, and the flicker to happen again, but I > >>> don't think it's a problem since we can really easily open back the > >>> issues if it's the case. > >>> > >>> The other solution IMO is to indeed keep the issue open and in fact to > >>> never really close them, because we just don't have time to investigate > >>> each of them properly. > >>> > >>> I really don't see any value of keeping things open and don't act on > >>> them, that's why I suggest to close them after doing the checks we > >>> suggested before: > >>> 1. try to repeat locally the failure; > >> > >> This is totally useless IMO unless you make sure that your computer is > >> made super slow some way since that's the reason for most of the > >> flickering tests. > >> > >>> 2. check that we didn't encounter those flickers since last cycle. > >> > >> This one is enough for me but the hard part is to knowing that. > > > > Ok, so the proposal is now to check only the age since last time we saw > > them of the open flickers before closing them. > > > >> > >>> > >>> So first question, do we all agree on that? > >>> > >>> Then for the second check, Vincent suggested to add some tooling: it > >>> will be best, but it takes time to do. So on the meantime, as Thomas > >>> also suggested, we could add a check in the release plan to create or > >>> update all jira issues that concerns flickers. It would allow us to keep > >>> some information about the liveness of our flickers. > >>> > >>> So second question, do you agree on that? > >> > >> Depends what it exactly means. Have some dedicated jira field to > >> indicate when you saw it last ? Comment that you just saw that test > >> failing again ? > > > > My suggestion was about a dedicated JIRA field if possible. > > So, ok if I create a new custom field in JIRA for flickers, called "Date > of last failure for flicker"? "Last seen failing" might be more accurate since we don't actually know when was the last failure. +1 in general for the field > > > > >> > >> Other useful and a little more automated tricks not requiring much > >> tooling: > >> * increase the currently very low history (10). The reason it's that > >> low is because of many performances issues we had in the past with old > >> style jobs but those most probably don't apply anymore so we should > >> increase the number now IMO (30 ?) > > > > +1 > >> * create a pipeline job which execute platform master integration > >> tests once a day with http://cpulimit.sourceforge.net (looks fun) and > >> keep a big history but not storing stuff like videos and images (100 > >> ?) > >> > > > > Not sure what you want there: to have a test execution where you master > > the slowness? to detect all problems we might have because of a slow > > server? > > > >>> > >>> Final question: for the flickers that I closed today, I relied mainly on > >>> my memory for the second check and on their age: I closed the older > >>> o
Re: [xwiki-devs] [Proposal] Cleaning of flickering tests
On Thu, Sep 5, 2019 at 5:40 PM Simon Urli wrote: > > > > On 05/09/2019 17:24, Thomas Mortagne wrote: > > On Thu, Sep 5, 2019 at 3:43 PM Simon Urli wrote: > >> > >> Hi everyone, > >> > >> reopening this thread since I started to close some flicker issues as > >> part of BFD and got comments for those. > >> > >> So the last mails on this threads suggested to close the flicker issues > >> if we didn't manage to reproduce them locally after a repeated tests, > >> and that we didn't see them after a while. > >> > >> We didn't vote for those suggestion and I assumed a bit quick that I > >> could close some flicker issues that I personally don't remember about > >> on the CI after having tested them locally. > >> My point for doing that is the same as for the first mail I posted on > >> this thread: those flickers are old, and the code did change enough for > >> those to be fixed in a way or another. > > > > Being old does not always means the code leading to those failures > > changed that much. > > > >> > >> Now I might be completely wrong, and the flicker to happen again, but I > >> don't think it's a problem since we can really easily open back the > >> issues if it's the case. > >> > >> The other solution IMO is to indeed keep the issue open and in fact to > >> never really close them, because we just don't have time to investigate > >> each of them properly. > >> > >> I really don't see any value of keeping things open and don't act on > >> them, that's why I suggest to close them after doing the checks we > >> suggested before: > >> 1. try to repeat locally the failure; > > > > This is totally useless IMO unless you make sure that your computer is > > made super slow some way since that's the reason for most of the > > flickering tests. > > > >> 2. check that we didn't encounter those flickers since last cycle. > > > > This one is enough for me but the hard part is to knowing that. > > Ok, so the proposal is now to check only the age since last time we saw > them of the open flickers before closing them. > > > > >> > >> So first question, do we all agree on that? > >> > >> Then for the second check, Vincent suggested to add some tooling: it > >> will be best, but it takes time to do. So on the meantime, as Thomas > >> also suggested, we could add a check in the release plan to create or > >> update all jira issues that concerns flickers. It would allow us to keep > >> some information about the liveness of our flickers. > >> > >> So second question, do you agree on that? > > > > Depends what it exactly means. Have some dedicated jira field to > > indicate when you saw it last ? Comment that you just saw that test > > failing again ? > > My suggestion was about a dedicated JIRA field if possible. > > > > > Other useful and a little more automated tricks not requiring much tooling: > > * increase the currently very low history (10). The reason it's that > > low is because of many performances issues we had in the past with old > > style jobs but those most probably don't apply anymore so we should > > increase the number now IMO (30 ?) > > +1 > > * create a pipeline job which execute platform master integration > > tests once a day with http://cpulimit.sourceforge.net (looks fun) and > > keep a big history but not storing stuff like videos and images (100 > > ?) > > > > Not sure what you want there: to have a test execution where you master > the slowness? to detect all problems we might have because of a slow > server? Have a big history of slowly executed tests so that we can very quickly see if some failing test in standard builds or in jira issues is still a thing and is failing for speed reasons (this also help fixing those tests and making sure they are actually fixed when you try something). > > >> > >> Final question: for the flickers that I closed today, I relied mainly on > >> my memory for the second check and on their age: I closed the older ones. > >> > >> So what should we do on them? > > > > My concern with them is that the reason you gave to close them (that > > you cannot reproduce them locally) was not valid IMO. If you say some > > test did not failed since a long time then fine, if what some test is > > about has completely been rewritten then fine too but that's not what > > you indicated :) > > I actually say that in
Re: [xwiki-devs] [Proposal] Cleaning of flickering tests
eline and make it available similar to our clover report. I > > could indicate if it’s a known flicker or not too in this report. That > > could compensate for the fact that we only keep 7 days of records in our > > jobs. > > > > Would need to define the report format, whether it’s the same file updated > > at each run or a different one. If the same one, then either: > > * I’d need to parse it first in memory, add the new tests and overwrite the > > file > > * or add to the bottom of the file which will grow quite large quickly > > > > WDYT? > > > > Thanks > > -Vincent > > > >> > >> So for now I propose to close the following list of issues as inactive: > >> > >> * XWIKI-14399: AddRemoveTagsTest#addAndDeleteTagFromTagPage is > >> flickering (https://jira.xwiki.org/browse/XWIKI-14399) > >> * XWIKI-14396: AnnotationsTest#addAndDeleteAnnotations is flickering > >> (https://jira.xwiki.org/browse/XWIKI-14396) > >> * XWIKI-14394: SectionTest.testSectionEditInWikiEditorWhenSyntax2x > >> (xwiki-enterprise-test-ui) is flaky > >> (https://jira.xwiki.org/browse/XWIKI-14394) > >> * XWIKI-14386: appwithinminutes.AppsLiveTableTest.testEditApplication is > >> possibly flaky (https://jira.xwiki.org/browse/XWIKI-14386) > >> * XWIKI-14835: DeletePageTest#deletePageIsImpossibleWhenNoDeleteRights > >> is flickering (https://jira.xwiki.org/browse/XWIKI-14835) > >> * XWIKI-14860: LoginTest#testDataIsPreservedAfterLogin is flickering > >> (https://jira.xwiki.org/browse/XWIKI-14860) > >> > >> And I propose in general to close the flickers we don't remember having > >> seen after a cycle as inactive. > >> > >> WDYT? > >> > >> Simon > >> -- > >> Simon Urli > >> Software Engineer at XWiki SAS > >> simon.u...@xwiki.com > >> More about us at http://www.xwiki.com > > > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.u...@xwiki.com > More about us at http://www.xwiki.com -- Thomas Mortagne
Re: [xwiki-devs] [GSoC] GSoC 2019 has concluded. Congratulations, XWiki students!
Congrats students and thanks for your great contributions ! On Wed, Sep 4, 2019 at 7:00 PM Divyansh Jain wrote: > > Thanks a lot, XWiki team for selecting me. It was a great experience and > through this internship, I learned a lot and improved my skills. Thanks to > my mentor Thomas & Ovsiannikov Aleksei who helped me and guided me > throughout the journey. > > I'm glad that I became a part of XWiki team, I'll keep contributing more to > improve the app. > > Thanks & Regards > Divyansh Jain > > On Wed, 4 Sep 2019 at 17:52, Ecaterina Moraru (Valica) > wrote: > > > Congrats to all of you and thank you for being part of our community. We > > hope you will continue to contribute :) > > Good luck with school! > > Caty > > > > On Wed, Sep 4, 2019, 13:59 Fawad Ali wrote: > > > >> Thanks a lot! > >> > >> It was an absolutely wonderful experience! > >> I had the chance to learn a lot of things. Even things apart from coding > >> which I was not expecting out of GSoC. > >> It is all thanks to the wonderful XWiki community and my mentors. :) > >> Thanks again. > >> > >> Best, > >> Fawad > >> > >> > >> On Wed, Sep 4, 2019 at 3:04 PM Vincent Massol wrote: > >> > >> > Congrats to students and mentors! > >> > > >> > Thanks > >> > -Vincent > >> > > >> > > On 4 Sep 2019, at 11:58, Eduard Moraru wrote: > >> > > > >> > > Hello, GSoC students, mentors, devs, > >> > > > >> > > As you have probably seen by now, the Google Summer of Code 2019 > >> program > >> > > has now concluded: > >> > > > >> > > >> https://opensource.googleblog.com/2019/09/thats-wrap-for-google-summer-of-code.html > >> > > > >> > > We would like to congratulate this year's students that have > >> successfully > >> > > finished their projects. Here's their end of project reports together > >> > with > >> > > some of their impressions of the experience: > >> > > > >> > > * Ashish Sharma - > >> > > > >> > > >> https://www.xwiki.org/xwiki/bin/view/Blog/My%20GSOC%20journey%20with%20xwiki/ > >> > > * Divyansh Jain - > >> > > https://www.xwiki.org/xwiki/bin/view/Blog/My%20GSOC19%20Experience./ > >> > > * Fawad Ali - > >> > > https://gist.github.com/9inpachi/b02fd831de7d79a7f3823634019470c4 > >> > > > >> > > We are very happy to have have had them in XWiki's community during > >> this > >> > > summer. We hope they had a good time while gaining practical > >> experience > >> > and > >> > > guidance in an open source project and that they found XWiki to be an > >> > > interesting and welcoming project that they can continue contributing > >> in > >> > > the future, by either continuously improving their GSoC project or > >> other > >> > > interesting parts of the XWiki project itself. > >> > > > >> > > See you around (on the mailing list, on the chat, forum, github, > >> etc.), > >> > > keep up the good work, good luck at school and thanks for helping the > >> > XWiki > >> > > project grow! > >> > > > >> > > -The XWiki Development Team > >> > > >> > > >> > > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Remove XWiki.User enable property and introduce email_check property
+1 never been a big fan of the duplicate. Would still be better to have a migration in case someone used the new disabled property to avoid bad surprises with security Le jeu. 22 août 2019 à 16:01, Simon Urli a écrit : > Hi everyone, > > I recently (in XWiki 11.6RC1) introduced a new property "enabled" in > XWiki.User as part of https://jira.xwiki.org/browse/XWIKI-12654 to > distinguish between inactive users (who have not confirm their > registration with the token sent by email), and disabled users (who are > deactivated by an admin, or by a security mechanism). > > Now as Marius noticed those two properties are quite redundant, > especially when you want to know which users are really active. > So it introduces unnecessary complexity and we might even need to change > existing extension to check enabled users (cf the last comments on > XWIKI-12564). > > So before doing those changes, I propose to fix immediately the issue by > removing that newly introduced property and by introducing a new > property only for assessing that users' email are checked. > > Then we will only have to check "active" property to check if a user is > active or not, and we could rely on it to set them enabled or disabled > in the admin. > The email_check property would be used only for the check email > mechanism, so it will avoid any confusion in the semantic. > > WDYT? > Simon > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.u...@xwiki.com > More about us at http://www.xwiki.com >
[xwiki-devs] [ANN] XWiki 11.7 RC1 released
The XWiki development team is proud to announce the availability of XWiki 11.7 RC1. This release brings a new date picker and various merge improvements. Developers will also be able to reuse the standard color picker and the merge API give more details about the conflicts. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.7RC1 Thanks for your support -The XWiki dev team
Re: [xwiki-devs] [contrib] any interest in another authenticator that deals with failed logins
Since you did it already and it might be needed by many people who don't plan to upgrade soon +1 to publish it. On Mon, Aug 19, 2019 at 7:44 AM Clemens Klein-Robbenhaar wrote: > > Hi devs. > > I noticed that the recent 11.6.x series have introduced a way to deal > with attempts to guess a users password by introducing a strategy to > handle repeated login failures. I should have payed attention before > this was published because I have been implementing something similar > because of several user requests. > > Anyway, my alternative solution has been finished in parallel, and I > wonder if there is any interest of hosting this as a contrib project. > > The implementation differs in the following details: > > - it does not use the new AuthenticationFailureEvents and the > introduced component API, instead it implements its own XWikiAuthService > - this means it works for 10.x, too (which my users are mostly running) > - otoh it does not work with e.g. the LDAPAuthenticator > - it also allows to block IPs (not that I care much about, but some > people want this) > - it unblocks the user after a given time frame without having an > Admin to intervene > > I guess I can migrate at least most of it into the new > AuthenticationFailureStrategy to have a showcase for a different > implementation, Could be interesting too yes. > but for now it is a separate and already slightly > outdated implementation. > > I think I will upload the results to e.x.o anyway (with a big note that > this is superseded since XWiki 11.6), but is there any interest of > hosting this as an xwiki-contrib project, maybe with the name > 'authenticator-blocking', package 'org.xwiki.contrib.blockingauth' and > maybe even a Jira project like 'BLOCKINGAUTH' ? > > Best, > Clemens > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Best practice: tests must not output anything outside of the target directory
Big +1 for this best practice of course.
And indeed it would be nice to have a share test tool (a junit 5
extension probably) to get a temporary test folder to work and which
is consistent.
What I do in all the tests that needs such a folder is:
File testDirectory = new File("target/test-" + new
Date().getTime()).getAbsoluteFile();
On Thu, Aug 1, 2019 at 10:43 AM Simon Urli wrote:
>
> Hi Vincent,
>
> On 01/08/2019 10:35, Vincent Massol wrote:
> > Hi devs,
> >
> > I was pretty sure that this was discussed before but I can’t find it so I’m
> > posting it again since I noticed that we continue to have tests (and even
> > add new ones) that use the OS tmp directory to output test data.
> >
> > Tests must not generate anything outside of the target/ directory as this
> > will cause several problems:
> > * not clean generated test data after the test
> > * create a state that can make other tests fail
> > * generate errors in jenkins since jenkins monitors created files and
> > doesn't allow to remove files outside of the worskspace
> >
> > WDYT?
> >
> > If ok I’ll add it to
> > https://dev.xwiki.org/xwiki/bin/view/Community/Testing/JavaUnitTesting/#HBestpractices
>
> I agree on the principle, but before adding it we need a utility method
> to know where to put those resources: I guess it would return a relative
> path to the target directory of the current module, but we need this
> method to avoid having to rely on explicit paths in our tests.
>
> It might also allow us to clean automatically those paths in a tearDown
> method if we want.
>
> Simon
> >
> > Thanks
> > -Vincent
> >
> > PS: Ideally we should have a automatic verification in the build but it
> > doesn’t seem easy to implement, so right now, I’m only proposing it as a
> > best practice.
> >
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> simon.u...@xwiki.com
> More about us at http://www.xwiki.com
--
Thomas Mortagne
Re: [xwiki-devs] [VOTE] Officially support for Tomcat 9
Updated https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletContainerSupportStrategy/. On Wed, Jul 31, 2019 at 4:05 PM Thomas Mortagne wrote: > > So Debian decided for us: tomcat8 is not provided anymore in the > current Debian stable (buster) so looks like we need to start putting > tomcat 9 in our tests. > > On Thu, Apr 18, 2019 at 5:16 PM Ecaterina Moraru (Valica) > wrote: > > > > +1 > > > > Thanks, > > Caty > > > > On Mon, Apr 15, 2019 at 10:27 AM Vincent Massol wrote: > > > > > > > > > > > > On 13 Apr 2019, at 12:59, Thomas Mortagne > > > wrote: > > > > > > > > On Sat, Apr 13, 2019 at 11:39 AM Vincent Massol > > > wrote: > > > >> > > > >> Since it’s a vote I think I am -1 to support both Tomcat 8.x and 9.x at > > > the same level (I could change that to a -0 if everyone else agrees). > > > >> > > > >> For 2 reasons: > > > >> * I feel we’re don’t have enough agent power to support so many configs > > > - we already have too many IMO, and each new config increases the test > > > time > > > exponentially. > > > >> * I’d really like that we continue having a single version for each > > > infra server in our docker-latest job. > > > >> > > > >> So I’m proposing one of the following 2 options: > > > >> > > > >> Option 1: Tomcat 8.x stays the supported version > > > >> === > > > >> > > > >> * Continue delivering XWiki on Tomcat 8.x by default. For ex the Docker > > > image continue to be on Tomcat 8.x, see the tags on > > > https://hub.docker.com/_/xwiki?tab=description > > > >> * Offer a preview for Tomcat 9.x but don’t consider it as being > > > officially supported. This means mentioning the “preview” in the various > > > docs. > > > >> * On the test side, this means adding it to docker-unsupported > > > >> > > > >> Option 2: Tomcat 9.x becomes the latest supported version > > > >> === > > > >> > > > >> * Consider that Tomcat 9.x is now the latest version of Tomcat, i.e. > > > make it go in the docker-latest build (ie all tests execute on it). > > > Executed daily. > > > >> * Consider that Tomcat 8.x is now an older version of Tomcat (but still > > > supported) and move all Tomcat 8.x tests to docker-all (ie only smoke > > > tests > > > on it). Executed weekly. > > > >> * Upgrade the official Docker image to use Tomcat 9.x. More generally > > > upgrade all distributions to use Tomcat 9.x. Note that we support only 1 > > > version of Tomcat in the Docker images we distribute. > > > >> > > > >> The only question I’m asking is whether Tomcat 9.x is stable enough for > > > using it in production vs Tomcat 8.x (8.5.x to be precise). Note that > > > Tomcat 8.5.x contains backports from Tomcat 9.x AFAIK and the main > > > difference is just the supported Servlet spec (AFAICS). > > > >> > > > >> So if we wish to make a move, I’d prefer option 2 but I don’t know if I > > > know enough about Tomcat 8.5.x vs Tomcat 9.x in production to make an > > > educated decision. I’d be curious to know if users would be ok to run > > > Tomcat 9.x in production. Now we would still support 8.5.x so users who > > > want to stay on Tomcat 8.5.x can. > > > >> > > > >> WDYT? > > > >> > > > >> Thanks > > > >> -Vincent > > > >> > > > >> PS: I thought I saw a jira issue being closed on this topic, did I > > > dream it or did you anticipate the vote results? ;) > > > > > > > > Providing a Debian package which work with Tomcat 9 does not make it > > > > officially supported as you said. > > > > > > For me it kind of does because I don’t see how we would officially provide > > > a package and not test it (and if we test it then it’s officially > > > supported). > > > > > > Unless we explicitly mark is as experimental so that users know that it’s > > > not supported when they use it. > > > > > > Thanks > > > -Vincent > > > > > > > > > > >> > > > >>> On 12 Apr 2019, at 17:53, Thomas Mortagne > > > wrote: > > > >>> > > > >>> On Fri, Apr 12, 2019 at
Re: [xwiki-devs] [VOTE] Officially support for Tomcat 9
So Debian decided for us: tomcat8 is not provided anymore in the current Debian stable (buster) so looks like we need to start putting tomcat 9 in our tests. On Thu, Apr 18, 2019 at 5:16 PM Ecaterina Moraru (Valica) wrote: > > +1 > > Thanks, > Caty > > On Mon, Apr 15, 2019 at 10:27 AM Vincent Massol wrote: > > > > > > > > On 13 Apr 2019, at 12:59, Thomas Mortagne > > wrote: > > > > > > On Sat, Apr 13, 2019 at 11:39 AM Vincent Massol > > wrote: > > >> > > >> Since it’s a vote I think I am -1 to support both Tomcat 8.x and 9.x at > > the same level (I could change that to a -0 if everyone else agrees). > > >> > > >> For 2 reasons: > > >> * I feel we’re don’t have enough agent power to support so many configs > > - we already have too many IMO, and each new config increases the test time > > exponentially. > > >> * I’d really like that we continue having a single version for each > > infra server in our docker-latest job. > > >> > > >> So I’m proposing one of the following 2 options: > > >> > > >> Option 1: Tomcat 8.x stays the supported version > > >> === > > >> > > >> * Continue delivering XWiki on Tomcat 8.x by default. For ex the Docker > > image continue to be on Tomcat 8.x, see the tags on > > https://hub.docker.com/_/xwiki?tab=description > > >> * Offer a preview for Tomcat 9.x but don’t consider it as being > > officially supported. This means mentioning the “preview” in the various > > docs. > > >> * On the test side, this means adding it to docker-unsupported > > >> > > >> Option 2: Tomcat 9.x becomes the latest supported version > > >> === > > >> > > >> * Consider that Tomcat 9.x is now the latest version of Tomcat, i.e. > > make it go in the docker-latest build (ie all tests execute on it). > > Executed daily. > > >> * Consider that Tomcat 8.x is now an older version of Tomcat (but still > > supported) and move all Tomcat 8.x tests to docker-all (ie only smoke tests > > on it). Executed weekly. > > >> * Upgrade the official Docker image to use Tomcat 9.x. More generally > > upgrade all distributions to use Tomcat 9.x. Note that we support only 1 > > version of Tomcat in the Docker images we distribute. > > >> > > >> The only question I’m asking is whether Tomcat 9.x is stable enough for > > using it in production vs Tomcat 8.x (8.5.x to be precise). Note that > > Tomcat 8.5.x contains backports from Tomcat 9.x AFAIK and the main > > difference is just the supported Servlet spec (AFAICS). > > >> > > >> So if we wish to make a move, I’d prefer option 2 but I don’t know if I > > know enough about Tomcat 8.5.x vs Tomcat 9.x in production to make an > > educated decision. I’d be curious to know if users would be ok to run > > Tomcat 9.x in production. Now we would still support 8.5.x so users who > > want to stay on Tomcat 8.5.x can. > > >> > > >> WDYT? > > >> > > >> Thanks > > >> -Vincent > > >> > > >> PS: I thought I saw a jira issue being closed on this topic, did I > > dream it or did you anticipate the vote results? ;) > > > > > > Providing a Debian package which work with Tomcat 9 does not make it > > > officially supported as you said. > > > > For me it kind of does because I don’t see how we would officially provide > > a package and not test it (and if we test it then it’s officially > > supported). > > > > Unless we explicitly mark is as experimental so that users know that it’s > > not supported when they use it. > > > > Thanks > > -Vincent > > > > > > > >> > > >>> On 12 Apr 2019, at 17:53, Thomas Mortagne > > wrote: > > >>> > > >>> On Fri, Apr 12, 2019 at 5:42 PM Vincent Massol > > wrote: > > >>>> > > >>>> > > >>>> > > >>>>> On 12 Apr 2019, at 17:35, Thomas Mortagne > > wrote: > > >>>>> > > >>>>> On Fri, Apr 12, 2019 at 5:07 PM Vincent Massol > > wrote: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> On 12 Apr 2019, at 17:00, Thomas Mortagne < > > thomas.morta...@xwiki.com> wrote: > > >>>>>>> > > >>>>>>> Hi devs, > >
Re: [xwiki-devs] [Proposal] Use an attribute whitelist for HtmlCleaner restricted mode
Note that this mail is only for the html cleaner. But this white list will also be important to fix https://jira.xwiki.org/browse/XWIKI-9151. On Thu, Jul 25, 2019 at 10:49 AM Simon Urli wrote: > > > > On 25/07/2019 10:39, Simon Urli wrote: > > Hi everyone, > > > > I'm currently working on improving security on XWiki comments. We > > already use a restricted mode in our comments but that does not cover > > every possible case. In order to improve it we should also filter out > > some part of the html when using the html macro. > > > > I propose: > > > >(a) that we use a configurable whitelist of HTML attributes that > > would be allowed in the output HTML: all the other attributes would be > > filtered out. > > > >(b) that the HTML macro is put in restricted mode for users who do > > not have scripting rights. > > > > For (a) I'm hesitating between a whitelist or a blacklist: I assume a > > blacklist would be shorter but there's also more risk of missing > > something. On the contrary a configurable whitelist doesn't prevent > > administrator to accept more than what we give in standard. > > > > A first whitelist could be (taken from: > > https://github.com/xwiki/xwiki-platform/pull/122/files#diff-c33fcb5dca86b155928768dd6e6fbf7eR146) > > > > alt, class, height, id, name, rel, scope, style, target, title, width > > > > Note that href is not included in this list for example. > > IMO the href not being included in the list is related to the > possibility to write something like: > > > Now I guess we could also detect the "javascript:" prefix in the href > attribute in restricted mode and discard only those, I don't see other > usecase where it could be a problem. > > > > > WDYT? > > > > Simon > > > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.u...@xwiki.com > More about us at http://www.xwiki.com -- Thomas Mortagne
Re: [xwiki-devs] Request for Account on Nexus
Done. You should have received a mail to set your password. On Mon, Jul 15, 2019 at 9:45 AM Fawad Ali wrote: > > Hi everyone, > Hope you are doing well. > > I would like to request an account on http://nexus.xwiki.org for the > release of Interactive Maps Application > (org.xwiki.contrib:application-interactive-maps) version 1.0-SNAPSHOT. > > *Requested username:* ginpachi > > Best, > Fawad -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] New wikimacro script binding
On Wed, Jul 3, 2019 at 8:39 AM Simon Urli wrote: > > Hi everyone, > > On 28/06/2019 21:32, Thomas Mortagne wrote: > > On Fri, Jun 28, 2019 at 7:12 PM Vincent Massol wrote: > >> > >> > >> > >>> On 28 Jun 2019, at 19:10, Vincent Massol wrote: > >>> > >>> Hi Simon, > >>> > >>>> On 28 Jun 2019, at 18:56, Simon Urli wrote: > >>>> > >>>> Hi everyone, > >>>> > >>>> this is a proposal to add a new wikimacro script binding for the next > >>>> release, that I also plan to backport on 11.3.x and 10.11.x branches. > >>>> > >>>> We had recently a bug report (https://jira.xwiki.org/browse/XWIKI-16520) > >>>> about the WikiMacro parameter: types were introduce in 10.10 (with > >>>> https://jira.xwiki.org/browse/XWIKI-13282) but we in fact never > >>>> converted them, making their type pretty useless. > >>>> > >>>> We provided a first fix to it actually broke at least one existing > >>>> macro, AttachmentSelector which was still expecting String parameter > >>>> values instead of the types used in some of those parameters. > >>>> > >>>> So even if the parameters were supposed to be typed since XWiki 10.10, > >>>> in practice they never have been. We might as well consider returning a > >>>> typed values as a regression since it might break some of the existing > >>>> macros. > >>>> > >>>> That's why I propose to implement right now a new wikimacro binding, to > >>>> be able to get both typed parameter values and string parameter values. > >>>> The old binding would then still be available by using $xcontext.macro > >>>> but we would deprecate its usage. > >>>> > >>>> I propose that all the existing $xcontext.macro information to be > >>>> available by using $macro, and to be able to use: > >>>> > >>>> * $macro.parameters.foo to get a typed parameter value > > > > +1, we chose params in the previous binding because it's shorter and I > > don't really have anything against it either > > So I did the implementation for this binding, as a matter of fact I had > to use > > $wikimacro instead of $macro because "macro" is already a reserved > binding for velocity. > > So $wikimacro have the same objects as $xcontext.macro except params > which is now parameters and contains converted values. Note: it's not the same object, Simon just mean the same bindings are exposed in both objects. > > The work is done as part of https://jira.xwiki.org/browse/XWIKI-16549. > > Simon > > > >>>> * $macro.parametersAsString.foo to get the string value parameter > > > > I don't think we really need that. Also it does not make much sense > > from API point of view since the input parameter value before > > conversion is not String but Object, macros coming from a wiki source > > will be Strings but it's just a use case. > > > > If we want to provider devs with a way to get the String > > representation of any property we can introduce a > > $services.properties.toString($value) for example. > > > >>>> > >>>> > >>>> Could you tell me if you agree with all those changes? > >>> > >>> Sounds good. > >> > >> Actually I’m hesitating because we said we didn’t want to expose bindings > >> directly in the velocity context. > >> > >> So $services.macro might be better since $services is reserved. > >> > >> Imagine an existing wiki macro doing: > >> > >> #set ($macro = “….”) > >> > >> You would break it. > > > > Why ? > > > > It's not because the macro binding is already set before the execution > > of the macro that the #set will crash. > > > >> > >> Thanks > >> -Vincent > >> > >>> I’m wondering if I wouldn’t prefer the following: > >>> > >>> * $macro.parameters.foo.value() <- typed > > > > -1, it's way too complex for what is supposed to be the thing you want > > to to pretty much all the time > > > >>> * $macro.parameters.foo.rawValue() or toString() <- string, as specified > >>> by the user when using the macro > >>> > >>> $macro.parameters.foo would return some MacroParameter object. > >>> > >>> Note that $macro.parameters.foo when used in a string context would call > >>> $macro.parameters.foo.toString() which would return the raw value. > >>> > >>> Thanks > >>> -Vincent > >>> > >>> > >>> > >>>> > >>>> Thanks, > >>>> Simon > >>>> > >>>> > >>>> -- > >>>> Simon Urli > >>>> Software Engineer at XWiki SAS > >>>> simon.u...@xwiki.com > >>>> More about us at http://www.xwiki.com > >> > > > > > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.u...@xwiki.com > More about us at http://www.xwiki.com -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] New wikimacro script binding
On Fri, Jun 28, 2019 at 7:12 PM Vincent Massol wrote: > > > > > On 28 Jun 2019, at 19:10, Vincent Massol wrote: > > > > Hi Simon, > > > >> On 28 Jun 2019, at 18:56, Simon Urli wrote: > >> > >> Hi everyone, > >> > >> this is a proposal to add a new wikimacro script binding for the next > >> release, that I also plan to backport on 11.3.x and 10.11.x branches. > >> > >> We had recently a bug report (https://jira.xwiki.org/browse/XWIKI-16520) > >> about the WikiMacro parameter: types were introduce in 10.10 (with > >> https://jira.xwiki.org/browse/XWIKI-13282) but we in fact never converted > >> them, making their type pretty useless. > >> > >> We provided a first fix to it actually broke at least one existing macro, > >> AttachmentSelector which was still expecting String parameter values > >> instead of the types used in some of those parameters. > >> > >> So even if the parameters were supposed to be typed since XWiki 10.10, in > >> practice they never have been. We might as well consider returning a typed > >> values as a regression since it might break some of the existing macros. > >> > >> That's why I propose to implement right now a new wikimacro binding, to be > >> able to get both typed parameter values and string parameter values. > >> The old binding would then still be available by using $xcontext.macro but > >> we would deprecate its usage. > >> > >> I propose that all the existing $xcontext.macro information to be > >> available by using $macro, and to be able to use: > >> > >> * $macro.parameters.foo to get a typed parameter value +1, we chose params in the previous binding because it's shorter and I don't really have anything against it either > >> * $macro.parametersAsString.foo to get the string value parameter I don't think we really need that. Also it does not make much sense from API point of view since the input parameter value before conversion is not String but Object, macros coming from a wiki source will be Strings but it's just a use case. If we want to provider devs with a way to get the String representation of any property we can introduce a $services.properties.toString($value) for example. > >> > >> > >> Could you tell me if you agree with all those changes? > > > > Sounds good. > > Actually I’m hesitating because we said we didn’t want to expose bindings > directly in the velocity context. > > So $services.macro might be better since $services is reserved. > > Imagine an existing wiki macro doing: > > #set ($macro = “….”) > > You would break it. Why ? It's not because the macro binding is already set before the execution of the macro that the #set will crash. > > Thanks > -Vincent > > > I’m wondering if I wouldn’t prefer the following: > > > > * $macro.parameters.foo.value() <- typed -1, it's way too complex for what is supposed to be the thing you want to to pretty much all the time > > * $macro.parameters.foo.rawValue() or toString() <- string, as specified by > > the user when using the macro > > > > $macro.parameters.foo would return some MacroParameter object. > > > > Note that $macro.parameters.foo when used in a string context would call > > $macro.parameters.foo.toString() which would return the raw value. > > > > Thanks > > -Vincent > > > > > > > >> > >> Thanks, > >> Simon > >> > >> > >> -- > >> Simon Urli > >> Software Engineer at XWiki SAS > >> simon.u...@xwiki.com > >> More about us at http://www.xwiki.com > -- Thomas Mortagne
Re: [xwiki-devs] [Docker] Move to java11 or drop arm64v8 architecture support?
I'm fine with moving the Java 11 on Docker. On Thu, Jun 27, 2019 at 9:32 AM Vincent Massol wrote: > > Hi guys, > > We have a decision to take re the docker image. > > Until now we were supporting the arm64v8 architecture. However due to some > changes, it's now ony supported with java11. So we have 2 solutions for the > tomcat base image to use: > > 1) stay on java8 and move to the adoptopenjdk base image (so that we get java > patches) BUT drop support for arm64v8 architectures > 2) move to java11 and move to the adoptopenjdk base image (so that we get > java patches) and keep support for arm64v8 archietectures > > My POV is that we should do 1) since XWiki is supposed to run well on Java11 > (it may even be faster on it?) and we want it to work on it anyway. We also > test it with our docker tests every week > > Side note: we could also decide to move to java11 everywhere on our CI agents > and keep some tests weekly on java8 (ie invert the current situation) > > WDYT? > > Thanks > -Vincent -- Thomas Mortagne
[xwiki-devs] [ANN] XWiki 11.5RC1 released
The XWiki development team is proud to announce the availability of XWiki 11.5RC1. This release continue the work on improving concurrent editing of documents, introduce new page and attachment pickers for macros. The code macro get a new layout to display line numbers. Inline editing support for wiki macro also been greatly improved. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.5RC1 Thanks for your support -The XWiki dev team
Re: [xwiki-devs] [Proposal] Rerun flaky tests several times?
+1 On Mon, Jun 10, 2019 at 11:43 AM Vincent Massol wrote: > > Hi devs, > > I was looking for a rerun optin in JUnit5 or Surefire but it seems it doesn’t > exist for Junit5: > * https://github.com/junit-team/junit5/issues/1558 > * https://issues.apache.org/jira/browse/SUREFIRE-1584 > > However, there’s an extension to do that: > * https://github.com/artsok/rerunner-jupiter > > Also WIP for JUnit Pioneer: > * https://github.com/junit-pioneer/junit-pioneer/pull/110 > > So my proposal FTM is to try https://github.com/artsok/rerunner-jupiter and > to start putting a repeat of 3 for JUnit5 tests that we know are flaky. > > For JUnit4 tests we could simply use: > * > https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html > > Note that this would also allow us to correct flaky tests that don’t set up > the initial conditions (fixture) correctly. > > Second note: This is not an endorsement that we should accept flaky tests. > They’re a plague and we need to work on them and fix them. This is just a > momentary workaround to identify how flaky a test is and to try to have a > better solution towards moving to a Continuous Delivery solution. > > WDYT? > > Thanks > -Vincent > -- Thomas Mortagne
Re: [xwiki-devs] [VOTE] API breakage - Extension point org.xwiki.platform.html.head
+1, it's new enough and the current one is really not great Should be cherry-picked in 11.3.x branch to make the change effective ASAP. On Thu, Jun 6, 2019 at 12:54 PM Stéphane Laurière wrote: > > Hi devs, > > I'm opening this vote in order to propose an API breakage consisting in > renaming the extension point "org.xwiki.platform.head" to > "org.xwiki.platform.html.head". The former identifier was introduced too > early by mistake in 11.1RC1 due to an omission by me, apologies, but it does > not fit well because it does not self-explain that it targets the html head. > Here is the extension point documentation page: > > > https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/ExtensionPoint/HTMLHead > > As far as I know, there's just one public extension using this extension > point for now, it's the OpenGraph Application, which already uses the new > identifier: > > > https://extensions.xwiki.org/xwiki/bin/view/Extension/OpenGraph%20Application/ > > Further information about the change is available in the following pull > request, which requires among other things that this vote passes: > >https://github.com/xwiki/xwiki-platform/pull/1115 > > Thanks to Caty for spotting the issue and the guidance on how to fix it, and > to Simon and Vincent. > > Kind regards > > Stéphane > > > -- > Stéphane Laurière > XWiki – https://xwiki.com > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Update database support strategy
gt;>>>>
> >>>>> Thanks
> >>>>> -Vincent
> >>>>>
> >>>>>> On 13 Nov 2018, at 11:50, Guillaume Delhumeau <
> >>>> guillaume.delhum...@xwiki.com> wrote:
> >>>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> We are in a weird situation where we don't say we support MariaDB but
> >>>>>> "the latest
> >>>>>> MySQL version of stable Debian repository", which is currently...
> >>>> MariaDB
> >>>>>> [1]
> >>>>>>
> >>>>>> So we need to update our strategy about this fact. I am currently
> >>>> setting
> >>>>>> up a server with debian 9 (stable) and I don't know if I should install
> >>>>>> MySQL from the Oracle repository our continue with the standard debian
> >>>>>> package (MariaDB).
> >>>>>>
> >>>>>> On my side, I am not against aligning ourself to debian. Basically, all
> >>>>>> users installing XWiki with our Debian packages are using MariaDB for a
> >>>>>> year now [2], and we never encounter any problem so far.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> [1] https://packages.debian.org/stretch/default-mysql-server (dep:
> >>>>>> mariadb-server-10.1)
> >>>>>> [2] https://www.debian.org/News/2017/20170617.en.html
> >>>>>>
> >>>>>> Le lun. 12 nov. 2018 à 18:54, Thomas Mortagne <
> >>>> thomas.morta...@xwiki.com> a
> >>>>>> écrit :
> >>>>>>
> >>>>>>> Indeed mysql-server package (version 5.5.) leads to
> >>>>>>> mariadb-server-10.1 in current stretch repository.
> >>>>>>>
> >>>>>>> What is surprising is that this is not the case for sid which is more
> >>>>>>> or less supposed to be the future. It's also not the case in Ubuntu
> >>>>>>> which is doing the same thing as sid.
> >>>>>>> On Mon, Nov 12, 2018 at 6:22 PM Eduard Moraru
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> I am not up to date on the topic, but I would like to add the fact
> >>>> that
> >>>>>>>> Debian 9 ("stretch") has actually dropped MySQL and moved officially
> >>>> to
> >>>>>>>> MariaDB, forcefully migrating existing MySQL installed versions to
> >>>>>>> MariaDB.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#mariadb-replaces-mysql
> >>>>>>>>
> >>>>>>>> The default mysql-server package now redirects to MariaDB instead.
> >>>>>>>>
> >>>>>>>> If we are going to follow Debian's lead, we might want to at least
> >>>>>>> consider
> >>>>>>>> this move.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Eduard
> >>>>>>>>
> >>>>>>>> On Mon, Nov 12, 2018 at 6:38 PM Vincent Massol
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On 12 Nov 2018, at 16:52, Vincent Massol
> >>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> So we need to conclude on this thread. I’m proposing to update the
> >>>>>>> page
> >>>>>>>>> with:
> >>>>>>>>>>
> >>>>>>>>>> * HSQLDB - Latest only
> >>>>>>>>>> * MySQL - latest of oldstable/stable/unstable from
> >>>>>>>>>
> >>>>>>>
> >>>> https://packages.debian.org/search?keywords=mysql-server=names=1
> >>>>>>>>> (i.e. latest of 5.5.x and 5.7.x today)
> >>>>>>>>>> * PostgreSQL - latest of oldstable/stable/unstable fromhttps://
> >>>>>&
Re: [xwiki-devs] [Proposal] Remove not supported HBM files
+1 for the move but I would create a different repo for each one. On Wed, Jun 5, 2019 at 9:49 AM Vincent Massol wrote: > > Hi devs, > > Right now we bundle 3 HBM files for DBs we don’t support: derby, mssql and > db2. So we can’t guarantee that they work and it’s possible they don’t > anymore after the Hibernate upgrade. > > I propose to do the following: > > * Create a single repo in contrib to host them. hibernate-mappings-extra or > something like that > * Document how to install these mappings in the page for each of these DBs. > For ex for DB2 it would be documented on > https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/InstallationWAR/InstallationDB2/, > etc. > > The only downside is that when we make chages to the HBM files we support we > won’t make the same adjustements for these non supported DBs… OTOH we don’t > support them... > > WDYT? > > Thanks > -Vincent > -- Thomas Mortagne
Re: [xwiki-devs] [Brainstorming] Controlling transformations
Yes the rest is fine and 5 days is comfortable IMO. On Wed, May 29, 2019 at 1:59 PM Vincent Massol wrote: > > Hi Thomas, > > > On 21 May 2019, at 14:20, Thomas Mortagne wrote: > > > > bq. * Make RenderingConfiguration.getTransformationNames() search in > > the current page, parent pages (spaces), current wiki, and fallback to > > xwiki.properties > > > > The document currently in the XWikiContext when you call > > RenderingConfiguration.getTransformationNames() often does not have > > much to do with content you are currently executing so it's not a good > > criteria IMO. It would make more sense (and be much easier) to have > > the display module get this information like it gets the content to > > execute and pass the list of transformations to the > > TransformationContext (which then end up in the RendereringContext). > > Indeed, good point. > > Does it mean you’re ok with the rest of the brainstorming/proposal? > > Any other input on this? > > I’m estimating the time to implement this at about 5 days of work. @Thomad > and all: WDYT? > > Thanks > -Vincent > > > > > On Tue, May 21, 2019 at 2:07 PM Vincent Massol wrote: > >> > >> Hi devs, > >> > >> I’d like to discuss about how to control transformations and when they are > >> executed. Right now we have an all-or-nothing strategy (either the > >> transformation is defined in the config property or it’s not). > >> > >> We have some needs to be able to turn on/turn off some transformations on > >> a page level basis. > >> > >> Here’s the idea that I put on https://jira.xwiki.org/browse/XWIKI-15100: > >> > >> * Add a new xproperty to Rendering.RenderingConfigClass > >> * Modify java code: XWikiRenderingConfiguration, > >> ExtendedRenderingConfiguration, DefaultExtendedRenderingConfiguration, > >> RenderingConfigClassDocumentConfigurationSource > >> * For the wiki level, get the config in Rendering.RenderingConfig > >> * For the page level, get the config from an xobject of type > >> Rendering.RenderingConfigClass > >> * Make RenderingConfiguration.getTransformationNames() search in the > >> current page, parent pages (spaces), current wiki, and fallback to > >> xwiki.properties > >> > >> Note that, as Thomas pointed out in comment of > >> https://jira.xwiki.org/browse/XWIKI-15100 the last point is the hard one. > >> We could imagine having a transformation cache that would be loaded at > >> startup and updated whenever a XWiki.RenderingConfigClass xobject is > >> modified in the wiki. Very similar to wiki components. > >> > >> Note: We could also implement https://jira.xwiki.org/browse/XWIKI-13167 at > >> the same time, with the query string in the URL overriding the > >> transformations. > >> > >> WDYT? > >> > >> Any idea of the cost of adding such a feature in term of days? Does 7 days > >> sounds good to you? (inluding testing and doc). > >> > >> Thanks > >> -Vincent > >> > > > > > > -- > > Thomas Mortagne > -- Thomas Mortagne
Re: [xwiki-devs] Improve Android XWiki authenticator GSOC-19
Hi Divyansh, Thanks for all these information ! It would be great if you could give us a sense of what's your planning and when we can expect the first testable milestone with your work in it. On Sat, May 25, 2019 at 8:38 AM Divyansh Jain wrote: > > Hello, devs > > My name is Divyansh Jain. I’m pursuing me under graduation in BCA. Bachelor > of Computer Application in Mahatma Jyoti Rao Phoole University Campus. > Currently, I’m in my sixth semester. I’m an avid and enthusiastic > programmer with strong experience in Java and Android. I'll be working on > the XWiki Android Authenticator App in this GSOC19. I've already submitted > my proposal on http://design.xwiki.org/xwiki/bin/view/Main/ Here's the link > to my proposal: > > >- > > https://design.xwiki.org/xwiki/bin/view/Proposal/Codemigrationandfixexistingbugs >- > > https://design.xwiki.org/xwiki/bin/view/Proposal/ImproveXWikiAndroidApplication > > Though there are still some areas where I still need to study/practice*:* > >- Kotlin (working on sample projects of my own) >- OCID (Need to watch some more google developer videos like >https://www.youtube.com/watch?v=DdQTXrk6YTk=youtu.be )e It's good that you are researching but don't hesitate to ask questions too. I implemented the OIDC provider in XWiki so I can at least help you regarding what you can expect from it and what's currently missing for your need. >- Unit Test (Practicing on sample projects.) >- AccountManager for adding several accounts in the XWiki Authenticator >page. > > I'm very excited to work with all of you devs. I've already started working > on migrating code in MVVM architecture and fixing existing bugs some of > which are merged: > >- >https://jira.xwiki.org/projects/ANDAUTH/issues/ANDAUTH-48?filter=doneissues >- >https://jira.xwiki.org/projects/ANDAUTH/issues/ANDAUTH-49?filter=doneissues >- >https://jira.xwiki.org/projects/ANDAUTH/issues/ANDAUTH-47?filter=doneissues >- >https://jira.xwiki.org/projects/ANDAUTH/issues/ANDAUTH-27?filter=doneissues > > > Regards, > Divyansh Jain -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Merge on save
on the 'default' and implement that. We keep adding options that > >>>>> only increase the complexity of the product and we never get to test all > >>>>> the possible mixes and configurations. > >>>>> So what are the use cases when we would need this option in the profile? > >>>> > >>>> As I said above I personally don't see the point of always displaying > >>>> the merge diff especially for basic users when there's no conflict. Now > >>>> I really think that some users would want that, that's why I proposed > >>>> the profile option. > >>> I agree that option 3 is not great as it gets in the way. Now it could be > >>> interesting for the user to know it happened. Maybe some fleeting > >>> notifications at the bottom of the screen or some info added to the > >>> commit message or some visual info when you’re in edit mode and before > >>> you press save. > >> > >> So in case of "Save" it's quite easy to change the "Saved" > >> notification message by another one. I'm not quite sure how to inform the > >> user about the merge if he cliks on "Save”. > > > > By implementing the part below :) ie by providing this info continuously > > before he clicks any save button. > > > >> > >>> Ideally I’d like that we poll regularly to see if there have been changes > >>> and display some icon if there are with the ability for the current user > >>> to click and see the diffs with his version, and if there’s a conflict, > >>> that a visible message is displayed on the screen (but without > >>> interrupting of his typing). > > > > More details: when there’s a conflict, clicking the message/button would > > show the diff and the conflict. > > > >>> And when he saves, the merge is done then. > >> > >> I like the idea, now would that be enough to inform about the performed > >> merge? If we go in that direction I'd need some design proposal for the UI > >> @Caty :) > > > > Yes we need to find where to put that information. > > > > BTW, even better, we should ideally also display the icons of the users who > > are editing the same doc and/or who have saved content after the current > > user started editing. > > > > And we already have a design page for this ;) We called it “collaborative > > editing”: > > https://design.xwiki.org/xwiki/bin/view/Improvements/CollaborativeEditing > > > > Thanks > > -Vincent > > > >> > >> Simon > >> > >>> WDYT? > >>> Thanks > >>> -Vincent > >>>> > >>>> Simon > >>>>> Thanks, > >>>>> Caty > >>>>> On Wed, May 22, 2019 at 12:04 PM Vincent Massol > >>>>> wrote: > >>>>>> Hi Simon, > >>>>>> > >>>>>>> On 22 May 2019, at 10:45, Simon Urli wrote: > >>>>>>> > >>>>>>> Hi everyone, > >>>>>>> > >>>>>>> I'm working on the merge on save for the roadmap of 11.5 and I need > >>>>>>> some > >>>>>> decision to be taken. > >>>>>>> > >>>>>>> The main idea of the merge on save, is to try to merge users work in > >>>>>> case of save conflict. Knowing that the merge might led to merge > >>>>>> conflict > >>>>>> in case of edits on the same places. Those merge conflict can be > >>>>>> tackled > >>>>>> automatically, but a priority will be then given to one version over > >>>>>> another. > >>>>>>> > >>>>>>> I first propose to add an option in user profile, so users would have > >>>>>> the possibility to choose between: > >>>>>>> 1. Always merge automatically the work, even in case of merge > >>>>>>> conflict > >>>>>> > >>>>>> I don’t understand this part. If there’s a conflict it means it cannot > >>>>>> be > >>>>>> merged… So would it do? Take latest version and overwrite previous > >>>>>> version? > >>>>>> > >>>>>>> 2. Always merge automatically, but ask what to do in case of merge > >>>>>> conflict > >>>>>>> 3. Always ask what to do in case of save conflict > >>>>>>> > >>>>>>> Now the question is: what should be the default option? > >>>>>> > >>>>>> Certainly not 1! 2 is really the best to me. > >>>>>> > >>>>>> Thanks > >>>>>> -Vincent > >>>>>> > >>>>>>> Option 1 looks like a good fit for decreasing the number of clicks to > >>>>>> do, but I'm a bit afraid that in case of conflict they would have the > >>>>>> same > >>>>>> feeling as before the warning conflict window: i.e. to loose some part > >>>>>> of > >>>>>> their work. > >>>>>>> > >>>>>>> WDYT? > >>>>>>> > >>>>>>> Simon > >>>>>>> > >>>>>>> -- > >>>>>>> Simon Urli > >>>>>>> Software Engineer at XWiki SAS > >>>>>>> simon.u...@xwiki.com > >>>>>>> More about us at http://www.xwiki.com > >>>>>> > >>>>>> > >>>> > >>>> -- > >>>> Simon Urli > >>>> Software Engineer at XWiki SAS > >>>> simon.u...@xwiki.com > >>>> More about us at http://www.xwiki.com > >> > >> -- > >> Simon Urli > >> Software Engineer at XWiki SAS > >> simon.u...@xwiki.com > >> More about us at http://www.xwiki.com > > > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.u...@xwiki.com > More about us at http://www.xwiki.com -- Thomas Mortagne
Re: [xwiki-devs] [Brainstorming] Controlling transformations
bq. * Make RenderingConfiguration.getTransformationNames() search in the current page, parent pages (spaces), current wiki, and fallback to xwiki.properties The document currently in the XWikiContext when you call RenderingConfiguration.getTransformationNames() often does not have much to do with content you are currently executing so it's not a good criteria IMO. It would make more sense (and be much easier) to have the display module get this information like it gets the content to execute and pass the list of transformations to the TransformationContext (which then end up in the RendereringContext). On Tue, May 21, 2019 at 2:07 PM Vincent Massol wrote: > > Hi devs, > > I’d like to discuss about how to control transformations and when they are > executed. Right now we have an all-or-nothing strategy (either the > transformation is defined in the config property or it’s not). > > We have some needs to be able to turn on/turn off some transformations on a > page level basis. > > Here’s the idea that I put on https://jira.xwiki.org/browse/XWIKI-15100: > > * Add a new xproperty to Rendering.RenderingConfigClass > * Modify java code: XWikiRenderingConfiguration, > ExtendedRenderingConfiguration, DefaultExtendedRenderingConfiguration, > RenderingConfigClassDocumentConfigurationSource > * For the wiki level, get the config in Rendering.RenderingConfig > * For the page level, get the config from an xobject of type > Rendering.RenderingConfigClass > * Make RenderingConfiguration.getTransformationNames() search in the current > page, parent pages (spaces), current wiki, and fallback to xwiki.properties > > Note that, as Thomas pointed out in comment of > https://jira.xwiki.org/browse/XWIKI-15100 the last point is the hard one. We > could imagine having a transformation cache that would be loaded at startup > and updated whenever a XWiki.RenderingConfigClass xobject is modified in the > wiki. Very similar to wiki components. > > Note: We could also implement https://jira.xwiki.org/browse/XWIKI-13167 at > the same time, with the query string in the URL overriding the > transformations. > > WDYT? > > Any idea of the cost of adding such a feature in term of days? Does 7 days > sounds good to you? (inluding testing and doc). > > Thanks > -Vincent > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Roadmaps for 11.5 and 11.6
Looks good to me On Tue, May 21, 2019 at 11:23 AM Vincent Massol wrote: > > Hi devs, > > Here’s a proposal for 11.5 + 11.6, discussed with Thomas, Marius and Simon > already. > > XWiki 11.5 > == > > * BFD: All > * Hibernate upgrade to finish - Assignee: Thomas > * "Finish the autocomplete of references which has been dropped since Adel > left and we still don't have it in the WYSIWYG + implement autocomplete on > attachments.”. - Assignee: Marius > * Merge on Save: https://jira.xwiki.org/browse/XWIKI-175 - Assignee: Simon > > Dates: > * 11.5RC1: 17 June 2019 > * 11.5: 24 June 2019 > > XWiki 11.6 > = > > * BFD: All > * Velocity upgrade (too dangerous for 11.2/11.3) - Assignee: Thomas > * Security: Add permissions for xobjects to prevent giving all permissions to > users with edit rights on a page. - Assignee: Marius (+ Thomas)? > * Limit number of login attempts until user gets blocked - > http://jira.xwiki.org/browse/XWIKI-15488 - Assignee: Simon ? > > Dates: > * 11.6RC1: 22 July 2019 (added one more week due to the XWiki SAS seminar) > * 11.6: 29 July 2019 > > Others > == > > The following item couldn’t be planned for 11.5 or 11.6 due to lack of > time/manpower but we should consider it for 11.7+: > * Better handling of user removal and transfer of rights ( > http://jira.xwiki.org/browse/XWIKI-12142 ) > > WDYT? > > @devs: please confirm that you’re ok. @Simon, please let me know if it’s ok > for the item where there’s a question mark. @Marius: same for you. > > @evalica: I didn’t put any investigations/designs but we should IMO. Any > proposals? > > Thanks > -Vincent > -- Thomas Mortagne
Re: [xwiki-devs] Map Application - GSoC 19
list of locations to choose from. > > > > Through the content available and binded to a location, the user will > > be > > > > able to learn some aspects of the location. > > > > > *Custom shapes* - Custom shapes can be used to highlight a specific > > > area > > > > for representation. The content associated with these shapes can give > > > > useful information about the area. > > > > > *Indoor maps* - Such maps will be able to describe the internal > > > structure > > > > or fair plan of a building or structure. They can be used to guide > > users > > > in > > > > a big building and locate point of interests. > > > > > *Maps on mobile* - Special design arrangements will be made for > > easily > > > > viewing of maps and availing all the features of the application on > > > mobile > > > > devices. > > > > > *Custom map backgrounds* - Custom backgrounds will make the > > environment > > > > of interactive maps much suitable for a specific purpose > > > > > > > > If you have any features in mind that will make the Map Application > > > better > > > > please feel free to reply to this mail. > > > > This is all for the summary of the project, if you want to have a more > > > > deeper insight, please check out the full proposal. > > > > > > > > *Project Proposal: * > > > > https://drive.google.com/open?id=14qXC7Oy2bPUASfVtSTIsNG1sPcfm5Ikr > > > > > > > > > > > > Thanks for reading through the mail. I will be looking forward to your > > > > guidance through this summer and your contributions to the project. > > > > If you have any questions or suggestions, please feel free to reply to > > > this > > > > mail. > > > > > > > > Au revoir. :) > > > > > > > > Best, > > > > Fawad Ali > > > > > > > > > -- Thomas Mortagne
Re: [xwiki-devs] Building/Installing XWiki Platform
The very first build does download a lot of stuff yes. Following builds are a lot faster, Maven only automatically refresh SNAPSHOT dependencies only every day but you can cancel that with -o if you know you want to use only local stuff. On Thu, May 16, 2019 at 11:45 AM Mua Rachmann wrote: > > Hi Thomas, > > Just to give you an update and I am a little frustrated since i got the > codebase. I haven't been able to > get it running. I switched to the rendering submodule to build and it is > still taking forever to download the dependencies and stuffs. > > How long can be the waiting time? I feel like i am not doing something > right sadly. > Do i keep waiting for the downloads to finish? cause its been a while it is > still downloading > > Regards, > Mua > > On Wed, May 15, 2019, 07:58 Thomas Mortagne > wrote: > > > Looks like your local clone of xwiki-platform has version 2.10.1 of > > Joda Time (which was just upgraded) in the root pom. You should make > > sure to git pull and build again with -U. > > > > On Tue, May 14, 2019 at 7:19 PM Mua Rachmann > > wrote: > > > > > > Hi Thomas, Vicent > > > > > > I signed up for jira and i am very much interested in the > > > xwiki-platform-rendering project. I have been trying to build it since > > and > > > it still keeps > > > downloading. > > > > > > What i did. > > > - Cloned the fork of my repo > > > - cd into xwiki-platform-core/xwiki-platform-rendering/ > > > - ran mvn clean install > > > > > > I get the following error log > > > > > > [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-upper-bounds) @ > > > xwiki-platform-rendering-async-default --- > > > [INFO] artifact io.sf.jclf:jclf: checking for updates from xwiki-releases > > > [INFO] artifact io.sf.jclf:jclf: checking for updates from central > > > [WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireUpperBoundDeps > > > failed with message: > > > Failed while enforcing RequireUpperBoundDeps. The error(s) are [ > > > Require upper bound dependencies error for joda-time:joda-time:2.10.1 > > paths > > > to dependency are: > > > +-org.xwiki.platform:xwiki-platform-rendering-async-default:11.4-SNAPSHOT > > > +-org.xwiki.platform:xwiki-platform-oldcore:11.4-SNAPSHOT > > > +-joda-time:joda-time:2.10.1 (managed) <-- joda-time:joda-time:2.10.2 > > > and > > > +-org.xwiki.platform:xwiki-platform-rendering-async-default:11.4-SNAPSHOT > > > +-org.xwiki.platform:xwiki-platform-oldcore:11.4-SNAPSHOT > > > +-org.xwiki.platform:xwiki-platform-office-importer:11.4-SNAPSHOT > > > +-org.xwiki.platform:xwiki-platform-tika-parsers:11.4-SNAPSHOT > > > +-org.apache.tika:tika-parsers:1.20 > > > +-edu.ucar:cdm:4.5.5 > > > +-joda-time:joda-time:2.10.1 (managed) <-- > > > joda-time:joda-time:2.2 > > > and > > > +-org.xwiki.platform:xwiki-platform-rendering-async-default:11.4-SNAPSHOT > > > +-org.xwiki.platform:xwiki-platform-oldcore:11.4-SNAPSHOT > > > +-org.xwiki.platform:xwiki-platform-office-importer:11.4-SNAPSHOT > > > +-org.xwiki.platform:xwiki-platform-tika-parsers:11.4-SNAPSHOT > > > +-org.apache.tika:tika-parsers:1.20 > > > +-edu.ucar:cdm:4.5.5 > > > +-edu.ucar:udunits:4.5.5 > > > +-joda-time:joda-time:2.10.1 (managed) <-- > > > joda-time:joda-time:2.2 > > > ] > > > [INFO] > > > > > > [INFO] Reactor Summary for XWiki Platform - Rendering - Parent POM > > > 11.4-SNAPSHOT: > > > [INFO] > > > [INFO] XWiki Platform - Rendering - Parent POM SUCCESS > > [01:31 > > > min] > > > [INFO] XWiki Platform - Rendering - Async - Parent POM SUCCESS [ > > > 9.470 s] > > > [INFO] XWiki Platform - Rendering - Async - API ... SUCCESS > > [01:21 > > > min] > > > [INFO] XWiki Platform - Rendering - Async - Default ... FAILURE > > [03:22 > > > min] > > > [INFO] XWiki Platform - Rendering - Configuration - Parent POM SKIPPED > > > [INFO] XWiki Platform - Rendering - Configuration - API ... SKIPPED > > > [INFO] XWiki Platform - Rendering - Configuration - Implementation > > SKIPPED > > > [INFO] XWiki Platform - Rendering - Signature . SKIPPED > > > [INFO] XWiki Platform - Rendering - Macros - Parent POM
Re: [xwiki-devs] Building/Installing XWiki Platform
FO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 06:49 min > [INFO] Finished at: 2019-05-14T18:17:04+01:00 > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce > (enforce-upper-bounds) on project xwiki-platform-rendering-async-default: > Some Enforcer rules have failed. Look above for specific messages > explaining why the rule failed. -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the > command > [ERROR] mvn -rf :xwiki-platform-rendering-async-default > MacBook-Pro-de-MACBOOK:xwiki-platform-rendering rachmann$ > > Any help would be appreciated thanks. > Mua > > > On Mon, May 6, 2019 at 2:55 PM Thomas Mortagne > wrote: > > > Building the whole xwiki-platform is very long yes (it's huge) but > > it's not something you do often. Generally you build only the > > sub-modules you are working on and let Maven take care of downloading > > snapshots (built by https://ci.xwiki.org) for other platform modules. > > > > On Mon, May 6, 2019 at 3:51 PM Mua Rachmann wrote: > > > > > > Sorry, my fault. I didn't pull the latest changes. > > > > > > I just did a fetch/merge from upstream master and the spanshot is 11.4. > > > It's downloading and building now. Its taking really long. > > > Is that how it is? > > > > > > Thanks very much > > > > > > On Sun, May 5, 2019 at 8:12 PM Vincent Massol > > wrote: > > > > > > > > > > > > > > > > On 5 May 2019, at 07:42, Mua Rachmann wrote: > > > > > > > > > > From the error i see it kinna depends on this > > > > > https://github.com/xwiki/xwiki-commons i am correct? > > > > > > > > Correct. > > > > > > > > > If so how can i edit > > > > > my pom.xml file > > > > > accordingly. > > > > > > > > Why would you want to edit some pom.xml file? > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > > > > > > Regards > > > > > > > > > > On Sun, May 5, 2019 at 6:39 AM Mua Rachmann > > > > wrote: > > > > > > > > > >> Hi there everyone, > > > > >> > > > > >> I am trying to begin my adventure with xwiki and begin > > contributions. I > > > > >> wish to build the xwiki platform but i ran into some errors. > > > > >> > > > > >> - I have downloaded and installed maven 3.6.1 > > > > >> - I have java v8 and on Mac OS > > > > >> > > > > >> Following the link Vincent provided here See > > > > >> https://dev.xwiki.org/xwiki/bin/view/Community/Building/ When i run > > > > **mvn > > > > >> clean install** i get the following error > > > > >> > > > > >> MBP-de-MACBOOK:xwiki-platform rachmann$ mvn clean install > > > > >> [INFO] Scanning for projects... > > > > >> [ERROR] [ERROR] Some problems were encountered while processing the > > > > POMs: > > > > >> [FATAL] Non-resolvable parent POM for > > > > >> org.xwiki.platform:xwiki-platform:11.2-SNAPSHOT: Could not find > > artifact > > > > >> org.xwiki.commons:xwiki-commons-pom:pom:11.2-SNAPSHOT and > > > > >> 'parent.relativePath' points at no local POM @ line 23, column 11 > > > > >> @ > > > > >> [ERROR] The build could not read 1 project -> [Help 1] > > > > >> [ERROR] > > > > >> [ERROR] The project > > org.xwiki.platform:xwiki-platform:11.2-SNAPSHOT > > > > >> (/Users/rachmann/Documents/open_source/xwiki-platform/pom.xml) has 1 > > > > error > > > > >> [ERROR] Non-resolvable parent POM for > > > > >> org.xwiki.platform:xwiki-platform:11.2-SNAPSHOT: Could not find > > artifact > > > > >> org.xwiki.commons:xwiki-commons-pom:pom:11.2-SNAPSHOT and > > > > >> 'parent.relativePath' points at no local POM @ line 23, column 11 -> > > > > [Help > > > > >> 2] > > > > >> [ERROR] > > > > >> [ERROR] To see the full stack trace of the errors, re-run Maven > > with the > > > > >> -e switch. > > > > >> [ERROR] Re-run Maven using the -X switch to enable full debug > > logging. > > > > >> [ERROR] > > > > >> [ERROR] For more information about the errors and possible > > solutions, > > > > >> please read the following articles: > > > > >> [ERROR] [Help 1] > > > > >> > > > > > > http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException > > > > >> [ERROR] [Help 2] > > > > >> > > > > > > http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException > > > > >> > > > > >> Any help would be appreciated thanks > > > > >> > > > > >> Regards, > > > > >> Mua > > > > >> > > > > > > > > > > > > > > > > -- > > Thomas Mortagne > > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] WikiMacro inline editing: 2 new dedicated macros
This mail is missing the most important part of what we talked about
with Simon actually but maybe the plan was to do that in another mail
?
Without entering too much in the details (I let Simon do that ;)) the
core idea to support inline editing in wiki macro is to cleanup macro
implementation details: in short remove in the result the macro
markers which are coming from the implementation (so in the end you
don't have the velocity macro marker which break the inline editing
flow, etc.). So one of the job of those those special macro helpers
would be to protect the inserted content from that cleanup.
On Wed, May 8, 2019 at 2:09 PM Marius Dumitru Florea
wrote:
>
> Hi Simon,
>
> As I commented on https://github.com/xwiki/xwiki-platform/pull/1109 I think
> that most of the time you will want to use a scripting macro + HTML macro
> like this:
>
> {{velocity}}
> {{html clean="false"}}
>
> ...
>
> ...
>
> {{/html}}
> {{/velocity}}
>
> An example of such a macro could be:
>
> {{figure src="someImage.png"}}some description{{/figure}}
>
> The macro code would look like this:
>
> {{velocity}}
> {{html clean="false"}}
>
>
>
>
>
>
>
>
> {{/html}}
> {{/velocity}}
>
> I know you can output DIVs with wiki syntax but that's not the point. The
> point is that we want to use HTML for the UI and leave the wiki syntax for
> the user content. So I don't think ``wikimacrocontent`` is that useful (if
> it's only purpose is to help you output the ``non-generated-content`` DIV).
>
> Thanks,
> Marius
>
>
> On Tue, May 7, 2019 at 9:21 AM Simon Urli wrote:
>
> > Hi everyone,
> >
> > I'm currently working on allowing inline editing on new wikimacros.
> > My first challenge right now is to cope with the problem of inserting
> > the macro content and allowing to inline edit it.
> >
> > In order to do so, I propose to create two new dedicated macro:
> >- wikimacrocontent: would allow to insert and inline edit a wiki
> > macro content
> >- wikimacroparameter: the same for a parameter.
> >
> > The idea would be to be able to write something such as:
> >
> > {{velocity}}
> > {{wikimacrocontent/}}
> > This is a content of $xcontext.macro.content.length() characters.
> > {{/velocity}}
> >
> > So the purpose of those macros would be twofold:
> >1. to ease the insertion of macro content/parameters (no need to
> > always use {{velocity}}$xcontext.macro.content{{/velocity}}
> >2. to create the dedicated metadata around the content and to be
> > processed during wikimacro rendering to allow inline editing
> >
> > Of course those macro would be only to be used inside a wikimacro.
> > I started to develop the wikimacroccontent, so I have a first working
> > POC, but I'd like to know WDYT about this.
> >
> > I would also be really happy if you could give me some wikimacro
> > examples where the inline editing would make sense, so I could use it in
> > my tests.
> >
> > Thanks,
> > Simon
> > --
> > Simon Urli
> > Software Engineer at XWiki SAS
> > simon.u...@xwiki.com
> > More about us at http://www.xwiki.com
> >
--
Thomas Mortagne
Re: [xwiki-devs] Analysis of BFD releases 11.2 and 11.3
On Thu, May 2, 2019 at 10:57 AM Vincent Massol wrote: > > I did a quick analysis of 11.2 & 11.3 to see how many bugs we fixed since > they were supposed to be BFD releases. > > The results are not that impressive: > > * XWiki 11.0 (non BFD): 32 bugs closed > * XWiki 11.1 (non BFD) 44 bugs closed > * XWiki 11.2 (BFD): 37 bugs closed > * XWiki 11.3 (BFD): 54 bugs closed > > Here’s the graph: > https://www.evernote.com/l/AHcQ57uKyNRK-YmB09gvM70OXXVTIhFWcs0 > > The graph shows that during the period (March and April) we had: > * Created issues (128) > * Resolved issues (123) > > So we were not even able to catch up with created bugs during the period. > > So the question is: why are we not able to catch up? > > Let’s look at who closed bugs during the period: > https://www.evernote.com/l/AHfj3Z0DW8RAuZ0AHw9BX6cnoDZc89KPvog > > Top resolvers: > > * Simon Urli - 32 > * Thomas Mortagne - 30 > * Vincent Massol - 15 > * Guillaume Delhumeau - 5 > * Marius Dumitru Florea - 2 > > So one reason is that we roughly have only 2 main issue resolvers (Simon and > Thomas) and the other committers are not closing enough. So not enough > manpower. > > Would be interesting to see if we have more bugs being created every month > these days when compared to, say, 2 years ago. > > For ex: > * category = 1 AND type = Bug and created >= 2019-03-01 and created <= > 2019-03-31 > ** 70 bugs created > * category = 1 AND type = Bug and created >= 2018-03-01 and created <= > 2018-03-31 > ** 41 bugs created > * category = 1 AND type = Bug and created >= 2017-03-01 and created <= > 2017-03-31 > ** 46 bugs created > * category = 1 AND type = Bug and created >= 2016-03-01 and created <= > 2016-03-31 > ** 81 bugs created > > More generally: > * category = 1 AND type = Bug and created >= 2015-01-01 and created <= > 2015-12-31 > ** 780 bugs created > * category = 1 AND type = Bug and created >= 2016-01-01 and created <= > 2016-12-31 > ** 732 bugs created > * category = 1 AND type = Bug and created >= 2017-01-01 and created <= > 2017-12-31 > ** 609 bugs created > * category = 1 AND type = Bug and created >= 2019-01-01 and created <= > 2019-12-31 > * 257 bugs created so far. Extrapolates to 257*3 = 771 > > So it seems we don’t have specifically more bugs being reported in general. > > So it seems it’s mostly a manpower/focus issue. Yes > > WDYT? > > Thanks > -Vincent > > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Define Xmx value in jvm.config for xwiki-* repositories
Sorry for the delay. Not sure it's make much sense to define it. It indeed depend a lot on the profiles you enable and the modules you build. If we put something it will be something high enough to build everything I guess which might be too big for many people who are just building part of it for a specific need and will be forced to change the default. On Sat, Apr 27, 2019 at 2:00 PM Vincent Massol wrote: > > Hi, > > Since Maven 3.3.1 it’s possible to declare default command line options and > JVM options, see https://maven.apache.org/docs/3.3.1/release-notes.html > > It could be interesting to do so in our repos so that all users run with the > right values. > > Or we could decide that the values depend too much on the profiles being > executed and it’s not worht it. > > WDYT? > > Thanks > -Vincent -- Thomas Mortagne
Re: [xwiki-devs] XAR source projects should allow source files
Hi Paul, I commented the jira issue and the PR. I don't see any harm in this approach at meast so it's a +1 from me. On Tue, Apr 16, 2019 at 3:06 PM wrote: > > >> On 26 Aug 2016, at 13:50, Vincent Massol wrote: > [...] > >> * What I understand is that you’re not proposing to change the XAR > >> format but to introduce some tooling to generate a XAR from a set of > >> source files, at build time. Correct? > [...] > > I am rewaking this rather older subject (see > http://xwiki.475771.n2.nabble.com/XAR-source-projects-should-allow-source-files-td7600774i20.html > and older things mentioned there) with yet another attempt which might > satisfy everyone: an attempt to use XAR-Transformations to include files > into XARs. It defines two extra transformations: > > - INSERT_TEXT (using an XPath expression): inserts the content of the > text file > - INSERT_ATTACHMENT_CONTENT (using a file name): inserts the content of > a file in base64 > > The attempt is detailed in https://jira.xwiki.org/browse/XCOMMONS-1614 > and has a pull-request and an example realisation. > > I claim that this attempt allows project developers to nicely edit files > and let them be combined into a xar when it is the time. See the issue > for an example realisation. > > I would love your comments. > > Paul -- Thomas Mortagne
Re: [xwiki-devs] [Brainstorming] Remove Tomcat 7.x support? (was Re: [VOTE] Officially support for Tomcat 9)
Keeping it does not cost anything and some people probably still use (for example tomcat8 does not exist in some old branches of Ubuntu and Debian) it so there is no reason to remove it for now IMO. On Sat, Apr 13, 2019 at 11:48 AM Vincent Massol wrote: > > BTW just noticed that we still have > https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-distribution/xwiki-platform-distribution-debian/xwiki-platform-distribution-debian-tomcat/xwiki-platform-distribution-debian-tomcat7-mysql/pom.xml > > However we don’t support Tomcat 7.x officially AFAIK (it’s not on > https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletContainerSupportStrategy/ > ). > > Note that we don’t have any tests executing on Tomcat 7.x ATM. > > Shouldn’t we remove it? > > Thanks > -Vincent > > > On 13 Apr 2019, at 11:39, Vincent Massol wrote: > > > > Since it’s a vote I think I am -1 to support both Tomcat 8.x and 9.x at the > > same level (I could change that to a -0 if everyone else agrees). > > > > For 2 reasons: > > * I feel we’re don’t have enough agent power to support so many configs - > > we already have too many IMO, and each new config increases the test time > > exponentially. > > * I’d really like that we continue having a single version for each infra > > server in our docker-latest job. > > > > So I’m proposing one of the following 2 options: > > > > Option 1: Tomcat 8.x stays the supported version > > === > > > > * Continue delivering XWiki on Tomcat 8.x by default. For ex the Docker > > image continue to be on Tomcat 8.x, see the tags on > > https://hub.docker.com/_/xwiki?tab=description > > * Offer a preview for Tomcat 9.x but don’t consider it as being officially > > supported. This means mentioning the “preview” in the various docs. > > * On the test side, this means adding it to docker-unsupported > > > > Option 2: Tomcat 9.x becomes the latest supported version > > === > > > > * Consider that Tomcat 9.x is now the latest version of Tomcat, i.e. make > > it go in the docker-latest build (ie all tests execute on it). Executed > > daily. > > * Consider that Tomcat 8.x is now an older version of Tomcat (but still > > supported) and move all Tomcat 8.x tests to docker-all (ie only smoke tests > > on it). Executed weekly. > > * Upgrade the official Docker image to use Tomcat 9.x. More generally > > upgrade all distributions to use Tomcat 9.x. Note that we support only 1 > > version of Tomcat in the Docker images we distribute. > > > > The only question I’m asking is whether Tomcat 9.x is stable enough for > > using it in production vs Tomcat 8.x (8.5.x to be precise). Note that > > Tomcat 8.5.x contains backports from Tomcat 9.x AFAIK and the main > > difference is just the supported Servlet spec (AFAICS). > > > > So if we wish to make a move, I’d prefer option 2 but I don’t know if I > > know enough about Tomcat 8.5.x vs Tomcat 9.x in production to make an > > educated decision. I’d be curious to know if users would be ok to run > > Tomcat 9.x in production. Now we would still support 8.5.x so users who > > want to stay on Tomcat 8.5.x can. > > > > WDYT? > > > > Thanks > > -Vincent > > > > PS: I thought I saw a jira issue being closed on this topic, did I dream it > > or did you anticipate the vote results? ;) > > > >> On 12 Apr 2019, at 17:53, Thomas Mortagne > >> wrote: > >> > >> On Fri, Apr 12, 2019 at 5:42 PM Vincent Massol wrote: > >>> > >>> > >>> > >>>> On 12 Apr 2019, at 17:35, Thomas Mortagne > >>>> wrote: > >>>> > >>>> On Fri, Apr 12, 2019 at 5:07 PM Vincent Massol > >>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>>> On 12 Apr 2019, at 17:00, Thomas Mortagne > >>>>>> wrote: > >>>>>> > >>>>>> Hi devs, > >>>>>> > >>>>>> tomcat9 package is now available in Debian repositories so I would > >>>>>> like to start providing xwiki-tomcat9-* Debian packages of XWiki. > >>>>>> > >>>>>> Nothing complex so far but it if we provide an official tomcat 9 > >>>>>> oriented package it would also make more sense to add Tomcat 9 in > >>>>>> https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletContainerSupportStrategy/ > >>>>>>
Re: [xwiki-devs] [VOTE] Officially support for Tomcat 9
On Sat, Apr 13, 2019 at 11:39 AM Vincent Massol wrote: > > Since it’s a vote I think I am -1 to support both Tomcat 8.x and 9.x at the > same level (I could change that to a -0 if everyone else agrees). > > For 2 reasons: > * I feel we’re don’t have enough agent power to support so many configs - we > already have too many IMO, and each new config increases the test time > exponentially. > * I’d really like that we continue having a single version for each infra > server in our docker-latest job. > > So I’m proposing one of the following 2 options: > > Option 1: Tomcat 8.x stays the supported version > === > > * Continue delivering XWiki on Tomcat 8.x by default. For ex the Docker image > continue to be on Tomcat 8.x, see the tags on > https://hub.docker.com/_/xwiki?tab=description > * Offer a preview for Tomcat 9.x but don’t consider it as being officially > supported. This means mentioning the “preview” in the various docs. > * On the test side, this means adding it to docker-unsupported > > Option 2: Tomcat 9.x becomes the latest supported version > === > > * Consider that Tomcat 9.x is now the latest version of Tomcat, i.e. make it > go in the docker-latest build (ie all tests execute on it). Executed daily. > * Consider that Tomcat 8.x is now an older version of Tomcat (but still > supported) and move all Tomcat 8.x tests to docker-all (ie only smoke tests > on it). Executed weekly. > * Upgrade the official Docker image to use Tomcat 9.x. More generally upgrade > all distributions to use Tomcat 9.x. Note that we support only 1 version of > Tomcat in the Docker images we distribute. > > The only question I’m asking is whether Tomcat 9.x is stable enough for using > it in production vs Tomcat 8.x (8.5.x to be precise). Note that Tomcat 8.5.x > contains backports from Tomcat 9.x AFAIK and the main difference is just the > supported Servlet spec (AFAICS). > > So if we wish to make a move, I’d prefer option 2 but I don’t know if I know > enough about Tomcat 8.5.x vs Tomcat 9.x in production to make an educated > decision. I’d be curious to know if users would be ok to run Tomcat 9.x in > production. Now we would still support 8.5.x so users who want to stay on > Tomcat 8.5.x can. > > WDYT? > > Thanks > -Vincent > > PS: I thought I saw a jira issue being closed on this topic, did I dream it > or did you anticipate the vote results? ;) Providing a Debian package which work with Tomcat 9 does not make it officially supported as you said. > > > On 12 Apr 2019, at 17:53, Thomas Mortagne wrote: > > > > On Fri, Apr 12, 2019 at 5:42 PM Vincent Massol wrote: > >> > >> > >> > >>> On 12 Apr 2019, at 17:35, Thomas Mortagne > >>> wrote: > >>> > >>> On Fri, Apr 12, 2019 at 5:07 PM Vincent Massol wrote: > >>>> > >>>> > >>>> > >>>>> On 12 Apr 2019, at 17:00, Thomas Mortagne > >>>>> wrote: > >>>>> > >>>>> Hi devs, > >>>>> > >>>>> tomcat9 package is now available in Debian repositories so I would > >>>>> like to start providing xwiki-tomcat9-* Debian packages of XWiki. > >>>>> > >>>>> Nothing complex so far but it if we provide an official tomcat 9 > >>>>> oriented package it would also make more sense to add Tomcat 9 in > >>>>> https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletContainerSupportStrategy/ > >>>>> (only Tomcat 8 right now). > >>>>> > >>>>> Another argument is that it's the current recommended stable version > >>>>> from Tomcat point of view so people will use it more and more. > >>>>> > >>>>> WDYT ? > >>>> > >>>> In principle it’s good but it means doing a lot more tests to officially > >>>> support it and we’re already doing a lot. So I’m not very inclined to > >>>> add new config tests. It adds a lot of hours to the build. I’d prefer > >>>> that we keep officially supporting only a single version if we can. Same > >>>> as for jetty for ex. > >>>> > >>>> BTW could you provide the URLs for the various debian repos (oldstable, > >>>> stable, unstable) so that we can check the precise Tomcat versions? > >>> > >>> https://packages.debian.org/search?keywords=tomcat9 so 9.0.16. It's > >>> available in the stable branch trough backport repository (stable > >>> branch never get
Re: [xwiki-devs] [VOTE] Officially support for Tomcat 9
On Fri, Apr 12, 2019 at 5:42 PM Vincent Massol wrote: > > > > > On 12 Apr 2019, at 17:35, Thomas Mortagne wrote: > > > > On Fri, Apr 12, 2019 at 5:07 PM Vincent Massol wrote: > >> > >> > >> > >>> On 12 Apr 2019, at 17:00, Thomas Mortagne > >>> wrote: > >>> > >>> Hi devs, > >>> > >>> tomcat9 package is now available in Debian repositories so I would > >>> like to start providing xwiki-tomcat9-* Debian packages of XWiki. > >>> > >>> Nothing complex so far but it if we provide an official tomcat 9 > >>> oriented package it would also make more sense to add Tomcat 9 in > >>> https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletContainerSupportStrategy/ > >>> (only Tomcat 8 right now). > >>> > >>> Another argument is that it's the current recommended stable version > >>> from Tomcat point of view so people will use it more and more. > >>> > >>> WDYT ? > >> > >> In principle it’s good but it means doing a lot more tests to officially > >> support it and we’re already doing a lot. So I’m not very inclined to add > >> new config tests. It adds a lot of hours to the build. I’d prefer that we > >> keep officially supporting only a single version if we can. Same as for > >> jetty for ex. > >> > >> BTW could you provide the URLs for the various debian repos (oldstable, > >> stable, unstable) so that we can check the precise Tomcat versions? > > > > https://packages.debian.org/search?keywords=tomcat9 so 9.0.16. It's > > available in the stable branch trough backport repository (stable > > branch never get new major version directly). > > So it seems there’s only an “unstable” version FTM. I would wait till there’s > a “stable” version at least. We could add it to our “unsupported” docker > tests that execute once a month though. WDYT? No as I said there is a stable package, you just have to enable stable backports. There is also a testing version. > > What’s your need for adding support for it now, since debian doesn’t have a > stable support for it yet? > > > > >> BTW I also noticed that https://packages.debian.org/sid/tomcat8 doesn’t > >> exist anymore. It’s been removed? This link is in our doc at > >> https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletContainerSupportStrategy/ > > > > This is the URL for sid only which is the unstable branch. Not really > > sure if it's like this on purpose or if it's a mistake but it will > > continue to be available for a very long time in the stable branch for > > sure anyway. On Tomcat side there is no date announced for 8.5.x end > > of life. > > This link used to work so it’s been removed. Not sure what we should do. > > Thanks > -Vincent > > > > >> > >> Thanks > >> -Vincent > >> > >> > >>> > >>> Here is my +1 > >>> -- > >>> Thomas Mortagne > >> > > > > > > -- > > Thomas Mortagne > -- Thomas Mortagne
[xwiki-devs] [VOTE] Officially support for Tomcat 9
Hi devs, tomcat9 package is now available in Debian repositories so I would like to start providing xwiki-tomcat9-* Debian packages of XWiki. Nothing complex so far but it if we provide an official tomcat 9 oriented package it would also make more sense to add Tomcat 9 in https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletContainerSupportStrategy/ (only Tomcat 8 right now). Another argument is that it's the current recommended stable version from Tomcat point of view so people will use it more and more. WDYT ? Here is my +1 -- Thomas Mortagne
[xwiki-devs] [ANN] XWiki 10.11.6 released
The XWiki development team is proud to announce the availability of XWiki 10.11.6. This is a bugfix release that covers important issues that we have discovered since 10.11.5 has been released. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.11.6 Thanks for your support -The XWiki dev team
Re: [xwiki-devs] [Brainstorming] Failing build when deprecated APIs are used in scripts?
+1 I'm pretty sure we used to have something like this. On Fri, Mar 29, 2019 at 10:27 AM Vincent Massol wrote: > > Hi devs, > > I'd like to discuss about introducing a checker in the tests to fail the test > if there's a warning message about a deprecated APIs being used in scripts. > > For example: > > ``` > 23:59:28.308 [main] INFO org.xwiki.test.ui.TestDebugger - > GroupIT-addUserAndSubgroupToGroup started > 23:59:32.593 [Exec Stream Pumper] ERROR o.x.t.i.XWikiLogOutputStream - > 2019-03-28 23:59:32,593 > [http://localhost:8080/xwiki/bin/view/XWiki/XWikiPreferences?xpage=getgroups=1=15=1] > WARN o.x.v.i.DefaultVelocityEngine - Deprecated usage of method > [com.xpn.xwiki.plugin.rightsmanager.RightsManagerPluginApi.countAllMembersNamesForGroup] > in 21:/templates/getgroups.vm@62,37 > 23:59:35.824 [Exec Stream Pumper] ERROR o.x.t.i.XWikiLogOutputStream - > 2019-03-28 23:59:35,824 > [http://localhost:8080/xwiki/bin/view/XWiki/XWikiPreferences?xpage=getgroups=1=15=2] > WARN o.x.v.i.DefaultVelocityEngine - Deprecated usage of method > [com.xpn.xwiki.plugin.rightsmanager.RightsManagerPluginApi.countAllMembersNamesForGroup] > in 18:/templates/getgroups.vm@62,37 > 23:59:41.349 [Exec Stream Pumper] ERROR o.x.t.i.XWikiLogOutputStream - > 2019-03-28 23:59:41,348 > [http://localhost:8080/xwiki/bin/view/XWiki/XWikiPreferences?xpage=getgroups=1=15=3] > WARN o.x.v.i.DefaultVelocityEngine - Deprecated usage of method > [com.xpn.xwiki.plugin.rightsmanager.RightsManagerPluginApi.countAllMembersNamesForGroup] > in 21:/templates/getgroups.vm@62,37 > 23:59:58.503 [main] INFO org.xwiki.test.ui.TestDebugger - > GroupIT-addUserAndSubgroupToGroup passed > ``` > > Rationale: > * This adds warnings in the xwiki logs when users navigate to those pages > which isn’t nice. > * It also helps reducing the number of deprecated methods we use (I have the > feeling this is not reducing) and helps us move towards being able to move > the deprecated code to legacy. > > WDYT? > > Thanks > -Vincent -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Improve our Test Coverage strategy (TAKE 3)
+1 On Thu, Mar 21, 2019 at 5:41 PM Vincent Massol wrote: > > Hi devs, > > I remember that we talked about this new global test coverage strategy but I > don’t recall where and I couldn’t find an email about it. So I’m reposting > the strategy that I’ve just finished implementing. > > * Every day the Clover job runs: https://ci.xwiki.org/view/Tools/job/Clover/ > * It generates a global coverage report and compares it automatically with > the first report generated for the current version > * If the global coverage is reduced, then: > ** an email is sent to notificati...@xwiki.org containing the report > ** the job is marked as FAILING > ** A failing badge is added to the job history > ** A red large text is added to the job page and a link to the report is sent > * Developers MUST fix the global coverage before we can release a version, so > the it means the global coverage must not be reduced during a version. > * The RM should check the CI (already part of his chores) and the > “Recommended Failing” view on ci.xwiki.org must not have errors or failures > (so that includes pitest job and clover job). > > Any comments? Does that seem ok to you? > > If you confirm it’s ok, I’ll document it on > https://dev.xwiki.org/xwiki/bin/view/Community/Testing/TestCoverage/ > > Note: A few minutes ago an email has been sent since the global coverage has > been reduced compared to yesterday. > > See > http://maven.xwiki.org/site/clover/20190321/XWikiReport-20190320-0128-20190321-1059.html > > So we need to fix it now. > > Thanks > -Vincent > -- Thomas Mortagne
Re: [xwiki-devs] [Feedback] Installation choices
On Mon, Mar 18, 2019 at 6:31 PM Vincent Massol wrote: > > Hi Caty, > > Sounds good generally. Some feedback: > > * It seems verbose. I would put a single box for the version. > * Not sure what “installation” is. “Production” and “Demo”? > * I would have an order on the boxes. Production or Demo should come first > for ex. > * If you choose Production then, I would prefill the version with the LTS > version by default. > * The OS field should be auto-guessed I'm really not sure about this one since it's a server software you rarely want to install it on the OS you are browsing from. > * The packaging will also be defined automatically based on the answer from > installation & OS > * The version should be the last question since the packaging doesn’t depend > on it. Actually it doesn’t even make sense for some packaging such as debian > since you don’t download anything. But I guess the command line we show could > specify the version. > * IMO it’s missing the concept of recommended packaging. So I would make the > defined packaging be the recommended one and make it clear (for ex when you > click the arrow you’ll see “Recommended Packaging” and then below “Other > Packagings”. > > Thanks! > -Vincent > > > On 18 Mar 2019, at 17:59, Ecaterina Moraru (Valica) > > wrote: > > > > Hi Devs, > > > > I'm curious what you think about this direction for the Download / Install > > page on xwiki.org: > > Iteration 1 > > https://design.xwiki.org/xwiki/bin/download/Install/LDJEasierInstallationFlow/WebHome/Iteration1ZIP.png > > > > Changes: > > * Download renamed to Install > > * Form at the beginning to select the version, OS, type and package > > * Depending on the user selection, there is an option to Download the > > package, or you just get Installation steps (personalized for each option > > selected). > > > > I've iterated currently just for the ZIP package (for Demo+Mac), but > > imagine something similar for all the other packages. > > > > What do you think? Should I continue in this direction? > > > > Thanks, > > Caty > -- Thomas Mortagne
Re: [xwiki-devs] [Feedback] Installation choices
On Mon, Mar 18, 2019 at 6:13 PM Simon Urli wrote: > > Hi Caty, > > that's nice! I think it avoids the overwhelming of choosing what to > download on the current page presenting standard pack + zip + xip + war > + docker, etc. > > Now, I have some questions: > > 1. I don't understand the "OS" choice section: AFAIK except for the deb > package we don't have any related package. It's for displaying those in > case of debian / ubuntu is selected? Indeed the OS selection makes a lot of sense for Debian based systems where the deb packaging makes it's an obvious recommended package. It's less obvious for other OSes, unless the plan is to make Docker part of the OS list (in which case it would be better to name it "System" probably). > > 2. Currently we display the major changes along with the version in the > downloaded page: I don't see it anymore in your version. You plan to > completely discard this info there? > > 3. I don't understand why there are arrows on the version: you plan to > allow changing the LTS version? it wouldn't be the LTS anymore then, so > a bit confusing, no? I understood it as showing details like what you are talking about in 2 but maybe I'm wrong. > > 4. Shouldn't the dev version not be as big as the LTS / stable, since > it's not recommended? Or at least to discard the prod installation when > it's selected? > > My 2 cents, > Simon > > > > On 18/03/2019 17:59, Ecaterina Moraru (Valica) wrote: > > Hi Devs, > > > > I'm curious what you think about this direction for the Download / Install > > page on xwiki.org: > > Iteration 1 > > https://design.xwiki.org/xwiki/bin/download/Install/LDJEasierInstallationFlow/WebHome/Iteration1ZIP.png > > > > Changes: > > * Download renamed to Install > > * Form at the beginning to select the version, OS, type and package > > * Depending on the user selection, there is an option to Download the > > package, or you just get Installation steps (personalized for each option > > selected). > > > > I've iterated currently just for the ZIP package (for Demo+Mac), but > > imagine something similar for all the other packages. > > > > What do you think? Should I continue in this direction? > > > > Thanks, > > Caty > > > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.u...@xwiki.com > More about us at http://www.xwiki.com -- Thomas Mortagne
Re: [xwiki-devs] [Feedback] Installation choices
On Mon, Mar 18, 2019 at 5:59 PM Ecaterina Moraru (Valica) wrote: > > Hi Devs, > > I'm curious what you think about this direction for the Download / Install > page on xwiki.org: > Iteration 1 > https://design.xwiki.org/xwiki/bin/download/Install/LDJEasierInstallationFlow/WebHome/Iteration1ZIP.png > > Changes: > * Download renamed to Install > * Form at the beginning to select the version, OS, type and package > * Depending on the user selection, there is an option to Download the > package, or you just get Installation steps (personalized for each option > selected). > > I've iterated currently just for the ZIP package (for Demo+Mac), but > imagine something similar for all the other packages. > > What do you think? Should I continue in this direction? I like the concept and it definitely look nice so sounds good to me. +1 to continue playing with this idea. Some comments: * I'm not sure "Installation" is the right word for "Demo" vs "Production" (if that's what you had in mind), maybe something that looks more like "Use case" (or maybe it's just my poor English level talking). I feel the whole page is about installation. * I guess this way is going to hide more the demo packages (since I doubt it will be selected by default), maybe that's a problem ? * I would put the STABLE version first and selected by default since that's the one we want people to test > > Thanks, > Caty -- Thomas Mortagne
Re: [xwiki-devs] asking for help, issues for a team
If you read https://dev.xwiki.org/xwiki/bin/view/Onboarding/ and especially https://dev.xwiki.org/xwiki/bin/view/Onboarding/TrackCore/#HCodeContribution you will find a link to get quite a few jira issues tagged as easy to fix for a newcomer. On Tue, Mar 12, 2019 at 9:25 PM Jeremi Kádár wrote: > > Dear XWiki developers, > > I and my friends learn Computer Science at the University Of Szeged. > > One of our obligatory task in this semester to participate in an open > source project. > We decide to choose a project so our team wouldn't be randomized and we > don't have to risk that we'll be put together with students who too lazy to > work. > > I've found XWiki and seen that this would be an excellent choice since it's > well known and has some history behind itself and the project itself is > really interesting too. > > We've read the different guides about how to participate, registrated to > jira, github, devmails... > > Our problem is that we couldn't find an issue / work item with the > following criterias: > - no one's working on it || not assigned > ( - it's beginner friendly, not have to know *everything *from A to B about > the project code ) > > Each of us have to take an issued or if there is 2-3 issue big enough, then > on each of the issues 2-3 members of our team would work on. > > We have to showcase the first milestone next week, until then we should get > to known to the project and get issues / task. > > We would be grateful if you could help us! > > Thanking you in advance... > > > Sorry for the language mistakes. > > I'm writing this letter down in Hungarian as well, just in case: > > Kedves XWiki fejlesztők, > > Én és a barátaim Programtervező Informatikára járunk a Szegedi > Tudományegyetemen. > > Ebben a félévben az egyik kötelező feladatunk részt venni egy nyílt > forráskódú projekt fejlesztésében. > Úgy döntöttünk, hogy mi választjuk a projektet, mivel így a csapatunk nem > véletlenszerű lesz kiválasztva és nem fogunk olyanokkal összekerülni, akik > nem akarnak dolgozni. > > Rátaláltam az XWiki-re és tökéletes választásnak találtam, mivel ismert, > van háttere és maga a projekt is nagyon érdekes. > > Elolvastuk a különböző leírásokat és regisztráltunk githubra, jirara, > fejlesztői e-mailekre. > > Az a problémánk, hogy nem találtunk issuet / feladatot az alábbi feltételek > mellett: > - senki sem dolgozik rajta || senkin sincs még rajta > ( - kezdőknek is jó, nem kell *mindent* tudni hozzá a projekt > forráskódjáról ) > > Mindannyiunknak kell felvennie egy issuet vagy ha van 2-3 nagyobb issue, > akkor mindegyiken a csapatból 2-3 ember is dolgozhatna. > > Az első mérföldkövet jövő héten kell bemutatnunk, addig meg kell ismernünk > a projektet és szereznünk kell feladatot is. > > Hálásak lennénk, ha tudnátok segíteni! > > Előre is köszönöm... -- Thomas Mortagne
Re: [xwiki-devs] [xwiki-notifications] About the GSOC mentors email address
You should not try to directly send mails to the mentors and instead communicate using general communication channels in which mentors will answer you. The best to to start start by reading https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines. On Fri, Mar 8, 2019 at 1:53 AM Weiqiang Cai wrote: > > Dear mentors， > > Good day. > > Hello there! sorry for disturbance. > > I am a student who is about to apply for GSOC2019. I am very interested in > XWIKI, although I have not used it before. But I have spent some time to > understand it. > > I am very interested in some projects, and would like to try it. So I want to > have a discussion with the project’s mentor. But I find the email address in > the mentor profile is incomplete. > > Would you give me some suggestions about how to get complete address? > > Thanks & Best Regards, > > CaiWeiqiang -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Introduce a new table BackLinks for solving issues on wiki farms
On Tue, Feb 26, 2019 at 2:59 PM Simon Urli wrote: > > > > On 26/02/2019 14:49, Marius Dumitru Florea wrote: > > +1, but since you're adding a new table maybe it's a good idea to have a > > backlink **type** column. I'm thinking that there are multiple ways in > > which 2 entities can be linked: wiki syntax link, image syntax, parameter > > of a macro call, etc. Notice that I mentioned entities. Maybe we shouldn't > > limit this table to wiki pages. Here's an example: you put a link to an > > attachment in the value of an object property. This means the object > > property is linked to the attachment. I think this improvement can come later since: * you will always need a field with the document reference anyway to find all the entry related to a document you are currently refactoring, you really need to know the type only when you actually start modify the document so new fields can be added to the table later without breaking anything * we don't currently register backlink for attachments or inside xobject properties so those new fields (if really needed) can be discussed when adding support for those > > So you would have: > - sourceType > - targetType > > to identify precisely what this backlink represents? > In that case shouldn't we put it in link table too? > > > > Thanks, > > Marius > > > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.u...@xwiki.com > More about us at http://www.xwiki.com -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Introduce a new table BackLinks for solving issues on wiki farms
+1 On Tue, Feb 26, 2019 at 12:03 PM Simon Urli wrote: > > Hi everyone, > > we currently have some issues when performing refactoring operations on > pages that are linked from another wiki page. See: > https://jira.xwiki.org/browse/XWIKI-8346 > > The current implementation of the links is to keep the local name of the > current document and to create a reference containing the name of the > wiki for the target document, only if it's a document from another wiki. > So basically if I have a wiki:A pointing to subwiki:B, I will get a link > stored in DB of "wiki", containing: >- fullName: A >- link: subwiki:B > > This forces us to currently iterate over all wikis, when we refactor a > page to edit all the links on the farm. That's why we currently have an > option which is disabled by default: i.e. we don't update backlinks on a > farm by default. > > In order to allow such operation with less performance issues, I propose > to add a new table dedicated to store the backlinks: basically this > table would store the reversed information as Links, in the target DB. > > If I take back my example, the table backlinks of "wiki" would be empty, > and I get in the table backlinks of "subwiki", the following information: >- fullName: B >- backlink: wiki:A > > Then we could load all backlinks of a document just by looking in one > table. > The impact on performance would be the necessity to update links in two > tables when performing a save, but we can mitigate this by first loading > the links so we only update what needs to be (currently we delete and > recreate all links, each time...). > > IMO it would really ease the understanding of links and backlinks, solve > the issues on farm and help us to maintain this code. + it doesn't break > any legacy since we keep the existing Link table. > > WDYT? > > Simon > -- > Simon Urli > Software Engineer at XWiki SAS > simon.u...@xwiki.com > More about us at http://www.xwiki.com -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Changes to remove Dashboard, Crypto, Macros, Rendering entries in the Navigation Panels
On Sun, Feb 24, 2019 at 11:42 AM Vincent Massol wrote: > > Hi devs, > > On a standard XS, if you show hidden document you see some entries that you > shouldn’t see and that should be hidden. See screenshot. > > > > Another problem is that clicking on the Dashboard, Crypto, Macros, Rendering > links lead to non-existing pages. > > I’m this proposing to: > > 1) Introduce a xwiki-platform-crypto-ui modules with a single Crypto.Webhome > page and some one liner explaining what this space is about. Or generate it since all the pages located in that space are generated classes. But I guess we can come up with some UI for the crypto module in the future even if it's a pity to introduce it just for that page. > 2) Introduce a xwiki-platform-rendering-wikimacro-ui module with a single > Macros.WebHome page and some one liner explaining what this space is about. > It makes sense to have it under xwiki-platform-rendering-wikimacro since it’s > about providing a location for wiki macros. Sounds like we should move the page currently located at XWiki.XWikiSyntaxMacrosList (xwiki-platform-help-ui) to Macros.WebHome. > 3) Add a Rendering.WebHome page inside xwiki-platform-rendering-ui to explain > what this space is about. The module is there and it’s just missing this > page. BTW an alternative is to modify the Navigation panel algorithm to > exclude spaces not having a top level WebHome page too. > @Marius: any reason we’re not doing this already? See https://jira.xwiki.org/browse/XWIKI-15296. > > By default the Navigation panel hides top level pages that are not meant to > be modified so this will remove Crypto, Macros & Rendering. > > 4) For Dashboard it’s a bit more complex. Ideally we would refactor > Dashboard.WebHome to include a new Dashboard.WikiDashboard page that would > contain the current content of Dashboard.WebHome. Thus the home page would > appear as not modifiable and not appear in the Navigation panel. However, > since users can have modified Dashboard.WebHome, this would cause an upgrade > merge conflict. Thus, instead, I propose to do what we do for the Sandbox > page and instead add Dashboard to the Exclude list of the Navigation panel. > > WDYT? > > Note: I’m going to do 4) right now since it’s a no-brainer. > > Longer term > = > > This is *not* part of the proposal but we need to start a thread again about > this and start doing something about it: Right now we have apps/extensions > creating pages under the top level root. I don’t think this is good at all > and we should reserve the top level root for user content. It would be much > better to have a place under “XWiki”, such as “XWiki.Extensions. name>..” where each extension could put its content. > > We already started discussing this. The past thread(s) needs to be unearthed > and the discussion resumed. > > Thanks > -Vincent > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] New Functional test best practice for docker-based tests
On Tue, Feb 12, 2019 at 2:45 PM Vincent Massol wrote:
>
> Hi,
>
> Now that JUnit 5.4.0 is out we have test ordering. I propose the following
> best practices for TC-based docker tests:
>
> @UITest
> @TestMethodOrder(OrderAnnotation.class)
> public class MenuIT
> {
> @Test
> @Order(1)
> public void verifyMenuInApplicationsIndex(TestUtils setup)
> {
> ...
> }
>
> @Test
> @Order(2)
> public void
> verifyMenuCreationInLeftPanelWithCurrentWikiVisibility(TestUtils setup)
> {
> ...
> }
>
> @Test
> @Order(3)
> public void verifyMenuIsAvailableInAdministration(TestUtils setup) throws
> Exception
> {
> …
> }
>
> Instead of the current:
>
> @Test
> public void verifyMenu(TestUtils setup) throws Exception
> {
> verifyMenuInApplicationsIndex(setup);
> verifyMenuCreationInLeftPanelWithCurrentWikiVisibility(setup);
> verifyMenuIsAvailableInAdministration(setup);
> }
>
>
> Pros:
> * Easier to run each test
> * Easier to debug and view recorded video for a specific failing test
> * More in sync with JUnit’s practices
> * It’s still a scenario and thus doesn’t incur penalty of extra test setup
>
> Cons:
> * Starts and stop the VNC docker container for each test. It takes between 1
> and 2s to start the VNC container and the stop (i.e. video recording save)
> should be the same as before.
>
> So I think it’s worth it. Out of 3mn, 3-6 more seconds for 3 tests is not too
> much (between 2% and 3% more).
>
> WDYT?
Why only docker based tests and not all UI tests ?
>
> Thanks
> -Vincent
>
>
>
>
>
>
>
>
--
Thomas Mortagne
Re: [xwiki-devs] [Proposal] Improve our Test Coverage strategy (TAKE 3)
+1 On Sun, Feb 10, 2019 at 2:50 PM Vincent Massol wrote: > > Hi devs, > > After TAKE 2 (see http://markmail.org/message/owtyhkmrz4tcbymn ), and after > analyzing several modules (I analyzed about 4-5 in total), I think we should > improve a bit the strategy to make it usable and applicable. > > Lessons learnt > > > * It takes a lot of time to analyze a single global tpc drop (every time it > takes me around 2 hours) > * In general the results of the analysis are not that great. There are often > “good enough” reasons for the drop. It’s often a lack of unit tests and code > that is exercised by functional tests but the path has changed for various > reasons. > * I find the ratio of time to spend on the analysis vs result to be too low. > * In the end what’s important is that our global TPC continues to grow > > New Strategy > === > > * We run the Clover Jenkins pipeline every night (between 11PM-8AM) > * The pipeline sends an email whenever the new report has its global TPC > going down when compared with the baseline (vs one or more modules had their > TPC lowered in TAKE 2) > * The baseline report is the report generated just after each XS release. > This means that we keep the same baseline during a XS release > ** Technically it means that the pipeline will update the latest.txt file > (which contains the clover report timestamp) when it notices a version change > * We add a step in the Release Plan Template to have the report passing > before we can release. > * The RM is in charge of a release from day 1 to the release day (already the > case), and is also in charge of making sure that the global coverage job > failures get addressed before the release day so that we’re ready on the > release day. > * Implementation detail: don’t send a failure email when there are failing > tests in the build, to avoid false positives > > WDYT? > > Thanks > -Vincent -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Get rid of Activity Stream and the Watchlist
On Mon, Feb 4, 2019 at 12:50 PM Guillaume Delhumeau wrote: > > Dear developers, > > Now that we consider notifications as an achieved replacement for both > Activity Stream and the Watchlist, I propose to stop maintaining them and > to move them into the "attic" section. > > You need to know that we had a dependency on the Activity Stream API, as > the only implementation of the Event Stream, on which the Notifications are > based. So to get rid of this dependency (the code is not using our > component system and is not well tested), I have written a new > implementation of the Event Stream that I have called "Event Stream Store". > It's fully backward compatible with the old implementation, since it is > using the same Database schema. In practice, I re-used some pieces of > Activity Stream that I have modified to fit into components. For more > information, see: https://jira.xwiki.org/browse/XWIKI-16052 > > So my proposal is this one: > - use the new store in 11.1 > - stop bundle Watchlist and AS in 11.1 Will 11.1 version be easily installable as extension (in case some old extension needs it for example) ? > - move Watchlist and AS into "attic" in 11.2 > > Thanks you, > > -- > Guillaume Delhumeau (guillaume.delhum...@xwiki.com) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project -- Thomas Mortagne
[xwiki-devs] Location for extensions ideas
Hi xwikiers, I'm never sure where to put ideas of extensions I have so I often forget them or details I had tough about or gathered back then. I don't think http://design.xwiki.org is the right place until you really start designing the extension. Also it's too generic for this need and not a very good entry point for searching something IMO, more something to link to from somewhere else. I would prefer something really dedicated to this "that would be a nice thingy but not sure about the details yet" state. Would be a good source for hackathons and GSOC or for contributors who are searching for something interesting to work on. I was thinking about the following alternatives: * a new dedicated project on https://jira.xwiki.org * reuse https://jira.xwiki.org/projects/XCONTRIB after some cleanup (close everything left in it basically) but not super clean (it's just that it's a good name) * some new application on http://www.xwiki.org WDYT ? Right now my preference goes to a clean new jira project (just need to think about a good project id) where you put description and close it when the extension work really start on a dedicated location. Less work and should do the job well. -- Thomas Mortagne
Re: [xwiki-devs] Update objects on class rename
On Wed, Jan 30, 2019 at 3:46 PM Marius Dumitru Florea
wrote:
>
> Hi devs,
>
> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the page
> rename job (from refactoring module) to update the existing objects when a
> class is renamed *if the "Update links" options is checked*.
>
> Of course, we could add a new option (e.g. "Update objects") but:
>
> * it complicates the rename UI (too many options)
> * I think most of the users understand the current "Update links" option as
> "update the places where this page is *used*". I don't think it makes sense
> to have separate options (at least at the UI level) for things like "Update
> macro calls" or "Update image includes".
> * I don't see why you would want to update the back-links but not the
> objects (or the other way around).
+1 for single option
>
> If we agree on using a single option ("Update links") then the next
> questions are:
>
> * Is there a better name? I think "Update links" is a good name for simple
> users so I would keep it. Another option is "Update references" but it has
> a special meaning for XWiki developers.
>
> * Should we update the hint for the "Update links" option? I think we
> should, but only for advanced users, since they should be aware of the
> implications of renaming a class. Simple users are not aware of the
> existence of objects, most probably, so I wouldn't complicate their lives.
+1 for update the hint, maybe reword it a bit to make clear is not
just about wiki links without entering too much in the details
>
> The final question is whether we should keep the rename job question about
> classes. I think we should. The reason we added it is because renaming a
> class is currently dangerous. Updating the objects makes it a bit less
> dangerous because the data is preserved, but classes are often used in
> scripts (e.g. a live table) and those scripts are not updated so there's a
> high chance that something will not work correctly after the class rename.
+1, object/class almost always imply that some code is manipulating
them it's not going to be fixed so the risk is still the same level
for me
>
> WDYT?
>
> Thanks,
> Marius
--
Thomas Mortagne
[xwiki-devs] [ANN] XWiki 11.0.2 released
The XWiki development team is proud to announce the availability of XWiki 11.0.2. This is a bugfix release that covers important issues that we have discovered since 11.0.1 has been released. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.0.2 Thanks for your support -The XWiki dev team
[xwiki-devs] [ANN] XWiki 11.0.1 released
The XWiki development team is proud to announce the availability of XWiki 11.0.1. This is a bugfix release that covers important issues that we have discovered since 11.0 has been released. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.0.1 Thanks for your support -The XWiki dev team
Re: [xwiki-devs] [ANN] XWiki 11.0 released
A blocker filesystem migration bug (triggered by deleted attachments) has been found in 11.0 and it's highly recommended to wait for 11.0.1 (which is currently being released). On Tue, Jan 29, 2019 at 1:11 PM Eduard Moraru wrote: > > The XWiki development team is proud to announce the availability of XWiki > 11.0. > > This release marks the start of the 11.x cycle and focuses mainly on > bugfixes and stabilization, but also features some AWM and CKEditor > improvements. > > You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download > > Make sure to review the release notes: > https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.0 > > Thanks for your support > -The XWiki dev team -- Thomas Mortagne
[xwiki-devs] [ANN] XWiki 9.11.9 released
The XWiki development team is proud to announce the availability of XWiki 9.11.9. This is a bugfix release that covers important issues that we have discovered since 9.11.8 has been released. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.11.9 Thanks for your support -The XWiki dev team
[xwiki-devs] [ANN] XWiki 10.11.2 released
The XWiki development team is proud to announce the availability of XWiki 10.11.2. This is a bugfix release that covers important issues that we have discovered since 10.11.1 has been released. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.11.2 Thanks for your support -The XWiki dev team
Re: [xwiki-devs] MyXWiki.org legal information
On Tue, Jan 22, 2019 at 8:43 PM Vincent Massol wrote: > > Hi Caty, > > > On 22 Jan 2019, at 12:52, Ecaterina Moraru (Valica) > > wrote: > > > > Hi Devs, > > > > We had an user ask about MyXWiki.org privacy agreements, see > > https://forum.xwiki.org/t/agreement-on-wiki-at-myxwiki-org-privacy/4241 > > > > I've added more details on MyXWiki.org homepage about: > > * Who is the legal entity behind MyXWiki? > > * What about Copyright and Intellectual Property? > > * What about Privacy Policy? > > > > See https://www.myxwiki.org/xwiki/bin/view/Main/ > > > > Please review it, see if you have more adjustments / details. > > Thanks for working on this! Looks good to me overall. Some small remarks > below. > > 1) "The content of this farm is licensed under a Creative Commons license. > Still, each wiki owner is responsible for their own content. Also the target > of this farm are non-profit organizations and individuals, so the generated > wiki should not be used for commercial purposes..”. > > I don’t understand these sentences. What is under CC? IMO the user is free to > choose the license they want for their contents. > > Or are you talking about the content of the main wiki only. If this is the > case then we should mention that. > I agree it should be made a little bit more clear, but not really sure we really need this since it does not really affect sub wiki content which is the target of this documentation. > 2) "MyXWiki.org administrators have technical access…” > > The group used is wrong IMO. It shouldn’t be XWikiSASGroup but an AdminGroup > for Myxwiki.org which can include active committers from different companies > and not just XWiki SAS. Also some non-active committers should be removed IMO > (Caleb for example). > > Easiest might be to point to > https://www.myxwiki.org/xwiki/bin/view/XWiki/XWikiAdminGroup. Not sure why we > need an XWikiSASGroup BTW. +1, XWiki SAS is a sponsor here and not an admin > > WDYT? > > Thanks > -Vincent > > > Thanks, > > Caty > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Document picker in include and display macros
instead of letting the > > > macro resolve it for him. > > > > > > > > > Note: If 1) or 2) or 3) are too hard for 11.0 (and it seems we’re too > > > late already since we’re releasing RC Monday!) then we could push that > > > one for later for the include/display macros and instead support other > > > and simpler well known macros in 11.0, from > > > https://design.xwiki.org/xwiki/bin/view/Proposal/AutocompleteOnReference#HWYIWYGMacros, > > > like DocumentTree macro. > > > > > > What I’d like is to have at least one macro that can use the picker in > > > 11.0, mostly to prove that it works and to have something to report for > > > users in the release notes and to show progress. > > > > > > Thanks > > > -Vincent > > > > > > > > > > >> > > > >> Thanks > > > >> -Vincent > > > >> > > > >>> * Introduce a new annotation to macro parameters to specify / override > > > >>> its type (different from its actual java type). > > > >>> > > > >>> The new annotation will mostly be useful for the WYSIWYG side. In our > > > >>> case we want to use the document parameter which is a String. The > > > >>> annotation will allow us to work with a DocumentReference instead > > > >>> which can be used to display the document picker when editing the > > > >>> macro in WYSIWYG mode. > > > >>> > > > >>> To be clear, here is how we would use it: > > > >>> @PropertyType(DocumentReference.class) > > > >>> public void setDocument(String document) > > > >>> > > > >>> WDYT? > > > >>> > > > >>> Thanks, > > > >>> Adel > > > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Document picker in include and display macros
On Thu, Jan 17, 2019 at 11:05 AM Adel Atallah wrote: > > Hi devs, > > After discussing with Marius and Thomas, we thought it might be a good > idea to do the following to have a document picker in the include and > display maros: > * Remove the deprecation of the document parameter (only for the include > macro). > * Introduce a new annotation to macro parameters to specify / override > its type (different from its actual java type). > > The new annotation will mostly be useful for the WYSIWYG side. In our > case we want to use the document parameter which is a String. The > annotation will allow us to work with a DocumentReference instead > which can be used to display the document picker when editing the > macro in WYSIWYG mode. > > To be clear, here is how we would use it: > @PropertyType(DocumentReference.class) >public void setDocument(String document) > > WDYT? > > Thanks, > Adel +1 -- Thomas Mortagne
Re: [xwiki-devs] [Proposl] Improve JIRA resolution and introduce a "Solved by" resolution
On Thu, Jan 10, 2019 at 11:43 AM Vincent Massol wrote: > > Hi devs, > > Right now we often use “duplicate” when we have an issue that is solved by > another issue (usually a more specific one). This is not semantically correct. > > Proposal: > * Add a new jira resolution named “Solved by” > * Best practice: when using “solved by”, also use the “depends on” link "depends on" is not really semantically correct either, if it's possible add custom links it would be nicer to have corresponding ones. > > WDYT? > > Thanks > -Vincent -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Improve our Test Coverage strategy (TAKE 2)
On Sun, Jan 6, 2019 at 12:06 PM Vincent Massol wrote: > > > > > On 6 Jan 2019, at 12:03, Vincent Massol wrote: > > > > Hi devs, > > > > I ran the modified Clover job yesterday and it generated the 2 reports: > > * Report - 20171222-1835 -> 20190106-0207 : > > http://maven.xwiki.org/site/clover/20190106/XWikiReport-20171222-1835-20190106-0207.html > > * (New) Report Report - 20190101-2330 -> 20190106-0207 : > > http://maven.xwiki.org/site/clover/20190106/XWikiReport-20190101-2330-20190106-0207.html > > > > This is quite interesting. > > > > The second report shows the modules that made us loose TPC since the 1st of > > Jan 2019, i.e. in only 6 days… > > > > Note: It also shows (that’s the positive aspect), that overall we won > > 0.1371 of global TPC. But we could have won more if we can understand why > > we lost some TPC and find out if there are actions we can put in place to > > avoid that. > > > > So I think it would be good if devs who have touched these modules recently > > could analyze the cause of the decrease and verify they’re real and what we > > want to do about them. > > > > WDYT? > > Two impressive results are: > * xwiki-platform-url-api: +11.% https://github.com/xwiki/xwiki-platform/commit/00d2a7af3e9d3a7c313738ef93843407f5c29ab0 I think > * xwiki-rendering-syntax-wikimodel: +28.587% Probably because of https://github.com/xwiki/xwiki-rendering/commit/85887ab217df3a4edc88ee81ad8b796e377bbada which removed a pretty big untested class. > > Any idea why these 2 were increased so much in the past 6 days? > > Thanks > -Vincent > > > > > Thanks! > > -Vincent > > > >> On 4 Jan 2019, at 15:14, Vincent Massol wrote: > >> > >> Hi devs, > >> > >> FYI I've modified the clover job to do the following today: > >> * run daily around midnight on a4 > >> * generate 2 diff reports: one against 20171220 (that's the one we're > >> currently getting) and one against 20190101 > >> * the first diff report doesn’t send an email on failure while the second > >> one does. > >> > >> I also changed yesterday: > >> * Only mark in RED (ie failures) modules where the global diff TPC is > >> negative (before it was in RED when the global contribution was < 0 but > >> that wasn’t accounting for removed modules for example). > >> > >> Consequences: > >> * When we get report failures from the CI we need to fix it since it means > >> we’ve regressed since 20190101 > >> * It would still be good that we continue to analyze the diff report since > >> 20171220 to fully understand it and make sure we haven’t regressed in > >> quality since then, or at least fix the big regressions. > >> > >> TODO: > >> * Need to find a way to indicate false positives, i.e. modules in RED for > >> which we consider it’s ok to have a negative diff TPC, and thus know > >> what’s left to do for the release. > >> * Once we better understand and fix modules we’ll get to the second step > >> which is to automate the baseline value (manual ATM) and to have the > >> report passing as a constraint for releasing and thus indicated in the > >> Release Plan. > >> > >> Let me know if you have questions. > >> > >> Thanks > >> -Vincent > >> > >>> On 3 Oct 2018, at 10:56, Vincent Massol wrote: > >>> > >>> Hi devs, > >>> > >>> We started discussing a first global test coverage strategy in > >>> https://markmail.org/message/grphwta63pp5p4l7 > >>> > >>> I’d like to propose some updates and tuning now that we have a Clover > >>> Jenkins pipeline working (brainstormed with Simon): > >>> > >>> Here’s the new proposal: > >>> > >>> * We run the Clover Jenkins pipeline every night (between 11PM-8AM) > >>> * The pipeline sends an email whenever the new report has modules > >>> lowering the global TPC score compared to the baseline report (negative > >>> contribution per module) > >>> * The baseline report is the report generated just after each XS release. > >>> This means that we keep the same baseline during a XS release > >>> ** Technically it means that the pipeline will update the latest.txt file > >>> (which contains the clover report timestamp) when it notices a version > >>> change > >>> * We add a step in the Release Plan Template to have the report passing > >>> before we can release. > >>> * The RM is in charge of a release from day 1 to the release day (already > >>> the case), and is also in charge of making sure that the global coverage > >>> job failures get addressed before the release day so that we’re ready on > >>> the release day. > >>> > >>> Options: > >>> * Make it easier and only fail the pipeline job when the global TPC value > >>> is lower than the baseline (vs failing whenever a module has negative > >>> contribution) > >>> > >>> WDYT? > >>> > >>> Thanks > >>> -Vincent > >>> > >> > > > -- Thomas Mortagne
Re: [xwiki-devs] [Discussion] Coding practice for location of internal package name
On Tue, Dec 25, 2018 at 8:12 PM Vincent Massol wrote: > > Hi devs, > > To progress on this topic, I’m trying to summarize the options we have since > it’s still not clear in my mind. > > Option 1: Internal package after the 1st package > > > Class FQN example: > * org.xwiki..internal...MyInternalClass > > Pros: > * Easy to find all internal code for a given module (they’re all grouped > together) > * Cons: ? > > Devs: > * Vincent > * Marius > > Option 2: Internal package at any level in the package hierarchy > > > Package examples: > * org.xwiki..internal...MyInternalClass > * org.xwiki...internal..MyInternalClass > * org.xwikiinternal.MyInternalClass > > Pros: > * ? > > Cons: > * Internal code scattered in more packages. > * No consistency. Some devs will use > org.xwiki..internal...MyInternalClass when > others will use > org.xwiki...internal..MyInternalClass and yet > others will use > org.xwikiinternal.MyInternalClass > > Devs: > * Thomas > * Edy > * Sergiu > * Guillaume I did not suggested to randomly choose the package based on the programmer mood which seems to be what you understood. What I proposed is pretty much the same as Option1 but the difference is that where you define what's between "org.xwiki" and "internal" based on the top level module only I would prefer to use the whole hierarchy. One of the goals being to have all the classes of the same module located in the same base package instead of have two very different hierarchies. So for example in your version, the module xwiki-rendering-macro-box looks like this (what we have currently): org.xwiki.rendering.internal.macro.box.DefaultBoxMacro org.xwiki.rendering.macro.box.AbstractBoxMacro org.xwiki.rendering.macro.box.BoxMacroParameters and mine would be more like this: org.xwiki.rendering.macro.box.AbstractBoxMacro org.xwiki.rendering.macro.box.BoxMacroParameters org.xwiki.rendering.macro.box.internal.DefaultBoxMacro With this version everything related to the box macro is located under org.xwiki.rendering.macro.box.**. In short everything which is part of a specific domain or subdomain important enough to deserve its own sub hierarchy has a dedicated base package for public package right now and there is no reason for related internal classes end up in a different hierarchy. Of course the idea is not to include in the hierarchy modules separated for very technical reasons (xwiki-platform-core, *-api, *-default, etc.) like we currently do for public packages. > > Conclusion > = > > @Thomas, Edy, Guillaume, Sergiu: could you confirm that you’re in favor of > option 2? If so could you aslo explain the Pros of it and the Cons you see > for option 1. Right now I see more pros for Option 1. But maybe I > misunderstood what you’re proposing. Maybe you’re suggesting an option 3, > based on the Maven module names? > > Thanks > -Vincent > > > > On 16 Apr 2018, at 18:28, Vincent Massol wrote: > > > > Hi devs, > > > > On Matrix/IRC, I’ve posted the following: > > > > " > > * Guillaume Delhumeau: BTW your naming is strange for the internal package > > * for ex: package org.xwiki.notifications.preferences.internal.email; > > * normally we put internal just after the main package part > > * ie. > > * org.xwiki.notifications.internal.* > > * and org.xwiki.notifications.* for public classes > > * see > > http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/JavaCodeStyle/#HPackagenames > > * General rule is org.xwiki.(module name).internal. > > * I see thomas has done the same “error" for org.xwiki.job.handler.internal > > and org.xwiki.job.handler.internal.question . So maybe there's something to > > discuss/change > > * I guess we have a mix of both now so we should discuss it and adjust our > > rules if need be > > “ > > > > So I think we don’t have all the same rules/understanding of the definition > > at > > http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/JavaCodeStyle/#HPackagenames > > > > I’d like to discuss with you to see what you prefer and adjust our rules so > > that it matches what we do in practice. > > > > Any take in this? > > > > Thanks > > -Vincent > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Change of XS Cycle strategy to account for Christmas
+1 On Sun, Dec 9, 2018 at 4:07 PM Vincent Massol wrote: > > Ok, summarizing again after feedback from Simon, Caty and Marius, here’s the > proposal; > > * Duration: 11 minor releases (e.g. N.0 till N.10), one each month, from > January to November. > * The last month of the year, December sees 2 bug fix releases, to stabilize > the cycle: N.10.1 and N.10.2. The releases are supposed to contain mostly bug > fixes. > ** Note that the N.10.2 release can happen on the first days of January to > account for end of year holidays but it should not go beyond the 3rd of > January. > ** Work for N+1.0 starts once N.10.2 has been released. > * When N.10.2 is released we announce it: > ** Send mail mentioning that the cycle is over and encourage users to start > using N.10.2 > ** In that mail, explain all the major features that were implemented during > that release cycle (make a special Release Notes for a Cycle) > * We announce the new LTS (N.10.x) once N+1.0 is released. Rationale: > ** We need to have feedback on a release before it can be considered super > stable and thus we usually need a few bug fix releases before a version can > be considered a good LTS. This gives us one month to release additional > bugfix releases for N.10.x in case it’s needed. > ** This also allows us to always support 3 branches: > *** LTS branch > *** Stable branch > *** master (latest SNAPSHOT) > > Note that I hesitated to announce the LTS when we released N.10.2 but after > thinking about it, I think it’s better to continue announcing it only when > N+1.0 is released (i.e. at end of January). > > I have modified > https://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices?viewer=changes=14.1=15.1 > already. > > Once I have the final validation this is ok, I’m redo the screenshot at > https://dev.xwiki.org/xwiki/bin/download/Community/VersioningAndReleasePractices/releasecycle.png > > Thanks > -Vincent > > > On 19 Nov 2018, at 17:13, Vincent Massol wrote: > > > > Hi devs, > > > > Some devs mentioned it’s too hard to release the N.11 release since it > > happens around Christmas every year. > > > > Here’s a proposal: > > > > * Shorten the cycle to 11 releases instead of 12. > > * Release N.9 at end of Nov > > * Release N.10 at end of first week of Jan. Note: N.10RC1 would be released > > mid December (about 17th of Dec to have 3 weeks of RC). > > * Release N+1.0 at end of February. Start of N+1.0 work > > > > Pros: > > * No release during Christmas, yeah :) > > * More time to prepare the first LTS bugfix release, i.e. N.10.1, which can > > be done during the month of January. > > * More time for the first released of N+1 (i.e. N+1.0). This is important > > since that’s the release where we can do heavy refactoring and it’s not bad > > to get some more time. > > > > Cons: > > * One less release > > > > WDYT? Do you see other cons? > > > > Thanks > > -Vincent > > > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] New xwiki-clover-maven repository
+1 On Thu, Nov 29, 2018 at 6:41 PM Vincent Massol wrote: > > Hi devs, > > I’d like to refactor the groovy code that I’ve currently put at > https://github.com/xwiki/xwiki-jenkins-pipeline/blob/59051fd8f61bd5a65db790684eff8679d17c51f1/src/org/xwiki/jenkins/Clover.groovy > and to move it into an XWiki Maven plugin for Clover. > > The goal of this plugin is to take as input two clover.xml Clover data files > and to generate a diff report (example: > http://maven.xwiki.org/site/clover/20181120/XWikiReport-20171222-1835-20181120-1737.html). > > Rationale for move this outside of Jenkins: > * Less dependency on Jenkins > * Much easier to test > * Better versioning and release > * Increased reuse (any project in the world will be able to use it whereas > the pipeline is specific to xwiki and not reusable easily) > > It’s not linked to releases of XWiki. But it should be maintained by the > xwiki dev team since we use it in our pipeline to compute the global coverage > and generate reports/emails when global TPC is lowered. > > WDYT? > > Thanks > -Vincent -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] WCAG exception: consecutive line breaks
On Mon, Nov 26, 2018 at 12:00 PM Marius Dumitru Florea wrote: > > On Thu, Nov 22, 2018 at 11:22 AM Thomas Mortagne > wrote: > > > On Thu, Nov 22, 2018 at 9:57 AM Vincent Massol wrote: > > > > > > > > > > > > > On 21 Nov 2018, at 17:46, Adel Atallah wrote: > > > > > > > > Hello, > > > > > > > > On Wed, Nov 21, 2018 at 5:36 PM Simon Urli > > wrote: > > > >> > > > >> Hi everyone, > > > >> > > > >> one of the most validation error we have with WCAG is about > > consecutive > > > >> line breaks: basically a presents in a page. > > > >> > > > >> This happens mostly in our translation pages since the linebreaks in > > > >> plain syntax are translated in tags. > > > >> Caty provided a lot of details about this error on the related issue: > > > >> https://jira.xwiki.org/browse/XWIKI-15666. > > > >> > > > >> Currently we have around 140 validations failure because of this. > > > >> > > > >> Different proposal have been made in order to fix it, that I will try > > to > > > >> sum-up here: > > > >> > > > >> A. Remove completely this validation check > > > > > > > > -0, I think the validation can be useful at least to keep good > > practices. > > > > > > > >> B. Add an exception for the translation pages > > > > > > > > +1, simplest one. > > > > > > Note that the question is not so much about being simple (we can just > > remove WCAG for that and it’s the simplest ;)) but about being the right > > thing to do for people with disabilities. > > > > > > For me we have the following options: > > > > > > A) We don’t think that this check is useful, ie that it brings > > advantages for people with disabilities and then we can remove it. No need > > to add exceptions. > > > > > > B) We think the check is useful for people with disabilities and we > > should keep it, even for translations pages since I don’t see why people > > with disabilities shouldn’t be able to use translation pages. There are > > some ideas to fix this: I listed some in the jira issue and Thomas > > mentioned one too (it’s option D). > > > > > > > > C) Now I’m fine if we say the following: for technical reasons it’s > > already hard to ensure that we pass WCAG for user pages and thus FTM we > > focus only on those ones and we agree that we don’t pass WCAG for > > developer-oriented features, with the goal of improving on that aspect in > > the future. And thus we disable WCAG checks on technical pages (hidden > > pages) for now. > > > > > > > Excluding hidden page for now is indeed something that would make a > > lot of sense. > > > > I agree. The issue is that we can have hidden pages that: > > * are not displayed by default (I'm thinking panels) Yes, we just need to have a filter a little bit more advanced than "hidden=false". We could imagine a white list of xclasses (which would have priority over "hidden=false" filter). Now for the specific panels use case we actually have a place where they are all displayed and validated all at once: the administration. > * are included / displayed dynamically with JavaScript so they won't appear > in the HTML downloaded by our WCAG tests (I'm thinking of async panels and > modals for instance) Validating DOM generated in javascript is indeed a problem we already have. Now for the few cases which are actually wiki pages included asynchronously and which don't fit in a generic xclass based filter we could add them trough the existing URL list property. About async panels, most of them are also cached which means they are really asyn only when loading the first page (when the framework find a cached content is return it instead of putting an async placeholder). > > So they won't be covered. > > > > > > > > > > Thanks > > > -Vincent > > > > > > > > > > >> C. Triggers the error only if more than 2 consecutive breaks is > > > >> encountered > > > > > > > > -1, it doesn't really makes sense to do that, it's like B. but badly > > done. > > > > > > > >> D. Create a rendering syntax dedicated to translation pages > > > > > > > > +1, could be a good idea but might be complicated. > > > > > > > >> > &
Re: [xwiki-devs] [Proposal] WCAG exception: consecutive line breaks
On Thu, Nov 22, 2018 at 9:57 AM Vincent Massol wrote: > > > > > On 21 Nov 2018, at 17:46, Adel Atallah wrote: > > > > Hello, > > > > On Wed, Nov 21, 2018 at 5:36 PM Simon Urli wrote: > >> > >> Hi everyone, > >> > >> one of the most validation error we have with WCAG is about consecutive > >> line breaks: basically a presents in a page. > >> > >> This happens mostly in our translation pages since the linebreaks in > >> plain syntax are translated in tags. > >> Caty provided a lot of details about this error on the related issue: > >> https://jira.xwiki.org/browse/XWIKI-15666. > >> > >> Currently we have around 140 validations failure because of this. > >> > >> Different proposal have been made in order to fix it, that I will try to > >> sum-up here: > >> > >> A. Remove completely this validation check > > > > -0, I think the validation can be useful at least to keep good practices. > > > >> B. Add an exception for the translation pages > > > > +1, simplest one. > > Note that the question is not so much about being simple (we can just remove > WCAG for that and it’s the simplest ;)) but about being the right thing to do > for people with disabilities. > > For me we have the following options: > > A) We don’t think that this check is useful, ie that it brings advantages for > people with disabilities and then we can remove it. No need to add exceptions. > > B) We think the check is useful for people with disabilities and we should > keep it, even for translations pages since I don’t see why people with > disabilities shouldn’t be able to use translation pages. There are some ideas > to fix this: I listed some in the jira issue and Thomas mentioned one too > (it’s option D). > > C) Now I’m fine if we say the following: for technical reasons it’s already > hard to ensure that we pass WCAG for user pages and thus FTM we focus only on > those ones and we agree that we don’t pass WCAG for developer-oriented > features, with the goal of improving on that aspect in the future. And thus > we disable WCAG checks on technical pages (hidden pages) for now. Excluding hidden page for now is indeed something that would make a lot of sense. > > Thanks > -Vincent > > > > >> C. Triggers the error only if more than 2 consecutive breaks is > >> encountered > > > > -1, it doesn't really makes sense to do that, it's like B. but badly done. > > > >> D. Create a rendering syntax dedicated to translation pages > > > > +1, could be a good idea but might be complicated. > > > >> > >> > >> A. Remove completely the validation check > >> > >> pros: > >> * the easiest one > >> * apparently the rule is not checked in other accessibility test, so > >> its real purpose for accessibility is unclear > >> > >> cons: > >> * IMO this rule is useful for checking the good practice of not using > >> > >> > >> B. Add an exception for the translation pages > >> > >> pros: > >> * same as for A > >> > >> cons: > >> * ? > >> > >> C. Triggers the error only if more than 2 consecutive breaks is encountered > >> > >> pros: > >> * ? > >> > >> cons: > >> * we would miss some consecutive that are used only for style > >> and we would catch some others in translations if we do 3 linebreaks > >> instead of 2. IMO it's only moving the problem > >> > >> D. Create a rendering syntax dedicated to translation pages > >> > >> pros: > >> * remove completely the problem of consecutive in translations > >> * can maybe be used to present them in another way? > >> > >> cons: > >> * need to develop/test/maintain a new rendering syntax > >> > >> I'd personnaly vote like this: > >> A: +0 > >> B: +1 > >> C: -1 > >> D: +0 > >> > >> WDYT? > >> > >> Simon > >> -- > >> Simon Urli > >> Software Engineer at XWiki SAS > >> simon.u...@xwiki.com > >> More about us at http://www.xwiki.com > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Always add a link to the reference doc in the RN items
It's certainly nicer to have a link to the documentation. Now not sure it's really work all the time and how to show it best, also we need to support several link for the same entry since a RN entry often contain several things in the same domain. On Tue, Nov 20, 2018 at 1:21 PM Guillaume Delhumeau wrote: > > Since the documentation url is already filled in our jira issue, could we > associate the issue number to Release Notes change, and so the url of the > documentation is automatically pulled from jira ? This way we could also > add a link to the jira issue. > > My 2 cents, > > Le mar. 20 nov. 2018 à 13:12, Marius Dumitru Florea < > mariusdumitru.flo...@xwiki.com> a écrit : > > > +1 > > > > On Sun, Nov 18, 2018 at 3:56 PM Vincent Massol wrote: > > > > > Hi devs, > > > > > > This is something I mentioned a few times (just did on IRC/matrix an hour > > > ago too) but I don’t know if we have an agreement about to, so I’m > > making a > > > proposal. > > > > > > The idea is that I think it would be nice for users to be able to the > > read > > > the RN and for each item to be able to navigate to the reference > > > documentation to know more about the topic. > > > > > > Thus the proposal is to always add a link to the reference doc in RN > > items. > > > > > > For example I added a link here: > > > > > > > > https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.10RC1/#HAllowwikimacrostoindicatethetypeofparameters > > > > > > When I created the RN app I had hesitate to have a field for that but I > > > thought it be nicer if the links were in the text (better flow) and it > > > would take less visual space (if we have a field we’ll need to add the > > info > > > somewhere which will take more space). The downside is that everyone is > > > forgetting to do it and it's not enforceable automatically. > > > > > > WDYT? > > > > > > Thanks > > > -Vincent > > > > > > > > > > > -- > Guillaume Delhumeau (guillaume.delhum...@xwiki.com) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Change of XS Cycle strategy to account for Christmas
+1 On Mon, Nov 19, 2018 at 5:13 PM Vincent Massol wrote: > > Hi devs, > > Some devs mentioned it’s too hard to release the N.11 release since it > happens around Christmas every year. > > Here’s a proposal: > > * Shorten the cycle to 11 releases instead of 12. > * Release N.9 at end of Nov > * Release N.10 at end of first week of Jan. Note: N.10RC1 would be released > mid December (about 17th of Dec to have 3 weeks of RC). > * Release N+1.0 at end of February. Start of N+1.0 work > > Pros: > * No release during Christmas, yeah :) > * More time to prepare the first LTS bugfix release, i.e. N.10.1, which can > be done during the month of January. > * More time for the first released of N+1 (i.e. N+1.0). This is important > since that’s the release where we can do heavy refactoring and it’s not bad > to get some more time. > > Cons: > * One less release > > WDYT? Do you see other cons? > > Thanks > -Vincent > -- Thomas Mortagne
Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters
Actually that's the wrong example, with that one you end up with page
and document in the same group so they can't conflict :)
The fixed one was:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
@PropertyGroup({"target", "page"})
@PropertyFeature("reference")
page
@PropertyGroup({"target", "entityReference"})
@PropertyFeature("reference")
reference
@PropertyGroup({"target", "entityReference"})
type
@PropertyGroup("target", "reference")
@PropertyFeature("reference")
document
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><
and properties not associated to a group being automatically part of a
group with a unique property.
On Fri, Nov 16, 2018 at 10:42 AM Adel Atallah wrote:
>
> So do we agree on trying the solution given by Thomas? i.e. creating
> two annotations:
> 1. PropertyGroup to specify a hierarchy of groups to a parameter
> 2. PropertyFeature to indicate that some parameters/groups represents the
> same feature (which can lead to conflicts).
>
> Here was the given example:
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> @PropertyGroup("target")
> @PropertyFeature("reference")
> page
>
> @PropertyGroup({"target", "entityReference"})
> @PropertyFeature("reference")
> reference
>
> @PropertyGroup({"target", "entityReference"})
> type
>
> @PropertyGroup("target")
> @PropertyFeature("reference")
> document
>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> I've already started implementing the PropertyGroup annotation.
>
> On Thu, Nov 15, 2018 at 3:13 PM Thomas Mortagne
> wrote:
> >
> > On Thu, Nov 15, 2018 at 2:06 PM Adel Atallah wrote:
> > >
> > > On Thu, Nov 15, 2018 at 1:56 PM Thomas Mortagne
> > > wrote:
> > > >
> > > > On Thu, Nov 15, 2018 at 1:24 PM Adel Atallah
> > > > wrote:
> > > > >
> > > > > On Thu, Nov 15, 2018 at 11:13 AM Thomas Mortagne
> > > > > wrote:
> > > > > >
> > > > > > On Thu, Nov 15, 2018 at 11:06 AM Adel Atallah
> > > > > > wrote:
> > > > > > >
> > > > > > > Ok so it seems like we are getting back to the proposition we
> > > > > > > made with Vincent.
> > > > > > > We need one annotation to enforce the dependence between
> > > > > > > parameters
> > > > > > > (reference and type in our example) and another one that can be
> > > > > > > used
> > > > > > > to *deduce* conflicting parameters.
> > > > > >
> > > > > > > I don't understand how a hierarchy of groups can help us specify a
> > > > > > > dependence between parameters.
> > > > > >
> > > > > > I don't think it does, it's just that since we are defining groups
> > > > > > having subgroups would be useful visually.
> > > > > >
> > > > > > > A parameter is either in the same group
> > > > > > > as another one or it is not. The hierarchy seems to focus on
> > > > > > > problems
> > > > > > > that we are not trying to solve here.
> > > > > > > The original proposal was similar to what Thomas proposed, but
> > > > > > > without
> > > > > > > hierarchy:
> > > > > > >
> > > > > > > @Alternative("reference")
> > > > > > > @Group("entityReference")
> > > > > > > reference
> > > > > > >
> > > > > > > @Alternative("reference")
> > > > > > > @Group("entityReference")
> > > > > > > type
> > > > > > >
> > > > > > > @Alternative("reference")
> > > > > > > page
> > > > > > >
Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters
On Thu, Nov 15, 2018 at 2:06 PM Adel Atallah wrote:
>
> On Thu, Nov 15, 2018 at 1:56 PM Thomas Mortagne
> wrote:
> >
> > On Thu, Nov 15, 2018 at 1:24 PM Adel Atallah wrote:
> > >
> > > On Thu, Nov 15, 2018 at 11:13 AM Thomas Mortagne
> > > wrote:
> > > >
> > > > On Thu, Nov 15, 2018 at 11:06 AM Adel Atallah
> > > > wrote:
> > > > >
> > > > > Ok so it seems like we are getting back to the proposition we made
> > > > > with Vincent.
> > > > > We need one annotation to enforce the dependence between parameters
> > > > > (reference and type in our example) and another one that can be used
> > > > > to *deduce* conflicting parameters.
> > > >
> > > > > I don't understand how a hierarchy of groups can help us specify a
> > > > > dependence between parameters.
> > > >
> > > > I don't think it does, it's just that since we are defining groups
> > > > having subgroups would be useful visually.
> > > >
> > > > > A parameter is either in the same group
> > > > > as another one or it is not. The hierarchy seems to focus on problems
> > > > > that we are not trying to solve here.
> > > > > The original proposal was similar to what Thomas proposed, but without
> > > > > hierarchy:
> > > > >
> > > > > @Alternative("reference")
> > > > > @Group("entityReference")
> > > > > reference
> > > > >
> > > > > @Alternative("reference")
> > > > > @Group("entityReference")
> > > > > type
> > > > >
> > > > > @Alternative("reference")
> > > > > page
> > > > >
> > > > > @Alternative("reference")
> > > > > document
> > > > >
> > > > > where "Alternative" is the same as "Feature". Now Marius didn't agree
> > > > > with that because the "Alternative" annotation should not be bind to
> > > > > "reference" and "type" parameters but to the group "entityReference"
> > > >
> > > > And as I said in my proposal the features are associated to the group,
> > > > not the properties. I agree that associating it to the property (and
> > > > ending up with half of a group conflicting with half of another) does
> > > > really make sense.
> > > >
> > >
> > > This is not enforced by the code.
> >
> > I don't understand what you mean, there is no code yet.
>
> By code I meant the annotations in the code.
Yes but hard to do much better I think without breaking anything now
that we have two parameters for a single information, we need to
maintain them.
>
> > For me the
> > code which is going to parse this Java bean will of course make sure
> > the features are associated to the group of the property.
>
> I agree with that.
>
> >
> > > You know that features are
> > > associated to groups *because* they are bound to the same property.
> > > Anyway I'm +1 to do it this way.
> > >
> > > > > ,
> > > > > which is not possible to do without creating other classes. I don't
> > > > > think this is an issue to put the "Alternative" annotation on
> > > > > "reference" and "type" because we should have all the necessary
> > > > > information to *deduce* the conflicting parameters. It's true that
> > > > > removing the "Alternative" annotation of one of "reference" or "type"
> > > > > should produce the same result though, which could be confusing.
> > > > > On Thu, Nov 15, 2018 at 10:23 AM Marius Dumitru Florea
> > > > > wrote:
> > > > > >
> > > > > > On Thu, Nov 15, 2018 at 10:51 AM Thomas Mortagne
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I'm also really not a fan of having to implement a component just
> > > > > > > to
> > > > > > > indicate that two groups of properties are conflicting.
> > > > > > >
> > > > > > > +1 for making @Group support a hierarchy, that's indeed nice.
> > > > > > >
> > > > > > > For for c
Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters
On Thu, Nov 15, 2018 at 1:24 PM Adel Atallah wrote:
>
> On Thu, Nov 15, 2018 at 11:13 AM Thomas Mortagne
> wrote:
> >
> > On Thu, Nov 15, 2018 at 11:06 AM Adel Atallah
> > wrote:
> > >
> > > Ok so it seems like we are getting back to the proposition we made with
> > > Vincent.
> > > We need one annotation to enforce the dependence between parameters
> > > (reference and type in our example) and another one that can be used
> > > to *deduce* conflicting parameters.
> >
> > > I don't understand how a hierarchy of groups can help us specify a
> > > dependence between parameters.
> >
> > I don't think it does, it's just that since we are defining groups
> > having subgroups would be useful visually.
> >
> > > A parameter is either in the same group
> > > as another one or it is not. The hierarchy seems to focus on problems
> > > that we are not trying to solve here.
> > > The original proposal was similar to what Thomas proposed, but without
> > > hierarchy:
> > >
> > > @Alternative("reference")
> > > @Group("entityReference")
> > > reference
> > >
> > > @Alternative("reference")
> > > @Group("entityReference")
> > > type
> > >
> > > @Alternative("reference")
> > > page
> > >
> > > @Alternative("reference")
> > > document
> > >
> > > where "Alternative" is the same as "Feature". Now Marius didn't agree
> > > with that because the "Alternative" annotation should not be bind to
> > > "reference" and "type" parameters but to the group "entityReference"
> >
> > And as I said in my proposal the features are associated to the group,
> > not the properties. I agree that associating it to the property (and
> > ending up with half of a group conflicting with half of another) does
> > really make sense.
> >
>
> This is not enforced by the code.
I don't understand what you mean, there is no code yet. For me the
code which is going to parse this Java bean will of course make sure
the features are associated to the group of the property.
> You know that features are
> associated to groups *because* they are bound to the same property.
> Anyway I'm +1 to do it this way.
>
> > > ,
> > > which is not possible to do without creating other classes. I don't
> > > think this is an issue to put the "Alternative" annotation on
> > > "reference" and "type" because we should have all the necessary
> > > information to *deduce* the conflicting parameters. It's true that
> > > removing the "Alternative" annotation of one of "reference" or "type"
> > > should produce the same result though, which could be confusing.
> > > On Thu, Nov 15, 2018 at 10:23 AM Marius Dumitru Florea
> > > wrote:
> > > >
> > > > On Thu, Nov 15, 2018 at 10:51 AM Thomas Mortagne
> > > >
> > > > wrote:
> > > >
> > > > > I'm also really not a fan of having to implement a component just to
> > > > > indicate that two groups of properties are conflicting.
> > > > >
> > > > > +1 for making @Group support a hierarchy, that's indeed nice.
> > > > >
> > > > > For for conflicting we need a dedicated annotation IMO.
> > > > >
> > > > > So starting from your previous example I would expect something like:
> > > > >
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >
> > > > > @PropertyGroup("target")
> > > > > @PropertyFeature("reference")
> > > > > page
> > > > >
> > > > > @PropertyGroup({"target", "entityReference"})
> > > > > @PropertyFeature("reference")
> > > > > reference
> > > > >
> > > > > @PropertyGroup({"target", "entityReference"})
> > > > > type
> > > > >
> > > > > @PropertyGroup("target")
> > > > > @PropertyFeature("reference")
> > > > > document
> > > > >
> > > > > <<<<<<<<<<
Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters
On Thu, Nov 15, 2018 at 11:06 AM Adel Atallah wrote:
>
> Ok so it seems like we are getting back to the proposition we made with
> Vincent.
> We need one annotation to enforce the dependence between parameters
> (reference and type in our example) and another one that can be used
> to *deduce* conflicting parameters.
> I don't understand how a hierarchy of groups can help us specify a
> dependence between parameters.
I don't think it does, it's just that since we are defining groups
having subgroups would be useful visually.
> A parameter is either in the same group
> as another one or it is not. The hierarchy seems to focus on problems
> that we are not trying to solve here.
> The original proposal was similar to what Thomas proposed, but without
> hierarchy:
>
> @Alternative("reference")
> @Group("entityReference")
> reference
>
> @Alternative("reference")
> @Group("entityReference")
> type
>
> @Alternative("reference")
> page
>
> @Alternative("reference")
> document
>
> where "Alternative" is the same as "Feature". Now Marius didn't agree
> with that because the "Alternative" annotation should not be bind to
> "reference" and "type" parameters but to the group "entityReference"
And as I said in my proposal the features are associated to the group,
not the properties. I agree that associating it to the property (and
ending up with half of a group conflicting with half of another) does
really make sense.
> ,
> which is not possible to do without creating other classes. I don't
> think this is an issue to put the "Alternative" annotation on
> "reference" and "type" because we should have all the necessary
> information to *deduce* the conflicting parameters. It's true that
> removing the "Alternative" annotation of one of "reference" or "type"
> should produce the same result though, which could be confusing.
> On Thu, Nov 15, 2018 at 10:23 AM Marius Dumitru Florea
> wrote:
> >
> > On Thu, Nov 15, 2018 at 10:51 AM Thomas Mortagne
> > wrote:
> >
> > > I'm also really not a fan of having to implement a component just to
> > > indicate that two groups of properties are conflicting.
> > >
> > > +1 for making @Group support a hierarchy, that's indeed nice.
> > >
> > > For for conflicting we need a dedicated annotation IMO.
> > >
> > > So starting from your previous example I would expect something like:
> > >
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >
> > > @PropertyGroup("target")
> > > @PropertyFeature("reference")
> > > page
> > >
> > > @PropertyGroup({"target", "entityReference"})
> > > @PropertyFeature("reference")
> > > reference
> > >
> > > @PropertyGroup({"target", "entityReference"})
> > > type
> > >
> > > @PropertyGroup("target")
> > > @PropertyFeature("reference")
> > > document
> > >
> > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> > >
> >
> > I don't think this is complete. The following doesn't make sense:
> >
> > {{include page="..." type="..."/}}
> >
> > and neither this:
> >
> > {{include document="..." type="..." /}}
> >
> > So it's not the reference parameter alone that provides the "reference"
> > feature. The pair / group of parameters (reference and type) are providing
> > the "reference" feature. This is why I think there is the need to specify
> > the "feature" on the sub group "entityReference" not on the parameter. And
> > to do this we need another class..
> >
> > >
> > >
> > > or
> > >
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >
> > > @PropertyGroup("target", features = "reference")
> > > page
> > >
> > > @PropertyGroup({"target", "ent
Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters
Also since there was group on all field in your example I forgot one
thing about the @PropertyFeature possibility (not possible with the
features field): you don't need a @PropertyGroup, if none id defined
you get a unique group with no name and associated feature so for
example work with the following use case:
@PropertyFeature("reference")
page
@PropertyGroup("entityReference")
@PropertyFeature("reference")
reference
@PropertyGroup(entityReference")
type
@PropertyFeature("reference")
document
On Thu, Nov 15, 2018 at 10:58 AM Thomas Mortagne
wrote:
>
> On Thu, Nov 15, 2018 at 10:23 AM Marius Dumitru Florea
> wrote:
> >
> > On Thu, Nov 15, 2018 at 10:51 AM Thomas Mortagne
> > wrote:
> >
> > > I'm also really not a fan of having to implement a component just to
> > > indicate that two groups of properties are conflicting.
> > >
> > > +1 for making @Group support a hierarchy, that's indeed nice.
> > >
> > > For for conflicting we need a dedicated annotation IMO.
> > >
> > > So starting from your previous example I would expect something like:
> > >
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >
> > > @PropertyGroup("target")
> > > @PropertyFeature("reference")
> > > page
> > >
> > > @PropertyGroup({"target", "entityReference"})
> > > @PropertyFeature("reference")
> > > reference
> > >
> > > @PropertyGroup({"target", "entityReference"})
> > > type
> > >
> > > @PropertyGroup("target")
> > > @PropertyFeature("reference")
> > > document
> > >
> > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> > >
> >
> > I don't think this is complete. The following doesn't make sense:
>
> Actually you missed one point: the features are associated to the group.
>
> But I wrote the example too quickly, here is a fixed one:
>
> @PropertyGroup({"target", "page"})
> @PropertyFeature("reference")
> page
>
> @PropertyGroup({"target", "entityReference"})
> @PropertyFeature("reference")
> reference
>
> @PropertyGroup({"target", "entityReference"})
> type
>
> @PropertyGroup("target", "reference")
> @PropertyFeature("reference")
> document
>
> >
> > {{include page="..." type="..."/}}
>
> No because page conflict with the whole target/entityReference group.
>
> >
> > and neither this:
> >
> > {{include document="..." type="..." /}}
>
> No because document conflict with the whole target/entityReference group.
>
> >
> > So it's not the reference parameter alone that provides the "reference"
> > feature. The pair / group of parameters (reference and type) are providing
> > the "reference" feature. This is why I think there is the need to specify
> > the "feature" on the sub group "entityReference" not on the parameter. And
> > to do this we need another class..
> >
> > >
> > >
> > > or
> > >
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >
> > > @PropertyGroup("target", features = "reference")
> > > page
> > >
> > > @PropertyGroup({"target", "entityReference"}, features = "reference")
> > > reference
> > >
> > > @PropertyGroup({"target", "entityReference"})
> > > type
> > >
> > > @PropertyGroup("target", features = "reference")
> > > document
> > >
> > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> > >
> > >
> >
> > > * PropertyGroup define the hierarchy (also proposed a String[] instead
> > > of String based valu
Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters
On Thu, Nov 15, 2018 at 10:23 AM Marius Dumitru Florea
wrote:
>
> On Thu, Nov 15, 2018 at 10:51 AM Thomas Mortagne
> wrote:
>
> > I'm also really not a fan of having to implement a component just to
> > indicate that two groups of properties are conflicting.
> >
> > +1 for making @Group support a hierarchy, that's indeed nice.
> >
> > For for conflicting we need a dedicated annotation IMO.
> >
> > So starting from your previous example I would expect something like:
> >
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >
> > @PropertyGroup("target")
> > @PropertyFeature("reference")
> > page
> >
> > @PropertyGroup({"target", "entityReference"})
> > @PropertyFeature("reference")
> > reference
> >
> > @PropertyGroup({"target", "entityReference"})
> > type
> >
> > @PropertyGroup("target")
> > @PropertyFeature("reference")
> > document
> >
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >
>
> I don't think this is complete. The following doesn't make sense:
Actually you missed one point: the features are associated to the group.
But I wrote the example too quickly, here is a fixed one:
@PropertyGroup({"target", "page"})
@PropertyFeature("reference")
page
@PropertyGroup({"target", "entityReference"})
@PropertyFeature("reference")
reference
@PropertyGroup({"target", "entityReference"})
type
@PropertyGroup("target", "reference")
@PropertyFeature("reference")
document
>
> {{include page="..." type="..."/}}
No because page conflict with the whole target/entityReference group.
>
> and neither this:
>
> {{include document="..." type="..." /}}
No because document conflict with the whole target/entityReference group.
>
> So it's not the reference parameter alone that provides the "reference"
> feature. The pair / group of parameters (reference and type) are providing
> the "reference" feature. This is why I think there is the need to specify
> the "feature" on the sub group "entityReference" not on the parameter. And
> to do this we need another class..
>
> >
> >
> > or
> >
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >
> > @PropertyGroup("target", features = "reference")
> > page
> >
> > @PropertyGroup({"target", "entityReference"}, features = "reference")
> > reference
> >
> > @PropertyGroup({"target", "entityReference"})
> > type
> >
> > @PropertyGroup("target", features = "reference")
> > document
> >
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >
> >
>
> > * PropertyGroup define the hierarchy (also proposed a String[] instead
> > of String based value to show all possible ways to pass the hierarchy
> > value)
> >
>
> +1 for this
>
>
> > * PropertyFeature (name is negotiable :)) or PropertyGroup "features"
> > field associate the group with a set of unique "features". This is the
> > same logic than for extensions where several groups with with a shared
> > feature are in conflict
> >
>
> You're not associating the feature to the group. That is the problem IMO.
> You are associating the feature to the parameter. For instance:
>
> @PropertyGroup("foo", features = "input")
> one
>
> @PropertyGroup("foo", features = "output")
> two
>
> Is the "input" and "output" feature associate to the "foo" group or to the
> parameters one and two respectively?
>
> Thanks,
> Marius
>
>
> >
> > We could also decide to support only one feature per group right now
> > since we don't yet have the need for several but it felt more natural
Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters
arget/entityReference")
> >>>> type
> >>>>
> >>>> @Group("target")
> >>>> document
> >>>>
> >>>> section
> >>>>
> >>>> context
> >>>> ->8---
> >>>>
> >>>> That is: specify *only* the group hierarchy in the macro parameter
> >>>> descriptor. This would produce the following hierarchy:
> >>>>
> >>>> *
> >>>> ** page
> >>>> **
> >>>> *** reference
> >>>> *** type
> >>>> ** document
> >>>> * section
> >>>> * context
> >>>>
> >>>> Next, for the cases where we want to customize the behavior of a group,
> >>> we
> >>>> introduce a component role ParameterGroup. For instance, for the "target"
> >>>> parameter group of the Include Macro we would create
> >>>>
> >>>> @Named("include/target")
> >>>> public class TargetParameterGroup implements ParameterGroup {}
> >>>>
> >>>> To specify that the members of a parameter group are exclusive we can
> >>>> either use a method in the ParameterGroup interface (e.g. isExclusive())
> >>> or
> >>>> use an annotation on the implementation TargetParameterGroup.
> >>>>
> >>>> Thanks,
> >>>> Marius
> >>>>
> >>>>
> >>>> On Tue, Nov 13, 2018 at 12:03 PM Adel Atallah
> >>>> wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> I'd like to briefly summarize the situation so that we can make some
> >>>>> progress.
> >>>>>
> >>>>> What we have:
> >>>>> * We define "parameters" in a macro by creating a Java Bean, which
> >>>>> provides all the getters and setters of the parameters we want.
> >>>>> * We can use annotations on these getters/setters to define some
> >>>>> behavior or metadata for these parameters (description, mandatory,
> >>>>> deprecated...)
> >>>>>
> >>>>> What we want:
> >>>>> * Being able to handle conflicting parameters. For instance when we
> >>>>> deprecate a parameter and add a new one to replace it, we should be
> >>>>> able to either use the deprecated parameter or the new one but not
> >>>>> both.
> >>>>> * We also want to group parameters that are related to each other.
> >>>>>
> >>>>> What we proposed:
> >>>>> * Use annotations on the parameters to express the conflict.
> >>>>> * Marius proposed to see the problem as a boolean expression such as:
> >>>>> (page XOR (reference AND type) XOR document) OR section OR context.
> >>>>> This would translate as: the user can use the 'section' and/or
> >>>>> 'context' parameters (if they want), can use only one of these
> >>>>> parameters: 'page', ('reference' and 'type') or 'document', where
> >>>>> 'reference' and 'type' depend on each other and you can't use one
> >>>>> without the other.
> >>>>> * You can see on previous e-mails the kind of annotations we proposed
> >>>>> to solve the issue.
> >>>>>
> >>>>> Thanks,
> >>>>> Adel
>
--
Thomas Mortagne
Re: [xwiki-devs] [Proposal] Update servlet container support strategy
On Tue, Nov 13, 2018 at 11:25 AM Vincent Massol wrote: > > So I’m proposing: > > * Tomcat: latest of debian oldstable/stable/unstable for tomcat 8.x, see > https://packages.debian.org/search?suite=default=all=any=names=tomcat8=1 > (in practice that’s 8.0.x and 8.5.x). > > @Thomas: I see that we provide a tomcat7 and tomcat8 packaging for debian. > Should we drop the tomcat7 one? I don’t think we should support it. Actually I have the need myself (some server stuck on a old Ubuntu 14.04 that I need to migrate) so I'm not going to delete it just yet :) But +1 to officially not support it yes. > > * Jetty: latest of debian oldstable/stable/unstable for jetty 9.x, see > https://packages.debian.org/search?suite=default=all=any=names=jetty9=1 > (in practice that’s 9.2.x). NOTE: Strange that “unstable” is lagging behind > so much and that Jetty 9.4.x is not being tested. Anyway it’s easier to > follow the debian repos. > > * Jetty Standaline: latest of Jetty 9.x, (i.e. 9.4.x FROM) > > I’m updating > https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrategy/ > , let me know if you disagree. > > Thanks > -Vincent > > > On 31 Oct 2018, at 10:04, Vincent Massol wrote: > > > > Hi devs, > > > > We now have > > https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrategy/ > > but it’s not precise enough. > > > > I’m proposing the following: > > > > * Mention the supported version cycle and mention that we support the > > latest version of the cycle. > > * For Tomcat, I propose to say we support Tomcat 8.x (which means Tomcat > > 8.5.34 as of today, see “latest” tag on https://hub.docker.com/_/tomcat/) > > * For Jetty (standalone packaging or standard), I propose to say we support > > Jetty 9.x (which means Jetty 9.4.12 as of today, see “latest” tag on > > https://hub.docker.com/_/jetty/) > > > > WDYT? > > > > Thanks > > -Vincent > > > > > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Update database support strategy
Indeed mysql-server package (version 5.5.) leads to
mariadb-server-10.1 in current stretch repository.
What is surprising is that this is not the case for sid which is more
or less supposed to be the future. It's also not the case in Ubuntu
which is doing the same thing as sid.
On Mon, Nov 12, 2018 at 6:22 PM Eduard Moraru wrote:
>
> I am not up to date on the topic, but I would like to add the fact that
> Debian 9 ("stretch") has actually dropped MySQL and moved officially to
> MariaDB, forcefully migrating existing MySQL installed versions to MariaDB.
>
> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#mariadb-replaces-mysql
>
> The default mysql-server package now redirects to MariaDB instead.
>
> If we are going to follow Debian's lead, we might want to at least consider
> this move.
>
> Thanks,
> Eduard
>
> On Mon, Nov 12, 2018 at 6:38 PM Vincent Massol wrote:
>
> >
> >
> > > On 12 Nov 2018, at 16:52, Vincent Massol wrote:
> > >
> > > So we need to conclude on this thread. I’m proposing to update the page
> > with:
> > >
> > > * HSQLDB - Latest only
> > > * MySQL - latest of oldstable/stable/unstable from
> > https://packages.debian.org/search?keywords=mysql-server=names=1
> > (i.e. latest of 5.5.x and 5.7.x today)
> > > * PostgreSQL - latest of oldstable/stable/unstable fromhttps://
> > packages.debian.org/search?keywords=postgresql=names=1
> > (i.e. latest of 9.4.x, 9.6.x and 11.x today)
> > > * Oracle - latest of 12.x (we currently test on 11.x AFAIK so we need to
> > start testing on 12.x from now on)
> > >
> > > Note that by “support" we mean test on. And it’s not because a version
> > is not supported that it doesn’t work nor that we won’t fix it if a problem
> > happens.
> > >
> > > I hesitated a long time for the mysql/pgsql versions since I wanted only
> > a single version supported, but since we provide a debian packaging it
> > makes sense to test the versions defined by the debian repos, and now that
> > we have automated functional tests on various configurations, we can test
> > on them. BTW I suggest we run all tests on the latest version only (i.e.
> > 5.7.x for mysql and 11.x for postgresql, and move to mysql 8.x when we fix
> > the bug on it) and then we do smoke tests on the other versions.
> > >
> > > Let me know quickly if you have a problem with this strategy since I’d
> > like to update the page + add the configs in our CI tests.
> >
> > FYI, I’ve now updated the page at
> > https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy
> > (but I can update/revert if need be).
> >
> > Thanks
> > -Vincent
> >
> > >
> > > Thanks
> > > -Vincent
> > >
> > >
> > >> On 31 Oct 2018, at 09:06, Vincent Massol wrote:
> > >>
> > >> Hi devs,
> > >>
> > >> We currently have
> > https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy
> > >>
> > >> However, it doesn’t say explicitly which versions we officially support:
> > >> * For HSQLDB it says 2.3.3 which is wrong since the latest version is
> > 2.4.1
> > >> * For MySQL it says 5.x but doesn’t specify which specific version(s)
> > >> * Same for other DBs
> > >>
> > >> We cannot really support every versions since supporting means testing
> > too.
> > >>
> > >> So what I propose:
> > >>
> > >> Question 1: definition
> > >>
> > >> * We say we support the latest stable version of the databases for a
> > given version cycle
> > >> ** For MySQL, it’s the latest of the 5.x cycle, which is 5.7.24 as of
> > today (see https://hub.docker.com/_/mysql/)
> > >> ** For PostgreSQL, it’s the latest of the 9.x cycle, which is 9.6.10
> > as of today (see https://hub.docker.com/_/postgres/)
> > >> ** For Oracle, it’s the latest of the 11.x cycle, which is 11.2.0.4.0
> > as of today (see
> > https://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html
> > )
> > >>
> > >> Question 2: review what we support
> > >>
> > >> * For MySQL I think we could also start supporting MySQL 8.x (ie the
> > latest version of that cycle). We have an issue open for it currently:
> > https://jira.xwiki.org/browse/XWIKI-15215
> > >> * For PostgreSQL we could also start supporting versions 11.x (ie the
> > latest version of that cycle)
> > >> * For Oracle, we could also start supporting versions 12.x (ie the
> > latest version of that cycle)
> > >>
> > >> Question 3: decide if we drop some support
> > >>
> > >> * Is there any cycle that we should support for? Right now I think that
> > MySQL 5.x is still heavily used, same for postgreSQL 9.x I guess. Don’t
> > know for Oracle.
> > >> * Any idea?
> > >>
> > >> So WDYT about the 3 questions?
> > >>
> > >> Thanks
> > >> -Vincent
> > >
> >
> >
--
Thomas Mortagne
Re: [xwiki-devs] [Proposal] Update database support strategy
+1 On Mon, Nov 12, 2018 at 5:37 PM Vincent Massol wrote: > > > > > On 12 Nov 2018, at 16:52, Vincent Massol wrote: > > > > So we need to conclude on this thread. I’m proposing to update the page > > with: > > > > * HSQLDB - Latest only > > * MySQL - latest of oldstable/stable/unstable from > > https://packages.debian.org/search?keywords=mysql-server=names=1 > > (i.e. latest of 5.5.x and 5.7.x today) > > * PostgreSQL - latest of oldstable/stable/unstable > > fromhttps://packages.debian.org/search?keywords=postgresql=names=1 > > (i.e. latest of 9.4.x, 9.6.x and 11.x today) > > * Oracle - latest of 12.x (we currently test on 11.x AFAIK so we need to > > start testing on 12.x from now on) > > > > Note that by “support" we mean test on. And it’s not because a version is > > not supported that it doesn’t work nor that we won’t fix it if a problem > > happens. > > > > I hesitated a long time for the mysql/pgsql versions since I wanted only a > > single version supported, but since we provide a debian packaging it makes > > sense to test the versions defined by the debian repos, and now that we > > have automated functional tests on various configurations, we can test on > > them. BTW I suggest we run all tests on the latest version only (i.e. 5.7.x > > for mysql and 11.x for postgresql, and move to mysql 8.x when we fix the > > bug on it) and then we do smoke tests on the other versions. > > > > Let me know quickly if you have a problem with this strategy since I’d like > > to update the page + add the configs in our CI tests. > > FYI, I’ve now updated the page at > https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy (but I > can update/revert if need be). > > Thanks > -Vincent > > > > > Thanks > > -Vincent > > > > > >> On 31 Oct 2018, at 09:06, Vincent Massol wrote: > >> > >> Hi devs, > >> > >> We currently have > >> https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy > >> > >> However, it doesn’t say explicitly which versions we officially support: > >> * For HSQLDB it says 2.3.3 which is wrong since the latest version is 2.4.1 > >> * For MySQL it says 5.x but doesn’t specify which specific version(s) > >> * Same for other DBs > >> > >> We cannot really support every versions since supporting means testing too. > >> > >> So what I propose: > >> > >> Question 1: definition > >> > >> * We say we support the latest stable version of the databases for a given > >> version cycle > >> ** For MySQL, it’s the latest of the 5.x cycle, which is 5.7.24 as of > >> today (see https://hub.docker.com/_/mysql/) > >> ** For PostgreSQL, it’s the latest of the 9.x cycle, which is 9.6.10 as > >> of today (see https://hub.docker.com/_/postgres/) > >> ** For Oracle, it’s the latest of the 11.x cycle, which is 11.2.0.4.0 as > >> of today (see > >> https://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html) > >> > >> Question 2: review what we support > >> > >> * For MySQL I think we could also start supporting MySQL 8.x (ie the > >> latest version of that cycle). We have an issue open for it currently: > >> https://jira.xwiki.org/browse/XWIKI-15215 > >> * For PostgreSQL we could also start supporting versions 11.x (ie the > >> latest version of that cycle) > >> * For Oracle, we could also start supporting versions 12.x (ie the latest > >> version of that cycle) > >> > >> Question 3: decide if we drop some support > >> > >> * Is there any cycle that we should support for? Right now I think that > >> MySQL 5.x is still heavily used, same for postgreSQL 9.x I guess. Don’t > >> know for Oracle. > >> * Any idea? > >> > >> So WDYT about the 3 questions? > >> > >> Thanks > >> -Vincent > > > -- Thomas Mortagne
Re: [xwiki-devs] [Brainstorming] Should we merge the 3 xwiki repos: commons, rendering & platform?
On Sat, Nov 10, 2018 at 11:52 AM Vincent Massol wrote: > > Hi devs, > > I’d like to start/revisit a brainstorming on the idea of merging the 3 xwiki > repos: commons, rendering & platform. > > Pros: > * Nicer to have XWiki Standard be contained in a single repo > * More logical since we release the 3 at the same time with the same versions > * Simpler to commit. Right now if you make changes that affect more than 1 > repo we get failures in the CI + we need several jira issues ideally + > developers need to rebuild locally the changes from the other repo or wait > for the CI to finish building the changes (takes long). > * Simpler for users to report issues. One jira project is simpler to know > where to report. > * Less CI jobs > * Simpler for running tools like jacoco, clover, etc since they can run in a > singe maven reactor. > * Simpler for releases (e.g. to find the list of committers for the RN, you > need to run the command only once instead of 3 times, etc) > * Simpler to understand the xwiki code base and for onboarding > > Cons: > * We need to find a solution for Maven plugins that need to be build before > they’re used (XAR plugin, Package plugin, etc). One solution for those is to > have them in a separate repo and using the last released version for their > XWiki dependencies. Unless it now works with Maven to build plugins in the > same reactor as where they’re used (need to try it). It's not really related to plugins but to lifecycle handlers (xar, webjar and xip artifact types right now). There is no problem with the package plugin, it would not be located in platform if there was. Also what you propose would not really work IMO: you introduce a new extension when you need it but here you would have to introduce it and wait for next release. > * Maybe could cause memory issues when running the whole build in a single > maven reactor? We don't build the whole platform in a single maven reactor already because of memory issues (mostly Jenkins issues). > * Note that I don’t think this would impact the release of commons and > rendering modules to Maven Central since we can still configure that in the > poms for those modules. I don't think it's as simple as you think actually, the Nexus Maven plugin which is taking care of doing the automatic release on Maven central really does not expect to have different deploy repositories in the same reactor. > * We might need to refactor some of our build checking tools such as the one > verifying that commons doesn’t use rendering or platform modules but that’s > not a big deal. > * Possibly slightly longer paths for building on windows (see below) > > If we were to agree on the merge, we could keep the separation between the 3 > repos with directories and have an addition level such as: > > xwiki (repo) > |_ xwiki-commons > |_ xwiki-rendering > |_ xwiki-platform > > Now we could also forge this organization and flatten it with: > > xwiki (repo) > |_ xwiki-(feature) > |_ xwiki-(feature)-(subname1) > > For example: > > xwiki > |_ xwiki-core > |_ xwiki-component > |_ xwiki-component-api (from commons) > |_ xwiki-component-multi (from platform) > |_ xwiki-rendering > |_ … > |_ xwiki-tools > > We could even try to go with an even flatter structure: > > xwiki > |_ xwiki-component > |_ xwiki-component-api (from commons) > |_ xwiki-component-multi (from platform) > |_ xwiki-rendering > |_ … > |_ xwiki-tools > |_ ... > > (it would mean that in xwiki-tools, we apply similar rules that for runtime > code or override the maven configs) > > WDYT? > > Thanks > -Vincent So again big +1 for moving rendering into commons since it's easy but I see more cons than pros for platform right now. -- Thomas Mortagne
Re: [xwiki-devs] [Brainstorming] Should we merge the 3 xwiki repos: commons, rendering & platform?
Before talking about merging the 3 repositories we should start by moving rendering into xwiki-commons. It's already very nice to remove to get rid of one repository and it does not add any complexity to keep pushing those to Maven central. On Mon, Nov 12, 2018 at 9:28 AM Simon Urli wrote: > > +1 with moving on a single repo. > However I'm not sure about the structures you proposed: it might be a > long term view, but on the short term it really looks safer to keep the > 3 modules separated, especially for the contrib extension which seems to > depends a lot from commons: > > https://github.com/search?p=1=%3CartifactId%3Exwiki-commons%3C%2FartifactId%3E=Code > > so I'd say +1 for the first structure and -0 for the other ones. > > On 10/11/2018 11:58, Vincent Massol wrote: > > Some additional notes below. > > > >> On 10 Nov 2018, at 11:52, Vincent Massol wrote: > >> > >> Hi devs, > >> > >> I’d like to start/revisit a brainstorming on the idea of merging the 3 > >> xwiki repos: commons, rendering & platform. > >> > >> Pros: > >> * Nicer to have XWiki Standard be contained in a single repo > >> * More logical since we release the 3 at the same time with the same > >> versions > >> * Simpler to commit. Right now if you make changes that affect more than 1 > >> repo we get failures in the CI + we need several jira issues ideally + > >> developers need to rebuild locally the changes from the other repo or wait > >> for the CI to finish building the changes (takes long). > >> * Simpler for users to report issues. One jira project is simpler to know > >> where to report. > >> * Less CI jobs > >> * Simpler for running tools like jacoco, clover, etc since they can run in > >> a singe maven reactor. > >> * Simpler for releases (e.g. to find the list of committers for the RN, > >> you need to run the command only once instead of 3 times, etc) > >> * Simpler to understand the xwiki code base and for onboarding > >> > >> Cons: > >> * We need to find a solution for Maven plugins that need to be build > >> before they’re used (XAR plugin, Package plugin, etc). One solution for > >> those is to have them in a separate repo and using the last released > >> version for their XWiki dependencies. Unless it now works with Maven to > >> build plugins in the same reactor as where they’re used (need to try it). > >> * Maybe could cause memory issues when running the whole build in a single > >> maven reactor? > >> * Note that I don’t think this would impact the release of commons and > >> rendering modules to Maven Central since we can still configure that in > >> the poms for those modules. > > > > TBH nobody uses XWiki commons and rendering in standalone modes, after over > > 10+ years of it, so I’m not even sure it makes sense to publish to central > > but we can continue to do that module per module, even with the flat > > structure, and even publish more and more modules one by one if we believe > > it’s a good thing. > > > >> * We might need to refactor some of our build checking tools such as the > >> one verifying that commons doesn’t use rendering or platform modules but > >> that’s not a big deal. > >> * Possibly slightly longer paths for building on windows (see below) > > > > Or shorter paths if we go with the flat structure… > > > > Thanks > > -Vincent > > > >> > >> If we were to agree on the merge, we could keep the separation between the > >> 3 repos with directories and have an addition level such as: > >> > >> xwiki (repo) > >> |_ xwiki-commons > >> |_ xwiki-rendering > >> |_ xwiki-platform > >> > >> Now we could also forge this organization and flatten it with: > >> > >> xwiki (repo) > >> |_ xwiki-(feature) > >> |_ xwiki-(feature)-(subname1) > >> > >> For example: > >> > >> xwiki > >> |_ xwiki-core > >> |_ xwiki-component > >> |_ xwiki-component-api (from commons) > >> |_ xwiki-component-multi (from platform) > >> |_ xwiki-rendering > >> |_ … > >> |_ xwiki-tools > >> > >> We could even try to go with an even flatter structure: > >> > >> xwiki > >> |_ xwiki-component > >> |_ xwiki-component-api (from commons) > >> |_ xwiki-component-multi (from platform) > >> |_ xwiki-rendering > >> |_ … > >> |_ xwiki-tools > >> |_ ... > >> > >> (it would mean that in xwiki-tools, we apply similar rules that for > >> runtime code or override the maven configs) > >> > >> WDYT? > >> > >> Thanks > >> -Vincent > > > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.u...@xwiki.com > More about us at http://www.xwiki.com -- Thomas Mortagne
Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters
Note: this should be done at xwiki-commons-properties level. Macro
parameters are just one use case.
On Wed, Nov 7, 2018 at 4:34 PM Adel Atallah wrote:
>
> Hello everyone,
>
> So what we thought about with Vincent for implementing the "concept of
> aliases or groups" would be to actually have two new annotations that
> we would use on macro properties.
> The first one is a "Group" annotation which is meant to indicate that
> some properties are part of the same group, obviously.
> The second is an "Alternative" annotation which is meant to indicate
> that only one property / group of properties can be used (among the
> ones that are part of the alternative).
> Here is an example:
> We want for the Include macro to be able to specify either:
> the "reference" and "type" parameters
> or
> the "page" parameter
> For that, we will change the IncludeMacroParameters java class like this:
>
> @Alternative("reference")
> @Group("entityReference")
> public void setReference(String reference)
>
> @Alternative("reference")
> @Group("entityReference")
> public void setType(EntityType type)
>
> @Alternative("reference")
> public void setPage(String page)
>
> In the WYSIWYG side, we will only be able to specify either the
> "reference" and the "type" or the "page" parameter.
>
> WDYT?
>
> Thanks,
> Adel
>
> On Tue, Sep 25, 2018 at 11:51 AM Marius Dumitru Florea
> wrote:
> >
> > On Wed, Sep 19, 2018 at 4:31 PM Vincent Massol wrote:
> >
> > >
> > >
> > > > On 19 Sep 2018, at 14:47, Adel Atallah wrote:
> > > >
> > > > On Wed, Jul 18, 2018 at 5:00 PM Vincent Massol
> > > wrote:
> > > >>
> > > >>
> > > >>
> > > >>> On 5 Jul 2018, at 12:06, Vincent Massol wrote:
> > > >>>
> > > >>>
> > > >>>
> > > >>>> On 4 Jul 2018, at 12:07, Thomas Mortagne
> > > wrote:
> > > >>>>
> > > >>>> Here are more details on the actual use case we need to support:
> > > >>>>
> > > >>>> In include/Display macro either you set:
> > > >>>>
> > > >>>> * "reference" and "type" (which default to DOCUMENT)
> > > >>>> * or you set “page"
> > > >>>
> > > >>> Globally I think we need to add 3 concepts to macro parameter
> > > descriptor:
> > > >>>
> > > >>> 1) The concept of “deprecated” parameter. For example for “document”
> > > in the include macro.
> > > >>> 2) The concept of aliases or groups, i.e the ability to list
> > > parameters that are mutually exclusive. Example: reference + type vs page
> > > for display/include macros. This would mean that in the Macro Dialog UI if
> > > you select one of those the other gets unselected/cleared out (you cannot
> > > have mutually exclusive params have values).
> > > >>> 3) The concept of Advanced parameters. For example, we should put
> > > reference + type as advanced parameters so that they are not shown to the
> > > user by default (and so that the page parameter is more highlighted).
> > > Users
> > > would need to click on Advanced to see advanced parameters. I think we’re
> > > doing something automatic today (I don’t remember the details) to try to
> > > hide some parameters but we should probably review this.
> > > >>>
> > > >>> WDYT?
> > > >>
> > > >> Ping!
> > > >>
> > > >> Do we agree about this? If we do we can then create jira issue about it
> > > and take it for implementation.
> > > >
> > > > +1, I can create the jira issue if it's ok.
> > >
> > > Please do :)
> > >
> > >
> >
> > > @Marius: Ok for you?
> > >
> >
> > Yes.
> >
> >
> > >
> > > thanks
> > > -Vincent
> > >
> > > [snip]
> > >
> > >
> > >
--
Thomas Mortagne
Re: [xwiki-devs] [Proposal] Jobs for the multiple configuration testing
On Wed, Nov 7, 2018 at 9:20 AM Vincent Massol wrote: > > Hi Thomas, > > > On 7 Nov 2018, at 08:44, Thomas Mortagne wrote: > > > > On Mon, Nov 5, 2018 at 5:22 PM Vincent Massol wrote: > >> > >> Hi devs, > >> > >> I’m still not sure but FTM I was thinking of having 2 pipeline jobs: > >> > >> 1) Job 1: Execute one functional test only (e.g. MenuIT for now) but on > >> the maximum number of configurations, in order to flesh out configs that > >> don’t start properly. For example XWiki on Tomcat 9.x would fail (since > >> the Tomcat 9.x docker image uses java9+). The job would not send a mail on > >> failure but it would update a report page (could even update a page on > >> xwiki.org directly or if too complex update some page on maven.xwiki.org > >> somewhere). This job would run not very often but say once per week. Note > >> that one config takes 3-4 minutes to run, so 50 configs would take 3 hours > >> which is acceptable. > > > > That's interesting indeed. +1 > > > >> > >> 2) Job 2: Execute all functional tests on a subset of supported configs. > >> For example we don’t need to run all the tests on PostgreSQL/Jetty/Chrome > >> if we already run on PostgreSQL/Tomcat/FF and MySQL/Tomcat/Chrome. This > >> job will take a long time to execute. We’ll start with 3-4 configs and > >> will go to about 10 configs when we add more. The tests will take roughly > >> 2 hours to execute per config I think. So a total of 20 hours when we have > >> 10 configs. If we run those once per week it should be fine. > > > > Can't those configs be executed in parallel in different agents ? > > Yes this is fully parallelizable. However we have only one agent with docker > ATM. Once we migrate more agents then we can have them in parallel. Indeed forgot about that. Anyway +1 for both > > Thanks > -Vincent > > > > >> > >> Note: Once we have job 1 & 2, we won't need to have the smoke tests I add > >> as part of the platform JenkinsFile. > >> > >> WDYT? > >> > >> Thanks > >> -Vincent > >> > > > > > > -- > > Thomas Mortagne > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Jobs for the multiple configuration testing
On Mon, Nov 5, 2018 at 5:22 PM Vincent Massol wrote: > > Hi devs, > > I’m still not sure but FTM I was thinking of having 2 pipeline jobs: > > 1) Job 1: Execute one functional test only (e.g. MenuIT for now) but on the > maximum number of configurations, in order to flesh out configs that don’t > start properly. For example XWiki on Tomcat 9.x would fail (since the Tomcat > 9.x docker image uses java9+). The job would not send a mail on failure but > it would update a report page (could even update a page on xwiki.org directly > or if too complex update some page on maven.xwiki.org somewhere). This job > would run not very often but say once per week. Note that one config takes > 3-4 minutes to run, so 50 configs would take 3 hours which is acceptable. That's interesting indeed. +1 > > 2) Job 2: Execute all functional tests on a subset of supported configs. For > example we don’t need to run all the tests on PostgreSQL/Jetty/Chrome if we > already run on PostgreSQL/Tomcat/FF and MySQL/Tomcat/Chrome. This job will > take a long time to execute. We’ll start with 3-4 configs and will go to > about 10 configs when we add more. The tests will take roughly 2 hours to > execute per config I think. So a total of 20 hours when we have 10 configs. > If we run those once per week it should be fine. Can't those configs be executed in parallel in different agents ? > > Note: Once we have job 1 & 2, we won't need to have the smoke tests I add as > part of the platform JenkinsFile. > > WDYT? > > Thanks > -Vincent > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Update database support strategy
uestions are: > >>>>> * Why are we supporting "Hypersonic DB" ? - but hey, apparently it's in > >>>>> the jetty thing. k :) Here we should just say latest, without any > >>> version > >>>>> to it. This DB is anyway only recommended for the demo version. > >>>>> * Why don't we support Microsoft SQL Server? > >>>>> > >>>>> Another reference: > >>>>> https://db-engines.com/en/ranking > >>>>> > >>>>> * MongoDB also is in the top 5 for 2018 in multiple resources. Should / > >>>>> could we also support that? In the Relational Databases section, DB2 is > >>>>> listed, see https://db-engines.com/en/ranking/relational+dbms > >>>>> > >>>>> Anyway, I think it would be enough if we support the top 3 DB for the > >>>>> latest versions. This would mean just MySQL 8.x instead of MySQL 5.x. > >>> Could > >>>>> not find any relevant comparison for DB versions. Found a graph from > >>> 2015 > >>>>> in https://plumbr.io/blog/io/most-popular-relational-databases where > >>>>> MySQL 5.6 was most popular (long time ago), so not sure what we could > >>> use > >>>>> as a reference. On the other hand MySQL 8.0 launched 6 month ago. So > >>>>> indeed, we should support the latest 5.7.x (5.7.24) and also 8.0.x > >>>>> (8.0.13), see https://en.wikipedia.org/wiki/MySQL#Release_history > >>>>> > >>>>> Regarding PostgreSQL, IMO we should support (10.5 || 9.6.10) and 11.0, > >>> see > >>>>> https://en.wikipedia.org/wiki/PostgreSQL#Release_history > >>>>> > >>>>> Regarding Oracle Database, we should support 12.2.0.1 and 18.1.0, see > >>>>> https://en.wikipedia.org/wiki/Oracle_Database#Releases_and_versions > >>>>> > >>>>> Regarding Microsoft SQL Server it should be (in case we decide it) SQL > >>>>> Server 2017, see > >>>>> https://en.wikipedia.org/wiki/Microsoft_SQL_Server#Currently > >>>>> > >>>>> My rule was: latest/latest + the latest stable/previous version. > >>>>> > >>>>> Thanks, > >>>>> Caty > >>>>> > >>>>> > >>>>>> > >>>>>> WDYT about that? > >>>>>> > >>>>>> Thanks > >>>>>> -Vincent > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Caty > >>>>>>> > >>>>>>> > >>>>>>> On Wed, Oct 31, 2018 at 12:11 PM Simon Urli > >>>>>> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 31/10/2018 10:52, Thomas Mortagne wrote: > >>>>>>>>> On Wed, Oct 31, 2018 at 10:28 AM Vincent Massol >>>> > >>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> On 31 Oct 2018, at 10:15, Simon Urli > >>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> On 31/10/2018 09:06, Vincent Massol wrote: > >>>>>>>>>>>> Hi devs, > >>>>>>>>>>>> We currently have > >>>>>>>> > >>> https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy > >>>>>>>>>>>> However, it doesn’t say explicitly which versions we officially > >>>>>>>> support: > >>>>>>>>>>>> * For HSQLDB it says 2.3.3 which is wrong since the latest > >>> version > >>>>>> is > >>>>>>>> 2.4.1 > >>>>>>>>>>>> * For MySQL it says 5.x but doesn’t specify which specific > >>>>>> version(s) > >>>>>>>>>>>> * Same for other DBs > >>>>>>>>>>>> We cannot really support every versions
Re: [xwiki-devs] [Proposal] Update servlet container support strategy
I know but it should also be on the support page IMO. On Wed, Oct 31, 2018 at 10:44 AM Vincent Massol wrote: > > > > > On 31 Oct 2018, at 10:42, Thomas Mortagne wrote: > > > > Actually there is another very important thing missing in that page: > > we should also indicate explicitly the minimum version of the Servlet > > API required by XWiki (currently 3.0.1). > > This is listed on > https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/#HHardwareandSoftwarerequirements > > Thanks > -Vincent > > > > > On Wed, Oct 31, 2018 at 10:30 AM Adel Atallah > > wrote: > >> > >> Hi Vincent, > >> > >> +1 > >> > >> Thanks, > >> Adel > >> > >> On Wed, Oct 31, 2018 at 10:07 AM Marius Dumitru Florea > >> wrote: > >>> > >>> +1 > >>> > >>> Thanks, > >>> Marius > >>> > >>> On Wed, Oct 31, 2018 at 11:04 AM Vincent Massol > >>> wrote: > >>> > >>>> Hi devs, > >>>> > >>>> We now have > >>>> https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrategy/ > >>>> but it’s not precise enough. > >>>> > >>>> I’m proposing the following: > >>>> > >>>> * Mention the supported version cycle and mention that we support the > >>>> latest version of the cycle. > >>>> * For Tomcat, I propose to say we support Tomcat 8.x (which means Tomcat > >>>> 8.5.34 as of today, see “latest” tag on https://hub.docker.com/_/tomcat/) > > > > Actually from Tomcat point of view 8.0.x and 8.5.x are two different > > cycles so it would be more clear to say we support 8.5.x. > > > >>>> * For Jetty (standalone packaging or standard), I propose to say we > >>>> support Jetty 9.x (which means Jetty 9.4.12 as of today, see “latest” tag > >>>> on https://hub.docker.com/_/jetty/) > >>>> > >>>> WDYT? > >>>> > >>>> Thanks > >>>> -Vincent > >>>> > >>>> > >>>> > > > > > > > > -- > > Thomas Mortagne > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Update database support strategy
On Wed, Oct 31, 2018 at 10:28 AM Vincent Massol wrote: > > > > > On 31 Oct 2018, at 10:15, Simon Urli wrote: > > > > Hi, > > > > On 31/10/2018 09:06, Vincent Massol wrote: > >> Hi devs, > >> We currently have > >> https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy > >> However, it doesn’t say explicitly which versions we officially support: > >> * For HSQLDB it says 2.3.3 which is wrong since the latest version is 2.4.1 > >> * For MySQL it says 5.x but doesn’t specify which specific version(s) > >> * Same for other DBs > >> We cannot really support every versions since supporting means testing too. > >> So what I propose: > >> Question 1: definition > >> * We say we support the latest stable version of the databases for a given > >> version cycle > >> ** For MySQL, it’s the latest of the 5.x cycle, which is 5.7.24 as of > >> today (see https://hub.docker.com/_/mysql/) > >> ** For PostgreSQL, it’s the latest of the 9.x cycle, which is 9.6.10 as > >> of today (see https://hub.docker.com/_/postgres/) > >> ** For Oracle, it’s the latest of the 11.x cycle, which is 11.2.0.4.0 as > >> of today (see > >> https://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html) > > > > +1 > > > >> Question 2: review what we support > >> * For MySQL I think we could also start supporting MySQL 8.x (ie the > >> latest version of that cycle). We have an issue open for it currently: > >> https://jira.xwiki.org/browse/XWIKI-15215 > >> * For PostgreSQL we could also start supporting versions 11.x (ie the > >> latest version of that cycle) > >> * For Oracle, we could also start supporting versions 12.x (ie the latest > >> version of that cycle) > > > > +0 I don't really know how much effort it involves to ensure the support of > > the latest version of each database and to fix the bugs accordingly. > > > >> Question 3: decide if we drop some support > >> * Is there any cycle that we should support for? Right now I think that > >> MySQL 5.x is still heavily used, same for postgreSQL 9.x I guess. Don’t > >> know for Oracle. > >> * Any idea? > > > > What about the cycles that are bundled in major LTS distributions? > > You mean the versions from apt-get for ex (when using the default repos)? > > Indeed the idea could to follow one of them. Any suggestion for which one to > follow and where the info is? Since we provide Debian package one good reference to know which version of MySQL to support IMO would be https://packages.debian.org/search?keywords=mysql-server=names=1 So it would be good to support 5.5 and 5.7 Here is the one for postgresql (since we also have a pgsql based Debian package) https://packages.debian.org/search?keywords=postgresql=names=1 So 9.4, 9.6 and 11 > > Thanks > -Vinent > > > > > Simon > > > >> So WDYT about the 3 questions? > >> Thanks > >> -Vincent > > > > -- > > Simon Urli > > Software Engineer at XWiki SAS > > simon.u...@xwiki.com > > More about us at http://www.xwiki.com > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Update servlet container support strategy
Actually there is another very important thing missing in that page: we should also indicate explicitly the minimum version of the Servlet API required by XWiki (currently 3.0.1). On Wed, Oct 31, 2018 at 10:30 AM Adel Atallah wrote: > > Hi Vincent, > > +1 > > Thanks, > Adel > > On Wed, Oct 31, 2018 at 10:07 AM Marius Dumitru Florea > wrote: > > > > +1 > > > > Thanks, > > Marius > > > > On Wed, Oct 31, 2018 at 11:04 AM Vincent Massol wrote: > > > > > Hi devs, > > > > > > We now have > > > https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrategy/ > > > but it’s not precise enough. > > > > > > I’m proposing the following: > > > > > > * Mention the supported version cycle and mention that we support the > > > latest version of the cycle. > > > * For Tomcat, I propose to say we support Tomcat 8.x (which means Tomcat > > > 8.5.34 as of today, see “latest” tag on https://hub.docker.com/_/tomcat/) Actually from Tomcat point of view 8.0.x and 8.5.x are two different cycles so it would be more clear to say we support 8.5.x. > > > * For Jetty (standalone packaging or standard), I propose to say we > > > support Jetty 9.x (which means Jetty 9.4.12 as of today, see “latest” tag > > > on https://hub.docker.com/_/jetty/) > > > > > > WDYT? > > > > > > Thanks > > > -Vincent > > > > > > > > > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Move Doxia-based syntaxes in contrib
+1 On Sat, Oct 27, 2018 at 2:01 PM Vincent Massol wrote: > > Hi, > > In the direction of keeping in commons/rendering/platform only modules that > are used in the XS distribution, I’m proposing to move Doxia-based syntaxes > to contrib (APT, Docbook & TWiki), in a single doxia github repository > (doxia-common, doxia-twiki, doxia-docbook, doxia-twiki). > > WDYT? > > Thanks > -Vincent > -- Thomas Mortagne
Re: [xwiki-devs] [Best Practice] Use lowercase for JIRA labels
+0 On Tue, Oct 23, 2018 at 6:54 AM Marius Dumitru Florea wrote: > > +0, I would have preferred camel case for composite names (like > bugfixingday) > > On Mon, Oct 22, 2018 at 4:17 PM Vincent Massol wrote: > > > Hi, > > > > I’d like to propose to use a consistent naming scheme for jira labels and > > use lowercase (and fix all the upper case we can find). > > > > Ok for everyone? > > > > Thanks > > -Vincent > > > > -- Thomas Mortagne
Re: [xwiki-devs] What do we do with Watchlist and Activity Stream
What is this code about exactly ? If it's the kind of thing that make the user profile take ages to load then it's a B for me, if not then A is fine. On Mon, Oct 22, 2018 at 3:14 PM Guillaume Delhumeau wrote: > > Hi. > > For 10.9RC1, my objective was to stop bundling the Activity Stream UI in > the default flavor. Several months before, I did the same with the > Watchlist. Now both of them are replaced by Notifications. > > Even if they are not bundled anymore by default, I have let the modules in > the "platform" repository. The idea was to maintain them until 11.x is > started (while we stabilize notifications), and to move them in "attic" at > the beginning of next year. > > Recently, while removing Activity Stream calls in our wiki pages, I > discovered some code in the User Profile that was handling both Activity > Stream and the Watchlist. I removed it, since it was handling deprecated > code. But maybe I should have not, since the modules are not moved into the > "attic" repository yet. Anyway, it is not clean to have special code for AS > and Watchlist in the User Profile module, we need to create a proper > mechanism to inject code into the user profile (see: > https://jira.xwiki.org/browse/XWIKI-12639). > > The removing of the code has broken some functional tests in the watchlist > module, that were precisely testing this code. So now, we have several > options: > > A - Put back the code I have removed, until Activity Stream UI and > Watchlist are moved outside the "platform" repository. So the build would > be fixed. > B - Remove the failing functional test since it is testing a code we have > been removed. So the build would be fixed. > C - Put back the code I have removed, but inside the Watchlist module and > injected into the User profile via a clean injection system (again: > https://jira.xwiki.org/browse/XWIKI-12639). The build would be fixed but it > requires more time to develop, and we risk to miss 10.9RC1. > > The release of 10.9RC1 is already late, so what do you think is the best > option? > > Thanks, > > -- > Guillaume Delhumeau (guillaume.delhum...@xwiki.com) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Prevent users from renaming/move pages with XClass definition
Vincent > >>>>>>> > >>>>>>> Simon > >>>>>>>> Thanks > >>>>>>>> -Vincent > >>>>>>>>> > >>>>>>>>> Simon > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 9/26/18 10:27 AM, Simon Urli wrote: > >>>>>>>>>> Hi everyone, > >>>>>>>>>> ok trying to sum-up (I'm only talking about cases with XClass > >>>>>>>>>> below, to simplify): > >>>>>>>>>> - according to Vincent, we should completely prevent simple > >>>>>>>>>> users to copy/move/rename and only allow advanced users to do it > >>>>>>>>>> after a warning > >>>>>>>>>> - according to Adel & Clément: preventing simple users will be > >>>>>>>>>> useless as they can easily switch the advanced feature in their > >>>>>>>>>> account > >>>>>>>>>> - according to Marius copying a page/app is not necessarily > >>>>>>>>>> harmful compared to moving/renaming and we should manage it > >>>>>>>>>> differently. > >>>>>>>>>> I really don't know the practice of users on the field, but it > >>>>>>>>>> looks to me that preventing simple users to do the action and > >>>>>>>>>> telling them to ask an advanced user is actually a good trade-off: > >>>>>>>>>> 1. it will warn users that they might be doing something wrong > >>>>>>>>>> 2. it's not something completely blocking: either they ask for > >>>>>>>>>> the admin/advanced user, or they know they can switch the advanced > >>>>>>>>>> features by themselves, at their own risks > >>>>>>>>>> Now maybe we can only do the warning for the "copy" action. > >>>>>>>>>> WDYT? > >>>>>>>>>> Simon > >>>>>>>>>> On 9/25/18 11:36 AM, Vincent Massol wrote: > >>>>>>>>>>> Hi Marius, > >>>>>>>>>>> > >>>>>>>>>>>> On 25 Sep 2018, at 11:34, Marius Dumitru Florea > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> On Sun, Sep 23, 2018 at 11:12 AM Vincent Massol > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi Simon, > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On 21 Sep 2018, at 16:58, Simon Urli > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 9/21/18 4:53 PM, Adel Atallah wrote: > >>>>>>>>>>>>>>> +1 for the warning, but I would not forbid simple users from > >>>>>>>>>>>>>>> renaming > >>>>>>>>>>>>>>> or moving pages but instead just hide the action (from the > >>>>>>>>>>>>>>> page menu). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> OK I should have written it: by "forbid" I meant: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 1. Hide the action from the menu > >>>>>>>>>>>>>> 2. Return an error message if the user try to access the > >>>>>>>>>>>>> renaming/moving page (using forged URL) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> So you suggest we shouldn't do 2? > >>>>>>>>>>>>> > >>>>>>>>>>>>> So +1 to prevent/warn the user when doing a move/renaming > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> AND copy pages containing XClass definitions > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> FTR, copying a single page having an XClass definition is not > >>>>>>>>>>>> dangerous (it > >>>>>>>>>>>> won't break the application that owns the page), as it only > >>>>>>>>>>>> creates a new > >>>>>>>>>>>> class definition. Copying an entire application is not dangerous > >>>>>>>>>>>> either. > >>>>>>>>>>>> The copy won't work like the original application (this > >>>>>>>>>>>> justifies a warning > >>>>>>>>>>>> as it may fail the user expectations), but the original > >>>>>>>>>>>> application will > >>>>>>>>>>>> still work. Renaming or moving an application is dangerous as it > >>>>>>>>>>>> breaks the > >>>>>>>>>>>> application. > >>>>>>>>>>> > >>>>>>>>>>> Yes you’re correct. Unless the user does a copy + delete ;) > >>>>>>>>>>> > >>>>>>>>>>> Thanks > >>>>>>>>>>> -Vincent > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> (the message should list all such pages). > >>>>>>>>>>>>> > >>>>>>>>>>>>> -1 to hide the action from the menu (if you’re talking about the > >>>>>>>>>>>>> “Move/Rename” and “Copy" actions) because: > >>>>>>>>>>>>> 1) you get to choose whether you move/rename/copy children > >>>>>>>>>>>>> after you click > >>>>>>>>>>>>> the action > >>>>>>>>>>>>> 2) even when the current page has an XClass, the user wouldn't > >>>>>>>>>>>>> understand > >>>>>>>>>>>>> why he cannot see/click on the action. It’s better that he can > >>>>>>>>>>>>> do it but > >>>>>>>>>>>>> get an error message, explaining why and telling him that to > >>>>>>>>>>>>> contact an > >>>>>>>>>>>>> advanced users if he really needs to do it. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks > >>>>>>>>>>>>> -Vincent > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Fri, Sep 21, 2018 at 4:44 PM Simon Urli > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> users might currently break their AWM application by > >>>>>>>>>>>>>>>> renaming/moving > >>>>>>>>>>>>>>>> pages containing XClass definition. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> We need a proper refactoring operation to be able to > >>>>>>>>>>>>>>>> properly do such > >>>>>>>>>>>>>>>> move/rename. But this feature might take a while to be > >>>>>>>>>>>>>>>> completely > >>>>>>>>>>>>>>>> available. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> In the meantime I propose that we prevent users from > >>>>>>>>>>>>>>>> renaming/moving > >>>>>>>>>>>>>>>> pages containing XClass. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> What I propose is the following: > >>>>>>>>>>>>>>>> - Forbid completely *simple users* to rename/move pages > >>>>>>>>>>>>>>>> containing > >>>>>>>>>>>>> XClass > >>>>>>>>>>>>>>>> - Display a warning to *advanced users* when they perform > >>>>>>>>>>>>>>>> such > >>>>>>>>>>>>>>>> operation: the same kind of warning we already have when > >>>>>>>>>>>>>>>> performing > >>>>>>>>>>>>> edit > >>>>>>>>>>>>>>>> on XWiki pages > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> WDYT? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Simon > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>> Simon Urli > >>>>>>>>>>>>>>>> Software Engineer at XWiki SAS > >>>>>>>>>>>>>>>> simon.u...@xwiki.com > >>>>>>>>>>>>>>>> More about us at http://www.xwiki.com > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> Simon Urli > >>>>>>>>>>>>>> Software Engineer at XWiki SAS > >>>>>>>>>>>>>> simon.u...@xwiki.com > >>>>>>>>>>>>>> More about us at http://www.xwiki.com > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Simon Urli > >>>>>>>>> Software Engineer at XWiki SAS > >>>>>>>>> simon.u...@xwiki.com > >>>>>>>>> More about us at http://www.xwiki.com > >>>>>>> > >>>>>>> -- > >>>>>>> Simon Urli > >>>>>>> Software Engineer at XWiki SAS > >>>>>>> simon.u...@xwiki.com > >>>>>>> More about us at http://www.xwiki.com > >>>>> > >>>>> -- > >>>>> Simon Urli > >>>>> Software Engineer at XWiki SAS > >>>>> simon.u...@xwiki.com > >>>>> More about us at http://www.xwiki.com > >>> > >>> -- > >>> Simon Urli > >>> Software Engineer at XWiki SAS > >>> simon.u...@xwiki.com > >>> More about us at http://www.xwiki.com > > > > -- > > Simon Urli > > Software Engineer at XWiki SAS > > simon.u...@xwiki.com > > More about us at http://www.xwiki.com > -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Change ObservationManager behaviour with CancelableEvents
+1 to stopping event propagation when it's cancelled On Tue, Oct 16, 2018 at 6:07 PM Simon Urli wrote: > > Hi everyone, > > the current behaviour of the ObservationManager is to always triggers > the listeners if it matches the events. > Now regarding the CancelableEvents, the match is only done on the type > of the event and some given filter rules, but never with its cancel > status: if an event is cancelled, the matching listeners are always > triggered. > > I propose to change that behaviour, to trigger listeners only if the > CancelableEvents are not canceled: basically, a cancelled event wouldn't > match any listener. > > My primary reason for wanting that change is that the current behaviour > led to a bad UX: if an event triggers multiple questions, no matter if > one is cancelled, all questions will be asked to the user. > > Do you know if the current behaviour is required at some places? > Else do you agree on changing it? > > Simon > -- > Simon Urli > Software Engineer at XWiki SAS > simon.u...@xwiki.com > More about us at http://www.xwiki.com -- Thomas Mortagne
Re: [xwiki-devs] [Proposal] Prevent users from renaming/move pages with XClass definition
tion from the menu (if you’re talking about the > >>>> “Move/Rename” and “Copy" actions) because: > >>>> 1) you get to choose whether you move/rename/copy children after you > >>>> click > >>>> the action > >>>> 2) even when the current page has an XClass, the user wouldn't > >>>> understand > >>>> why he cannot see/click on the action. It’s better that he can do it > >>>> but > >>>> get an error message, explaining why and telling him that to contact an > >>>> advanced users if he really needs to do it. > >>>> > >>>> Thanks > >>>> -Vincent > >>>> > >>>>> > >>>>>> On Fri, Sep 21, 2018 at 4:44 PM Simon Urli > >>>> wrote: > >>>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> users might currently break their AWM application by renaming/moving > >>>>>>> pages containing XClass definition. > >>>>>>> > >>>>>>> We need a proper refactoring operation to be able to properly do > >>>>>>> such > >>>>>>> move/rename. But this feature might take a while to be completely > >>>>>>> available. > >>>>>>> > >>>>>>> In the meantime I propose that we prevent users from renaming/moving > >>>>>>> pages containing XClass. > >>>>>>> > >>>>>>> What I propose is the following: > >>>>>>> - Forbid completely *simple users* to rename/move pages containing > >>>> XClass > >>>>>>> - Display a warning to *advanced users* when they perform such > >>>>>>> operation: the same kind of warning we already have when performing > >>>> edit > >>>>>>> on XWiki pages > >>>>>>> > >>>>>>> WDYT? > >>>>>>> > >>>>>>> Simon > >>>>>>> > >>>>>>> -- > >>>>>>> Simon Urli > >>>>>>> Software Engineer at XWiki SAS > >>>>>>> simon.u...@xwiki.com > >>>>>>> More about us at http://www.xwiki.com > >>>>> > >>>>> -- > >>>>> Simon Urli > >>>>> Software Engineer at XWiki SAS > >>>>> simon.u...@xwiki.com > >>>>> More about us at http://www.xwiki.com > >> > > > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.u...@xwiki.com > More about us at http://www.xwiki.com -- Thomas Mortagne
[xwiki-devs] [ANN] XWiki 10.8.1 released
The XWiki development team is proud to announce the availability of XWiki 10.8.1. This is a bugfix release that covers important issues that we have discovered since 10.8 has been released. 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/Data/XWiki/10.8.1 Thanks for your support -The XWiki dev team
