Re: [xwiki-devs] [Contrib] New repo and JIRA for an OpenStreetMap macro

[Thomas Mortagne]

I also think it's better to push for OSM as the default. You might
want to name the next release "2.0" to make this breaking change more
explicit.

On Mon, Jul 2, 2018 at 5:42 PM, Ludovic Dubost  wrote:
> Yes I'm +1 to move to OSM being the default
>
> Ludovic
>
> --
> *Ludovic Dubost*
> *Founder and CEO*
> ludo...@xwiki.com
> skype: ldubost
> Blog: http://blog.ludovic.orgTry XWiki on the cloud
>   - Try Cryptpad: Secure
> realtime Wysiwyg Editing 
>
>
> On Mon, Jul 2, 2018 at 4:31 PM, Stéphane Laurière 
> wrote:
>
>> Hi Alex, Ludo, all,
>>
>> Thanks for your feedbacks. I created a pull request which now includes OSM
>> geocoding and opens OSM directions when clicking on the marker:
>>
>>   https://github.com/xwiki-contrib/macro-map/pull/9
>>
>> As for the default value, now that OSM geocoding is supported I'd rather
>> be for using it but on the other hand it's true that it will have an impact
>> on existing instances...
>>
>> Stéphane
>>
>>
>> Ludovic Dubost:
>>
>>> Hi,
>>>
>>> The idea was to push for usage of OSM instead of Google, especially with
>>> the changes Google is giving and the fact that it requires a key by
>>> default.
>>> Now indeed this is unsual to change the default as it might break the
>>> cases
>>> where geocoding was used until we support geocoding as part of the OSM
>>> macro
>>>
>>> Ludovic
>>>
>>> --
>>> *Ludovic Dubost*
>>> *Founder and CEO*
>>> ludo...@xwiki.com
>>> skype: ldubost
>>> Blog: http://blog.ludovic.orgTry XWiki on the cloud
>>>   - Try Cryptpad:
>>> Secure
>>> realtime Wysiwyg Editing 
>>>
>>>
>>> On Mon, Jul 2, 2018 at 1:24 PM, Alex Cotiugă >> >
>>> wrote:
>>>
>>> Hi Stéphane,

 Why would you change the default from googlemaps? Since we only have one
 implementation so far, I think we should keep it as default. WDYT?

 Alex

 On Wed, Jun 27, 2018 at 3:13 PM, Stéphane Laurière 
 wrote:

 Ludovic Dubost:
>
> Do we have the plan of being able to configure the openstreetmap
>> provider ?
>>
>>
> My plan is to add two parameters to the macro:
>
> - "tiles" for configuring the tile provider URL scheme. Examples:
> https://
> {s}.tile.openstreetmap.org/{z}/{x}/{y}.png
> 
>  http://{s}.
> tile.stamen.com/toner/{z}/{x}/{y}.png
> 
> 
>
>
> - "library" for choosing the JavaScript library to be used: either
> "leaflet" (default) or "googlemaps". If "googlemaps" is chosen, the tile
> URL is not needed as it's necessarily the one by Google and it's
> configured
> by the library itself. It "leaflet" is chosen, it remains possible to
> use
> Google Maps tiles (not sure the macro will support it though):
> https://ivansanchez.gitlab.io/Leaflet.GridLayer.GoogleMutant/demo.html
>
> Stéphane
>
> Ludovic
>
>>
>> --
>> *Ludovic Dubost*
>> *Founder and CEO*
>> ludo...@xwiki.com
>> skype: ldubost
>> Blog: http://blog.ludovic.orgTry XWiki on the cloud
>>   - Try Cryptpad:
>> Secure
>> realtime Wysiwyg Editing 
>>
>>
>>
> --
> Stéphane Laurière
> XWiki www.xwiki.com
> @slauriere
>
>
>

>>
>> --
>> Stéphane Laurière
>> XWiki www.xwiki.com
>> @slauriere
>>
>>



-- 
Thomas Mortagne

[xwiki-devs] Location of macro pages (was Re: [Contrib] New repo and JIRA for an OpenStreetMap macro)

[Vincent Massol]

Hi Stephane and all,

I see in your last commit:

   M src/main/resources/MapMacro/Code/GoogleMap.xml
   M src/main/resources/MapMacro/Code/LeafletMap.xml
   M src/main/resources/XWiki/MapMacro.xml
   M src/main/resources/XWiki/MapMacroTranslations.fa.xml
   M src/main/resources/XWiki/MapMacroTranslations.fr.xml
   M src/main/resources/XWiki/MapMacroTranslations.hr.xml
   M src/main/resources/XWiki/MapMacroTranslations.sk.xml
   M src/main/resources/XWiki/MapMacroTranslations.xml

I’m thinking that maybe we should put all the pages in the same space for the 
MapMacro.

Right now we usually put Macros in the Macros space as a best practice. Usually 
those wiki macros have a singe wiki page.

So I’m proposing to have all the Map Macro pages located in Macros.MapMacro.*

WDYT?

If we agree we should also add this to 
https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPractices

Thanks
-Vincent

> On 2 Jul 2018, at 17:42, Ludovic Dubost  wrote:
> 
> Yes I'm +1 to move to OSM being the default
> 
> Ludovic
> 
> --
> *Ludovic Dubost*
> *Founder and CEO*
> ludo...@xwiki.com
> skype: ldubost
> Blog: http://blog.ludovic.orgTry XWiki on the cloud
>   - Try Cryptpad: Secure
> realtime Wysiwyg Editing 
> 
> 
> On Mon, Jul 2, 2018 at 4:31 PM, Stéphane Laurière 
> wrote:
> 
>> Hi Alex, Ludo, all,
>> 
>> Thanks for your feedbacks. I created a pull request which now includes OSM
>> geocoding and opens OSM directions when clicking on the marker:
>> 
>>  https://github.com/xwiki-contrib/macro-map/pull/9
>> 
>> As for the default value, now that OSM geocoding is supported I'd rather
>> be for using it but on the other hand it's true that it will have an impact
>> on existing instances...
>> 
>> Stéphane
>> 
>> 
>> Ludovic Dubost:
>> 
>>> Hi,
>>> 
>>> The idea was to push for usage of OSM instead of Google, especially with
>>> the changes Google is giving and the fact that it requires a key by
>>> default.
>>> Now indeed this is unsual to change the default as it might break the
>>> cases
>>> where geocoding was used until we support geocoding as part of the OSM
>>> macro
>>> 
>>> Ludovic
>>> 
>>> --
>>> *Ludovic Dubost*
>>> *Founder and CEO*
>>> ludo...@xwiki.com
>>> skype: ldubost
>>> Blog: http://blog.ludovic.orgTry XWiki on the cloud
>>>   - Try Cryptpad:
>>> Secure
>>> realtime Wysiwyg Editing 
>>> 
>>> 
>>> On Mon, Jul 2, 2018 at 1:24 PM, Alex Cotiugă >>> 
>>> wrote:
>>> 
>>> Hi Stéphane,
 
 Why would you change the default from googlemaps? Since we only have one
 implementation so far, I think we should keep it as default. WDYT?
 
 Alex
 
 On Wed, Jun 27, 2018 at 3:13 PM, Stéphane Laurière 
 wrote:
 
 Ludovic Dubost:
> 
> Do we have the plan of being able to configure the openstreetmap
>> provider ?
>> 
>> 
> My plan is to add two parameters to the macro:
> 
> - "tiles" for configuring the tile provider URL scheme. Examples:
> https://
> {s}.tile.openstreetmap.org/{z}/{x}/{y}.png
> 
>  http://{s}.
> tile.stamen.com/toner/{z}/{x}/{y}.png
> 
> 
> 
> 
> - "library" for choosing the JavaScript library to be used: either
> "leaflet" (default) or "googlemaps". If "googlemaps" is chosen, the tile
> URL is not needed as it's necessarily the one by Google and it's
> configured
> by the library itself. It "leaflet" is chosen, it remains possible to
> use
> Google Maps tiles (not sure the macro will support it though):
> https://ivansanchez.gitlab.io/Leaflet.GridLayer.GoogleMutant/demo.html
> 
> Stéphane
> 
> Ludovic
> 
>> 
>> --
>> *Ludovic Dubost*
>> *Founder and CEO*
>> ludo...@xwiki.com
>> skype: ldubost
>> Blog: http://blog.ludovic.orgTry XWiki on the cloud
>>   - Try Cryptpad:
>> Secure
>> realtime Wysiwyg Editing 
>> 
>> 
>> 
> --
> Stéphane Laurière
> XWiki www.xwiki.com
> @slauriere
> 
> 
> 
 
>> 
>> --
>> Stéphane Laurière
>> XWiki www.xwiki.com
>> @slauriere

Re: [xwiki-devs] [Contrib] New repo and JIRA for an OpenStreetMap macro

[Ludovic Dubost]

Yes I'm +1 to move to OSM being the default

Ludovic

--
*Ludovic Dubost*
*Founder and CEO*
ludo...@xwiki.com
skype: ldubost
Blog: http://blog.ludovic.orgTry XWiki on the cloud
  - Try Cryptpad: Secure
realtime Wysiwyg Editing 


On Mon, Jul 2, 2018 at 4:31 PM, Stéphane Laurière 
wrote:

> Hi Alex, Ludo, all,
>
> Thanks for your feedbacks. I created a pull request which now includes OSM
> geocoding and opens OSM directions when clicking on the marker:
>
>   https://github.com/xwiki-contrib/macro-map/pull/9
>
> As for the default value, now that OSM geocoding is supported I'd rather
> be for using it but on the other hand it's true that it will have an impact
> on existing instances...
>
> Stéphane
>
>
> Ludovic Dubost:
>
>> Hi,
>>
>> The idea was to push for usage of OSM instead of Google, especially with
>> the changes Google is giving and the fact that it requires a key by
>> default.
>> Now indeed this is unsual to change the default as it might break the
>> cases
>> where geocoding was used until we support geocoding as part of the OSM
>> macro
>>
>> Ludovic
>>
>> --
>> *Ludovic Dubost*
>> *Founder and CEO*
>> ludo...@xwiki.com
>> skype: ldubost
>> Blog: http://blog.ludovic.orgTry XWiki on the cloud
>>   - Try Cryptpad:
>> Secure
>> realtime Wysiwyg Editing 
>>
>>
>> On Mon, Jul 2, 2018 at 1:24 PM, Alex Cotiugă > >
>> wrote:
>>
>> Hi Stéphane,
>>>
>>> Why would you change the default from googlemaps? Since we only have one
>>> implementation so far, I think we should keep it as default. WDYT?
>>>
>>> Alex
>>>
>>> On Wed, Jun 27, 2018 at 3:13 PM, Stéphane Laurière 
>>> wrote:
>>>
>>> Ludovic Dubost:

 Do we have the plan of being able to configure the openstreetmap
> provider ?
>
>
 My plan is to add two parameters to the macro:

 - "tiles" for configuring the tile provider URL scheme. Examples:
 https://
 {s}.tile.openstreetmap.org/{z}/{x}/{y}.png
 
  http://{s}.
 tile.stamen.com/toner/{z}/{x}/{y}.png
 
 


 - "library" for choosing the JavaScript library to be used: either
 "leaflet" (default) or "googlemaps". If "googlemaps" is chosen, the tile
 URL is not needed as it's necessarily the one by Google and it's
 configured
 by the library itself. It "leaflet" is chosen, it remains possible to
 use
 Google Maps tiles (not sure the macro will support it though):
 https://ivansanchez.gitlab.io/Leaflet.GridLayer.GoogleMutant/demo.html

 Stéphane

 Ludovic

>
> --
> *Ludovic Dubost*
> *Founder and CEO*
> ludo...@xwiki.com
> skype: ldubost
> Blog: http://blog.ludovic.orgTry XWiki on the cloud
>   - Try Cryptpad:
> Secure
> realtime Wysiwyg Editing 
>
>
>
 --
 Stéphane Laurière
 XWiki www.xwiki.com
 @slauriere



>>>
>
> --
> Stéphane Laurière
> XWiki www.xwiki.com
> @slauriere
>
>

Re: [xwiki-devs] [Contrib] New repo and JIRA for an OpenStreetMap macro

[Stéphane Laurière]

Hi Alex, Ludo, all,

Thanks for your feedbacks. I created a pull request which now includes OSM 
geocoding and opens OSM directions when clicking on the marker:

  https://github.com/xwiki-contrib/macro-map/pull/9

As for the default value, now that OSM geocoding is supported I'd rather be for 
using it but on the other hand it's true that it will have an impact on 
existing instances...

Stéphane


Ludovic Dubost:

Hi,

The idea was to push for usage of OSM instead of Google, especially with
the changes Google is giving and the fact that it requires a key by default.
Now indeed this is unsual to change the default as it might break the cases
where geocoding was used until we support geocoding as part of the OSM macro

Ludovic

--
*Ludovic Dubost*
*Founder and CEO*
ludo...@xwiki.com
skype: ldubost
Blog: http://blog.ludovic.orgTry XWiki on the cloud
  - Try Cryptpad: Secure
realtime Wysiwyg Editing 


On Mon, Jul 2, 2018 at 1:24 PM, Alex Cotiugă 
wrote:


Hi Stéphane,

Why would you change the default from googlemaps? Since we only have one
implementation so far, I think we should keep it as default. WDYT?

Alex

On Wed, Jun 27, 2018 at 3:13 PM, Stéphane Laurière 
wrote:


Ludovic Dubost:


Do we have the plan of being able to configure the openstreetmap
provider ?



My plan is to add two parameters to the macro:

- "tiles" for configuring the tile provider URL scheme. Examples: https://
{s}.tile.openstreetmap.org/{z}/{x}/{y}.png
 http://{s}.
tile.stamen.com/toner/{z}/{x}/{y}.png


- "library" for choosing the JavaScript library to be used: either
"leaflet" (default) or "googlemaps". If "googlemaps" is chosen, the tile
URL is not needed as it's necessarily the one by Google and it's configured
by the library itself. It "leaflet" is chosen, it remains possible to use
Google Maps tiles (not sure the macro will support it though):
https://ivansanchez.gitlab.io/Leaflet.GridLayer.GoogleMutant/demo.html

Stéphane

Ludovic


--
*Ludovic Dubost*
*Founder and CEO*
ludo...@xwiki.com
skype: ldubost
Blog: http://blog.ludovic.orgTry XWiki on the cloud
  - Try Cryptpad:
Secure
realtime Wysiwyg Editing 




--
Stéphane Laurière
XWiki www.xwiki.com
@slauriere







--
Stéphane Laurière
XWiki www.xwiki.com
@slauriere

Re: [xwiki-devs] [Brainstorm] Notifications filters capabilities and performances.

[Guillaume Delhumeau]

Hi Clément,

2018-06-29 13:34 GMT+02:00 Clément Aubin :

> Hi,
>
> With the complexity of the additive filtering system, it's kind of
> normal to see OOM errors. AFAIR we already talked about that a year ago,
> when looking at how we could implement this feature.
>

We could try to improve a bit the situation by "optimizing" the filters.
For example, we can currently end up with filters like these:
- filter events about SpaceA.PageB
- filter events about SpaceA.PageC
- filter events about SpaceA.

Obviously the 2 first filters can be removed since the third one is already
doing their job. I've tried to minimize the number of unnecessary filters
by not creating a new one if the page is already concerned by a wider
filter, but it won't fix existing filters.

An other example is the watch list bridge that simply convert the list of
watched pages as they were in the previous version of XWiki and translate
them to the same number of filters. This may explain many of the OOM
problems. It is even enforced by the fact we had (and we still have) the
"autowatch" mode enabled by default.

So a filter optimizer could be a great help.


>
> On 06/29/2018 05:41 AM, Sergiu Dumitriu wrote:
> > The two main problems that I see are that you're mixing two separate
> things:
> >
> > 1. Tags which are stored in one place, and events which are stored in a
> > different place
> > 2. Again tags, and document locations. They may seem similar, but they
> > are completely different as they are implemented. That's why saying "not
> > in this wiki, except for this tag" cannot ever be implemented in a sane
> > way since the exception is on a different plane.
> >
> > The logical approach would be to also store the tags in the events, but
> > this is not a good thing to do. Where do we stop? For future-proofing
> > filters, we would have to store the entire document in the event, in
> > case someone wants to add a filter on "documents with a specific type of
> > object attached", or "documents with a specific value for a specific
> > property of a specific object", or "documents with attachments ending in
> > .extension".
> >
> > On 06/28/2018 04:44 PM, Guillaume Delhumeau wrote:
> >> For the tags filter, I can also:
> >>
> >> * perform a query to fetch all documents that correspond to the given
> tags
> >> (it doesn't need to be permanent, but it would be better to cache it)
> >> * add a HQL filter on these pages (OR document IN :list_of_pages).
> >>
> >> It's a little variation of solution A. It's ugly but it could do the
> job.
> >
> > It's the sanest proposal so far, but still impossible.
> >
> > Since "not in LOCATION except WITH TAG" doesn't work because it mixes
> > two types of information in the same query fragment, how about making
> > this a one-dimensional query as "only WITH TAG". And since this
> > information is in a different place, pre-querying it is needed. However,
> > if there are thousands or tens/hundreds of thousands of documents with a
> > tag, won't the query crash anyway?
> >
> >> 2018-06-27 12:58 GMT+02:00 Guillaume Delhumeau <
> >> guillaume.delhum...@xwiki.com>:
> >>
> >>> Hi developers.
> >>>
> >>> I am trying to add a new filter to the notifications to be able to
> follow
> >>> pages
> >>> that are marked with a given tag. And it leads me to some questions
> about
> >>> the
> >>> technical implementation of the notifications.
> >>>
> >>> To remind the context: notifications are computed on top of the events
> >>> recorded
> >>> by the event stream (a.k.a activity stream). We take events from the
> event
> >>> stream SQL table, we apply some transformations on them, and we display
> >>> them to
> >>> the user.
> >>>
> >>> Then we have implemented the ability to filter on these events: for
> >>> example
> >>> "don't show events concerning the document A nor the wiki B". Filters
> are
> >>> implemented with 2 distinct ways:
> >>>
> >>>   1/ SQL injections: each filter can add SQL elements in the query we
> make
> >>> to
> >>>  fetch the events from the event stream table. We made this
> mechanism
> >>> so we
> >>>  can let the database do a lot of the filtering process. After all,
> >>> it's its
> >>>  job and it's supposed to perform well. To be precise, Clement has
> >>> even
> >>>  created an Abstract Syntax Tree (AST) so it's easier to inject
> some
> >>> content
> >>>  in the query and it creates an abstraction over the SQL language
> so
> >>> we can
> >>>  even consider to change the storage of the event stream someday.
> >>>
> >>>  The bad thing is that some complex filtering are difficult to
> write
> >>> with
> >>>  the SQL language (event with the AST) or even impossible.
> >>>
> >>>   2/ Post-filtering: after the events have been fetched from the
> database,
> >>> each
> >>>  filter can still decide to keep or filter them. This is useful for
> >>>  complex filtering that cannot be expressed with the SQL language.
> It
> >>> is
> >>>  also needed by the rea

Re: [xwiki-devs] [Contrib] New repo and JIRA for an OpenStreetMap macro

[Ludovic Dubost]

Hi,

The idea was to push for usage of OSM instead of Google, especially with
the changes Google is giving and the fact that it requires a key by default.
Now indeed this is unsual to change the default as it might break the cases
where geocoding was used until we support geocoding as part of the OSM macro

Ludovic

--
*Ludovic Dubost*
*Founder and CEO*
ludo...@xwiki.com
skype: ldubost
Blog: http://blog.ludovic.orgTry XWiki on the cloud
  - Try Cryptpad: Secure
realtime Wysiwyg Editing 


On Mon, Jul 2, 2018 at 1:24 PM, Alex Cotiugă 
wrote:

> Hi Stéphane,
>
> Why would you change the default from googlemaps? Since we only have one
> implementation so far, I think we should keep it as default. WDYT?
>
> Alex
>
> On Wed, Jun 27, 2018 at 3:13 PM, Stéphane Laurière 
> wrote:
>
>> Ludovic Dubost:
>>
>>> Do we have the plan of being able to configure the openstreetmap
>>> provider ?
>>>
>>
>> My plan is to add two parameters to the macro:
>>
>> - "tiles" for configuring the tile provider URL scheme. Examples: https://
>> {s}.tile.openstreetmap.org/{z}/{x}/{y}.png
>>  http://{s}.
>> tile.stamen.com/toner/{z}/{x}/{y}.png
>> 
>>
>> - "library" for choosing the JavaScript library to be used: either
>> "leaflet" (default) or "googlemaps". If "googlemaps" is chosen, the tile
>> URL is not needed as it's necessarily the one by Google and it's configured
>> by the library itself. It "leaflet" is chosen, it remains possible to use
>> Google Maps tiles (not sure the macro will support it though):
>> https://ivansanchez.gitlab.io/Leaflet.GridLayer.GoogleMutant/demo.html
>>
>> Stéphane
>>
>> Ludovic
>>>
>>> --
>>> *Ludovic Dubost*
>>> *Founder and CEO*
>>> ludo...@xwiki.com
>>> skype: ldubost
>>> Blog: http://blog.ludovic.orgTry XWiki on the cloud
>>>   - Try Cryptpad:
>>> Secure
>>> realtime Wysiwyg Editing 
>>>
>>>
>>
>> --
>> Stéphane Laurière
>> XWiki www.xwiki.com
>> @slauriere
>>
>>
>

Re: [xwiki-devs] [Contrib] New repo and JIRA for an OpenStreetMap macro

[Alex Cotiugă]

Hi Stéphane,

Why would you change the default from googlemaps? Since we only have one
implementation so far, I think we should keep it as default. WDYT?

Alex

On Wed, Jun 27, 2018 at 3:13 PM, Stéphane Laurière 
wrote:

> Ludovic Dubost:
>
>> Do we have the plan of being able to configure the openstreetmap provider
>> ?
>>
>
> My plan is to add two parameters to the macro:
>
> - "tiles" for configuring the tile provider URL scheme. Examples: https://
> {s}.tile.openstreetmap.org/{z}/{x}/{y}.png
>  http://{s}.
> tile.stamen.com/toner/{z}/{x}/{y}.png
> 
>
> - "library" for choosing the JavaScript library to be used: either
> "leaflet" (default) or "googlemaps". If "googlemaps" is chosen, the tile
> URL is not needed as it's necessarily the one by Google and it's configured
> by the library itself. It "leaflet" is chosen, it remains possible to use
> Google Maps tiles (not sure the macro will support it though):
> https://ivansanchez.gitlab.io/Leaflet.GridLayer.GoogleMutant/demo.html
>
> Stéphane
>
> Ludovic
>>
>> --
>> *Ludovic Dubost*
>> *Founder and CEO*
>> ludo...@xwiki.com
>> skype: ldubost
>> Blog: http://blog.ludovic.orgTry XWiki on the cloud
>>   - Try Cryptpad:
>> Secure
>> realtime Wysiwyg Editing 
>>
>>
>
> --
> Stéphane Laurière
> XWiki www.xwiki.com
> @slauriere
>
>

Re: [xwiki-devs] [Brainstorming] Next gen functional testing for XWiki

[Vincent Massol]

> On 2 Jul 2018, at 10:52, Adel Atallah  wrote:
> 
> Hi,
> 
> It will be very useful to be able to run functional tests on all
> supported browsers. However I wonder if it will also be as useful for
> different servlet containers and databases (at least when the database
> schema doesn't change).

Re the DB Thomas has replied already and it’s very useful (we regularly have 
regressions because of that).

Re the container, we need to decide and write a Servlet Container Support 
Strategy document as we have for DB and Browsers. Right now it’s a grey area. 
We document some installation instructions for some servlet containers on 
https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/InstallationWAR/#HInstallandconfigureaServletContainer
 but we don’t verify they work.

And they don’t for several of them… for example we’ve received several forum 
posts and JIRAs about XWiki not starting fine on Glassfish for ex. We had the 
same issue on JBoss in the past (we even bundle some Jboss config files in our 
WEB-INF/ directory as a result ;)).

So for me, even for servlet containers, it would be useful if we really want to 
ensure that XWiki deploys fine in them and thus increase user installation 
satisfaction.

Thanks
-Vincent

> I tried to run the tests on my machine but I got an error:
> https://pastebin.com/raw/cYjec5Bm (I haven't analyzed it yet but you
> might have an idea why I'm getting this).
> Also it's a bit disturbing to wait for the docker images to be
> downloaded without knowing it (we should at least have a message
> saying "Downloading images..." or even better, the docker output).
> 
> Thanks,
> Adel
> 
> 
> On Mon, Jul 2, 2018 at 10:40 AM, Vincent Massol  wrote:
>> Important note:
>> * We’ll only be able to test Firefox and Chrome browsers since there’s no 
>> Docker containers for windows/mac having IE11/Edge and Safari (they’re not 
>> supported ATM even on windows machines).
>> * We could work around this by having some agents running on Windows and 
>> using the installed IE11/Edge browser (i.e. not running in a Docker 
>> container). However it’s too complex FTM and I’d instead move this to later 
>> and instead focus on running XWiki on various DBs.
>> * So this means that we’ll still need manual tests for IE11/Edge/Safari for 
>> the moment...
>> 
>> Thanks
>> -Vincent
>> 
>>> On 30 Jun 2018, at 14:59, Vincent Massol  wrote:
>>> 
>>> Status as of today:
>>> 
>>> * I have a working POC for running XWiki functional tests in various 
>>> browsers (chrome and firefox FTM), using the latest Selenium and latest 
>>> Chrome/Firefox. I’ll commit today or in the coming days. Ofc it requires 
>>> docker to be installed so I’ll create a “docker” profile in the build so 
>>> that the build doesn’t break on agents which don’t have docker installed 
>>> yet. It’ll allow you to start testing it on your local machines.
>>> 
>>> * I have updated the design page at 
>>> http://design.xwiki.org/xwiki/bin/view/Proposal/ConfigurationTesting
>>> 
>>> Next steps:
>>> 
>>> * Commit the work one (in the coming days)
>>> * I have started trying to deploy XWiki in an embedded undertow. Still not 
>>> working at this stage (but I’ve progressed). I still don’t know if this is 
>>> going to work or not. I hope it will since that would save me from having 
>>> to write the equivalent of the Packager plugin.
>>> * Integrate ability to choose the DB to use for the tests.
>>> 
>>> Feedback most welcome.
>>> 
>>> Thanks
>>> -Vincent
>>> 
 On 27 May 2018, at 21:44, Vincent Massol  wrote:
 
 Hi devs,
 
 I’d like to give you some info about what I’ve started working on and 
 verify you like the direction I’m proposing to take for the future of 
 functional testing on the xwiki project.
 
 Needs
 =
 
 * Be able to test xwiki on multiple environments
 
 Context
 ==
 
 * Right now we test only in 1 env (Jetty+HSQLDB)
 * I've started some docker images in xwiki-contrib
 * I’ve also started some experiment through 
 https://jira.xwiki.org/browse/XWIKI-14929 and 
 https://jira.xwiki.org/browse/XWIKI-14930 (see also email thread 
 "[Brainstorming] Implementing multi-environment tests - Take 2” and 
 https://github.com/xwiki/xwiki-platform/compare/XWIKI-14929-14930). This 
 email supersedes the "[Brainstorming] Implementing multi-environment tests 
 - Take 2” thread.
 * Initially I imagined doing the multi env testing in Jenkins thanks to 
 the Jenkins Docker plugin/library. However I realized that it would be 
 better to be able to run that on the dev machines and thus decided instead 
 to implement it at the maven level thanks to the Fabric8 Maven plugin.
 
 Proposal
 ===
 
 * The new proposal is to stop trying to do it at the maven level and 
 instead do it at the Java level, i.e. be able to control (start/stop the 
 various docker images for the DB, Se

Re: [xwiki-devs] [Brainstorming] Next gen functional testing for XWiki

[Vincent Massol]

> On 2 Jul 2018, at 10:58, Adel Atallah  wrote:
> 
> Also I hope it will not make CI builds a lot longer.

It should make it slower to start the container but only marginally. What can 
be slower is that it starts a VNC server which we were not starting before.

Globally that should add a couple of seconds.

Thanks
-Vincent

> Adel Atallah
> Product developer intern
> adel.atal...@xwiki.com
> tel: +33 (0)6 12 96 35 06
> 
> 
> On Mon, Jul 2, 2018 at 10:52 AM, Adel Atallah  wrote:
>> Hi,
>> 
>> It will be very useful to be able to run functional tests on all
>> supported browsers. However I wonder if it will also be as useful for
>> different servlet containers and databases (at least when the database
>> schema doesn't change).
>> I tried to run the tests on my machine but I got an error:
>> https://pastebin.com/raw/cYjec5Bm (I haven't analyzed it yet but you
>> might have an idea why I'm getting this).
>> Also it's a bit disturbing to wait for the docker images to be
>> downloaded without knowing it (we should at least have a message
>> saying "Downloading images..." or even better, the docker output).
>> 
>> Thanks,
>> Adel
>> 
>> 
>> On Mon, Jul 2, 2018 at 10:40 AM, Vincent Massol  wrote:
>>> Important note:
>>> * We’ll only be able to test Firefox and Chrome browsers since there’s no 
>>> Docker containers for windows/mac having IE11/Edge and Safari (they’re not 
>>> supported ATM even on windows machines).
>>> * We could work around this by having some agents running on Windows and 
>>> using the installed IE11/Edge browser (i.e. not running in a Docker 
>>> container). However it’s too complex FTM and I’d instead move this to later 
>>> and instead focus on running XWiki on various DBs.
>>> * So this means that we’ll still need manual tests for IE11/Edge/Safari for 
>>> the moment...
>>> 
>>> Thanks
>>> -Vincent
>>> 
 On 30 Jun 2018, at 14:59, Vincent Massol  wrote:
 
 Status as of today:
 
 * I have a working POC for running XWiki functional tests in various 
 browsers (chrome and firefox FTM), using the latest Selenium and latest 
 Chrome/Firefox. I’ll commit today or in the coming days. Ofc it requires 
 docker to be installed so I’ll create a “docker” profile in the build so 
 that the build doesn’t break on agents which don’t have docker installed 
 yet. It’ll allow you to start testing it on your local machines.
 
 * I have updated the design page at 
 http://design.xwiki.org/xwiki/bin/view/Proposal/ConfigurationTesting
 
 Next steps:
 
 * Commit the work one (in the coming days)
 * I have started trying to deploy XWiki in an embedded undertow. Still not 
 working at this stage (but I’ve progressed). I still don’t know if this is 
 going to work or not. I hope it will since that would save me from having 
 to write the equivalent of the Packager plugin.
 * Integrate ability to choose the DB to use for the tests.
 
 Feedback most welcome.
 
 Thanks
 -Vincent
 
> On 27 May 2018, at 21:44, Vincent Massol  wrote:
> 
> Hi devs,
> 
> I’d like to give you some info about what I’ve started working on and 
> verify you like the direction I’m proposing to take for the future of 
> functional testing on the xwiki project.
> 
> Needs
> =
> 
> * Be able to test xwiki on multiple environments
> 
> Context
> ==
> 
> * Right now we test only in 1 env (Jetty+HSQLDB)
> * I've started some docker images in xwiki-contrib
> * I’ve also started some experiment through 
> https://jira.xwiki.org/browse/XWIKI-14929 and 
> https://jira.xwiki.org/browse/XWIKI-14930 (see also email thread 
> "[Brainstorming] Implementing multi-environment tests - Take 2” and 
> https://github.com/xwiki/xwiki-platform/compare/XWIKI-14929-14930). This 
> email supersedes the "[Brainstorming] Implementing multi-environment 
> tests - Take 2” thread.
> * Initially I imagined doing the multi env testing in Jenkins thanks to 
> the Jenkins Docker plugin/library. However I realized that it would be 
> better to be able to run that on the dev machines and thus decided 
> instead to implement it at the maven level thanks to the Fabric8 Maven 
> plugin.
> 
> Proposal
> ===
> 
> * The new proposal is to stop trying to do it at the maven level and 
> instead do it at the Java level, i.e. be able to control (start/stop the 
> various docker images for the DB, Servlet Container/XWiki and the Browser 
> from within the java junit/selenium tests).
> * There are several java libraries existing to control docker from within 
> java. For example: https://github.com/docker-java/docker-java
> * I got convinced when finding this awesome library that combines 
> JUnit5/Selenium and Docker for multi-browser testing: 
> https://bonigarcia.github.io/selenium-jupiter/

Re: [xwiki-devs] [Brainstorming] Next gen functional testing for XWiki

[Vincent Massol]

Hi Adel,

Thanks for trying it! :)

> On 2 Jul 2018, at 10:52, Adel Atallah  wrote:
> 
> Hi,
> 
> It will be very useful to be able to run functional tests on all
> supported browsers. However I wonder if it will also be as useful for
> different servlet containers and databases (at least when the database
> schema doesn't change).
> I tried to run the tests on my machine but I got an error:
> https://pastebin.com/raw/cYjec5Bm (I haven't analyzed it yet but you
> might have an idea why I'm getting this).

Yes I know why. It’s because I need to find the IP so that the browser in the 
docker container can open a URL to your XWiki running on your host.

It seems in your case that the IP resolving that I do lead to 127.0.0.1 which 
is wrong since that points to the container and not outside.

I’ve pushed a fix for my code, see 
https://github.com/xwiki/xwiki-platform/commit/380c803357d49231eaf4f513d5c2ddf1bfcfc55c

Note that it’s also possible to pass the system property “xwiki.test.baseURL”, 
e.g. "xwiki.test.baseURL=http://192.168.0.45” (without the port).

> Also it's a bit disturbing to wait for the docker images to be
> downloaded without knowing it (we should at least have a message
> saying "Downloading images..." or even better, the docker output).

Note that it’s only the first time.

Re displaying some progress/info, I’ll need to check if that can be configured 
in TestContainers but I doubt it.

Thanks
-Vincent

> 
> Thanks,
> Adel
> 
> 
> On Mon, Jul 2, 2018 at 10:40 AM, Vincent Massol  wrote:
>> Important note:
>> * We’ll only be able to test Firefox and Chrome browsers since there’s no 
>> Docker containers for windows/mac having IE11/Edge and Safari (they’re not 
>> supported ATM even on windows machines).
>> * We could work around this by having some agents running on Windows and 
>> using the installed IE11/Edge browser (i.e. not running in a Docker 
>> container). However it’s too complex FTM and I’d instead move this to later 
>> and instead focus on running XWiki on various DBs.
>> * So this means that we’ll still need manual tests for IE11/Edge/Safari for 
>> the moment...
>> 
>> Thanks
>> -Vincent
>> 
>>> On 30 Jun 2018, at 14:59, Vincent Massol  wrote:
>>> 
>>> Status as of today:
>>> 
>>> * I have a working POC for running XWiki functional tests in various 
>>> browsers (chrome and firefox FTM), using the latest Selenium and latest 
>>> Chrome/Firefox. I’ll commit today or in the coming days. Ofc it requires 
>>> docker to be installed so I’ll create a “docker” profile in the build so 
>>> that the build doesn’t break on agents which don’t have docker installed 
>>> yet. It’ll allow you to start testing it on your local machines.
>>> 
>>> * I have updated the design page at 
>>> http://design.xwiki.org/xwiki/bin/view/Proposal/ConfigurationTesting
>>> 
>>> Next steps:
>>> 
>>> * Commit the work one (in the coming days)
>>> * I have started trying to deploy XWiki in an embedded undertow. Still not 
>>> working at this stage (but I’ve progressed). I still don’t know if this is 
>>> going to work or not. I hope it will since that would save me from having 
>>> to write the equivalent of the Packager plugin.
>>> * Integrate ability to choose the DB to use for the tests.
>>> 
>>> Feedback most welcome.
>>> 
>>> Thanks
>>> -Vincent
>>> 
 On 27 May 2018, at 21:44, Vincent Massol  wrote:
 
 Hi devs,
 
 I’d like to give you some info about what I’ve started working on and 
 verify you like the direction I’m proposing to take for the future of 
 functional testing on the xwiki project.
 
 Needs
 =
 
 * Be able to test xwiki on multiple environments
 
 Context
 ==
 
 * Right now we test only in 1 env (Jetty+HSQLDB)
 * I've started some docker images in xwiki-contrib
 * I’ve also started some experiment through 
 https://jira.xwiki.org/browse/XWIKI-14929 and 
 https://jira.xwiki.org/browse/XWIKI-14930 (see also email thread 
 "[Brainstorming] Implementing multi-environment tests - Take 2” and 
 https://github.com/xwiki/xwiki-platform/compare/XWIKI-14929-14930). This 
 email supersedes the "[Brainstorming] Implementing multi-environment tests 
 - Take 2” thread.
 * Initially I imagined doing the multi env testing in Jenkins thanks to 
 the Jenkins Docker plugin/library. However I realized that it would be 
 better to be able to run that on the dev machines and thus decided instead 
 to implement it at the maven level thanks to the Fabric8 Maven plugin.
 
 Proposal
 ===
 
 * The new proposal is to stop trying to do it at the maven level and 
 instead do it at the Java level, i.e. be able to control (start/stop the 
 various docker images for the DB, Servlet Container/XWiki and the Browser 
 from within the java junit/selenium tests).
 * There are several java libraries existing to control docker from within 
 java. For example: https://

Re: [xwiki-devs] [Brainstorming] Next gen functional testing for XWiki

[Thomas Mortagne]

On Mon, Jul 2, 2018 at 10:52 AM, Adel Atallah  wrote:
> Hi,
>
> It will be very useful to be able to run functional tests on all
> supported browsers. However I wonder if it will also be as useful for
> different servlet containers and databases (at least when the database
> schema doesn't change).

I don't think it's very useful for different containers but we very
often have issues with differences between databases that we discover
only after the release (like Oracle and its f... empty string=null or
MySQL and its weird handling of escaping) so it will definitely be
useful.

> I tried to run the tests on my machine but I got an error:
> https://pastebin.com/raw/cYjec5Bm (I haven't analyzed it yet but you
> might have an idea why I'm getting this).
> Also it's a bit disturbing to wait for the docker images to be
> downloaded without knowing it (we should at least have a message
> saying "Downloading images..." or even better, the docker output).
>
> Thanks,
> Adel
>
>
> On Mon, Jul 2, 2018 at 10:40 AM, Vincent Massol  wrote:
>> Important note:
>> * We’ll only be able to test Firefox and Chrome browsers since there’s no 
>> Docker containers for windows/mac having IE11/Edge and Safari (they’re not 
>> supported ATM even on windows machines).
>> * We could work around this by having some agents running on Windows and 
>> using the installed IE11/Edge browser (i.e. not running in a Docker 
>> container). However it’s too complex FTM and I’d instead move this to later 
>> and instead focus on running XWiki on various DBs.
>> * So this means that we’ll still need manual tests for IE11/Edge/Safari for 
>> the moment...
>>
>> Thanks
>> -Vincent
>>
>>> On 30 Jun 2018, at 14:59, Vincent Massol  wrote:
>>>
>>> Status as of today:
>>>
>>> * I have a working POC for running XWiki functional tests in various 
>>> browsers (chrome and firefox FTM), using the latest Selenium and latest 
>>> Chrome/Firefox. I’ll commit today or in the coming days. Ofc it requires 
>>> docker to be installed so I’ll create a “docker” profile in the build so 
>>> that the build doesn’t break on agents which don’t have docker installed 
>>> yet. It’ll allow you to start testing it on your local machines.
>>>
>>> * I have updated the design page at 
>>> http://design.xwiki.org/xwiki/bin/view/Proposal/ConfigurationTesting
>>>
>>> Next steps:
>>>
>>> * Commit the work one (in the coming days)
>>> * I have started trying to deploy XWiki in an embedded undertow. Still not 
>>> working at this stage (but I’ve progressed). I still don’t know if this is 
>>> going to work or not. I hope it will since that would save me from having 
>>> to write the equivalent of the Packager plugin.
>>> * Integrate ability to choose the DB to use for the tests.
>>>
>>> Feedback most welcome.
>>>
>>> Thanks
>>> -Vincent
>>>
 On 27 May 2018, at 21:44, Vincent Massol  wrote:

 Hi devs,

 I’d like to give you some info about what I’ve started working on and 
 verify you like the direction I’m proposing to take for the future of 
 functional testing on the xwiki project.

 Needs
 =

 * Be able to test xwiki on multiple environments

 Context
 ==

 * Right now we test only in 1 env (Jetty+HSQLDB)
 * I've started some docker images in xwiki-contrib
 * I’ve also started some experiment through 
 https://jira.xwiki.org/browse/XWIKI-14929 and 
 https://jira.xwiki.org/browse/XWIKI-14930 (see also email thread 
 "[Brainstorming] Implementing multi-environment tests - Take 2” and 
 https://github.com/xwiki/xwiki-platform/compare/XWIKI-14929-14930). This 
 email supersedes the "[Brainstorming] Implementing multi-environment tests 
 - Take 2” thread.
 * Initially I imagined doing the multi env testing in Jenkins thanks to 
 the Jenkins Docker plugin/library. However I realized that it would be 
 better to be able to run that on the dev machines and thus decided instead 
 to implement it at the maven level thanks to the Fabric8 Maven plugin.

 Proposal
 ===

 * The new proposal is to stop trying to do it at the maven level and 
 instead do it at the Java level, i.e. be able to control (start/stop the 
 various docker images for the DB, Servlet Container/XWiki and the Browser 
 from within the java junit/selenium tests).
 * There are several java libraries existing to control docker from within 
 java. For example: https://github.com/docker-java/docker-java
 * I got convinced when finding this awesome library that combines 
 JUnit5/Selenium and Docker for multi-browser testing: 
 https://bonigarcia.github.io/selenium-jupiter/
 ** Note that this relies on the browser docker images provided by the 
 Selenoid project: https://aerokube.com/selenoid/latest/
 * So the idea is to extend that to be able to control the other 2 docker 
 containers for the DB + ServletContainer/XWiki.

 Pros

Re: [xwiki-devs] [Brainstorming] Next gen functional testing for XWiki

[Adel Atallah]

Also I hope it will not make CI builds a lot longer.
Adel Atallah
Product developer intern
adel.atal...@xwiki.com
tel: +33 (0)6 12 96 35 06


On Mon, Jul 2, 2018 at 10:52 AM, Adel Atallah  wrote:
> Hi,
>
> It will be very useful to be able to run functional tests on all
> supported browsers. However I wonder if it will also be as useful for
> different servlet containers and databases (at least when the database
> schema doesn't change).
> I tried to run the tests on my machine but I got an error:
> https://pastebin.com/raw/cYjec5Bm (I haven't analyzed it yet but you
> might have an idea why I'm getting this).
> Also it's a bit disturbing to wait for the docker images to be
> downloaded without knowing it (we should at least have a message
> saying "Downloading images..." or even better, the docker output).
>
> Thanks,
> Adel
>
>
> On Mon, Jul 2, 2018 at 10:40 AM, Vincent Massol  wrote:
>> Important note:
>> * We’ll only be able to test Firefox and Chrome browsers since there’s no 
>> Docker containers for windows/mac having IE11/Edge and Safari (they’re not 
>> supported ATM even on windows machines).
>> * We could work around this by having some agents running on Windows and 
>> using the installed IE11/Edge browser (i.e. not running in a Docker 
>> container). However it’s too complex FTM and I’d instead move this to later 
>> and instead focus on running XWiki on various DBs.
>> * So this means that we’ll still need manual tests for IE11/Edge/Safari for 
>> the moment...
>>
>> Thanks
>> -Vincent
>>
>>> On 30 Jun 2018, at 14:59, Vincent Massol  wrote:
>>>
>>> Status as of today:
>>>
>>> * I have a working POC for running XWiki functional tests in various 
>>> browsers (chrome and firefox FTM), using the latest Selenium and latest 
>>> Chrome/Firefox. I’ll commit today or in the coming days. Ofc it requires 
>>> docker to be installed so I’ll create a “docker” profile in the build so 
>>> that the build doesn’t break on agents which don’t have docker installed 
>>> yet. It’ll allow you to start testing it on your local machines.
>>>
>>> * I have updated the design page at 
>>> http://design.xwiki.org/xwiki/bin/view/Proposal/ConfigurationTesting
>>>
>>> Next steps:
>>>
>>> * Commit the work one (in the coming days)
>>> * I have started trying to deploy XWiki in an embedded undertow. Still not 
>>> working at this stage (but I’ve progressed). I still don’t know if this is 
>>> going to work or not. I hope it will since that would save me from having 
>>> to write the equivalent of the Packager plugin.
>>> * Integrate ability to choose the DB to use for the tests.
>>>
>>> Feedback most welcome.
>>>
>>> Thanks
>>> -Vincent
>>>
 On 27 May 2018, at 21:44, Vincent Massol  wrote:

 Hi devs,

 I’d like to give you some info about what I’ve started working on and 
 verify you like the direction I’m proposing to take for the future of 
 functional testing on the xwiki project.

 Needs
 =

 * Be able to test xwiki on multiple environments

 Context
 ==

 * Right now we test only in 1 env (Jetty+HSQLDB)
 * I've started some docker images in xwiki-contrib
 * I’ve also started some experiment through 
 https://jira.xwiki.org/browse/XWIKI-14929 and 
 https://jira.xwiki.org/browse/XWIKI-14930 (see also email thread 
 "[Brainstorming] Implementing multi-environment tests - Take 2” and 
 https://github.com/xwiki/xwiki-platform/compare/XWIKI-14929-14930). This 
 email supersedes the "[Brainstorming] Implementing multi-environment tests 
 - Take 2” thread.
 * Initially I imagined doing the multi env testing in Jenkins thanks to 
 the Jenkins Docker plugin/library. However I realized that it would be 
 better to be able to run that on the dev machines and thus decided instead 
 to implement it at the maven level thanks to the Fabric8 Maven plugin.

 Proposal
 ===

 * The new proposal is to stop trying to do it at the maven level and 
 instead do it at the Java level, i.e. be able to control (start/stop the 
 various docker images for the DB, Servlet Container/XWiki and the Browser 
 from within the java junit/selenium tests).
 * There are several java libraries existing to control docker from within 
 java. For example: https://github.com/docker-java/docker-java
 * I got convinced when finding this awesome library that combines 
 JUnit5/Selenium and Docker for multi-browser testing: 
 https://bonigarcia.github.io/selenium-jupiter/
 ** Note that this relies on the browser docker images provided by the 
 Selenoid project: https://aerokube.com/selenoid/latest/
 * So the idea is to extend that to be able to control the other 2 docker 
 containers for the DB + ServletContainer/XWiki.

 Pros
 

 * Very simple setup to start/stop functional tests (and to debug them). 
 Only requires Docker to be installed locally

Re: [xwiki-devs] [Brainstorming] Next gen functional testing for XWiki

[Adel Atallah]

Hi,

It will be very useful to be able to run functional tests on all
supported browsers. However I wonder if it will also be as useful for
different servlet containers and databases (at least when the database
schema doesn't change).
I tried to run the tests on my machine but I got an error:
https://pastebin.com/raw/cYjec5Bm (I haven't analyzed it yet but you
might have an idea why I'm getting this).
Also it's a bit disturbing to wait for the docker images to be
downloaded without knowing it (we should at least have a message
saying "Downloading images..." or even better, the docker output).

Thanks,
Adel


On Mon, Jul 2, 2018 at 10:40 AM, Vincent Massol  wrote:
> Important note:
> * We’ll only be able to test Firefox and Chrome browsers since there’s no 
> Docker containers for windows/mac having IE11/Edge and Safari (they’re not 
> supported ATM even on windows machines).
> * We could work around this by having some agents running on Windows and 
> using the installed IE11/Edge browser (i.e. not running in a Docker 
> container). However it’s too complex FTM and I’d instead move this to later 
> and instead focus on running XWiki on various DBs.
> * So this means that we’ll still need manual tests for IE11/Edge/Safari for 
> the moment...
>
> Thanks
> -Vincent
>
>> On 30 Jun 2018, at 14:59, Vincent Massol  wrote:
>>
>> Status as of today:
>>
>> * I have a working POC for running XWiki functional tests in various 
>> browsers (chrome and firefox FTM), using the latest Selenium and latest 
>> Chrome/Firefox. I’ll commit today or in the coming days. Ofc it requires 
>> docker to be installed so I’ll create a “docker” profile in the build so 
>> that the build doesn’t break on agents which don’t have docker installed 
>> yet. It’ll allow you to start testing it on your local machines.
>>
>> * I have updated the design page at 
>> http://design.xwiki.org/xwiki/bin/view/Proposal/ConfigurationTesting
>>
>> Next steps:
>>
>> * Commit the work one (in the coming days)
>> * I have started trying to deploy XWiki in an embedded undertow. Still not 
>> working at this stage (but I’ve progressed). I still don’t know if this is 
>> going to work or not. I hope it will since that would save me from having to 
>> write the equivalent of the Packager plugin.
>> * Integrate ability to choose the DB to use for the tests.
>>
>> Feedback most welcome.
>>
>> Thanks
>> -Vincent
>>
>>> On 27 May 2018, at 21:44, Vincent Massol  wrote:
>>>
>>> Hi devs,
>>>
>>> I’d like to give you some info about what I’ve started working on and 
>>> verify you like the direction I’m proposing to take for the future of 
>>> functional testing on the xwiki project.
>>>
>>> Needs
>>> =
>>>
>>> * Be able to test xwiki on multiple environments
>>>
>>> Context
>>> ==
>>>
>>> * Right now we test only in 1 env (Jetty+HSQLDB)
>>> * I've started some docker images in xwiki-contrib
>>> * I’ve also started some experiment through 
>>> https://jira.xwiki.org/browse/XWIKI-14929 and 
>>> https://jira.xwiki.org/browse/XWIKI-14930 (see also email thread 
>>> "[Brainstorming] Implementing multi-environment tests - Take 2” and 
>>> https://github.com/xwiki/xwiki-platform/compare/XWIKI-14929-14930). This 
>>> email supersedes the "[Brainstorming] Implementing multi-environment tests 
>>> - Take 2” thread.
>>> * Initially I imagined doing the multi env testing in Jenkins thanks to the 
>>> Jenkins Docker plugin/library. However I realized that it would be better 
>>> to be able to run that on the dev machines and thus decided instead to 
>>> implement it at the maven level thanks to the Fabric8 Maven plugin.
>>>
>>> Proposal
>>> ===
>>>
>>> * The new proposal is to stop trying to do it at the maven level and 
>>> instead do it at the Java level, i.e. be able to control (start/stop the 
>>> various docker images for the DB, Servlet Container/XWiki and the Browser 
>>> from within the java junit/selenium tests).
>>> * There are several java libraries existing to control docker from within 
>>> java. For example: https://github.com/docker-java/docker-java
>>> * I got convinced when finding this awesome library that combines 
>>> JUnit5/Selenium and Docker for multi-browser testing: 
>>> https://bonigarcia.github.io/selenium-jupiter/
>>> ** Note that this relies on the browser docker images provided by the 
>>> Selenoid project: https://aerokube.com/selenoid/latest/
>>> * So the idea is to extend that to be able to control the other 2 docker 
>>> containers for the DB + ServletContainer/XWiki.
>>>
>>> Pros
>>> 
>>>
>>> * Very simple setup to start/stop functional tests (and to debug them). 
>>> Only requires Docker to be installed locally.
>>> * Very simple to test any combination of DB/Servlet Container/Browser.
>>> * Always up to date images with the latest version (we can depend on LATEST 
>>> of Browser images, MySQL, Tomcat, etc).
>>> * Using JUnit5 and thus the latest features
>>> * Moving to the latest Selenium version too
>>> * Also supports manu

[xwiki-devs] [Need proposal] How to show "conflicting" macro parameters

[Thomas Mortagne]

Hi xwikiers,

In the contact of bringing new Page concept (OK 7.4 is starting to get
old) to the API and macros too we decided (1) to introduce a "page"
shortcut property (even if we keep the reference/type for other
types).

While it's nicer for wiki syntax, one issue is that on WYSIWYG macros
UI side, which display all properties, it means ending up with
conflicting parameters that needs to be displayed as such.

I don't really have much clue on how best to display this so I'm
searching for ideas :)

Then I will add in the macro descriptor what's required for whatever
UI we want to build (group and sub groups of properties, etc.).

1: 
http://design.xwiki.org/xwiki/bin/view/Proposal/DeprecatingSpaceAndSpaceReference#HMacros

Thanks,
-- 
Thomas Mortagnes

Re: [xwiki-devs] [Brainstorming] Next gen functional testing for XWiki

[Vincent Massol]

Important note: 
* We’ll only be able to test Firefox and Chrome browsers since there’s no 
Docker containers for windows/mac having IE11/Edge and Safari (they’re not 
supported ATM even on windows machines).
* We could work around this by having some agents running on Windows and using 
the installed IE11/Edge browser (i.e. not running in a Docker container). 
However it’s too complex FTM and I’d instead move this to later and instead 
focus on running XWiki on various DBs.
* So this means that we’ll still need manual tests for IE11/Edge/Safari for the 
moment...

Thanks
-Vincent

> On 30 Jun 2018, at 14:59, Vincent Massol  wrote:
> 
> Status as of today:
> 
> * I have a working POC for running XWiki functional tests in various browsers 
> (chrome and firefox FTM), using the latest Selenium and latest 
> Chrome/Firefox. I’ll commit today or in the coming days. Ofc it requires 
> docker to be installed so I’ll create a “docker” profile in the build so that 
> the build doesn’t break on agents which don’t have docker installed yet. 
> It’ll allow you to start testing it on your local machines.
> 
> * I have updated the design page at 
> http://design.xwiki.org/xwiki/bin/view/Proposal/ConfigurationTesting
> 
> Next steps:
> 
> * Commit the work one (in the coming days)
> * I have started trying to deploy XWiki in an embedded undertow. Still not 
> working at this stage (but I’ve progressed). I still don’t know if this is 
> going to work or not. I hope it will since that would save me from having to 
> write the equivalent of the Packager plugin.
> * Integrate ability to choose the DB to use for the tests.
> 
> Feedback most welcome.
> 
> Thanks
> -Vincent 
> 
>> On 27 May 2018, at 21:44, Vincent Massol  wrote:
>> 
>> Hi devs,
>> 
>> I’d like to give you some info about what I’ve started working on and verify 
>> you like the direction I’m proposing to take for the future of functional 
>> testing on the xwiki project.
>> 
>> Needs
>> =
>> 
>> * Be able to test xwiki on multiple environments
>> 
>> Context
>> ==
>> 
>> * Right now we test only in 1 env (Jetty+HSQLDB)
>> * I've started some docker images in xwiki-contrib
>> * I’ve also started some experiment through 
>> https://jira.xwiki.org/browse/XWIKI-14929 and 
>> https://jira.xwiki.org/browse/XWIKI-14930 (see also email thread 
>> "[Brainstorming] Implementing multi-environment tests - Take 2” and 
>> https://github.com/xwiki/xwiki-platform/compare/XWIKI-14929-14930). This 
>> email supersedes the "[Brainstorming] Implementing multi-environment tests - 
>> Take 2” thread.
>> * Initially I imagined doing the multi env testing in Jenkins thanks to the 
>> Jenkins Docker plugin/library. However I realized that it would be better to 
>> be able to run that on the dev machines and thus decided instead to 
>> implement it at the maven level thanks to the Fabric8 Maven plugin.
>> 
>> Proposal
>> ===
>> 
>> * The new proposal is to stop trying to do it at the maven level and instead 
>> do it at the Java level, i.e. be able to control (start/stop the various 
>> docker images for the DB, Servlet Container/XWiki and the Browser from 
>> within the java junit/selenium tests).
>> * There are several java libraries existing to control docker from within 
>> java. For example: https://github.com/docker-java/docker-java
>> * I got convinced when finding this awesome library that combines 
>> JUnit5/Selenium and Docker for multi-browser testing: 
>> https://bonigarcia.github.io/selenium-jupiter/
>> ** Note that this relies on the browser docker images provided by the 
>> Selenoid project: https://aerokube.com/selenoid/latest/
>> * So the idea is to extend that to be able to control the other 2 docker 
>> containers for the DB + ServletContainer/XWiki.
>> 
>> Pros
>> 
>> 
>> * Very simple setup to start/stop functional tests (and to debug them). Only 
>> requires Docker to be installed locally.
>> * Very simple to test any combination of DB/Servlet Container/Browser.
>> * Always up to date images with the latest version (we can depend on LATEST 
>> of Browser images, MySQL, Tomcat, etc).
>> * Using JUnit5 and thus the latest features
>> * Moving to the latest Selenium version too
>> * Also supports manually executing tests in a given running xwiki instance
>> 
>> Implementation
>> 
>> 
>> Something like:
>> 
>> --> XWikiSeleniumExtension extends SeleniumExtension
>> 
>> @ExtendWith(XWikiSeleniumExtension.class)
>> public class Test
>> 
>> @Test
>> public void xxx(XWikiWebDriver driver)
>> {
>> …
>> }
>> 
>> And be able to configure the DB to use, the Servlet container to use, and 
>> the packaging to use from system properties (and also from the test itself, 
>> see https://bonigarcia.github.io/selenium-jupiter/#generic-driver).
>> 
>> The idea is to reimplement the XWiki Packaging Maven plugin as a java lib 
>> using Aether and to just start our functional tests using pure junit without 
>> anymore more. All the hard work will be performed