Re: [xwiki-devs] Activating Wiki on a single host in fleet clears security cache for entire fleet

[Denis Gervalle]

Hi Ktc,

The unexpected behavior is the event sent by the 
XWikiServerXwikiDocumentInitializer. Upon starting a new node, there is no 
reason that the main wiki descriptor gets updated, and therefore no reason for 
an DocumentUpdatedEvent to be triggered. I hardly suggest trying to understand 
why such an update happens.

The purpose of cleaning the whole security cache when the main wiki descriptor 
is updated is simply to ensure that if this document update was updating the 
wiki owner, the new owner is taken into account. Since this owner receives 
admin right on the whole farm, all the information contained in the security 
cache could be invalid, hence the complete cleanup.

Please let us know if you find why the descriptor is updated.

--
Denis Gervalle
SOFTEC sa - CEO

On 11 May 2018, 18:44 +0200, ktc , wrote:
>
> XWikiServerXwikiDocumentInitializer's

[xwiki-devs] GSoC Goals for Improving Dokuwiki importer

[Neha Gupta]

Hey everyone,

I’m working on improving dokuwiki importer this GSoC and have designed a 
proposal defining goals according to the current issues and some proposed 
ideas, for this summer.
I’ll be glad if developers can share their views and let me know if you feel 
something more can be added to it or changed for better.

Thanks to Thomas Mortagne and Shubham Jain for mentoring me on this project.

You can find the proposal here 
http://design.xwiki.org/xwiki/bin/view/Improve%20dokuwiki%20Extension/ 



Best,
Neha

Re: [xwiki-devs] Fwd: Get started with XWiki

[Vincent Massol]

> On 14 May 2018, at 15:30, Thomas Mortagne  wrote:
> 
> On Mon, May 14, 2018 at 2:57 PM, Vincent Massol  wrote:
>> 
>> 
>>> On 14 May 2018, at 14:13, Eduard Moraru  wrote:
>>> 
>>> On Mon, May 14, 2018 at 12:46 PM, Vincent Massol  wrote:
>>> 
 FYI we dropped the installer because it was a pain to maintain and causing
 too much trouble (FTR izpack allowed to bundled the JRE too).
 
 I’m not sure a this stage we should go back to that.
 
>>> 
>>> FTR, I never suggested adding an installer, just including in the ZIP an
>>> already available JDK.
>> 
>> I thought a JRE had to be installed. Are you really sure it doesn’t have to?
> 
> I really doubt you have to install it. You certainly don't on Linux
> (and I guess it's the same on Mac),

I’ve always installed on mac…

Thanks
-Vincent

> I'm not 100% sure for Window but I
> don't see why this would be required.
> 
>> 
>> Thanks
>> -Vincent
>> 
>>> 
>>> Thanks,
>>> Eduard
>>> 
 
 Here’s an idea:
 * Merge Try and Download on xwiki.org into a single entry point
 * Have a wizard in that entry point and ask some questions to the user
 (with the option to skip the wizard) to direct the user to use the right
 distribution for him/her.
 * Thus, promote more the cloud option for users who are not technical and
 want a quick way to test xwiki.
 
 It wouldn’t solve everything for sure but maybe it would help?
 
 Thanks
 -Vincent
 
> On 14 May 2018, at 11:32, Eduard Moraru  wrote:
> 
> There seem to be some resources on the topic:
> 
> https://github.com/libgdx/libgdx/wiki/Bundling-a-JRE
> https://stackoverflow.com/questions/7071133/how-to-
 bundle-a-jre-with-launch4j
> https://codeiseasy.wordpress.com/2012/07/31/including-a-
 jre-in-a-tycho-build/
> 
> ...so it's not such an uncommon practice.
> 
> On the legal side, OpenJDK should be the obvious choice:
> https://opensource.stackexchange.com/questions/
 4824/is-it-legal-to-bundle-oracles-jre-with-an-open-source-program/4826
> 
> IMO, it would make sense to provide the full and ready to test package,
> rather than an only 90% ready to test one.
> 
> Thanks,
> Eduard
> 
> On Mon, May 14, 2018 at 12:04 PM, Thomas Mortagne <
 thomas.morta...@xwiki.com
>> wrote:
> 
>> On Mon, May 14, 2018 at 10:49 AM, Eduard Moraru 
>> wrote:
>>> AFAIR, Eclipse also does this (i.e. bundle their own JRE), we could
 look
>>> into how they do it.
>> 
>> Eclipse JDT comes with its own Java compiler but you are supposed to
>> install Java to run Eclipse itself.
>> 
>>> 
>>> On a quick check, OpenJDK's JRE is only 38.4 MB (
>>> http://jdk.java.net/java-se-ri/8) ... I find that acceptable.
>> 
>> Not sure the license allow us to embbed what's on that page.
>> 
>> 38.4MB is probably only for one system, I think you need 3 of those
>> (Linux, Windows, Mac)
>> 
>>> 
>>> FTR, the JDK is 164 MB.
>>> 
>>> Thanks,
>>> Eduard
>>> 
>>> On Mon, May 14, 2018 at 11:40 AM, Thomas Mortagne <
>> thomas.morta...@xwiki.com
 wrote:
>>> 
 One issue with embedded Java (OpenJDK I guess) is that it would make
 the zip quite huge.
 
 On Mon, May 14, 2018 at 10:30 AM, Eduard Moraru  
 wrote:
> Hi,
> 
> On the palliative side (i.e. not actually fixing, but at least making
 life
> a bit easier), we might consider a naming scheme for the downloadable
 that
> includes that supported java version, e.g. xwiki-10.3-java8.zip
>> (though
> this might also lead users to thinking that the java 8 runtime is
> included... which might not be that bad of an idea, if we think about
 it...
> at least for the zip version that is for demo purposes, which already
> contains the web server, the database, but still expects the user to
> understand and install the correct Java runtime, which makes no
>> sense.)
> 
> So, yeah... TL;DR: add the java8 runtime to the .zip package and make
 life
> easier for everyone. Optionally (though not sure if needed anymore,
>> if we
> bundle it), include it in the .zip file name.
> 
> Of course, the production install, if done manually (i.e. not through
> .deb/.rpm packages), expects that the user reads the documentation.
> 
> Thanks,
> Eduard
> 
> On Mon, May 14, 2018 at 10:19 AM, Vincent Massol  
 wrote:
> 
>> Hi devs, here’s a feedback we received, FYI.
>> 
>> Ideas?
>> 

Re: [xwiki-devs] Fwd: Get started with XWiki

[Thomas Mortagne]

On Mon, May 14, 2018 at 2:57 PM, Vincent Massol  wrote:
>
>
>> On 14 May 2018, at 14:13, Eduard Moraru  wrote:
>>
>> On Mon, May 14, 2018 at 12:46 PM, Vincent Massol  wrote:
>>
>>> FYI we dropped the installer because it was a pain to maintain and causing
>>> too much trouble (FTR izpack allowed to bundled the JRE too).
>>>
>>> I’m not sure a this stage we should go back to that.
>>>
>>
>> FTR, I never suggested adding an installer, just including in the ZIP an
>> already available JDK.
>
> I thought a JRE had to be installed. Are you really sure it doesn’t have to?

I really doubt you have to install it. You certainly don't on Linux
(and I guess it's the same on Mac), I'm not 100% sure for Window but I
don't see why this would be required.

>
> Thanks
> -Vincent
>
>>
>> Thanks,
>> Eduard
>>
>>>
>>> Here’s an idea:
>>> * Merge Try and Download on xwiki.org into a single entry point
>>> * Have a wizard in that entry point and ask some questions to the user
>>> (with the option to skip the wizard) to direct the user to use the right
>>> distribution for him/her.
>>> * Thus, promote more the cloud option for users who are not technical and
>>> want a quick way to test xwiki.
>>>
>>> It wouldn’t solve everything for sure but maybe it would help?
>>>
>>> Thanks
>>> -Vincent
>>>
 On 14 May 2018, at 11:32, Eduard Moraru  wrote:

 There seem to be some resources on the topic:

 https://github.com/libgdx/libgdx/wiki/Bundling-a-JRE
 https://stackoverflow.com/questions/7071133/how-to-
>>> bundle-a-jre-with-launch4j
 https://codeiseasy.wordpress.com/2012/07/31/including-a-
>>> jre-in-a-tycho-build/

 ...so it's not such an uncommon practice.

 On the legal side, OpenJDK should be the obvious choice:
 https://opensource.stackexchange.com/questions/
>>> 4824/is-it-legal-to-bundle-oracles-jre-with-an-open-source-program/4826

 IMO, it would make sense to provide the full and ready to test package,
 rather than an only 90% ready to test one.

 Thanks,
 Eduard

 On Mon, May 14, 2018 at 12:04 PM, Thomas Mortagne <
>>> thomas.morta...@xwiki.com
> wrote:

> On Mon, May 14, 2018 at 10:49 AM, Eduard Moraru 
> wrote:
>> AFAIR, Eclipse also does this (i.e. bundle their own JRE), we could
>>> look
>> into how they do it.
>
> Eclipse JDT comes with its own Java compiler but you are supposed to
> install Java to run Eclipse itself.
>
>>
>> On a quick check, OpenJDK's JRE is only 38.4 MB (
>> http://jdk.java.net/java-se-ri/8) ... I find that acceptable.
>
> Not sure the license allow us to embbed what's on that page.
>
> 38.4MB is probably only for one system, I think you need 3 of those
> (Linux, Windows, Mac)
>
>>
>> FTR, the JDK is 164 MB.
>>
>> Thanks,
>> Eduard
>>
>> On Mon, May 14, 2018 at 11:40 AM, Thomas Mortagne <
> thomas.morta...@xwiki.com
>>> wrote:
>>
>>> One issue with embedded Java (OpenJDK I guess) is that it would make
>>> the zip quite huge.
>>>
>>> On Mon, May 14, 2018 at 10:30 AM, Eduard Moraru >> wrote:
 Hi,

 On the palliative side (i.e. not actually fixing, but at least making
>>> life
 a bit easier), we might consider a naming scheme for the downloadable
>>> that
 includes that supported java version, e.g. xwiki-10.3-java8.zip
> (though
 this might also lead users to thinking that the java 8 runtime is
 included... which might not be that bad of an idea, if we think about
>>> it...
 at least for the zip version that is for demo purposes, which already
 contains the web server, the database, but still expects the user to
 understand and install the correct Java runtime, which makes no
> sense.)

 So, yeah... TL;DR: add the java8 runtime to the .zip package and make
>>> life
 easier for everyone. Optionally (though not sure if needed anymore,
> if we
 bundle it), include it in the .zip file name.

 Of course, the production install, if done manually (i.e. not through
 .deb/.rpm packages), expects that the user reads the documentation.

 Thanks,
 Eduard

 On Mon, May 14, 2018 at 10:19 AM, Vincent Massol >> wrote:

> Hi devs, here’s a feedback we received, FYI.
>
> Ideas?
>
> Thanks
> -Vincent
>
>> Begin forwarded message:
>>
>> From: Vincent Massol
>> Subject: Re: Get started with XWiki
>> Date: 14 May 2018 at 09:10:06 CEST
>> To: XXX
>> Cc: XXX
>>
>> Hi Christian,
>>
>>> On 12 May 2018, at 

Re: [xwiki-devs] Fwd: Get started with XWiki

[Vincent Massol]

> On 14 May 2018, at 14:13, Eduard Moraru  wrote:
> 
> On Mon, May 14, 2018 at 12:46 PM, Vincent Massol  wrote:
> 
>> FYI we dropped the installer because it was a pain to maintain and causing
>> too much trouble (FTR izpack allowed to bundled the JRE too).
>> 
>> I’m not sure a this stage we should go back to that.
>> 
> 
> FTR, I never suggested adding an installer, just including in the ZIP an
> already available JDK.

I thought a JRE had to be installed. Are you really sure it doesn’t have to?

Thanks
-Vincent

> 
> Thanks,
> Eduard
> 
>> 
>> Here’s an idea:
>> * Merge Try and Download on xwiki.org into a single entry point
>> * Have a wizard in that entry point and ask some questions to the user
>> (with the option to skip the wizard) to direct the user to use the right
>> distribution for him/her.
>> * Thus, promote more the cloud option for users who are not technical and
>> want a quick way to test xwiki.
>> 
>> It wouldn’t solve everything for sure but maybe it would help?
>> 
>> Thanks
>> -Vincent
>> 
>>> On 14 May 2018, at 11:32, Eduard Moraru  wrote:
>>> 
>>> There seem to be some resources on the topic:
>>> 
>>> https://github.com/libgdx/libgdx/wiki/Bundling-a-JRE
>>> https://stackoverflow.com/questions/7071133/how-to-
>> bundle-a-jre-with-launch4j
>>> https://codeiseasy.wordpress.com/2012/07/31/including-a-
>> jre-in-a-tycho-build/
>>> 
>>> ...so it's not such an uncommon practice.
>>> 
>>> On the legal side, OpenJDK should be the obvious choice:
>>> https://opensource.stackexchange.com/questions/
>> 4824/is-it-legal-to-bundle-oracles-jre-with-an-open-source-program/4826
>>> 
>>> IMO, it would make sense to provide the full and ready to test package,
>>> rather than an only 90% ready to test one.
>>> 
>>> Thanks,
>>> Eduard
>>> 
>>> On Mon, May 14, 2018 at 12:04 PM, Thomas Mortagne <
>> thomas.morta...@xwiki.com
 wrote:
>>> 
 On Mon, May 14, 2018 at 10:49 AM, Eduard Moraru 
 wrote:
> AFAIR, Eclipse also does this (i.e. bundle their own JRE), we could
>> look
> into how they do it.
 
 Eclipse JDT comes with its own Java compiler but you are supposed to
 install Java to run Eclipse itself.
 
> 
> On a quick check, OpenJDK's JRE is only 38.4 MB (
> http://jdk.java.net/java-se-ri/8) ... I find that acceptable.
 
 Not sure the license allow us to embbed what's on that page.
 
 38.4MB is probably only for one system, I think you need 3 of those
 (Linux, Windows, Mac)
 
> 
> FTR, the JDK is 164 MB.
> 
> Thanks,
> Eduard
> 
> On Mon, May 14, 2018 at 11:40 AM, Thomas Mortagne <
 thomas.morta...@xwiki.com
>> wrote:
> 
>> One issue with embedded Java (OpenJDK I guess) is that it would make
>> the zip quite huge.
>> 
>> On Mon, May 14, 2018 at 10:30 AM, Eduard Moraru >> 
>> wrote:
>>> Hi,
>>> 
>>> On the palliative side (i.e. not actually fixing, but at least making
>> life
>>> a bit easier), we might consider a naming scheme for the downloadable
>> that
>>> includes that supported java version, e.g. xwiki-10.3-java8.zip
 (though
>>> this might also lead users to thinking that the java 8 runtime is
>>> included... which might not be that bad of an idea, if we think about
>> it...
>>> at least for the zip version that is for demo purposes, which already
>>> contains the web server, the database, but still expects the user to
>>> understand and install the correct Java runtime, which makes no
 sense.)
>>> 
>>> So, yeah... TL;DR: add the java8 runtime to the .zip package and make
>> life
>>> easier for everyone. Optionally (though not sure if needed anymore,
 if we
>>> bundle it), include it in the .zip file name.
>>> 
>>> Of course, the production install, if done manually (i.e. not through
>>> .deb/.rpm packages), expects that the user reads the documentation.
>>> 
>>> Thanks,
>>> Eduard
>>> 
>>> On Mon, May 14, 2018 at 10:19 AM, Vincent Massol >> 
>> wrote:
>>> 
 Hi devs, here’s a feedback we received, FYI.
 
 Ideas?
 
 Thanks
 -Vincent
 
> Begin forwarded message:
> 
> From: Vincent Massol
> Subject: Re: Get started with XWiki
> Date: 14 May 2018 at 09:10:06 CEST
> To: XXX
> Cc: XXX
> 
> Hi Christian,
> 
>> On 12 May 2018, at 14:25, Christian XXX wrote:
>> 
>> It's not working.
>> 
>> And as usual ith java, the log does not help. Maybe if I were an
 expert? But an app is supposed to be installed by just 'smart'
>> users,
>> not
 experts.
> 
> If you choose the easy installation methods we propose then it’s
 

Re: [xwiki-devs] Fwd: Get started with XWiki

[Eduard Moraru]

On Mon, May 14, 2018 at 12:46 PM, Vincent Massol  wrote:

> FYI we dropped the installer because it was a pain to maintain and causing
> too much trouble (FTR izpack allowed to bundled the JRE too).
>
> I’m not sure a this stage we should go back to that.
>

FTR, I never suggested adding an installer, just including in the ZIP an
already available JDK.

Thanks,
Eduard

>
> Here’s an idea:
> * Merge Try and Download on xwiki.org into a single entry point
> * Have a wizard in that entry point and ask some questions to the user
> (with the option to skip the wizard) to direct the user to use the right
> distribution for him/her.
> * Thus, promote more the cloud option for users who are not technical and
> want a quick way to test xwiki.
>
> It wouldn’t solve everything for sure but maybe it would help?
>
> Thanks
> -Vincent
>
> > On 14 May 2018, at 11:32, Eduard Moraru  wrote:
> >
> > There seem to be some resources on the topic:
> >
> > https://github.com/libgdx/libgdx/wiki/Bundling-a-JRE
> > https://stackoverflow.com/questions/7071133/how-to-
> bundle-a-jre-with-launch4j
> > https://codeiseasy.wordpress.com/2012/07/31/including-a-
> jre-in-a-tycho-build/
> >
> > ...so it's not such an uncommon practice.
> >
> > On the legal side, OpenJDK should be the obvious choice:
> > https://opensource.stackexchange.com/questions/
> 4824/is-it-legal-to-bundle-oracles-jre-with-an-open-source-program/4826
> >
> > IMO, it would make sense to provide the full and ready to test package,
> > rather than an only 90% ready to test one.
> >
> > Thanks,
> > Eduard
> >
> > On Mon, May 14, 2018 at 12:04 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com
> >> wrote:
> >
> >> On Mon, May 14, 2018 at 10:49 AM, Eduard Moraru 
> >> wrote:
> >>> AFAIR, Eclipse also does this (i.e. bundle their own JRE), we could
> look
> >>> into how they do it.
> >>
> >> Eclipse JDT comes with its own Java compiler but you are supposed to
> >> install Java to run Eclipse itself.
> >>
> >>>
> >>> On a quick check, OpenJDK's JRE is only 38.4 MB (
> >>> http://jdk.java.net/java-se-ri/8) ... I find that acceptable.
> >>
> >> Not sure the license allow us to embbed what's on that page.
> >>
> >> 38.4MB is probably only for one system, I think you need 3 of those
> >> (Linux, Windows, Mac)
> >>
> >>>
> >>> FTR, the JDK is 164 MB.
> >>>
> >>> Thanks,
> >>> Eduard
> >>>
> >>> On Mon, May 14, 2018 at 11:40 AM, Thomas Mortagne <
> >> thomas.morta...@xwiki.com
>  wrote:
> >>>
>  One issue with embedded Java (OpenJDK I guess) is that it would make
>  the zip quite huge.
> 
>  On Mon, May 14, 2018 at 10:30 AM, Eduard Moraru  >
>  wrote:
> > Hi,
> >
> > On the palliative side (i.e. not actually fixing, but at least making
>  life
> > a bit easier), we might consider a naming scheme for the downloadable
>  that
> > includes that supported java version, e.g. xwiki-10.3-java8.zip
> >> (though
> > this might also lead users to thinking that the java 8 runtime is
> > included... which might not be that bad of an idea, if we think about
>  it...
> > at least for the zip version that is for demo purposes, which already
> > contains the web server, the database, but still expects the user to
> > understand and install the correct Java runtime, which makes no
> >> sense.)
> >
> > So, yeah... TL;DR: add the java8 runtime to the .zip package and make
>  life
> > easier for everyone. Optionally (though not sure if needed anymore,
> >> if we
> > bundle it), include it in the .zip file name.
> >
> > Of course, the production install, if done manually (i.e. not through
> > .deb/.rpm packages), expects that the user reads the documentation.
> >
> > Thanks,
> > Eduard
> >
> > On Mon, May 14, 2018 at 10:19 AM, Vincent Massol  >
>  wrote:
> >
> >> Hi devs, here’s a feedback we received, FYI.
> >>
> >> Ideas?
> >>
> >> Thanks
> >> -Vincent
> >>
> >>> Begin forwarded message:
> >>>
> >>> From: Vincent Massol
> >>> Subject: Re: Get started with XWiki
> >>> Date: 14 May 2018 at 09:10:06 CEST
> >>> To: XXX
> >>> Cc: XXX
> >>>
> >>> Hi Christian,
> >>>
>  On 12 May 2018, at 14:25, Christian XXX wrote:
> 
>  It's not working.
> 
>  And as usual ith java, the log does not help. Maybe if I were an
> >> expert? But an app is supposed to be installed by just 'smart'
> users,
>  not
> >> experts.
> >>>
> >>> If you choose the easy installation methods we propose then it’s
> >> easy
> >> and you have nothing to do.
> >>>
> >>> Which distribution did you choose and use?
> >>>
>  And there is no help from the website.
> 
>  Oracle Linux 7.
>  Linux localhost.localdomain 

Re: [xwiki-devs] [Proposal] Improve our Test Coverage strategy

[Vincent Massol]

> On 14 May 2018, at 13:48, Marius Dumitru Florea 
>  wrote:

[snip]
> 
>> ** Find new packages introduced that have a TPC < the average computed
 TPC
>> 
> 
> What is the average computed TPC currently?
 
 It’s about 70%, see for example:
 http://maven.xwiki.org/site/clover/20180511/clover-
 commons+rendering+platform-20180511-0147/dashboard.html
 
 
>>> Requiring 70% TPC for new packages is a nice goal but I find it hard to
>>> achieve in practice.
>> 
>> Two points on this:
>> 
> 
> 
>> * We should have above 80-90%+ in practice for new modules, not 70%. If we
>> have 70% or less we can be sure you did a bad job on quality and that
>> you’re impacting the overall quality of XWiki.
>> 
> 
> *should* but I don't think it happens in practice, for various reasons,
> mainly due to limited time. Did you check the TPC of the last 10 new
> packages? Is it above 70%?

I’ll check it.

Thanks
-Vincent

> 
> 
>> * For some modules, it makes less sense or it’s harder to have unit tests
>> and integration tests are better. We’re not talking about 70% of unit test
>> coverage but 70%+ coverage of overall testing (unit, integration,
>> functional).
>> 
>> Now we’ll need to put in place to see it in action and verify if there are
>> cases where this can be hard to achieve. But I’d prefer that we consider
>> those cases as exceptional and handle them in an ad-hoc manner.
>> 
>>> 
> 
>> ** Find packages and/or files having a TPC lower than the previous TPC
>> ** Find removed packages that had a TPC higher than the average
>> computed
>> TPC
>> 
> 
> I would add:
> 
> ** find the packages that have the TPC higher than what is declared in
 the
> pom (because we don't always update the TPC value declared in the pom
 when
> we refactor the code or when we add new tests)
 
 Yes I agree. We should do that but not in the pipeline for the global
 coverage. We should have another pipeline for this and update the
>> pom.xml
 files in it.
 
> 
>> * Save a report in the directory for the Clover report at
>> http://ci.xwiki.org/view/Tools/job/Clover/
>> * For all failures, send an email to notificati...@xwiki.org with
 details
>> and a link to the saved report
>> * Ideally, and if we can do it, call the github API to find the
>> authors
 of
>> commits for those packages and add them in the report. Examples of
>> APIs
 we
>> could use:
>> ** https://api.github.com/repos/xwiki/xwiki-platform/commits?
>> since=2018-05-07T00:00:00Z=2018-05-10T00:00:00Z (there’s a path
>> parameter that could be used to filter but I don’t think it’ll work
>> ** https://github.com/xwiki/xwiki-platform/compare/master@
>> %7B2018-05-07%7D...master@%7B2018-05-10%7D (the committers/authors
>> need
>> to be extracted from the HTML which is a bit fragile)
>> * Add a step in the Release process to ensure that the global TPC has
 not
>> been lowered. This would be a way to ensure we pay attention to that
>> and
>> fix it when we lower it. We would need to tune this to find something
 that
>> helps keep the TPC increasing while not putting too much pressure at
>> the
>> same time on the release date. It doesn’t have to be in the release
 process
>> but we need some checkpoint to make sure we look at it and that all
>> devs
>> fix the tests when they lower the global TPC, or at the very least
>> that
 an
>> analysis is done in case where it’s hard to keep the TPC (for example,
>> removing existing code that had a lot of tests will lower the TPC ;)).
>> 
>> WDYT?
>> 
>> As a dev, would you be willing to pay attention to not lower the
>> global
>> TPC and work to fix it when it happens?
 
 @Marius: what about this question? Would you be ok with it? :)
 
>>> 
>>> Sure.
>> 
>> ok cool
>> 
>> Thanks
>> -Vincent
>> 
>>> 
>>> 
 
 Thanks
 -Vincent
 
>> 
>> Thanks
>> -Vincent

Re: [xwiki-devs] [Proposal] Improve our Test Coverage strategy

[Marius Dumitru Florea]

On Mon, May 14, 2018 at 2:41 PM, Vincent Massol  wrote:

>
>
> > On 14 May 2018, at 13:30, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > On Mon, May 14, 2018 at 2:17 PM, Vincent Massol 
> wrote:
> >
> >>
> >>
> >>> On 14 May 2018, at 12:28, Marius Dumitru Florea <
> >> mariusdumitru.flo...@xwiki.com> wrote:
> >>>
> >>> On Thu, May 10, 2018 at 10:03 PM, Vincent Massol 
> >> wrote:
> >>>
>  Hi devs,
> 
>  Our current Test coverage strategy is to fail the build when new code
>  added results in a coverage lower than the threshold for the module,
> >> using
>  jacoco.
> 
>  This has 2 limitations causing our global TPC to go down from time to
> >> time
>  (see https://markmail.org/message/hqumkdiz7jm76ya6 ).
> 
>  Thus I’d like to propose the following addition to our strategy:
> 
>  * We already have a jenkins pipeline to automatically compute the full
> >> TPC
>  using Clover. See http://dev.xwiki.org/xwiki/
> >> bin/view/Community/Testing#
>  HUsingClover2BJenkins
>  * Make it run more often (it’s currently executed once per month, see
>  http://ci.xwiki.org/view/Tools/job/Clover/). Takes about 5-6 hours to
>  execute. Thus we could run it once per week or even once per day
> during
> >> the
>  night.
>  * Add some groovy logic in the pipeline to perform an analysis after
> the
>  Clover report has been generated. Perform 2 checks by comparing the
>  previous report with the one that just executed:
> 
> >>>
> >>>
>  ** Find new packages introduced that have a TPC < the average computed
> >> TPC
> 
> >>>
> >>> What is the average computed TPC currently?
> >>
> >> It’s about 70%, see for example:
> >> http://maven.xwiki.org/site/clover/20180511/clover-
> >> commons+rendering+platform-20180511-0147/dashboard.html
> >>
> >>
> > Requiring 70% TPC for new packages is a nice goal but I find it hard to
> > achieve in practice.
>
> Two points on this:
>


> * We should have above 80-90%+ in practice for new modules, not 70%. If we
> have 70% or less we can be sure you did a bad job on quality and that
> you’re impacting the overall quality of XWiki.
>

*should* but I don't think it happens in practice, for various reasons,
mainly due to limited time. Did you check the TPC of the last 10 new
packages? Is it above 70%?


> * For some modules, it makes less sense or it’s harder to have unit tests
> and integration tests are better. We’re not talking about 70% of unit test
> coverage but 70%+ coverage of overall testing (unit, integration,
> functional).
>
> Now we’ll need to put in place to see it in action and verify if there are
> cases where this can be hard to achieve. But I’d prefer that we consider
> those cases as exceptional and handle them in an ad-hoc manner.
>
> >
> >>>
>  ** Find packages and/or files having a TPC lower than the previous TPC
>  ** Find removed packages that had a TPC higher than the average
> computed
>  TPC
> 
> >>>
> >>> I would add:
> >>>
> >>> ** find the packages that have the TPC higher than what is declared in
> >> the
> >>> pom (because we don't always update the TPC value declared in the pom
> >> when
> >>> we refactor the code or when we add new tests)
> >>
> >> Yes I agree. We should do that but not in the pipeline for the global
> >> coverage. We should have another pipeline for this and update the
> pom.xml
> >> files in it.
> >>
> >>>
>  * Save a report in the directory for the Clover report at
>  http://ci.xwiki.org/view/Tools/job/Clover/
>  * For all failures, send an email to notificati...@xwiki.org with
> >> details
>  and a link to the saved report
>  * Ideally, and if we can do it, call the github API to find the
> authors
> >> of
>  commits for those packages and add them in the report. Examples of
> APIs
> >> we
>  could use:
>  ** https://api.github.com/repos/xwiki/xwiki-platform/commits?
>  since=2018-05-07T00:00:00Z=2018-05-10T00:00:00Z (there’s a path
>  parameter that could be used to filter but I don’t think it’ll work
>  ** https://github.com/xwiki/xwiki-platform/compare/master@
>  %7B2018-05-07%7D...master@%7B2018-05-10%7D (the committers/authors
> need
>  to be extracted from the HTML which is a bit fragile)
>  * Add a step in the Release process to ensure that the global TPC has
> >> not
>  been lowered. This would be a way to ensure we pay attention to that
> and
>  fix it when we lower it. We would need to tune this to find something
> >> that
>  helps keep the TPC increasing while not putting too much pressure at
> the
>  same time on the release date. It doesn’t have to be in the release
> >> process
>  but we need some checkpoint to make sure we look at it and that all
> devs
>  fix the tests when they lower the global TPC, or at the very least
> that
> >> an
>  analysis is 

Re: [xwiki-devs] [Proposal] Improve our Test Coverage strategy

[Vincent Massol]

> On 14 May 2018, at 13:30, Marius Dumitru Florea 
>  wrote:
> 
> On Mon, May 14, 2018 at 2:17 PM, Vincent Massol  wrote:
> 
>> 
>> 
>>> On 14 May 2018, at 12:28, Marius Dumitru Florea <
>> mariusdumitru.flo...@xwiki.com> wrote:
>>> 
>>> On Thu, May 10, 2018 at 10:03 PM, Vincent Massol 
>> wrote:
>>> 
 Hi devs,
 
 Our current Test coverage strategy is to fail the build when new code
 added results in a coverage lower than the threshold for the module,
>> using
 jacoco.
 
 This has 2 limitations causing our global TPC to go down from time to
>> time
 (see https://markmail.org/message/hqumkdiz7jm76ya6 ).
 
 Thus I’d like to propose the following addition to our strategy:
 
 * We already have a jenkins pipeline to automatically compute the full
>> TPC
 using Clover. See http://dev.xwiki.org/xwiki/
>> bin/view/Community/Testing#
 HUsingClover2BJenkins
 * Make it run more often (it’s currently executed once per month, see
 http://ci.xwiki.org/view/Tools/job/Clover/). Takes about 5-6 hours to
 execute. Thus we could run it once per week or even once per day during
>> the
 night.
 * Add some groovy logic in the pipeline to perform an analysis after the
 Clover report has been generated. Perform 2 checks by comparing the
 previous report with the one that just executed:
 
>>> 
>>> 
 ** Find new packages introduced that have a TPC < the average computed
>> TPC
 
>>> 
>>> What is the average computed TPC currently?
>> 
>> It’s about 70%, see for example:
>> http://maven.xwiki.org/site/clover/20180511/clover-
>> commons+rendering+platform-20180511-0147/dashboard.html
>> 
>> 
> Requiring 70% TPC for new packages is a nice goal but I find it hard to
> achieve in practice.

Two points on this:
* We should have above 80-90%+ in practice for new modules, not 70%. If we have 
70% or less we can be sure you did a bad job on quality and that you’re 
impacting the overall quality of XWiki.
* For some modules, it makes less sense or it’s harder to have unit tests and 
integration tests are better. We’re not talking about 70% of unit test coverage 
but 70%+ coverage of overall testing (unit, integration, functional).

Now we’ll need to put in place to see it in action and verify if there are 
cases where this can be hard to achieve. But I’d prefer that we consider those 
cases as exceptional and handle them in an ad-hoc manner.

> 
>>> 
 ** Find packages and/or files having a TPC lower than the previous TPC
 ** Find removed packages that had a TPC higher than the average computed
 TPC
 
>>> 
>>> I would add:
>>> 
>>> ** find the packages that have the TPC higher than what is declared in
>> the
>>> pom (because we don't always update the TPC value declared in the pom
>> when
>>> we refactor the code or when we add new tests)
>> 
>> Yes I agree. We should do that but not in the pipeline for the global
>> coverage. We should have another pipeline for this and update the pom.xml
>> files in it.
>> 
>>> 
 * Save a report in the directory for the Clover report at
 http://ci.xwiki.org/view/Tools/job/Clover/
 * For all failures, send an email to notificati...@xwiki.org with
>> details
 and a link to the saved report
 * Ideally, and if we can do it, call the github API to find the authors
>> of
 commits for those packages and add them in the report. Examples of APIs
>> we
 could use:
 ** https://api.github.com/repos/xwiki/xwiki-platform/commits?
 since=2018-05-07T00:00:00Z=2018-05-10T00:00:00Z (there’s a path
 parameter that could be used to filter but I don’t think it’ll work
 ** https://github.com/xwiki/xwiki-platform/compare/master@
 %7B2018-05-07%7D...master@%7B2018-05-10%7D (the committers/authors need
 to be extracted from the HTML which is a bit fragile)
 * Add a step in the Release process to ensure that the global TPC has
>> not
 been lowered. This would be a way to ensure we pay attention to that and
 fix it when we lower it. We would need to tune this to find something
>> that
 helps keep the TPC increasing while not putting too much pressure at the
 same time on the release date. It doesn’t have to be in the release
>> process
 but we need some checkpoint to make sure we look at it and that all devs
 fix the tests when they lower the global TPC, or at the very least that
>> an
 analysis is done in case where it’s hard to keep the TPC (for example,
 removing existing code that had a lot of tests will lower the TPC ;)).
 
 WDYT?
 
 As a dev, would you be willing to pay attention to not lower the global
 TPC and work to fix it when it happens?
>> 
>> @Marius: what about this question? Would you be ok with it? :)
>> 
> 
> Sure.

ok cool

Thanks
-Vincent

> 
> 
>> 
>> Thanks
>> -Vincent
>> 
 
 Thanks
 -Vincent

Re: [xwiki-devs] [Proposal] Improve our Test Coverage strategy

[Marius Dumitru Florea]

On Mon, May 14, 2018 at 2:17 PM, Vincent Massol  wrote:

>
>
> > On 14 May 2018, at 12:28, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > On Thu, May 10, 2018 at 10:03 PM, Vincent Massol 
> wrote:
> >
> >> Hi devs,
> >>
> >> Our current Test coverage strategy is to fail the build when new code
> >> added results in a coverage lower than the threshold for the module,
> using
> >> jacoco.
> >>
> >> This has 2 limitations causing our global TPC to go down from time to
> time
> >> (see https://markmail.org/message/hqumkdiz7jm76ya6 ).
> >>
> >> Thus I’d like to propose the following addition to our strategy:
> >>
> >> * We already have a jenkins pipeline to automatically compute the full
> TPC
> >> using Clover. See http://dev.xwiki.org/xwiki/
> bin/view/Community/Testing#
> >> HUsingClover2BJenkins
> >> * Make it run more often (it’s currently executed once per month, see
> >> http://ci.xwiki.org/view/Tools/job/Clover/). Takes about 5-6 hours to
> >> execute. Thus we could run it once per week or even once per day during
> the
> >> night.
> >> * Add some groovy logic in the pipeline to perform an analysis after the
> >> Clover report has been generated. Perform 2 checks by comparing the
> >> previous report with the one that just executed:
> >>
> >
> >
> >> ** Find new packages introduced that have a TPC < the average computed
> TPC
> >>
> >
> > What is the average computed TPC currently?
>
> It’s about 70%, see for example:
> http://maven.xwiki.org/site/clover/20180511/clover-
> commons+rendering+platform-20180511-0147/dashboard.html
>
>
Requiring 70% TPC for new packages is a nice goal but I find it hard to
achieve in practice.


> >
> >
> >> ** Find packages and/or files having a TPC lower than the previous TPC
> >> ** Find removed packages that had a TPC higher than the average computed
> >> TPC
> >>
> >
> > I would add:
> >
> > ** find the packages that have the TPC higher than what is declared in
> the
> > pom (because we don't always update the TPC value declared in the pom
> when
> > we refactor the code or when we add new tests)
>
> Yes I agree. We should do that but not in the pipeline for the global
> coverage. We should have another pipeline for this and update the pom.xml
> files in it.
>
> >
> >> * Save a report in the directory for the Clover report at
> >> http://ci.xwiki.org/view/Tools/job/Clover/
> >> * For all failures, send an email to notificati...@xwiki.org with
> details
> >> and a link to the saved report
> >> * Ideally, and if we can do it, call the github API to find the authors
> of
> >> commits for those packages and add them in the report. Examples of APIs
> we
> >> could use:
> >> ** https://api.github.com/repos/xwiki/xwiki-platform/commits?
> >> since=2018-05-07T00:00:00Z=2018-05-10T00:00:00Z (there’s a path
> >> parameter that could be used to filter but I don’t think it’ll work
> >> ** https://github.com/xwiki/xwiki-platform/compare/master@
> >> %7B2018-05-07%7D...master@%7B2018-05-10%7D (the committers/authors need
> >> to be extracted from the HTML which is a bit fragile)
> >> * Add a step in the Release process to ensure that the global TPC has
> not
> >> been lowered. This would be a way to ensure we pay attention to that and
> >> fix it when we lower it. We would need to tune this to find something
> that
> >> helps keep the TPC increasing while not putting too much pressure at the
> >> same time on the release date. It doesn’t have to be in the release
> process
> >> but we need some checkpoint to make sure we look at it and that all devs
> >> fix the tests when they lower the global TPC, or at the very least that
> an
> >> analysis is done in case where it’s hard to keep the TPC (for example,
> >> removing existing code that had a lot of tests will lower the TPC ;)).
> >>
> >> WDYT?
> >>
> >> As a dev, would you be willing to pay attention to not lower the global
> >> TPC and work to fix it when it happens?
>
> @Marius: what about this question? Would you be ok with it? :)
>

Sure.


>
> Thanks
> -Vincent
>
> >>
> >> Thanks
> >> -Vincent
>
>

Re: [xwiki-devs] [Proposal] Improve our Test Coverage strategy

[Vincent Massol]

> On 14 May 2018, at 12:28, Marius Dumitru Florea 
>  wrote:
> 
> On Thu, May 10, 2018 at 10:03 PM, Vincent Massol  wrote:
> 
>> Hi devs,
>> 
>> Our current Test coverage strategy is to fail the build when new code
>> added results in a coverage lower than the threshold for the module, using
>> jacoco.
>> 
>> This has 2 limitations causing our global TPC to go down from time to time
>> (see https://markmail.org/message/hqumkdiz7jm76ya6 ).
>> 
>> Thus I’d like to propose the following addition to our strategy:
>> 
>> * We already have a jenkins pipeline to automatically compute the full TPC
>> using Clover. See http://dev.xwiki.org/xwiki/bin/view/Community/Testing#
>> HUsingClover2BJenkins
>> * Make it run more often (it’s currently executed once per month, see
>> http://ci.xwiki.org/view/Tools/job/Clover/). Takes about 5-6 hours to
>> execute. Thus we could run it once per week or even once per day during the
>> night.
>> * Add some groovy logic in the pipeline to perform an analysis after the
>> Clover report has been generated. Perform 2 checks by comparing the
>> previous report with the one that just executed:
>> 
> 
> 
>> ** Find new packages introduced that have a TPC < the average computed TPC
>> 
> 
> What is the average computed TPC currently?

It’s about 70%, see for example:
http://maven.xwiki.org/site/clover/20180511/clover-commons+rendering+platform-20180511-0147/dashboard.html

> 
> 
>> ** Find packages and/or files having a TPC lower than the previous TPC
>> ** Find removed packages that had a TPC higher than the average computed
>> TPC
>> 
> 
> I would add:
> 
> ** find the packages that have the TPC higher than what is declared in the
> pom (because we don't always update the TPC value declared in the pom when
> we refactor the code or when we add new tests)

Yes I agree. We should do that but not in the pipeline for the global coverage. 
We should have another pipeline for this and update the pom.xml files in it.

> 
>> * Save a report in the directory for the Clover report at
>> http://ci.xwiki.org/view/Tools/job/Clover/
>> * For all failures, send an email to notificati...@xwiki.org with details
>> and a link to the saved report
>> * Ideally, and if we can do it, call the github API to find the authors of
>> commits for those packages and add them in the report. Examples of APIs we
>> could use:
>> ** https://api.github.com/repos/xwiki/xwiki-platform/commits?
>> since=2018-05-07T00:00:00Z=2018-05-10T00:00:00Z (there’s a path
>> parameter that could be used to filter but I don’t think it’ll work
>> ** https://github.com/xwiki/xwiki-platform/compare/master@
>> %7B2018-05-07%7D...master@%7B2018-05-10%7D (the committers/authors need
>> to be extracted from the HTML which is a bit fragile)
>> * Add a step in the Release process to ensure that the global TPC has not
>> been lowered. This would be a way to ensure we pay attention to that and
>> fix it when we lower it. We would need to tune this to find something that
>> helps keep the TPC increasing while not putting too much pressure at the
>> same time on the release date. It doesn’t have to be in the release process
>> but we need some checkpoint to make sure we look at it and that all devs
>> fix the tests when they lower the global TPC, or at the very least that an
>> analysis is done in case where it’s hard to keep the TPC (for example,
>> removing existing code that had a lot of tests will lower the TPC ;)).
>> 
>> WDYT?
>> 
>> As a dev, would you be willing to pay attention to not lower the global
>> TPC and work to fix it when it happens?

@Marius: what about this question? Would you be ok with it? :)

Thanks
-Vincent

>> 
>> Thanks
>> -Vincent

Re: [xwiki-devs] [Proposal] Improve our Test Coverage strategy

[Marius Dumitru Florea]

On Thu, May 10, 2018 at 10:03 PM, Vincent Massol  wrote:

> Hi devs,
>
> Our current Test coverage strategy is to fail the build when new code
> added results in a coverage lower than the threshold for the module, using
> jacoco.
>
> This has 2 limitations causing our global TPC to go down from time to time
> (see https://markmail.org/message/hqumkdiz7jm76ya6 ).
>
> Thus I’d like to propose the following addition to our strategy:
>
> * We already have a jenkins pipeline to automatically compute the full TPC
> using Clover. See http://dev.xwiki.org/xwiki/bin/view/Community/Testing#
> HUsingClover2BJenkins
> * Make it run more often (it’s currently executed once per month, see
> http://ci.xwiki.org/view/Tools/job/Clover/). Takes about 5-6 hours to
> execute. Thus we could run it once per week or even once per day during the
> night.
> * Add some groovy logic in the pipeline to perform an analysis after the
> Clover report has been generated. Perform 2 checks by comparing the
> previous report with the one that just executed:
>


> ** Find new packages introduced that have a TPC < the average computed TPC
>

What is the average computed TPC currently?


> ** Find packages and/or files having a TPC lower than the previous TPC
> ** Find removed packages that had a TPC higher than the average computed
> TPC
>

I would add:

** find the packages that have the TPC higher than what is declared in the
pom (because we don't always update the TPC value declared in the pom when
we refactor the code or when we add new tests)


> * Save a report in the directory for the Clover report at
> http://ci.xwiki.org/view/Tools/job/Clover/
> * For all failures, send an email to notificati...@xwiki.org with details
> and a link to the saved report
> * Ideally, and if we can do it, call the github API to find the authors of
> commits for those packages and add them in the report. Examples of APIs we
> could use:
> ** https://api.github.com/repos/xwiki/xwiki-platform/commits?
> since=2018-05-07T00:00:00Z=2018-05-10T00:00:00Z (there’s a path
> parameter that could be used to filter but I don’t think it’ll work
> ** https://github.com/xwiki/xwiki-platform/compare/master@
> %7B2018-05-07%7D...master@%7B2018-05-10%7D (the committers/authors need
> to be extracted from the HTML which is a bit fragile)
> * Add a step in the Release process to ensure that the global TPC has not
> been lowered. This would be a way to ensure we pay attention to that and
> fix it when we lower it. We would need to tune this to find something that
> helps keep the TPC increasing while not putting too much pressure at the
> same time on the release date. It doesn’t have to be in the release process
> but we need some checkpoint to make sure we look at it and that all devs
> fix the tests when they lower the global TPC, or at the very least that an
> analysis is done in case where it’s hard to keep the TPC (for example,
> removing existing code that had a lot of tests will lower the TPC ;)).
>
> WDYT?
>
> As a dev, would you be willing to pay attention to not lower the global
> TPC and work to fix it when it happens?
>
> Thanks
> -Vincent
>
>

Re: [xwiki-devs] [Proposal] New extension point: content header

[Ecaterina Moraru (Valica)]

Issue fixed in https://jira.xwiki.org/browse/XWIKI-15252 and will be
available starting with 10.4-rc-1.
Documentation at
http://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/ExtensionPoint/AfterContentHeaderUIX

Thanks Stéphane,
Caty

On Mon, May 14, 2018 at 12:09 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> +1
>
> Thanks,
> Marius
>
> On Wed, May 9, 2018 at 5:16 PM, Stéphane Laurière <
> stephane.lauri...@xwiki.com> wrote:
>
> > Hi all,
> >
> > I'd like to propose a new UI extension point: content header (or before
> > content). My current motivation for it relates to the page-relations
> > application that will display the pages related to the current one: it
> can
> > be handy to have the relations displayed in the content header for
> > navigation purpose (even though other areas in the UI would make sense,
> > such as a dedicated navigation panel). Other usages I have in mind:
> display
> > content licensing information, content warning, display that the page is
> > currently not editable as the wiki is read only, let the user choose
> > between displaying tags before or after content... Note that Caty already
> > proposed an extension point for the customizing the content footer:
> > http://jira.xwiki.org/browse/XWIKI-13081
> >
> > I created the following issue: https://jira.xwiki.org/browse/XWIKI-15252
> >
> > What do you think?
> >
> > Cheers
> >
> > Stéphane
> >
> >
> > --
> > Stéphane Laurière
> > XWiki www.xwiki.com
> > @slauriere
> >
> >
> >
>

Re: [xwiki-devs] [Proposal] New extension point: content header

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Wed, May 9, 2018 at 5:16 PM, Stéphane Laurière <
stephane.lauri...@xwiki.com> wrote:

> Hi all,
>
> I'd like to propose a new UI extension point: content header (or before
> content). My current motivation for it relates to the page-relations
> application that will display the pages related to the current one: it can
> be handy to have the relations displayed in the content header for
> navigation purpose (even though other areas in the UI would make sense,
> such as a dedicated navigation panel). Other usages I have in mind: display
> content licensing information, content warning, display that the page is
> currently not editable as the wiki is read only, let the user choose
> between displaying tags before or after content... Note that Caty already
> proposed an extension point for the customizing the content footer:
> http://jira.xwiki.org/browse/XWIKI-13081
>
> I created the following issue: https://jira.xwiki.org/browse/XWIKI-15252
>
> What do you think?
>
> Cheers
>
> Stéphane
>
>
> --
> Stéphane Laurière
> XWiki www.xwiki.com
> @slauriere
>
>
>

Re: [xwiki-devs] Fwd: Get started with XWiki

[Vincent Massol]

FYI we dropped the installer because it was a pain to maintain and causing too 
much trouble (FTR izpack allowed to bundled the JRE too).

I’m not sure a this stage we should go back to that.

Here’s an idea:
* Merge Try and Download on xwiki.org into a single entry point
* Have a wizard in that entry point and ask some questions to the user (with 
the option to skip the wizard) to direct the user to use the right distribution 
for him/her.
* Thus, promote more the cloud option for users who are not technical and want 
a quick way to test xwiki.

It wouldn’t solve everything for sure but maybe it would help?

Thanks
-Vincent

> On 14 May 2018, at 11:32, Eduard Moraru  wrote:
> 
> There seem to be some resources on the topic:
> 
> https://github.com/libgdx/libgdx/wiki/Bundling-a-JRE
> https://stackoverflow.com/questions/7071133/how-to-bundle-a-jre-with-launch4j
> https://codeiseasy.wordpress.com/2012/07/31/including-a-jre-in-a-tycho-build/
> 
> ...so it's not such an uncommon practice.
> 
> On the legal side, OpenJDK should be the obvious choice:
> https://opensource.stackexchange.com/questions/4824/is-it-legal-to-bundle-oracles-jre-with-an-open-source-program/4826
> 
> IMO, it would make sense to provide the full and ready to test package,
> rather than an only 90% ready to test one.
> 
> Thanks,
> Eduard
> 
> On Mon, May 14, 2018 at 12:04 PM, Thomas Mortagne > wrote:
> 
>> On Mon, May 14, 2018 at 10:49 AM, Eduard Moraru 
>> wrote:
>>> AFAIR, Eclipse also does this (i.e. bundle their own JRE), we could look
>>> into how they do it.
>> 
>> Eclipse JDT comes with its own Java compiler but you are supposed to
>> install Java to run Eclipse itself.
>> 
>>> 
>>> On a quick check, OpenJDK's JRE is only 38.4 MB (
>>> http://jdk.java.net/java-se-ri/8) ... I find that acceptable.
>> 
>> Not sure the license allow us to embbed what's on that page.
>> 
>> 38.4MB is probably only for one system, I think you need 3 of those
>> (Linux, Windows, Mac)
>> 
>>> 
>>> FTR, the JDK is 164 MB.
>>> 
>>> Thanks,
>>> Eduard
>>> 
>>> On Mon, May 14, 2018 at 11:40 AM, Thomas Mortagne <
>> thomas.morta...@xwiki.com
 wrote:
>>> 
 One issue with embedded Java (OpenJDK I guess) is that it would make
 the zip quite huge.
 
 On Mon, May 14, 2018 at 10:30 AM, Eduard Moraru 
 wrote:
> Hi,
> 
> On the palliative side (i.e. not actually fixing, but at least making
 life
> a bit easier), we might consider a naming scheme for the downloadable
 that
> includes that supported java version, e.g. xwiki-10.3-java8.zip
>> (though
> this might also lead users to thinking that the java 8 runtime is
> included... which might not be that bad of an idea, if we think about
 it...
> at least for the zip version that is for demo purposes, which already
> contains the web server, the database, but still expects the user to
> understand and install the correct Java runtime, which makes no
>> sense.)
> 
> So, yeah... TL;DR: add the java8 runtime to the .zip package and make
 life
> easier for everyone. Optionally (though not sure if needed anymore,
>> if we
> bundle it), include it in the .zip file name.
> 
> Of course, the production install, if done manually (i.e. not through
> .deb/.rpm packages), expects that the user reads the documentation.
> 
> Thanks,
> Eduard
> 
> On Mon, May 14, 2018 at 10:19 AM, Vincent Massol 
 wrote:
> 
>> Hi devs, here’s a feedback we received, FYI.
>> 
>> Ideas?
>> 
>> Thanks
>> -Vincent
>> 
>>> Begin forwarded message:
>>> 
>>> From: Vincent Massol
>>> Subject: Re: Get started with XWiki
>>> Date: 14 May 2018 at 09:10:06 CEST
>>> To: XXX
>>> Cc: XXX
>>> 
>>> Hi Christian,
>>> 
 On 12 May 2018, at 14:25, Christian XXX wrote:
 
 It's not working.
 
 And as usual ith java, the log does not help. Maybe if I were an
>> expert? But an app is supposed to be installed by just 'smart' users,
 not
>> experts.
>>> 
>>> If you choose the easy installation methods we propose then it’s
>> easy
>> and you have nothing to do.
>>> 
>>> Which distribution did you choose and use?
>>> 
 And there is no help from the website.
 
 Oracle Linux 7.
 Linux localhost.localdomain 4.1.12-124.14.5.el7uek.x86_64 #2 SMP
>> Fri
>> May 4 15:26:53 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
 Java 10
 Xwiki 10.3
 tomcat.
 
 If it is not compatible whith this java. It should not install.
>>> 
>>> It’s just not been tested with Java 10 yet. It’s not even fully
 working
>> with Java 9.
>>> 
>>> Note that it’s hard to check for the java version for all the
>> distributions since 

Re: [xwiki-devs] Fwd: Get started with XWiki

[Eduard Moraru]

There seem to be some resources on the topic:

https://github.com/libgdx/libgdx/wiki/Bundling-a-JRE
https://stackoverflow.com/questions/7071133/how-to-bundle-a-jre-with-launch4j
https://codeiseasy.wordpress.com/2012/07/31/including-a-jre-in-a-tycho-build/

...so it's not such an uncommon practice.

On the legal side, OpenJDK should be the obvious choice:
https://opensource.stackexchange.com/questions/4824/is-it-legal-to-bundle-oracles-jre-with-an-open-source-program/4826

IMO, it would make sense to provide the full and ready to test package,
rather than an only 90% ready to test one.

Thanks,
Eduard

On Mon, May 14, 2018 at 12:04 PM, Thomas Mortagne  wrote:

> On Mon, May 14, 2018 at 10:49 AM, Eduard Moraru 
> wrote:
> > AFAIR, Eclipse also does this (i.e. bundle their own JRE), we could look
> > into how they do it.
>
> Eclipse JDT comes with its own Java compiler but you are supposed to
> install Java to run Eclipse itself.
>
> >
> > On a quick check, OpenJDK's JRE is only 38.4 MB (
> > http://jdk.java.net/java-se-ri/8) ... I find that acceptable.
>
> Not sure the license allow us to embbed what's on that page.
>
> 38.4MB is probably only for one system, I think you need 3 of those
> (Linux, Windows, Mac)
>
> >
> > FTR, the JDK is 164 MB.
> >
> > Thanks,
> > Eduard
> >
> > On Mon, May 14, 2018 at 11:40 AM, Thomas Mortagne <
> thomas.morta...@xwiki.com
> >> wrote:
> >
> >> One issue with embedded Java (OpenJDK I guess) is that it would make
> >> the zip quite huge.
> >>
> >> On Mon, May 14, 2018 at 10:30 AM, Eduard Moraru 
> >> wrote:
> >> > Hi,
> >> >
> >> > On the palliative side (i.e. not actually fixing, but at least making
> >> life
> >> > a bit easier), we might consider a naming scheme for the downloadable
> >> that
> >> > includes that supported java version, e.g. xwiki-10.3-java8.zip
> (though
> >> > this might also lead users to thinking that the java 8 runtime is
> >> > included... which might not be that bad of an idea, if we think about
> >> it...
> >> > at least for the zip version that is for demo purposes, which already
> >> > contains the web server, the database, but still expects the user to
> >> > understand and install the correct Java runtime, which makes no
> sense.)
> >> >
> >> > So, yeah... TL;DR: add the java8 runtime to the .zip package and make
> >> life
> >> > easier for everyone. Optionally (though not sure if needed anymore,
> if we
> >> > bundle it), include it in the .zip file name.
> >> >
> >> > Of course, the production install, if done manually (i.e. not through
> >> > .deb/.rpm packages), expects that the user reads the documentation.
> >> >
> >> > Thanks,
> >> > Eduard
> >> >
> >> > On Mon, May 14, 2018 at 10:19 AM, Vincent Massol 
> >> wrote:
> >> >
> >> >> Hi devs, here’s a feedback we received, FYI.
> >> >>
> >> >> Ideas?
> >> >>
> >> >> Thanks
> >> >> -Vincent
> >> >>
> >> >> > Begin forwarded message:
> >> >> >
> >> >> > From: Vincent Massol
> >> >> > Subject: Re: Get started with XWiki
> >> >> > Date: 14 May 2018 at 09:10:06 CEST
> >> >> > To: XXX
> >> >> > Cc: XXX
> >> >> >
> >> >> > Hi Christian,
> >> >> >
> >> >> >> On 12 May 2018, at 14:25, Christian XXX wrote:
> >> >> >>
> >> >> >> It's not working.
> >> >> >>
> >> >> >> And as usual ith java, the log does not help. Maybe if I were an
> >> >> expert? But an app is supposed to be installed by just 'smart' users,
> >> not
> >> >> experts.
> >> >> >
> >> >> > If you choose the easy installation methods we propose then it’s
> easy
> >> >> and you have nothing to do.
> >> >> >
> >> >> > Which distribution did you choose and use?
> >> >> >
> >> >> >> And there is no help from the website.
> >> >> >>
> >> >> >> Oracle Linux 7.
> >> >> >> Linux localhost.localdomain 4.1.12-124.14.5.el7uek.x86_64 #2 SMP
> Fri
> >> >> May 4 15:26:53 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
> >> >> >> Java 10
> >> >> >> Xwiki 10.3
> >> >> >> tomcat.
> >> >> >>
> >> >> >> If it is not compatible whith this java. It should not install.
> >> >> >
> >> >> > It’s just not been tested with Java 10 yet. It’s not even fully
> >> working
> >> >> with Java 9.
> >> >> >
> >> >> > Note that it’s hard to check for the java version for all the
> >> >> distributions since XWiki is a webapp and the XWiki WAR can just be
> >> dropped
> >> >> in a servlet container and thus we don’t have a startup script and a
> >> place
> >> >> where we can put a check. All we could do is have a Servlet Listener
> >> that
> >> >> would emit a big stack trace (like the one you got) and that would
> say
> >> at
> >> >> the innermost level that XWiki requires Java <= 8. But even that
> >> wouldn’t
> >> >> be good since it would prevent testing in Java 9+. We want feedback
> from
> >> >> users about what works/what doesn’t work so improve support for Java
> 9
> >> and
> >> >> 10.
> >> >> >
> >> >> >> If it is compatible with only one version of java, which one?
> >> >> >
> >> >> > 

Re: [xwiki-devs] Fwd: Get started with XWiki

[Thomas Mortagne]

On Mon, May 14, 2018 at 10:49 AM, Eduard Moraru  wrote:
> AFAIR, Eclipse also does this (i.e. bundle their own JRE), we could look
> into how they do it.

Eclipse JDT comes with its own Java compiler but you are supposed to
install Java to run Eclipse itself.

>
> On a quick check, OpenJDK's JRE is only 38.4 MB (
> http://jdk.java.net/java-se-ri/8) ... I find that acceptable.

Not sure the license allow us to embbed what's on that page.

38.4MB is probably only for one system, I think you need 3 of those
(Linux, Windows, Mac)

>
> FTR, the JDK is 164 MB.
>
> Thanks,
> Eduard
>
> On Mon, May 14, 2018 at 11:40 AM, Thomas Mortagne > wrote:
>
>> One issue with embedded Java (OpenJDK I guess) is that it would make
>> the zip quite huge.
>>
>> On Mon, May 14, 2018 at 10:30 AM, Eduard Moraru 
>> wrote:
>> > Hi,
>> >
>> > On the palliative side (i.e. not actually fixing, but at least making
>> life
>> > a bit easier), we might consider a naming scheme for the downloadable
>> that
>> > includes that supported java version, e.g. xwiki-10.3-java8.zip (though
>> > this might also lead users to thinking that the java 8 runtime is
>> > included... which might not be that bad of an idea, if we think about
>> it...
>> > at least for the zip version that is for demo purposes, which already
>> > contains the web server, the database, but still expects the user to
>> > understand and install the correct Java runtime, which makes no sense.)
>> >
>> > So, yeah... TL;DR: add the java8 runtime to the .zip package and make
>> life
>> > easier for everyone. Optionally (though not sure if needed anymore, if we
>> > bundle it), include it in the .zip file name.
>> >
>> > Of course, the production install, if done manually (i.e. not through
>> > .deb/.rpm packages), expects that the user reads the documentation.
>> >
>> > Thanks,
>> > Eduard
>> >
>> > On Mon, May 14, 2018 at 10:19 AM, Vincent Massol 
>> wrote:
>> >
>> >> Hi devs, here’s a feedback we received, FYI.
>> >>
>> >> Ideas?
>> >>
>> >> Thanks
>> >> -Vincent
>> >>
>> >> > Begin forwarded message:
>> >> >
>> >> > From: Vincent Massol
>> >> > Subject: Re: Get started with XWiki
>> >> > Date: 14 May 2018 at 09:10:06 CEST
>> >> > To: XXX
>> >> > Cc: XXX
>> >> >
>> >> > Hi Christian,
>> >> >
>> >> >> On 12 May 2018, at 14:25, Christian XXX wrote:
>> >> >>
>> >> >> It's not working.
>> >> >>
>> >> >> And as usual ith java, the log does not help. Maybe if I were an
>> >> expert? But an app is supposed to be installed by just 'smart' users,
>> not
>> >> experts.
>> >> >
>> >> > If you choose the easy installation methods we propose then it’s easy
>> >> and you have nothing to do.
>> >> >
>> >> > Which distribution did you choose and use?
>> >> >
>> >> >> And there is no help from the website.
>> >> >>
>> >> >> Oracle Linux 7.
>> >> >> Linux localhost.localdomain 4.1.12-124.14.5.el7uek.x86_64 #2 SMP Fri
>> >> May 4 15:26:53 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
>> >> >> Java 10
>> >> >> Xwiki 10.3
>> >> >> tomcat.
>> >> >>
>> >> >> If it is not compatible whith this java. It should not install.
>> >> >
>> >> > It’s just not been tested with Java 10 yet. It’s not even fully
>> working
>> >> with Java 9.
>> >> >
>> >> > Note that it’s hard to check for the java version for all the
>> >> distributions since XWiki is a webapp and the XWiki WAR can just be
>> dropped
>> >> in a servlet container and thus we don’t have a startup script and a
>> place
>> >> where we can put a check. All we could do is have a Servlet Listener
>> that
>> >> would emit a big stack trace (like the one you got) and that would say
>> at
>> >> the innermost level that XWiki requires Java <= 8. But even that
>> wouldn’t
>> >> be good since it would prevent testing in Java 9+. We want feedback from
>> >> users about what works/what doesn’t work so improve support for Java 9
>> and
>> >> 10.
>> >> >
>> >> >> If it is compatible with only one version of java, which one?
>> >> >
>> >> > You need to read the installation page ;)
>> >> >
>> >> > See http://www.xwiki.org/xwiki/bin/view/Documentation/
>> >> AdminGuide/Installation/ and especially:
>> >> > http://www.xwiki.org/xwiki/bin/view/Documentation/
>> >> AdminGuide/Installation/#HHardwareandSoftwarerequirements
>> >> >
>> >> >> Here is the error:
>> >> >>
>> >> >>
>> >> >> Error number 4001 in 4: Error while evaluating velocity template
>> >> colorThemeInit.vm
>> >> >> Error number 4001 in 4: Error while evaluating velocity template
>> >> colorThemeInit.vm
>> >> >> com.xpn.xwiki.XWikiException: Error number 4001 in 4: Error while
>> >> evaluating velocity template colorThemeInit.vm
>> >> >
>> >> > [snip]
>> >> >
>> >> >> Caused by: java.lang.IllegalStateException: No standard field found
>> >> for reverse order comparator!
>> >> >>  at org.jboss.marshalling.river.Protocol.(Protocol.
>> >> java:276)
>> >> >>  ... 249 mor
>> >> >
>> >> > [snip
>> >> >
>> >> >> Caused 

Re: [xwiki-devs] Fwd: Get started with XWiki

[Eduard Moraru]

Correction to the correction: They are OpenJDK, got confused by the Oracle
logo. :)

On Mon, May 14, 2018 at 11:51 AM, Eduard Moraru 
wrote:

> Correction, the above are Oracle builds, not OpenJDK :)
>
> On Mon, May 14, 2018 at 11:49 AM, Eduard Moraru 
> wrote:
>
>> AFAIR, Eclipse also does this (i.e. bundle their own JRE), we could look
>> into how they do it.
>>
>> On a quick check, OpenJDK's JRE is only 38.4 MB (
>> http://jdk.java.net/java-se-ri/8) ... I find that acceptable.
>>
>> FTR, the JDK is 164 MB.
>>
>> Thanks,
>> Eduard
>>
>> On Mon, May 14, 2018 at 11:40 AM, Thomas Mortagne <
>> thomas.morta...@xwiki.com> wrote:
>>
>>> One issue with embedded Java (OpenJDK I guess) is that it would make
>>> the zip quite huge.
>>>
>>> On Mon, May 14, 2018 at 10:30 AM, Eduard Moraru 
>>> wrote:
>>> > Hi,
>>> >
>>> > On the palliative side (i.e. not actually fixing, but at least making
>>> life
>>> > a bit easier), we might consider a naming scheme for the downloadable
>>> that
>>> > includes that supported java version, e.g. xwiki-10.3-java8.zip (though
>>> > this might also lead users to thinking that the java 8 runtime is
>>> > included... which might not be that bad of an idea, if we think about
>>> it...
>>> > at least for the zip version that is for demo purposes, which already
>>> > contains the web server, the database, but still expects the user to
>>> > understand and install the correct Java runtime, which makes no sense.)
>>> >
>>> > So, yeah... TL;DR: add the java8 runtime to the .zip package and make
>>> life
>>> > easier for everyone. Optionally (though not sure if needed anymore, if
>>> we
>>> > bundle it), include it in the .zip file name.
>>> >
>>> > Of course, the production install, if done manually (i.e. not through
>>> > .deb/.rpm packages), expects that the user reads the documentation.
>>> >
>>> > Thanks,
>>> > Eduard
>>> >
>>> > On Mon, May 14, 2018 at 10:19 AM, Vincent Massol 
>>> wrote:
>>> >
>>> >> Hi devs, here’s a feedback we received, FYI.
>>> >>
>>> >> Ideas?
>>> >>
>>> >> Thanks
>>> >> -Vincent
>>> >>
>>> >> > Begin forwarded message:
>>> >> >
>>> >> > From: Vincent Massol
>>> >> > Subject: Re: Get started with XWiki
>>> >> > Date: 14 May 2018 at 09:10:06 CEST
>>> >> > To: XXX
>>> >> > Cc: XXX
>>> >> >
>>> >> > Hi Christian,
>>> >> >
>>> >> >> On 12 May 2018, at 14:25, Christian XXX wrote:
>>> >> >>
>>> >> >> It's not working.
>>> >> >>
>>> >> >> And as usual ith java, the log does not help. Maybe if I were an
>>> >> expert? But an app is supposed to be installed by just 'smart' users,
>>> not
>>> >> experts.
>>> >> >
>>> >> > If you choose the easy installation methods we propose then it’s
>>> easy
>>> >> and you have nothing to do.
>>> >> >
>>> >> > Which distribution did you choose and use?
>>> >> >
>>> >> >> And there is no help from the website.
>>> >> >>
>>> >> >> Oracle Linux 7.
>>> >> >> Linux localhost.localdomain 4.1.12-124.14.5.el7uek.x86_64 #2 SMP
>>> Fri
>>> >> May 4 15:26:53 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
>>> >> >> Java 10
>>> >> >> Xwiki 10.3
>>> >> >> tomcat.
>>> >> >>
>>> >> >> If it is not compatible whith this java. It should not install.
>>> >> >
>>> >> > It’s just not been tested with Java 10 yet. It’s not even fully
>>> working
>>> >> with Java 9.
>>> >> >
>>> >> > Note that it’s hard to check for the java version for all the
>>> >> distributions since XWiki is a webapp and the XWiki WAR can just be
>>> dropped
>>> >> in a servlet container and thus we don’t have a startup script and a
>>> place
>>> >> where we can put a check. All we could do is have a Servlet Listener
>>> that
>>> >> would emit a big stack trace (like the one you got) and that would
>>> say at
>>> >> the innermost level that XWiki requires Java <= 8. But even that
>>> wouldn’t
>>> >> be good since it would prevent testing in Java 9+. We want feedback
>>> from
>>> >> users about what works/what doesn’t work so improve support for Java
>>> 9 and
>>> >> 10.
>>> >> >
>>> >> >> If it is compatible with only one version of java, which one?
>>> >> >
>>> >> > You need to read the installation page ;)
>>> >> >
>>> >> > See http://www.xwiki.org/xwiki/bin/view/Documentation/
>>> >> AdminGuide/Installation/ and especially:
>>> >> > http://www.xwiki.org/xwiki/bin/view/Documentation/
>>> >> AdminGuide/Installation/#HHardwareandSoftwarerequirements
>>> >> >
>>> >> >> Here is the error:
>>> >> >>
>>> >> >>
>>> >> >> Error number 4001 in 4: Error while evaluating velocity template
>>> >> colorThemeInit.vm
>>> >> >> Error number 4001 in 4: Error while evaluating velocity template
>>> >> colorThemeInit.vm
>>> >> >> com.xpn.xwiki.XWikiException: Error number 4001 in 4: Error while
>>> >> evaluating velocity template colorThemeInit.vm
>>> >> >
>>> >> > [snip]
>>> >> >
>>> >> >> Caused by: java.lang.IllegalStateException: No standard field
>>> found
>>> >> for reverse order comparator!
>>> >> >>  at 

Re: [xwiki-devs] Fwd: Get started with XWiki

[Eduard Moraru]

Correction, the above are Oracle builds, not OpenJDK :)

On Mon, May 14, 2018 at 11:49 AM, Eduard Moraru 
wrote:

> AFAIR, Eclipse also does this (i.e. bundle their own JRE), we could look
> into how they do it.
>
> On a quick check, OpenJDK's JRE is only 38.4 MB (
> http://jdk.java.net/java-se-ri/8) ... I find that acceptable.
>
> FTR, the JDK is 164 MB.
>
> Thanks,
> Eduard
>
> On Mon, May 14, 2018 at 11:40 AM, Thomas Mortagne <
> thomas.morta...@xwiki.com> wrote:
>
>> One issue with embedded Java (OpenJDK I guess) is that it would make
>> the zip quite huge.
>>
>> On Mon, May 14, 2018 at 10:30 AM, Eduard Moraru 
>> wrote:
>> > Hi,
>> >
>> > On the palliative side (i.e. not actually fixing, but at least making
>> life
>> > a bit easier), we might consider a naming scheme for the downloadable
>> that
>> > includes that supported java version, e.g. xwiki-10.3-java8.zip (though
>> > this might also lead users to thinking that the java 8 runtime is
>> > included... which might not be that bad of an idea, if we think about
>> it...
>> > at least for the zip version that is for demo purposes, which already
>> > contains the web server, the database, but still expects the user to
>> > understand and install the correct Java runtime, which makes no sense.)
>> >
>> > So, yeah... TL;DR: add the java8 runtime to the .zip package and make
>> life
>> > easier for everyone. Optionally (though not sure if needed anymore, if
>> we
>> > bundle it), include it in the .zip file name.
>> >
>> > Of course, the production install, if done manually (i.e. not through
>> > .deb/.rpm packages), expects that the user reads the documentation.
>> >
>> > Thanks,
>> > Eduard
>> >
>> > On Mon, May 14, 2018 at 10:19 AM, Vincent Massol 
>> wrote:
>> >
>> >> Hi devs, here’s a feedback we received, FYI.
>> >>
>> >> Ideas?
>> >>
>> >> Thanks
>> >> -Vincent
>> >>
>> >> > Begin forwarded message:
>> >> >
>> >> > From: Vincent Massol
>> >> > Subject: Re: Get started with XWiki
>> >> > Date: 14 May 2018 at 09:10:06 CEST
>> >> > To: XXX
>> >> > Cc: XXX
>> >> >
>> >> > Hi Christian,
>> >> >
>> >> >> On 12 May 2018, at 14:25, Christian XXX wrote:
>> >> >>
>> >> >> It's not working.
>> >> >>
>> >> >> And as usual ith java, the log does not help. Maybe if I were an
>> >> expert? But an app is supposed to be installed by just 'smart' users,
>> not
>> >> experts.
>> >> >
>> >> > If you choose the easy installation methods we propose then it’s easy
>> >> and you have nothing to do.
>> >> >
>> >> > Which distribution did you choose and use?
>> >> >
>> >> >> And there is no help from the website.
>> >> >>
>> >> >> Oracle Linux 7.
>> >> >> Linux localhost.localdomain 4.1.12-124.14.5.el7uek.x86_64 #2 SMP Fri
>> >> May 4 15:26:53 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
>> >> >> Java 10
>> >> >> Xwiki 10.3
>> >> >> tomcat.
>> >> >>
>> >> >> If it is not compatible whith this java. It should not install.
>> >> >
>> >> > It’s just not been tested with Java 10 yet. It’s not even fully
>> working
>> >> with Java 9.
>> >> >
>> >> > Note that it’s hard to check for the java version for all the
>> >> distributions since XWiki is a webapp and the XWiki WAR can just be
>> dropped
>> >> in a servlet container and thus we don’t have a startup script and a
>> place
>> >> where we can put a check. All we could do is have a Servlet Listener
>> that
>> >> would emit a big stack trace (like the one you got) and that would say
>> at
>> >> the innermost level that XWiki requires Java <= 8. But even that
>> wouldn’t
>> >> be good since it would prevent testing in Java 9+. We want feedback
>> from
>> >> users about what works/what doesn’t work so improve support for Java 9
>> and
>> >> 10.
>> >> >
>> >> >> If it is compatible with only one version of java, which one?
>> >> >
>> >> > You need to read the installation page ;)
>> >> >
>> >> > See http://www.xwiki.org/xwiki/bin/view/Documentation/
>> >> AdminGuide/Installation/ and especially:
>> >> > http://www.xwiki.org/xwiki/bin/view/Documentation/
>> >> AdminGuide/Installation/#HHardwareandSoftwarerequirements
>> >> >
>> >> >> Here is the error:
>> >> >>
>> >> >>
>> >> >> Error number 4001 in 4: Error while evaluating velocity template
>> >> colorThemeInit.vm
>> >> >> Error number 4001 in 4: Error while evaluating velocity template
>> >> colorThemeInit.vm
>> >> >> com.xpn.xwiki.XWikiException: Error number 4001 in 4: Error while
>> >> evaluating velocity template colorThemeInit.vm
>> >> >
>> >> > [snip]
>> >> >
>> >> >> Caused by: java.lang.IllegalStateException: No standard field found
>> >> for reverse order comparator!
>> >> >>  at org.jboss.marshalling.river.Protocol.(Protocol.
>> >> java:276)
>> >> >>  ... 249 mor
>> >> >
>> >> > [snip
>> >> >
>> >> >> Caused by: java.lang.IllegalStateException: No standard field found
>> >> for reverse order comparator!
>> >> >>  at org.jboss.marshalling.river.Protocol.(Protocol.
>> >> java:276)
>> >> >>  ... 

Re: [xwiki-devs] Fwd: Get started with XWiki

[Eduard Moraru]

AFAIR, Eclipse also does this (i.e. bundle their own JRE), we could look
into how they do it.

On a quick check, OpenJDK's JRE is only 38.4 MB (
http://jdk.java.net/java-se-ri/8) ... I find that acceptable.

FTR, the JDK is 164 MB.

Thanks,
Eduard

On Mon, May 14, 2018 at 11:40 AM, Thomas Mortagne  wrote:

> One issue with embedded Java (OpenJDK I guess) is that it would make
> the zip quite huge.
>
> On Mon, May 14, 2018 at 10:30 AM, Eduard Moraru 
> wrote:
> > Hi,
> >
> > On the palliative side (i.e. not actually fixing, but at least making
> life
> > a bit easier), we might consider a naming scheme for the downloadable
> that
> > includes that supported java version, e.g. xwiki-10.3-java8.zip (though
> > this might also lead users to thinking that the java 8 runtime is
> > included... which might not be that bad of an idea, if we think about
> it...
> > at least for the zip version that is for demo purposes, which already
> > contains the web server, the database, but still expects the user to
> > understand and install the correct Java runtime, which makes no sense.)
> >
> > So, yeah... TL;DR: add the java8 runtime to the .zip package and make
> life
> > easier for everyone. Optionally (though not sure if needed anymore, if we
> > bundle it), include it in the .zip file name.
> >
> > Of course, the production install, if done manually (i.e. not through
> > .deb/.rpm packages), expects that the user reads the documentation.
> >
> > Thanks,
> > Eduard
> >
> > On Mon, May 14, 2018 at 10:19 AM, Vincent Massol 
> wrote:
> >
> >> Hi devs, here’s a feedback we received, FYI.
> >>
> >> Ideas?
> >>
> >> Thanks
> >> -Vincent
> >>
> >> > Begin forwarded message:
> >> >
> >> > From: Vincent Massol
> >> > Subject: Re: Get started with XWiki
> >> > Date: 14 May 2018 at 09:10:06 CEST
> >> > To: XXX
> >> > Cc: XXX
> >> >
> >> > Hi Christian,
> >> >
> >> >> On 12 May 2018, at 14:25, Christian XXX wrote:
> >> >>
> >> >> It's not working.
> >> >>
> >> >> And as usual ith java, the log does not help. Maybe if I were an
> >> expert? But an app is supposed to be installed by just 'smart' users,
> not
> >> experts.
> >> >
> >> > If you choose the easy installation methods we propose then it’s easy
> >> and you have nothing to do.
> >> >
> >> > Which distribution did you choose and use?
> >> >
> >> >> And there is no help from the website.
> >> >>
> >> >> Oracle Linux 7.
> >> >> Linux localhost.localdomain 4.1.12-124.14.5.el7uek.x86_64 #2 SMP Fri
> >> May 4 15:26:53 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
> >> >> Java 10
> >> >> Xwiki 10.3
> >> >> tomcat.
> >> >>
> >> >> If it is not compatible whith this java. It should not install.
> >> >
> >> > It’s just not been tested with Java 10 yet. It’s not even fully
> working
> >> with Java 9.
> >> >
> >> > Note that it’s hard to check for the java version for all the
> >> distributions since XWiki is a webapp and the XWiki WAR can just be
> dropped
> >> in a servlet container and thus we don’t have a startup script and a
> place
> >> where we can put a check. All we could do is have a Servlet Listener
> that
> >> would emit a big stack trace (like the one you got) and that would say
> at
> >> the innermost level that XWiki requires Java <= 8. But even that
> wouldn’t
> >> be good since it would prevent testing in Java 9+. We want feedback from
> >> users about what works/what doesn’t work so improve support for Java 9
> and
> >> 10.
> >> >
> >> >> If it is compatible with only one version of java, which one?
> >> >
> >> > You need to read the installation page ;)
> >> >
> >> > See http://www.xwiki.org/xwiki/bin/view/Documentation/
> >> AdminGuide/Installation/ and especially:
> >> > http://www.xwiki.org/xwiki/bin/view/Documentation/
> >> AdminGuide/Installation/#HHardwareandSoftwarerequirements
> >> >
> >> >> Here is the error:
> >> >>
> >> >>
> >> >> Error number 4001 in 4: Error while evaluating velocity template
> >> colorThemeInit.vm
> >> >> Error number 4001 in 4: Error while evaluating velocity template
> >> colorThemeInit.vm
> >> >> com.xpn.xwiki.XWikiException: Error number 4001 in 4: Error while
> >> evaluating velocity template colorThemeInit.vm
> >> >
> >> > [snip]
> >> >
> >> >> Caused by: java.lang.IllegalStateException: No standard field found
> >> for reverse order comparator!
> >> >>  at org.jboss.marshalling.river.Protocol.(Protocol.
> >> java:276)
> >> >>  ... 249 mor
> >> >
> >> > [snip
> >> >
> >> >> Caused by: java.lang.IllegalStateException: No standard field found
> >> for reverse order comparator!
> >> >>  at org.jboss.marshalling.river.Protocol.(Protocol.
> >> java:276)
> >> >>  ... 249 mor
> >> >
> >> > What this says is that JBoss Infinispan (which we use) is not
> compatible
> >> with Java 10. Apparently this is fixed in recent version of JBoss
> >> Marshalling: https://issues.jboss.org/browse/JBMAR-216. We probably
> just
> >> need to wait for JBoss Infinispan to 

Re: [xwiki-devs] Fwd: Get started with XWiki

[Thomas Mortagne]

One issue with embedded Java (OpenJDK I guess) is that it would make
the zip quite huge.

On Mon, May 14, 2018 at 10:30 AM, Eduard Moraru  wrote:
> Hi,
>
> On the palliative side (i.e. not actually fixing, but at least making life
> a bit easier), we might consider a naming scheme for the downloadable that
> includes that supported java version, e.g. xwiki-10.3-java8.zip (though
> this might also lead users to thinking that the java 8 runtime is
> included... which might not be that bad of an idea, if we think about it...
> at least for the zip version that is for demo purposes, which already
> contains the web server, the database, but still expects the user to
> understand and install the correct Java runtime, which makes no sense.)
>
> So, yeah... TL;DR: add the java8 runtime to the .zip package and make life
> easier for everyone. Optionally (though not sure if needed anymore, if we
> bundle it), include it in the .zip file name.
>
> Of course, the production install, if done manually (i.e. not through
> .deb/.rpm packages), expects that the user reads the documentation.
>
> Thanks,
> Eduard
>
> On Mon, May 14, 2018 at 10:19 AM, Vincent Massol  wrote:
>
>> Hi devs, here’s a feedback we received, FYI.
>>
>> Ideas?
>>
>> Thanks
>> -Vincent
>>
>> > Begin forwarded message:
>> >
>> > From: Vincent Massol
>> > Subject: Re: Get started with XWiki
>> > Date: 14 May 2018 at 09:10:06 CEST
>> > To: XXX
>> > Cc: XXX
>> >
>> > Hi Christian,
>> >
>> >> On 12 May 2018, at 14:25, Christian XXX wrote:
>> >>
>> >> It's not working.
>> >>
>> >> And as usual ith java, the log does not help. Maybe if I were an
>> expert? But an app is supposed to be installed by just 'smart' users, not
>> experts.
>> >
>> > If you choose the easy installation methods we propose then it’s easy
>> and you have nothing to do.
>> >
>> > Which distribution did you choose and use?
>> >
>> >> And there is no help from the website.
>> >>
>> >> Oracle Linux 7.
>> >> Linux localhost.localdomain 4.1.12-124.14.5.el7uek.x86_64 #2 SMP Fri
>> May 4 15:26:53 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
>> >> Java 10
>> >> Xwiki 10.3
>> >> tomcat.
>> >>
>> >> If it is not compatible whith this java. It should not install.
>> >
>> > It’s just not been tested with Java 10 yet. It’s not even fully working
>> with Java 9.
>> >
>> > Note that it’s hard to check for the java version for all the
>> distributions since XWiki is a webapp and the XWiki WAR can just be dropped
>> in a servlet container and thus we don’t have a startup script and a place
>> where we can put a check. All we could do is have a Servlet Listener that
>> would emit a big stack trace (like the one you got) and that would say at
>> the innermost level that XWiki requires Java <= 8. But even that wouldn’t
>> be good since it would prevent testing in Java 9+. We want feedback from
>> users about what works/what doesn’t work so improve support for Java 9 and
>> 10.
>> >
>> >> If it is compatible with only one version of java, which one?
>> >
>> > You need to read the installation page ;)
>> >
>> > See http://www.xwiki.org/xwiki/bin/view/Documentation/
>> AdminGuide/Installation/ and especially:
>> > http://www.xwiki.org/xwiki/bin/view/Documentation/
>> AdminGuide/Installation/#HHardwareandSoftwarerequirements
>> >
>> >> Here is the error:
>> >>
>> >>
>> >> Error number 4001 in 4: Error while evaluating velocity template
>> colorThemeInit.vm
>> >> Error number 4001 in 4: Error while evaluating velocity template
>> colorThemeInit.vm
>> >> com.xpn.xwiki.XWikiException: Error number 4001 in 4: Error while
>> evaluating velocity template colorThemeInit.vm
>> >
>> > [snip]
>> >
>> >> Caused by: java.lang.IllegalStateException: No standard field found
>> for reverse order comparator!
>> >>  at org.jboss.marshalling.river.Protocol.(Protocol.
>> java:276)
>> >>  ... 249 mor
>> >
>> > [snip
>> >
>> >> Caused by: java.lang.IllegalStateException: No standard field found
>> for reverse order comparator!
>> >>  at org.jboss.marshalling.river.Protocol.(Protocol.
>> java:276)
>> >>  ... 249 mor
>> >
>> > What this says is that JBoss Infinispan (which we use) is not compatible
>> with Java 10. Apparently this is fixed in recent version of JBoss
>> Marshalling: https://issues.jboss.org/browse/JBMAR-216. We probably just
>> need to wait for JBoss Infinispan to release a new version that uses JBoss
>> Marshalling 2.1.0.Final.
>> >
>> > What would be awesome would be for you to report the problem of using
>> XWiki with Java 10 on https://jira.xwiki.org so that we can have an issue
>> for it and work to make it work.
>> >
>> > Note that I’m replying to this message to help you out but it’s not the
>> right place to post a question and get help normally. For that we have a
>> user forum at https://forum.xwiki.org/.
>> >
>> > I’m sorry you had some issues. OTOH you’re looking for trouble by trying
>> with Java 10. There are very few (if any!) java app that 

Re: [xwiki-devs] Fwd: Get started with XWiki

[Eduard Moraru]

Hi,

On the palliative side (i.e. not actually fixing, but at least making life
a bit easier), we might consider a naming scheme for the downloadable that
includes that supported java version, e.g. xwiki-10.3-java8.zip (though
this might also lead users to thinking that the java 8 runtime is
included... which might not be that bad of an idea, if we think about it...
at least for the zip version that is for demo purposes, which already
contains the web server, the database, but still expects the user to
understand and install the correct Java runtime, which makes no sense.)

So, yeah... TL;DR: add the java8 runtime to the .zip package and make life
easier for everyone. Optionally (though not sure if needed anymore, if we
bundle it), include it in the .zip file name.

Of course, the production install, if done manually (i.e. not through
.deb/.rpm packages), expects that the user reads the documentation.

Thanks,
Eduard

On Mon, May 14, 2018 at 10:19 AM, Vincent Massol  wrote:

> Hi devs, here’s a feedback we received, FYI.
>
> Ideas?
>
> Thanks
> -Vincent
>
> > Begin forwarded message:
> >
> > From: Vincent Massol
> > Subject: Re: Get started with XWiki
> > Date: 14 May 2018 at 09:10:06 CEST
> > To: XXX
> > Cc: XXX
> >
> > Hi Christian,
> >
> >> On 12 May 2018, at 14:25, Christian XXX wrote:
> >>
> >> It's not working.
> >>
> >> And as usual ith java, the log does not help. Maybe if I were an
> expert? But an app is supposed to be installed by just 'smart' users, not
> experts.
> >
> > If you choose the easy installation methods we propose then it’s easy
> and you have nothing to do.
> >
> > Which distribution did you choose and use?
> >
> >> And there is no help from the website.
> >>
> >> Oracle Linux 7.
> >> Linux localhost.localdomain 4.1.12-124.14.5.el7uek.x86_64 #2 SMP Fri
> May 4 15:26:53 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
> >> Java 10
> >> Xwiki 10.3
> >> tomcat.
> >>
> >> If it is not compatible whith this java. It should not install.
> >
> > It’s just not been tested with Java 10 yet. It’s not even fully working
> with Java 9.
> >
> > Note that it’s hard to check for the java version for all the
> distributions since XWiki is a webapp and the XWiki WAR can just be dropped
> in a servlet container and thus we don’t have a startup script and a place
> where we can put a check. All we could do is have a Servlet Listener that
> would emit a big stack trace (like the one you got) and that would say at
> the innermost level that XWiki requires Java <= 8. But even that wouldn’t
> be good since it would prevent testing in Java 9+. We want feedback from
> users about what works/what doesn’t work so improve support for Java 9 and
> 10.
> >
> >> If it is compatible with only one version of java, which one?
> >
> > You need to read the installation page ;)
> >
> > See http://www.xwiki.org/xwiki/bin/view/Documentation/
> AdminGuide/Installation/ and especially:
> > http://www.xwiki.org/xwiki/bin/view/Documentation/
> AdminGuide/Installation/#HHardwareandSoftwarerequirements
> >
> >> Here is the error:
> >>
> >>
> >> Error number 4001 in 4: Error while evaluating velocity template
> colorThemeInit.vm
> >> Error number 4001 in 4: Error while evaluating velocity template
> colorThemeInit.vm
> >> com.xpn.xwiki.XWikiException: Error number 4001 in 4: Error while
> evaluating velocity template colorThemeInit.vm
> >
> > [snip]
> >
> >> Caused by: java.lang.IllegalStateException: No standard field found
> for reverse order comparator!
> >>  at org.jboss.marshalling.river.Protocol.(Protocol.
> java:276)
> >>  ... 249 mor
> >
> > [snip
> >
> >> Caused by: java.lang.IllegalStateException: No standard field found
> for reverse order comparator!
> >>  at org.jboss.marshalling.river.Protocol.(Protocol.
> java:276)
> >>  ... 249 mor
> >
> > What this says is that JBoss Infinispan (which we use) is not compatible
> with Java 10. Apparently this is fixed in recent version of JBoss
> Marshalling: https://issues.jboss.org/browse/JBMAR-216. We probably just
> need to wait for JBoss Infinispan to release a new version that uses JBoss
> Marshalling 2.1.0.Final.
> >
> > What would be awesome would be for you to report the problem of using
> XWiki with Java 10 on https://jira.xwiki.org so that we can have an issue
> for it and work to make it work.
> >
> > Note that I’m replying to this message to help you out but it’s not the
> right place to post a question and get help normally. For that we have a
> user forum at https://forum.xwiki.org/.
> >
> > I’m sorry you had some issues. OTOH you’re looking for trouble by trying
> with Java 10. There are very few (if any!) java app that currently work
> with Java 9 and 10. You’d be much better off using Java 8. On the positive
> side, if you raise the issue on https://jira.xwiki.org, then you will
> transform your negative experience into a positive one, by contributing to
> the development of XWiki and helping out future users.
> >
> > Thanks
> > 

Re: [xwiki-devs] [Brainstorming] What XAR file type for Mail Template pages?

[Eduard Moraru]

Hi,

On Fri, May 11, 2018 at 7:21 PM, Vincent Massol  wrote:

>
>
> > On 11 May 2018, at 14:22, Thomas Mortagne 
> wrote:
> >
> > On Fri, May 11, 2018 at 11:00 AM, Vincent Massol 
> wrote:
> >> Hi Edy,
> >>
> >>> On 8 May 2018, at 12:38, Eduard Moraru  wrote:
> >>>
> >>> Hi,
> >>>
> >>> IMO, it's just like any other page: it depends on the application it is
> >>> part of and we can't treat them all the same.
> >>>
> >>> XWiki.ResetPasswordMailContent should be "default". I see no particular
> >>> reason to customize the reset password email, as it is a standard
> feature
> >>> and it must be synchronized with the code that is calling the template
> >>> (i.e. any variable bindings define a sort of API that the caller uses.
> >>> Changing the content also risks breaking that contract, since the
> caller
> >>> could be updated while a customized version of this template will
> not.).
> >>> The only case I could imagine where the reset password email might be
> >>> customized would be when there exists no translation for a particular
> >>> language and an admin might want to translate it on the fly, however,
> we
> >>> could treat this as a limitation of the current version and improve it
> in
> >>> future versions, just like any other code feature.
> >>
> >> For me anything visual (themes, skins and thus email templates) are
> things that only should be able to be changed but that users will change
> for sure (and we”ve seen changes for all of them in the history of XWiki).
> >
> > "anything visual" contains much more than themes, skins and email
> templates.
> >
> >>
> >> And yes the bindings we allow using in them are “API contracts” that we
> shouldn’t break at all. They’re exactly like scripting APIs.
> >>
> >>> Share by email probably also has an email template which should be
> >>> "default" as well, since the only customization it is designed to
> support
> >>> is the actual message included by the user and that is already separate
> >>> from the template.
> >>>
> >>> Other examples? (Notifications probably has its own mechanism for
> >>> displaying certain notifications or what notifications to send by
> email)
> >>
> >> Sure, it’s even documented:
> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/
> Notifications%20Application/#HCustomizingthenotificationemailtemplate
> >>
> >> Same for watchlist:
> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/
> Watchlist%20Application#HAdministrators:CustomizingtheWatchListemailte
> mplate
> >
> > IMO those documentations don't really make those templates
> > specifically designed to be customized, it's just "if you really need
> > to customize them that's the only way”.
>
> No, they’re meant to be customized and modified.
>

I'm sorry, but I personally don not agree with this point of view at all.

This may be the way the Mail API works, with a template page that is meant
to be customized to be able to make up the content of the email. However,
when an application chooses to use the mail API, it is forced to use the
same mechanism, but that does not also come with the obligation for the
resulting email to be customized by the user, just because it's relatively
easy for the user to do so, through a relatively well known mechanism. IMO,
our target with the "disallow editing" effort is to identify pages that
contain code (including code and content) that are part of an
application/extension and make sure users don't start simply editing them,
for whatever customization reason they or we may come up with. These
particular 2 mail templates do contain a lot of code and are subject to
improvement. The fact that both are document is probably a consequence of
Notifications trying to offer the same level of features/doc as the
previous watchlist feature.

I am still advocating for the copy and customize approach, as we need to
clearly identify what is standard and what is the user's customization and
we need to limit as much as possible the number of automatic merges
(possible point of failure) that are to be done during an upgrade. If we
want to make the Notifications email customizable, we should add a
configuration option of the Notifications feature that allows an admin to
provide a custom email template. IMO, that is the clear and clean solution
that we should strive for.

As an exercise, Try to visualize the likelihood of a customized
Notifications (i.e. still under development) email template surviving for
3-5 years later on, specially if we go it the previously suggested approach
of not overriding or merging at all, because the user customized it.

Thanks,
Eduard


>
> >
> >>
> >> Any template contains UI and as such users will want to change them.
> That’s 100% guaranteed. I’m not saying that they’ll all change them but
> some will. They’ll change the wording, they’ll add some custom logo/banner,
> they’ll make some modifications, adding some links, etc.
> 

[xwiki-devs] Fwd: Get started with XWiki

[Vincent Massol]

Hi devs, here’s a feedback we received, FYI.

Ideas?

Thanks
-Vincent

> Begin forwarded message:
> 
> From: Vincent Massol
> Subject: Re: Get started with XWiki
> Date: 14 May 2018 at 09:10:06 CEST
> To: XXX
> Cc: XXX
> 
> Hi Christian,
> 
>> On 12 May 2018, at 14:25, Christian XXX wrote:
>> 
>> It's not working.
>> 
>> And as usual ith java, the log does not help. Maybe if I were an expert? But 
>> an app is supposed to be installed by just 'smart' users, not experts.
> 
> If you choose the easy installation methods we propose then it’s easy and you 
> have nothing to do.
> 
> Which distribution did you choose and use?
> 
>> And there is no help from the website.
>> 
>> Oracle Linux 7.
>> Linux localhost.localdomain 4.1.12-124.14.5.el7uek.x86_64 #2 SMP Fri May 4 
>> 15:26:53 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
>> Java 10
>> Xwiki 10.3
>> tomcat.
>> 
>> If it is not compatible whith this java. It should not install.
> 
> It’s just not been tested with Java 10 yet. It’s not even fully working with 
> Java 9.
> 
> Note that it’s hard to check for the java version for all the distributions 
> since XWiki is a webapp and the XWiki WAR can just be dropped in a servlet 
> container and thus we don’t have a startup script and a place where we can 
> put a check. All we could do is have a Servlet Listener that would emit a big 
> stack trace (like the one you got) and that would say at the innermost level 
> that XWiki requires Java <= 8. But even that wouldn’t be good since it would 
> prevent testing in Java 9+. We want feedback from users about what works/what 
> doesn’t work so improve support for Java 9 and 10.
> 
>> If it is compatible with only one version of java, which one?
> 
> You need to read the installation page ;)
> 
> See 
> http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/ 
> and especially:
> http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/#HHardwareandSoftwarerequirements
> 
>> Here is the error:
>> 
>> 
>> Error number 4001 in 4: Error while evaluating velocity template 
>> colorThemeInit.vm
>> Error number 4001 in 4: Error while evaluating velocity template 
>> colorThemeInit.vm
>> com.xpn.xwiki.XWikiException: Error number 4001 in 4: Error while evaluating 
>> velocity template colorThemeInit.vm
> 
> [snip]
> 
>> Caused by: java.lang.IllegalStateException: No standard field found for 
>> reverse order comparator!
>>  at org.jboss.marshalling.river.Protocol.(Protocol.java:276)
>>  ... 249 mor
> 
> [snip
> 
>> Caused by: java.lang.IllegalStateException: No standard field found for 
>> reverse order comparator!
>>  at org.jboss.marshalling.river.Protocol.(Protocol.java:276)
>>  ... 249 mor
> 
> What this says is that JBoss Infinispan (which we use) is not compatible with 
> Java 10. Apparently this is fixed in recent version of JBoss Marshalling: 
> https://issues.jboss.org/browse/JBMAR-216. We probably just need to wait for 
> JBoss Infinispan to release a new version that uses JBoss Marshalling 
> 2.1.0.Final.
> 
> What would be awesome would be for you to report the problem of using XWiki 
> with Java 10 on https://jira.xwiki.org so that we can have an issue for it 
> and work to make it work.
> 
> Note that I’m replying to this message to help you out but it’s not the right 
> place to post a question and get help normally. For that we have a user forum 
> at https://forum.xwiki.org/. 
> 
> I’m sorry you had some issues. OTOH you’re looking for trouble by trying with 
> Java 10. There are very few (if any!) java app that currently work with Java 
> 9 and 10. You’d be much better off using Java 8. On the positive side, if you 
> raise the issue on https://jira.xwiki.org, then you will transform your 
> negative experience into a positive one, by contributing to the development 
> of XWiki and helping out future users.
> 
> Thanks
> -Vincent Massol

[snip]

Re: [xwiki-devs] New extensions for querying XWiki data and generating Charts

[Vincent Massol]

Cool Ludo, thanks for your work.

If you want to advertise it even more you could post it on the forum in the new 
section:
https://forum.xwiki.org/c/News

Thanks
-Vincent

> On 12 May 2018, at 19:53, Ludovic Dubost  wrote:
> 
> Hi,
> 
> I've created a new extension (appwithinminutes-charts) and updated an older
> one (application-querygenerator).
> 
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Query%20Generator
> http://extensions.xwiki.org/xwiki/bin/view/Extension/AppWithin%20Minutes%20Charts%20and%20Data/
> 
> These extensions allow to query XWiki data in a simpler way for non
> technical users and help create a macro allowing to display a sub-set of
> XWiki data as well as a chart to count or sum data.
> 
> The query generator extension in adding to the "querymacro" now includes a
> "livetable" macro. This livetable extension wraps the velocity #livetable
> macro in an XWiki macro. The livetable macro is using a modified version of
> the AppWithinMinute livetable generator.
> 
> The query macro supports XWQL and HQL queries and displays the data as HTML
> tables.
> 
> The chart macro allows to display a 2 columns aggregation as a table and as
> a chart. The chart package also includes a small UI to generate a chart of
> a specific AWM application.
> 
> The query generator is the most complex code as it allows to create an XWQL
> or HQL query with restrictions on the different field types (string, date,
> number, list) and also generate the syntax for the livetable, query and
> chart macros. It is quite useful to generate the right XWQL and HQL syntax
> based on the restrictions you want to do. It allows to preview the result
> in the same screen.
> 
> The chart package includes french and english translation, however the
> query generator is not translated at all and the code is not very clean. It
> includes quite some groovy code to generate the UI and includes the XWQL
> and HQL query generator.
> 
> 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