[xwiki-devs] [GSoC] GSoC 2019 has concluded. Congratulations, XWiki students!

[Eduard Moraru]

Hello, GSoC students, mentors, devs,

As you have probably seen by now, the Google Summer of Code 2019 program
has now concluded:
https://opensource.googleblog.com/2019/09/thats-wrap-for-google-summer-of-code.html

We would like to congratulate this year's students that have successfully
finished their projects. Here's their end of project reports together with
some of their impressions of the experience:

* Ashish Sharma -
https://www.xwiki.org/xwiki/bin/view/Blog/My%20GSOC%20journey%20with%20xwiki/
* Divyansh Jain -
https://www.xwiki.org/xwiki/bin/view/Blog/My%20GSOC19%20Experience./
* Fawad Ali -
https://gist.github.com/9inpachi/b02fd831de7d79a7f3823634019470c4

We are very happy to have have had them in XWiki's community during this
summer. We hope they had a good time while gaining practical experience and
guidance in an open source project and that they found XWiki to be an
interesting and welcoming project that they can continue contributing in
the future, by either continuously improving their GSoC project or other
interesting parts of the XWiki project itself.

See you around (on the mailing list, on the chat, forum, github, etc.),
keep up the good work, good luck at school and thanks for helping the XWiki
project grow!

-The XWiki Development Team

Re: [xwiki-devs] [Docker] Move to java11 or drop arm64v8 architecture support?

[Eduard Moraru]

+1 for the docker package to be on Java 11. It's kind of a no-brainer at
this point, as Vincent also mentioned, and I'm not sure which would be the
disadvantages of doing so.

Re backwards compatibility, I'm not sure that's an issue here, since we're
talking about docker containers that you switch entirely (i.e. JVM + server
container + etc.). The backwards compatibility discussion is probably more
appropriate for the debian/OS-specific packages that need to be upgraded
inside the same machine.

Thanks,
Eduard

On Thu, Jun 27, 2019 at 10:50 AM Vincent Massol  wrote:

> Hi,
>
> > On 27 Jun 2019, at 09:32, Vincent Massol  wrote:
> >
> > Hi guys,
> >
> > We have a decision to take re the docker image.
> >
> > Until now we were supporting the arm64v8 architecture. However due to
> some changes, it's now ony supported with java11. So we have 2 solutions
> for the tomcat base image to use:
> >
> > 1) stay on java8 and move to the adoptopenjdk base image (so that we get
> java patches) BUT drop support for arm64v8 architectures
> > 2) move to java11 and move to the adoptopenjdk base image (so that we
> get java patches) and keep support for arm64v8 archietectures
> >
> > My POV is that we should do 1) since XWiki is supposed to run well on
> Java11 (it may even be faster on it?) and we want it to work on it anyway.
> We also test it with our docker tests every week
>
> I meant 2) :)
>
> Thanks
> -Vincent
>
> >
> > Side note: we could also decide to move to java11 everywhere on our CI
> agents and keep some tests weekly on java8 (ie invert the current situation)
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
>
>

Re: [xwiki-devs] [Proposal] Rerun flaky tests several times?

[Eduard Moraru]

Hi,

I would really like to see something like this in our build, specially
since I've always wanted us to enable the surefire flag that would
re-execute a failed test.

Now, it's not very clear to me, but both the JUnit Pioneer thing and the
rerunner-jupiter one seem to be proposing an annotation that needs to be
set apriori on a test, otherwise the plugin/feature does not do its job? I
understand that, due to JUnit5, things might still be work in progress, but
I'd like to clarify on the intent that, AFAIU, any test that fails should
be rerun to check if it's a flaky test or an actual failure and not only
tests marked before (since it would slightly defeat the purpose of
automatically detecting and marking flaky tests).

+1 to try to automate at least the flagging of such plagues (that are flaky
tests) :)

Thanks,
Eduard

On Mon, Jun 10, 2019 at 12:43 PM Vincent Massol  wrote:

> Hi devs,
>
> I was looking for a rerun optin in JUnit5 or Surefire but it seems it
> doesn’t exist for Junit5:
> * https://github.com/junit-team/junit5/issues/1558
> * https://issues.apache.org/jira/browse/SUREFIRE-1584
>
> However, there’s an extension to do that:
> * https://github.com/artsok/rerunner-jupiter
>
> Also WIP for JUnit Pioneer:
> * https://github.com/junit-pioneer/junit-pioneer/pull/110
>
> So my proposal FTM is to try https://github.com/artsok/rerunner-jupiter
> and to start putting a repeat of 3 for JUnit5 tests that we know are flaky.
>
> For JUnit4 tests we could simply use:
> *
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html
>
> Note that this would also allow us to correct flaky tests that don’t set
> up the initial conditions (fixture) correctly.
>
> Second note: This is not an endorsement that we should accept flaky tests.
> They’re a plague and we need to work on them and fix them. This is just a
> momentary workaround to identify how flaky a test is and to try to have a
> better solution towards moving to a Continuous Delivery solution.
>
> WDYT?
>
> Thanks
> -Vincent
>
>

Re: [xwiki-devs] [Proposal] Merge on save

[Eduard Moraru]

Also, there is the possibility of having to go though the conflict
resolution screen multiple times if, whenever trying to finish it and press
save, a new change was done in the background user, generating a conflict
with the version you have just resolved. If it's a very popular page that
users are constantly editing generally on the same places of the document,
this could get a bit annoying the more time you spend in edit mode :)

On Mon, May 27, 2019 at 5:25 PM Eduard Moraru  wrote:

> Hi,
>
> I feel we're over-engineering things a bit, at least for a fist version.
> My feeling is that the approach is to go with an UI-first version (the
> whole talk about being able to choose "mine" vs "their" versions) and only
> then, at a later point, coming back to a text-based version that allows you
> to fix the details. Why not go the other way around, in a simpler and
> already familiar (to some at least) yet flexible solution of starting with
> the text-based version, since we are editing wiki syntax after all?
>
> IMO, the easiest thing we could do is that, when a save is attempted, a
> merge should be attempted first. If no conflict occurs and the merge can be
> done automatically, the save should be done on the DB as well and the user
> should not perceive anything, thus not affecting his flow.
>
> Note: I hope we are all on the same page when I say that the merge
> conflict resolution should target/work on wiki syntax in the UI as well.
>
> If, however, conflicts do occur, the save does not go to the DB. Instead:
> * If it was a save, the UI should inform the user (popup/bottom
> screen notification) that the save failed because of a conflict and offer
> the possibility to keep editing or resolve the conflict
> * If it was a save (or if the user clicked "resolve conflict" after a
> failed save), the UI should reload the (wiki) editor with the
> entire merged content that will include the conflicts in a way that is (at
> least in the first implementation) similar to how git conflicts are
> displayed in a file, i.e. clearly marked in the content (where the conflict
> starts and ends), showing your version vs the version that is currently on
> the server (in the DB). Example (with html, but imagine wiki syntax here
> and we could use something better than "HEAD", etc.):
> https://d33v4339jhl8k0.cloudfront.net/docs/assets/55c3b5cae4b01fdb81eb1259/images/569e7be1c697914361560809/file-AzxXs4HkkG.png
>
> An improved version (iteration) of this could then be to use something
> like CodeMirror's "merge" addon (since we already use CodeMirror in the
> syntax highlighting application). It supports 2-way or 3-way display and
> live diff computation between the versions, synchronized scrollbars, and
> other neat stuff: https://codemirror.net/demo/merge.html We could decide
> if in "our" version we include the user's original version OR if we put
> directly the merged version (where the auto-merges are already applied) OR
> if we have a button under the user's original version to perform auto-merge
> on request, leaving just the remaining conflicts to be handled by the user.
> Finally, when save is pressed in this mode (note: probably we need to
> disable save so that the "conflict resolution" action is "atomic",
> i.e. without leaving the content in an unfinished merge state), whatever
> the edited version is will overwrite the DB version of the document (i.e.
> force with whatever it contains).
>
> WDYT?
>
> Thanks,
> Eduard
>
> On Fri, May 24, 2019 at 2:53 PM Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
>
>> On Thu, May 23, 2019 at 6:33 PM Simon Urli  wrote:
>>
>> >
>> >
>> > On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:
>> > > On Thu, May 23, 2019 at 12:10 PM Simon Urli 
>> > wrote:
>> > >
>> > >> So trying to sum up the discussion to see if we all agree.
>> > >>
>> > >> All the above is in the case of a save conflict:
>> > >>
>> > >> 1. Default behaviour for all users is to try an automatic merge, and
>> to
>> > >> display a window conflict resolution in case of merge conflict. The
>> > >> conflict resolution is an all-or-nothing based, allowing to choose a
>> > >> version over another.
>> > >>
>> > >
>> > > I don't agree about the all-or-nothing, since I would prefer to accept
>> > what
>> > > we can, warn on conflicts.
>> > > We should show a resolution conflict when the conflict is on the same
>> > line.
>> > > Auto-merge the rest.
>> >
>> > A

Re: [xwiki-devs] [Proposal] Merge on save

[Eduard Moraru]

Hi,

I feel we're over-engineering things a bit, at least for a fist version. My
feeling is that the approach is to go with an UI-first version (the whole
talk about being able to choose "mine" vs "their" versions) and only then,
at a later point, coming back to a text-based version that allows you to
fix the details. Why not go the other way around, in a simpler and already
familiar (to some at least) yet flexible solution of starting with the
text-based version, since we are editing wiki syntax after all?

IMO, the easiest thing we could do is that, when a save is attempted, a
merge should be attempted first. If no conflict occurs and the merge can be
done automatically, the save should be done on the DB as well and the user
should not perceive anything, thus not affecting his flow.

Note: I hope we are all on the same page when I say that the merge conflict
resolution should target/work on wiki syntax in the UI as well.

If, however, conflicts do occur, the save does not go to the DB. Instead:
* If it was a save, the UI should inform the user (popup/bottom
screen notification) that the save failed because of a conflict and offer
the possibility to keep editing or resolve the conflict
* If it was a save (or if the user clicked "resolve conflict" after a
failed save), the UI should reload the (wiki) editor with the
entire merged content that will include the conflicts in a way that is (at
least in the first implementation) similar to how git conflicts are
displayed in a file, i.e. clearly marked in the content (where the conflict
starts and ends), showing your version vs the version that is currently on
the server (in the DB). Example (with html, but imagine wiki syntax here
and we could use something better than "HEAD", etc.):
https://d33v4339jhl8k0.cloudfront.net/docs/assets/55c3b5cae4b01fdb81eb1259/images/569e7be1c697914361560809/file-AzxXs4HkkG.png

An improved version (iteration) of this could then be to use something like
CodeMirror's "merge" addon (since we already use CodeMirror in the syntax
highlighting application). It supports 2-way or 3-way display and live diff
computation between the versions, synchronized scrollbars, and other neat
stuff: https://codemirror.net/demo/merge.html We could decide if in "our"
version we include the user's original version OR if we put directly the
merged version (where the auto-merges are already applied) OR if we have a
button under the user's original version to perform auto-merge on request,
leaving just the remaining conflicts to be handled by the user. Finally,
when save is pressed in this mode (note: probably we need to disable
save so that the "conflict resolution" action is "atomic", i.e.
without leaving the content in an unfinished merge state), whatever the
edited version is will overwrite the DB version of the document (i.e. force
with whatever it contains).

WDYT?

Thanks,
Eduard

On Fri, May 24, 2019 at 2:53 PM Ecaterina Moraru (Valica) 
wrote:

> On Thu, May 23, 2019 at 6:33 PM Simon Urli  wrote:
>
> >
> >
> > On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:
> > > On Thu, May 23, 2019 at 12:10 PM Simon Urli 
> > wrote:
> > >
> > >> So trying to sum up the discussion to see if we all agree.
> > >>
> > >> All the above is in the case of a save conflict:
> > >>
> > >> 1. Default behaviour for all users is to try an automatic merge, and
> to
> > >> display a window conflict resolution in case of merge conflict. The
> > >> conflict resolution is an all-or-nothing based, allowing to choose a
> > >> version over another.
> > >>
> > >
> > > I don't agree about the all-or-nothing, since I would prefer to accept
> > what
> > > we can, warn on conflicts.
> > > We should show a resolution conflict when the conflict is on the same
> > line.
> > > Auto-merge the rest.
> >
> > Apparently I wasn't clear about my "all or nothing" feature. For me it
> > only concern the resolution of the merge conflicts, but the choice made
> > apply to ALL conflict of the document. That's what I meant.
> >
>
> Here it was the confusion, since in my mind, I though we were going line by
> line. You said that in the first version we won't have this, but ideal
> implementation it should go like that (and even at the word / character
> level for realtime-editing).
>
>
> > >
> > >
> > >>
> > >> 2. There is an option in the user profile to be able to always see the
> > >> diff in case of save conflict, to accept or not the merge, even when
> > >> there's no conflict.
> > >>
> > >
> > > I don't like the option in the profile. IMO we should decide on the
> > > behavior and apply it for all users. Edit is a core feature, conflicts
> > > again are part of this kind of interaction.
> > >
> >
> > So you'd go with a -1 for this option?
> >
>
> We should add a new configuration only if it's needed. Again, I think we
> are introducing a lot of things (parent/child relation, accessibility
> options, etc.) that we never test. We don't reach a conclusion by
> ourselves, so trying to make 

Re: [xwiki-devs] Map Application - GSoC 19

[Eduard Moraru]

Hi, Fawad,

Please make double sure to read and follow the Student Guidelines,
specially the section about the work process:

https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HSuggestedwayofworkingforacceptedGSoCstudents

It covers stuff like where to place your code (Contrib), how to document
your process (project page), how to communicate, etc.

Otherwise, just from my quick "helicopter look", it looks like you're
getting the hang of how to structure your project's code and how XWiki
extensions work.

Keep it up,
Eduard

On Mon, May 20, 2019 at 12:50 PM Fawad Ali  wrote:

> Hi developers,
>
> I have started working on the map application with some of the work done.
> So I wanted to get an update across to have a review of how I am doing so
> far.
> The source files for the project are available at:
> https://github.com/9inpachi/application-map
> I have been and in future intend to document the daily progress of the
> development. The progress is available at PROGRESS.md
> <https://github.com/9inpachi/application-map/blob/master/PROGRESS.md>
> within
> the repository,
>
> The design proposal for the project is available at
> https://design.xwiki.org/xwiki/bin/view/Proposal/MapApplication.
>
> And I would like to request a repository on xwiki-contrib.
>
> Best,
> Fawad
>
>
> On Mon, May 13, 2019 at 6:50 PM Eduard Moraru 
> wrote:
>
> > Hi, Ali, and welcome to XWiki!
> >
> > Hope you'll have a great summer and enjoy discovering our product and
> being
> > part of our community!
> >
> > Looking forward to see your project come to life.
> >
> > Best,
> > Eduard
> >
> > On Mon, May 13, 2019 at 4:00 PM Ecaterina Moraru (Valica) <
> > vali...@gmail.com>
> > wrote:
> >
> > > Hi ginpachi,
> > >
> > > Thank you for introducing yourself and the project.
> > > Welcome to XWiki and enjoy this summer :)
> > >
> > > Best,
> > > Caty
> > >
> > > On Sun, May 12, 2019 at 6:46 PM Fawad Ali 
> > wrote:
> > >
> > > > Hi everyone,
> > > > Hope all of you are doing great.
> > > >
> > > > About Me
> > > >
> > > > I am Fawad Ali, selected as a student for Google Summer of Code.
> > > Currently
> > > > enrolled in the 6th semester at University of Engineering and
> > Technology,
> > > > Taxila. I am a resident of Pakistan currently living in the city of
> > > > Rawalpindi.
> > > >
> > > > It is a great honor to have been selected and have a chance to work
> > with
> > > > XWiki. :)
> > > >
> > > > *Profiles*
> > > > GitHub - https://github.com/9inpachi
> > > > LinkedIn - https://www.linkedin.com/in/fawadaliq/
> > > > Riot - @ginpachi:matrix.org
> > > >
> > > > I will be presenting my project "Map Application" to all of you.
> > > Following
> > > > are the relevant details.
> > > >
> > > >
> > > > Map Application
> > > >
> > > > *Mentors: *Stéphane Laurière, Ecaterina Moraru
> > > >
> > > > *Technologies:* JavaScript, Velocity, Java, Leaflet, other if
> required
> > > >
> > > > Overview
> > > >
> > > > This project is about the development of interactive maps in XWiki.
> > > > Creation of an application within XWiki that will allow users to
> > generate
> > > > interactive maps which support collaboration and are easy to create
> so
> > > that
> > > > locations can be shared, and areas can be associated with structured
> > > data.
> > > >
> > > > This application will open several possibilities that can be utilized
> > > > within XWiki and broaden the overall scope by allowing map rich wikis
> > > where
> > > > locations and areas can be presented in a way that will increase the
> > > > understandability of data.
> > > >
> > > > It will also allow for the sharing of custom map related data which
> > would
> > > > be very helpful since users and admins will be able to present
> > locations
> > > in
> > > > an information rich map environment which will be interactive.
> > > >
> > > > Features
> > > >
> > > > > *Markers and popups* - Place markers anywhere on the map and
> > associate
> > > > popups with them.
> > > > > *Path between two points* - A

Re: [xwiki-devs] Map Application - GSoC 19

[Eduard Moraru]

Hi, Ali, and welcome to XWiki!

Hope you'll have a great summer and enjoy discovering our product and being
part of our community!

Looking forward to see your project come to life.

Best,
Eduard

On Mon, May 13, 2019 at 4:00 PM Ecaterina Moraru (Valica) 
wrote:

> Hi ginpachi,
>
> Thank you for introducing yourself and the project.
> Welcome to XWiki and enjoy this summer :)
>
> Best,
> Caty
>
> On Sun, May 12, 2019 at 6:46 PM Fawad Ali  wrote:
>
> > Hi everyone,
> > Hope all of you are doing great.
> >
> > About Me
> >
> > I am Fawad Ali, selected as a student for Google Summer of Code.
> Currently
> > enrolled in the 6th semester at University of Engineering and Technology,
> > Taxila. I am a resident of Pakistan currently living in the city of
> > Rawalpindi.
> >
> > It is a great honor to have been selected and have a chance to work with
> > XWiki. :)
> >
> > *Profiles*
> > GitHub - https://github.com/9inpachi
> > LinkedIn - https://www.linkedin.com/in/fawadaliq/
> > Riot - @ginpachi:matrix.org
> >
> > I will be presenting my project "Map Application" to all of you.
> Following
> > are the relevant details.
> >
> >
> > Map Application
> >
> > *Mentors: *Stéphane Laurière, Ecaterina Moraru
> >
> > *Technologies:* JavaScript, Velocity, Java, Leaflet, other if required
> >
> > Overview
> >
> > This project is about the development of interactive maps in XWiki.
> > Creation of an application within XWiki that will allow users to generate
> > interactive maps which support collaboration and are easy to create so
> that
> > locations can be shared, and areas can be associated with structured
> data.
> >
> > This application will open several possibilities that can be utilized
> > within XWiki and broaden the overall scope by allowing map rich wikis
> where
> > locations and areas can be presented in a way that will increase the
> > understandability of data.
> >
> > It will also allow for the sharing of custom map related data which would
> > be very helpful since users and admins will be able to present locations
> in
> > an information rich map environment which will be interactive.
> >
> > Features
> >
> > > *Markers and popups* - Place markers anywhere on the map and associate
> > popups with them.
> > > *Path between two points* - A path will be generated by the application
> > linking two points of interest.
> > > *Location search* - Search any location on the map.
> > > *Filtered list maps* - Allow the user to search for a specific kind of
> > place (e.g. restaurants) and get a list of locations to choose from.
> > Through the content available and binded to a location, the user will be
> > able to learn some aspects of the location.
> > > *Custom shapes* - Custom shapes can be used to highlight a specific
> area
> > for representation. The content associated with these shapes can give
> > useful information about the area.
> > > *Indoor maps* - Such maps will be able to describe the internal
> structure
> > or fair plan of a building or structure. They can be used to guide users
> in
> > a big building and locate point of interests.
> > > *Maps on mobile* - Special design arrangements will be made for easily
> > viewing of maps and availing all the features of the application on
> mobile
> > devices.
> > > *Custom map backgrounds* - Custom backgrounds will make the environment
> > of interactive maps much suitable for a specific purpose
> >
> > If you have any features in mind that will make the Map Application
> better
> > please feel free to reply to this mail.
> > This is all for the summary of the project, if you want to have a more
> > deeper insight, please check out the full proposal.
> >
> > *Project Proposal: *
> > https://drive.google.com/open?id=14qXC7Oy2bPUASfVtSTIsNG1sPcfm5Ikr
> >
> >
> > Thanks for reading through the mail. I will be looking forward to your
> > guidance through this summer and your contributions to the project.
> > If you have any questions or suggestions, please feel free to reply to
> this
> > mail.
> >
> > Au revoir. :)
> >
> > Best,
> > Fawad Ali
> >
>

[xwiki-devs] [GSOC] Welcoming our GSoC students

[Eduard Moraru]

Hello community, Hello Google Summer of Code students,

First of all, congratulations on your applications and your activity during
the selection period, and welcome in the XWiki development team.

Before guiding the accepted students to their next steps, we'd like to
thank again all those who showed interest in XWiki for this Summer of Code.
We had a lot of good applications this year, with professional approaches
and interesting ideas, and it was very difficult to choose. Unfortunately,
some very good students, with great potential, were not accepted. So, to
those interested in getting involved anyway, without Google's implication,
I renew the invitation to put your ideas in practice under the guidance of
the community. Even though the money will be missing, you can still take
advantage of the other GSoC benefits: learning new things, gaining
experience, earning recognition, etc [1]. If you would like to do that,
please let us know by replying to this mail.

For the accepted students, here are some getting started hints:

= Community bonding period =

According to the program timeline [2], the next month (until - May 27th) is
to be used for community bonding.

The first thing to do, sometime this week, is to present yourself and your
project on the dev list, so that everyone knows who you are and what to
expect from you. A precondition to being able to send mails to the devs
list is to first be subscribed [2.1] to it, which you __need to do ASAP__
if you haven't already.

Also, you should continue getting acquainted with the code, the practices
and the developers. Please make sure you all read and understand the
following - very useful - documents:
- [3] http://dev.xwiki.org/xwiki/bin/view/Community/
- [4] http://platform.xwiki.org/xwiki/bin/view/DevGuide/
- [5] http://platform.xwiki.org/xwiki/bin/view/Features/

= Mentorship =

We prefer open mentorship. While your assigned mentor is the one officially
in charge with your guidance, almost all interaction should be done 'in the
open' as much as possible, on the IRC channel or on the mailing list. You
should choose the communication medium according to the importance of the
matters to be discussed: naturally, the less important issues are to be
discussed on IRC/Matrix, while the design decisions, important progress
announcements and testing/feedback requests go on the devs list. This way,
the community is informed on the evolution of your project, and other
developers can come up any time with useful ideas and suggestions.
Moreover, if your mentor is "hit by a bus" (the bus factor [6]), another
developer can take his place with little effort.

= Communication =

Sitting alone in your room, working secretly on your project is definitely
a __bad__ approach. However, please keep in mind that too much
communication can also be harmful, as it distracts the others from their
own work. You need to be able to communicate just right:
- provide meaningful information about your progress,
- ask the community's opinion on non-trivial design or implementation
decisions
- avoid wasting a lot of time on a problem, when a more experienced
developer (or a student that fought the same problem) could quickly provide
you an answer; however, do try to find the answer yourself at first.

Wrong: "Where do I start? What do I do now? And how do I do that? Is this
good? It doesn't work, help me!"

Right: "Since a couple of hours ago I get a strange exception when building
my project, and googling for a solution doesn't seem to help. Looking at
the error, I think that there's a wrong setting for the assembly plugin,
but nothing I tried works. Can someone please take a look?"

Subscribe to the devs list (if you didn't do this already), and start
monitoring the discussions. It is also recommended to register on the users
forum, but not mandatory. The notifications list is a little too high
volume and technical for the moment, but it is a great knowledge source.

Also, try to make sure that you're generally available on chat (IRC/Matrix)
in order to have a better view on the daily discussions, get involved and
generally be easily reachable, should your mentors or any of the students
want to easily get a hold of you. Generally speaking, if you are online
(working on your project), you should also be available on the chat, just
in case.

= Development process =

The project's lifecycle is NOT design -> implementation -> testing ->
documentation. [7]

We invite you to adopt a test driven development [8][9][10] approach and to
experience agile development [11]. After the first coding week, you must
have some code that works. It won't do much, of course, but it will be the
seed of your project. Every functionality will be validated by tests. The
code must be properly tested and commented at the time of the writing
(don't think you'll do that afterwards, because in most cases you won't).

Since our code is hosted on GitHub [12], you should register an account
there and fork some xwiki 

[xwiki-devs] [ANN] XWiki 10.11.5 released

[Eduard Moraru]

The XWiki development team is proud to announce the availability of XWiki
10.11.5.
This is a bugfix release that covers important issues that we have
discovered since 10.11.4 has been released.

You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.11.5

Thanks for your support
-The XWiki dev team

Re: [xwiki-devs] [contrib] Page Preview Popover extension request

[Eduard Moraru]

The result looks very nice!

The loading time seems a bit long, probably because of the entire page
rendering, but that should not be a big problem.

Thanks,
Eduard

On Tue, Feb 19, 2019 at 9:52 AM Stéphane Laurière 
wrote:

> Hi Eduard, Hi devs,
>
> I'm following up on this discussion which I had left aside for a while:
>
> Eduard Moraru:
> > Hi, Stephane.
> >
> > On Tue, Aug 28, 2018 at 10:49 AM Stéphane Laurière 
> > wrote:
> >
> >> Vincent Massol:
> >>> Hi Stephane,
> >>>
> >>>> On 28 Aug 2018, at 08:55, Stéphane Laurière 
> >> wrote:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> I would like to contribute an extension that will display page preview
> >> popovers when hovering wiki links, similarly to what MediaWiki offers:
> >>>>
> >>>>https://www.mediawiki.org/wiki/Page_Previews
> >>>>https://blog.wikimedia.org/2018/05/09/page-previews-documentation/
> >
> >
> > Sounds like a nice extension!
> >
> > However, how are you going to extract the "summary" of a page? In
> > Wikipedia, pages have a certain structure and, at the beginning of each
> > page, you have at least the first paragraph that is describing the
> > resource. Even the Wikipedia API allows you to get the "extract"
> > (summary/topic) of a page and that is what the Wikipedia feature is using
> > as text content to display in that preview popup.
> >
> > In XWiki, the usecases are not defined and you could have anything
> inside a
> > page. Do you plan to show the entire page content inside that preview? Do
> > you plan to have an empirical approach in order to get some sort of
> summary
> > by e.g. displaying just the first paragraph as well? What's the approach?
>
> My proposal would be to make the approach configurable, so that the
> preview could be anything ranging from the full page to any element of the
> page. The default configuration could consist in displaying 1) the first
> block that matches one of the following: Paragraph, List, Quotation, Table.
> 2) the first image attached to the page, if any. What do you think?
>
> In a second step, that could be nice to let the users define custom
> configurations to adapt the previews to their needs.
>
> >>
> >>>
> >>> Sounds nice. Do you plan to implement it as a Rendering Transformation
> >> (similar to what the Glossary app do) or as Javascript code?
> >>
> >
> > Definitely  JavaScript + REST API would be the way to go here, to avoid
> > rendering, at display time, all the linked pages on the server side. Each
> > preview should be obtained when the user asks for it, i.e. when
> displaying
> > the preview. Optimisations could be done to prefetch the data, but that
> > would also increase the network traffic and server load, while improving
> > the user experience (i.e. not having to wait for the preview popup to
> load
> > its content).
>
> OK great, we agree on JavaScript then. I published a first experiment,
> welcoming code reviews and also feedback regarding the user experience:
>
>https://github.com/xwiki-contrib/application-page-preview
>
> https://dev.xwiki.org/xwiki/bin/view/Drafts/Page%20Preview%20Application
>
> At the moment, the code is using a dedicated service rather than the REST
> API because it allows some flexibility such as the ability to display in
> the preview the first image attached to the target page even if it's not
> present in the content itself (this is probably something that should be
> made configurable).
>
> In a first try, I had extracted the preview on the server side using the
> XDOM API. However, following a discussion with Anca, I realised that it's
> probably more efficient to send the whole page rendered content and to let
> the client display only part of it.
>
> >> Actually I had not considered the rendering transformation option. At
> >> first glance, plain JavaScript code seems more lightweight to me without
> >> any downside but if you see pros for using a transformation, please let
> me
> >> know. There's one issue with plain JavaScript at the moment though: the
> >> Bootstrap popover feature in version 3.x adds a div next to the clicked
> >> element. In our case, this means adding a div to the surrounding
> >> span.wikilink, which is not allowed in HTML5. However, Bootstrap 4
> popovers
> >> work differently: they're added as direct childs of the body:
> >> https://getbootstrap.com/docs/4.0/components/popovers/ so t

Re: [xwiki-devs] Location for extensions ideas

[Eduard Moraru]

We also have the "Idea" issue type in Jira so I don't think we need a
dedicated project just for that. It would be best to find the existing
project that your idea could extend, otherwise the "XWIKI" (platform)
project is still a good fit, IMO, since we should then better determine if
the feature should be a core/platform feature or if it should best be
suited in its own separate extension.

It's easy to build a filter for all the ideas from all the projects we have
on Jira.

Thanks,
Eduard


On Thu, Jan 31, 2019 at 12:31 PM Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> We could install the Ideas app somewhere on design.xwiki.org and make it
> exclusive for listing Extensions ideas.
> Thanks,
> Caty
>
>
> On Thu, Jan 31, 2019 at 10:35 AM Thomas Mortagne <
> thomas.morta...@xwiki.com>
> wrote:
>
> > Hi xwikiers,
> >
> > I'm never sure where to put ideas of extensions I have so I often
> > forget them or details I had tough about or gathered back then.
> >
> > I don't think http://design.xwiki.org is the right place until you
> > really start designing the extension. Also it's too generic for this
> > need and not a very good entry point for searching something IMO, more
> > something to link to from somewhere else.
> >
> > I would prefer something really dedicated to this "that would be a
> > nice thingy but not sure about the details yet" state. Would be a good
> > source for hackathons and GSOC or for contributors who are searching
> > for something interesting to work on.
> >
> > I was thinking about the following alternatives:
> > * a new dedicated project on https://jira.xwiki.org
> > * reuse https://jira.xwiki.org/projects/XCONTRIB after some cleanup
> > (close everything left in it basically) but not super clean (it's just
> > that it's a good name)
> > * some new application on http://www.xwiki.org
> >
> > WDYT ?
> >
> > Right now my preference goes to a clean new jira project (just need to
> > think about a good project id) where you put description and close it
> > when the extension work really start on a dedicated location. Less
> > work and should do the job well.
> >
> > --
> > Thomas Mortagne
> >
>

Re: [xwiki-devs] [Proposal] Get rid of Activity Stream and the Watchlist

[Eduard Moraru]

+1 in general, but please consider migration issues, specially calls to the
{{activity/}} macro that will be still found in wiki pages that will stop
working if the ActivityStream (which is a macro) is removed.

Also, for anyone using or extending the ActivityStream plugin's API
directly, their code will fail. I doubt there were many (if any) users of
the relatively obscure EventStream API, so the effect of the backwards
compatible "Event Stream Store" implementation will not compensate for
much, IMO.

What I am personally concerned about is that, ideally, the upgrade to the
new XWiki version (which no longer bundles these modules) require as less
(preferably none) manual operations as possible.

Thanks,
Eduard

On Wed, Feb 6, 2019 at 5:10 PM Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> +1
>
> Thanks,
> Marius
>
> On Mon, Feb 4, 2019 at 1:50 PM Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
>
> > Dear developers,
> >
> > Now that we consider notifications as an achieved replacement for both
> > Activity Stream and the Watchlist, I propose to stop maintaining them and
> > to move them into the "attic" section.
> >
> > You need to know that we had a dependency on the Activity Stream API, as
> > the only implementation of the Event Stream, on which the Notifications
> are
> > based. So to get rid of this dependency (the code is not using our
> > component system and is not well tested), I have written a new
> > implementation of the Event Stream that I have called "Event Stream
> Store".
> > It's fully backward compatible with the old implementation, since it is
> > using the same Database schema. In practice, I re-used some pieces of
> > Activity Stream that I have modified to fit into components. For more
> > information, see: https://jira.xwiki.org/browse/XWIKI-16052
> >
> > So my proposal is this one:
> > - use the new store in 11.1
> > - stop bundle Watchlist and AS in 11.1
> > - move Watchlist and AS into "attic" in 11.2
> >
> > Thanks you,
> >
> > --
> > Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
> >
>

Re: [xwiki-devs] [Proposal] Do not write pure-developer release notes

[Eduard Moraru]

Hi,

What I don't like about this is the fact that, because of the rule that
says that all closed issues must have assigned documentation links
(including in the RN), the developer now has to make yet another decision,
and a pretty subjective one, this time. You (the dev) need to decide if the
issue you've just worked on is RN worthy... a decision that can be
problematic at multiple levels and I foresee possible friction (e.g. you
believe you're done with your issue and, on the last minute or at release
day, someone starts telling you that it should have been documented in the
RN, when you had previously decided that it was not the case).

Re "Developers", I also prefer to keep it and to target both "advanced
users" and "platform users" (i.e. extension devs that would normally be
interested in API changes). IMO, it's more important to focus in the RN on
explaining what *changes* in the platform's behavior with the modification
that was performed, nor only in explaining what the modification does.

Also, AFAIR, we used to consider the issue tracker as "ephemeral" so the
fact that we are listing the issues that might be gone at some point might
no be very helpful on the long run.

So I see the proposal as slightly conflicting with the potentially
vanishing list of issues and the rule that requires dev to always document
(including in the RN).

IMO, we already deploy an "importance" ordering and we have the
Miscellaneous section that readers can easily skip. I agree with Marius
when he says that XWiki and SonarQube are completely different beasts.

An even more extreme approach, building on what Denis suggested, is to
break the RN into completely separate pages, for Users, Devs and Admins...
but I just feel we're creating busy work for ourselves at this point...

IMO, our current approach works. Sure, we might have to avoid cryptic lines
in the Miscellaneous section, but that's something we can improve.

Thanks,
Eduard

On Thu, Jan 31, 2019 at 10:36 AM Vincent Massol  wrote:

>
>
> > On 31 Jan 2019, at 09:24, Denis Gervalle  wrote:
> >
> > Hi Vincent,
> >
> > Maybe, we need to introduce an Advanced checkbox in the RN, and publish
> it in two parts. One part would be expanded, and very visible, and the
> other one, need some action from the user to be shown. Normal users will
> therefore get what you expect, and more interested people still have that
> insightful information they delight. As an advanced user, I really don’t
> see JIRA as release notes, since JIRA also contains a bunch of very
> non-significant information, and the way the issue is written, is also
> sometimes confusing since it might contain a discussion. Reading a list of
> JIRA issue is not a usual way to be updated, you check them mainly when you
> have a specific problem.
>
> Thanks Denis. Good feedback
>
> I agree. There’s just one aspect to take into consideration: the cost :)
>
> In the end it’s a cost/benefit ratio. Also we document in the reference
> documentation so for me just links to reference doc for developer changes
> could be enough (especially if we use the “Since XXX” information in the
> reference doc).
>
> Thanks
> -Vincent
>
> > Just my thought as an interested user of some technical highlights. And
> I most agree with your remarks about the way those note are written, there
> is plenty of room for improvement there, to really distinguish them from
> the JIRA issue.
> >
> > Thanks,
> >
> > --
> > Denis Gervalle
> > SOFTEC sa - CEO
> > On 31 Jan 2019, 08:27 +0100, Vincent Massol , wrote:
> >>
> >>
> >>> On 30 Jan 2019, at 18:09, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >>>
> >>> Yes, it looks nice, but SonarQube is a different kind of product. I
> don't
> >>> think it's a development platform like us..
> >>
> >> Yes (although you could argue about that). However I still believe that
> to attract and keep users (which is our primary objective IMO), we should
> focus on RN for users (Highlights only and not 100% transform JIRA issues
> into RN items) and for developers simply link to reference documentation.
> >>
> >> In other words, focus on quality vs quantity for the RN. Our full RN is
> the JIRA list. Our RN page is supposed to be an extract of the full JIRA
> list.
> >>
> >> Am I the only one to think this? :)
> >>
> >> Thanks
> >> -Vincent
> >>
> >>>
> >>> On Wed, Jan 30, 2019 at 6:41 PM Vincent Massol 
> wrote:
> >>>
>  BTW I really like the quality of the SonarQube release notes:
>  * Not too much (nobody reads when there’s too much)
>  * Only document important highlights and make the RN nice for them
> (nice
>  screenshots, nice doc)
> 
>  https://www.sonarqube.org/sonarqube-7-6/
> 
>  WDYT?
> 
>  Thanks
>  -Vincent
> 
> > On 25 Jan 2019, at 09:31, Vincent Massol  wrote:
> >
> > Hi devs,
> >
> > Context
> > ===
> >
> > It’s been since we’ve deviated from the original purpose of the
> Release
>  Notes 

[xwiki-devs] [GSOC] XWiki is applying for GSoC 2019. Proposals and mentors needed!

[Eduard Moraru]

Hello fellow XWiki community members,

This year XWiki is planning to participate once more at Google's Summer of
Code [1].

The organization registration period has already started (15th January) and
the deadline is on the 6th February [2] (just 1 week left).

1. We need to provide by then a list of proposals and assign mentors for
the students that are going to implement them.

I would like to ask everybody that wants to participate as a mentor from
the XWiki organization to review the proposals [3] list (we have just 5
proposed projects up to now) and add as many interesting proposals as
possible.

The proposals can be either new, or they can be revived from previous
years. Just navigate to the previous years [4], find the proposal you like
and know about, go to its proposal page (click it) and press the "Clone to
this year" link. Now you can assign yourself as lead for that project,
update it's description if needed and wait for the student applications to
start pouring :)

2. We also need to submit the actual application [5] of the XWiki
organization to participate to the GSoC 2019 project so I would also like
to ask you to review it so that we have a better chance of being selected
into the program.

3. If you feel that you would like to help on improving XWiki's GSoC guides
and application forms, please find tips for students [6] on XWiki's GSoC
page, the student application form [7] and the lessons learned [8] from
previous years participations.

Thanks for your help,
Eduard


[1] https://summerofcode.withgoogle.com/
[2] https://summerofcode.withgoogle.com/how-it-works/#timeline
[3]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/#HProposedProjects2829
[4]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HPreviousGSoCeditions
[5]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/OrganizationApplicationForm

[6] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines

[7]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/student+application+form

[8] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/LessonsLearned

[xwiki-devs] [ANN] XWiki 11.0 released

[Eduard Moraru]

The XWiki development team is proud to announce the availability of XWiki
11.0.

This release marks the start of the 11.x cycle and focuses mainly on
bugfixes and stabilization, but also features some AWM and CKEditor
improvements.

You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.0

Thanks for your support
-The XWiki dev team

Re: [xwiki-devs] [Proposal] Change of XS Cycle strategy to account for Christmas

[Eduard Moraru]

Hi,

On Sun, Dec 9, 2018 at 5:07 PM Vincent Massol  wrote:

> Ok, summarizing again after feedback from Simon, Caty and Marius, here’s
> the proposal;
>
> * Duration: 11 minor releases (e.g. N.0 till N.10), one each month, from
> January to November.
> * The last month of the year, December sees 2 bug fix releases, to
> stabilize the cycle: N.10.1 and N.10.2. The releases are supposed to
> contain mostly bug fixes.
> ** Note that the N.10.2 release can happen on the first days of January to
> account for end of year holidays but it should not go beyond the 3rd of
> January.
> ** Work for N+1.0 starts once N.10.2 has been released.
>

Note that, AFAIU, work for N+1.0 *can* actually start beginning with
December, i.e. once N.10 is released and the master branch becomes
N+1.0-SNAPSHOT. However, the main focus *should* go on the N.10.x
stabilization branch until EOY (N.10.2).


> * When N.10.2 is released we announce it:
> ** Send mail mentioning that the cycle is over and encourage users to
> start using N.10.2
> ** In that mail, explain all the major features that were implemented
> during that release cycle (make a special Release Notes for a Cycle)
> * We announce the new LTS (N.10.x) once N+1.0 is released. Rationale:
> ** We need to have feedback on a release before it can be considered super
> stable and thus we usually need a few bug fix releases before a version can
> be considered a good LTS. This gives us one month to release additional
> bugfix releases for N.10.x in case it’s needed.
> ** This also allows us to always support 3 branches:
> *** LTS branch
> *** Stable branch
> *** master (latest SNAPSHOT)
>
> Note that I hesitated to announce the LTS when we released N.10.2 but
> after thinking about it, I think it’s better to continue announcing it only
> when N+1.0 is released (i.e. at end of January).
>
> I have modified
> https://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices?viewer=changes=14.1=15.1
> already.
>
> Once I have the final validation this is ok, I’m redo the screenshot at
>
> https://dev.xwiki.org/xwiki/bin/download/Community/VersioningAndReleasePractices/releasecycle.png
>
> Thanks
> -Vincent
>

+1.

Thanks,
Eduard


>
> > On 19 Nov 2018, at 17:13, Vincent Massol  wrote:
> >
> > Hi devs,
> >
> > Some devs mentioned it’s too hard to release the N.11 release since it
> happens around Christmas every year.
> >
> > Here’s a proposal:
> >
> > * Shorten the cycle to 11 releases instead of 12.
> > * Release N.9 at end of Nov
> > * Release N.10 at end of first week of Jan. Note: N.10RC1 would be
> released mid December (about 17th of Dec to have 3 weeks of RC).
> > * Release N+1.0 at end of February. Start of N+1.0 work
> >
> > Pros:
> > * No release during Christmas, yeah :)
> > * More time to prepare the first LTS bugfix release, i.e. N.10.1, which
> can be done during the month of January.
> > * More time for the first released of N+1 (i.e. N+1.0). This is
> important since that’s the release where we can do heavy refactoring and
> it’s not bad to get some more time.
> >
> > Cons:
> > * One less release
> >
> > WDYT? Do you see other cons?
> >
> > Thanks
> > -Vincent
> >
>
>

Re: [xwiki-devs] [Proposal] Change of XS Cycle strategy to account for Christmas

[Eduard Moraru]

Hi, Vincent.

+1 for the general goal of avoiding needless holiday stress.

Now, on the details, there is something I'm struggling to understand:
* I see that we have 2 options for finishing N.11:
A) In the middle of December (i.e. 10.11RC on 10th of Dec -2w- and 10.11
Final on 17 Dec -1w-), similar to what we did for 9.11.x (9.11RC1 was on
11th of Dec 2017 and 9.11 Final was on 18th of Dec 2017)
B) At the beginning of January (i.e. 10.11RC on 17th of Dec -3w- and 10.11
Final on the 7th of Jan 2019 -3w-)
** I would personally prefer A) in order to "close the books" before the
holiday season and start fresh in January. Anyone working during the
Holidays can start on N+1.0 or work on bugfixes for N.11.1.
* In both cases, N+1.0 should be same at the end of January, not February.
** Why would it have to be end of February, and thus lose a release, as
mentioned in your "Cons" section?
** I get it if it comes as a new proposal to double the length of N.0 to 2m
instead of 1 (for which I'd be +0, since I prefer less exceptions, if
possible), but I don't get it if we see it as a consequence of how we
handle holidays.

Side note: While trying to understand how all of this works, I can't but
help to notice how the week-based calculations don't add up, since a month
is 4.3(3) weeks long and everything planned around weeks is bound to be
distorted when you look at it by months. IMO, it would make more sense to
reason in terms of months (synchronized with our 12 releases cycle) and say
things like "last Monday of December". Not sure how easy it would be to
work with... just food for thought.

Thanks,
Eduard



On Mon, Nov 19, 2018 at 6:13 PM Vincent Massol  wrote:

> Hi devs,
>
> Some devs mentioned it’s too hard to release the N.11 release since it
> happens around Christmas every year.
>
> Here’s a proposal:
>
> * Shorten the cycle to 11 releases instead of 12.
> * Release N.9 at end of Nov
> * Release N.10 at end of first week of Jan. Note: N.10RC1 would be
> released mid December (about 17th of Dec to have 3 weeks of RC).
> * Release N+1.0 at end of February. Start of N+1.0 work
>
> Pros:
> * No release during Christmas, yeah :)
> * More time to prepare the first LTS bugfix release, i.e. N.10.1, which
> can be done during the month of January.
> * More time for the first released of N+1 (i.e. N+1.0). This is important
> since that’s the release where we can do heavy refactoring and it’s not bad
> to get some more time.
>
> Cons:
> * One less release
>
> WDYT? Do you see other cons?
>
> Thanks
> -Vincent
>
>

Re: [xwiki-devs] [Proposal] Update database support strategy

[Eduard Moraru]

On Tue, Nov 13, 2018 at 3:21 PM Vincent Massol  wrote:

>
>
> > On 13 Nov 2018, at 11:58, Vincent Massol  wrote:
> >
> > There are 2 questions here:
> > * Should we add support for MariaDB? And if so which versions. Just
> found that there’s an official docker image for it so it should be
> relatively easy to support MariaDB in our docker-based testing framework:
> https://hub.docker.com/_/mariadb/ (TestContainers also has a wrapper now
> for MariaDB:
> https://github.com/testcontainers/testcontainers-java/tree/master/modules/mariadb).
> Note that the MariaDB versions don’t match the MySQL versions.
>
> FTR, I’ve tried adding support for MariaDB and it’s currently not working,
> because of
> https://github.com/testcontainers/testcontainers-java/issues/949. But we
> could provide a PR to them with not so big efforts or using a
> GenericContainer (less nice).
>

Maybe I'm misunderstanding, but it looks like we're mixing XWiki's support
of the MariaDB database itself with XWiki's test infrastructure's
capability to support a MariaDB database container, which looks a bit
off-topic to me. I get that we need it integrated in our tests to detect
anomalies, but I don't really see it as an eliminatory criterion.

Thanks,
Eduard


>
> Thanks
> -Vincent
>
> > * Should we drop support for MySQL?
> >
> > Thanks
> > -Vincent
> >
> >> On 13 Nov 2018, at 11:50, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
> >>
> >> Hello,
> >>
> >> We are in a weird situation where we don't say we support MariaDB but
> >> "the latest
> >> MySQL version of stable Debian repository", which is currently...
> MariaDB
> >> [1]
> >>
> >> So we need to update our strategy about this fact. I am currently
> setting
> >> up a server with debian 9 (stable) and I don't know if I should install
> >> MySQL from the Oracle repository our continue with the standard debian
> >> package (MariaDB).
> >>
> >> On my side, I am not against aligning ourself to debian. Basically, all
> >> users installing XWiki with our Debian packages are using MariaDB for a
> >> year now [2], and we never encounter any problem so far.
> >>
> >> Thanks,
> >>
> >> [1] https://packages.debian.org/stretch/default-mysql-server (dep:
> >> mariadb-server-10.1)
> >> [2] https://www.debian.org/News/2017/20170617.en.html
> >>
> >> Le lun. 12 nov. 2018 à 18:54, Thomas Mortagne <
> thomas.morta...@xwiki.com> a
> >> écrit :
> >>
> >>> Indeed mysql-server package (version 5.5.) leads to
> >>> mariadb-server-10.1 in current stretch repository.
> >>>
> >>> What is surprising is that this is not the case for sid which is more
> >>> or less supposed to be the future. It's also not the case in Ubuntu
> >>> which is doing the same thing as sid.
> >>> On Mon, Nov 12, 2018 at 6:22 PM Eduard Moraru 
> >>> wrote:
> >>>>
> >>>> I am not up to date on the topic, but I would like to add the fact
> that
> >>>> Debian 9 ("stretch") has actually dropped MySQL and moved officially
> to
> >>>> MariaDB, forcefully migrating existing MySQL installed versions to
> >>> MariaDB.
> >>>>
> >>>>
> >>>
> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#mariadb-replaces-mysql
> >>>>
> >>>> The default mysql-server package now redirects to MariaDB instead.
> >>>>
> >>>> If we are going to follow Debian's lead, we might want to at least
> >>> consider
> >>>> this move.
> >>>>
> >>>> Thanks,
> >>>> Eduard
> >>>>
> >>>> On Mon, Nov 12, 2018 at 6:38 PM Vincent Massol 
> >>> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>>> On 12 Nov 2018, at 16:52, Vincent Massol 
> wrote:
> >>>>>>
> >>>>>> So we need to conclude on this thread. I’m proposing to update the
> >>> page
> >>>>> with:
> >>>>>>
> >>>>>> * HSQLDB - Latest only
> >>>>>> * MySQL - latest of oldstable/stable/unstable from
> >>>>>
> >>>
> https://packages.debian.org/search?keywords=mysql-server=names=1
> >>>>> (i.e. latest of 5.5.x and 5.7.x today)
> >>>>>> * PostgreSQL 

Re: [xwiki-devs] [Proposal] Update database support strategy

[Eduard Moraru]

I am not up to date on the topic, but I would like to add the fact that
Debian 9 ("stretch") has actually dropped MySQL and moved officially to
MariaDB, forcefully migrating existing MySQL installed versions to MariaDB.

https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#mariadb-replaces-mysql

The default mysql-server package now redirects to MariaDB instead.

If we are going to follow Debian's lead, we might want to at least consider
this move.

Thanks,
Eduard

On Mon, Nov 12, 2018 at 6:38 PM Vincent Massol  wrote:

>
>
> > On 12 Nov 2018, at 16:52, Vincent Massol  wrote:
> >
> > So we need to conclude on this thread. I’m proposing to update the page
> with:
> >
> > * HSQLDB - Latest only
> > * MySQL - latest of oldstable/stable/unstable from
> https://packages.debian.org/search?keywords=mysql-server=names=1
> (i.e. latest of 5.5.x and 5.7.x today)
> > * PostgreSQL -  latest of oldstable/stable/unstable fromhttps://
> packages.debian.org/search?keywords=postgresql=names=1
> (i.e. latest of 9.4.x, 9.6.x and 11.x today)
> > * Oracle - latest of 12.x (we currently test on 11.x AFAIK so we need to
> start testing on 12.x from now on)
> >
> > Note that by “support" we mean test on. And it’s not because a version
> is not supported that it doesn’t work nor that we won’t fix it if a problem
> happens.
> >
> > I hesitated a long time for the mysql/pgsql versions since I wanted only
> a single version supported, but since we provide a debian packaging it
> makes sense to test the versions defined by the debian repos, and now that
> we have automated functional tests on various configurations, we can test
> on them. BTW I suggest we run all tests on the latest version only (i.e.
> 5.7.x for mysql and 11.x for postgresql, and move to mysql 8.x when we fix
> the bug on it) and then we do smoke tests on the other versions.
> >
> > Let me know quickly if you have a problem with this strategy since I’d
> like to update the page + add the configs in our CI tests.
>
> FYI, I’ve now updated the page at
> https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy
> (but I can update/revert if need be).
>
> Thanks
> -Vincent
>
> >
> > Thanks
> > -Vincent
> >
> >
> >> On 31 Oct 2018, at 09:06, Vincent Massol  wrote:
> >>
> >> Hi devs,
> >>
> >> We currently have
> https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy
> >>
> >> However, it doesn’t say explicitly which versions we officially support:
> >> * For HSQLDB it says 2.3.3 which is wrong since the latest version is
> 2.4.1
> >> * For MySQL it says 5.x but doesn’t specify which specific version(s)
> >> * Same for other DBs
> >>
> >> We cannot really support every versions since supporting means testing
> too.
> >>
> >> So what I propose:
> >>
> >> Question 1: definition
> >>
> >> * We say we support the latest stable version of the databases for a
> given version cycle
> >> ** For MySQL, it’s the latest of the 5.x cycle, which is 5.7.24 as of
> today (see https://hub.docker.com/_/mysql/)
> >> ** For PostgreSQL,  it’s the latest of the 9.x cycle, which is 9.6.10
> as of today (see https://hub.docker.com/_/postgres/)
> >> ** For Oracle, it’s the latest of the 11.x cycle, which is 11.2.0.4.0
> as of today (see
> https://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html
> )
> >>
> >> Question 2: review what we support
> >>
> >> * For MySQL I think we could also start supporting MySQL 8.x (ie the
> latest version of that cycle). We have an issue open for it currently:
> https://jira.xwiki.org/browse/XWIKI-15215
> >> * For PostgreSQL we could also start supporting versions 11.x (ie the
> latest version of that cycle)
> >> * For Oracle, we could also start supporting versions 12.x (ie the
> latest version of that cycle)
> >>
> >> Question 3: decide if we drop some support
> >>
> >> * Is there any cycle that we should support for? Right now I think that
> MySQL 5.x is still heavily used, same for postgreSQL 9.x I guess. Don’t
> know for Oracle.
> >> * Any idea?
> >>
> >> So WDYT about the 3 questions?
> >>
> >> Thanks
> >> -Vincent
> >
>
>

[xwiki-devs] [ANN] XWiki 9.11.8 released

[Eduard Moraru]

The XWiki development team is proud to announce the availability of XWiki
9.11.8.

This is a bugfix release that covers important issues that we have
discovered since 9.11.7 has been released.

You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.11.8

Thanks for your support
-The XWiki dev team

Re: [xwiki-devs] [VOTE] Update the xar plugin and stop committing XML wiki page date fields

[Eduard Moraru]

Also, xar:format was executed at xwiki-platform level, in order for the
build not to fail.
https://github.com/xwiki/xwiki-platform/commit/053f0a2757cea18a5916632a58c6046ba61954cd
https://github.com/xwiki/xwiki-platform/commit/324c033cccdfe90074089e906e3960ff07156451

All other projects/extensions outside platform will have to execute a
xar:format on their own, at least once, after they upgrade to the new xar
plugin version. Of course, the behavior can be also skipped, if needed,
with details in https://dev.xwiki.org/xwiki/bin/view/Community/XARPlugin.

Thanks,
Eduard

On Mon, Sep 3, 2018 at 6:40 PM Eduard Moraru  wrote:

> Thanks for your votes.
>
> No -1s. The vote has passed.
>
> Done in https://jira.xwiki.org/browse/XCOMMONS-1447 and updated
> https://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/XWikiXMLFilesCodeStyle/
> .
>
> Thanks,
> Eduard
>
>
> On Mon, Aug 13, 2018 at 11:04 AM Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
>
>> +1
>>
>> 2018-08-07 10:48 GMT+02:00 Marius Dumitru Florea <
>> mariusdumitru.flo...@xwiki.com>:
>>
>> > +1
>> >
>> > Thanks,
>> > Marius
>> >
>> > On Tue, Jul 31, 2018 at 7:43 PM, Eduard Moraru 
>> > wrote:
>> >
>> > > Hi, devs.
>> > >
>> > > We have had 2 previous discussions on this topic:
>> > > * July 2016 (discussion):
>> https://markmail.org/thread/oodciq7pv6pj7eic
>> > > * Jan 2018 (proposal): https://markmail.org/thread/ymwsebvr3k7voy3p
>> > >
>> > > And we have at least 2 issues on this topic:
>> > > * Oct 2011: XWIKI-7058 <http://jira.xwiki.org/browse/XWIKI-7058>:
>> Page
>> > > creation date should be the date of the installation
>> > > * Feb 2015: XCOMMONS-1447 <
>> https://jira.xwiki.org/browse/XCOMMONS-1447>:
>> > > XAR plugin should replace the dates with a common number
>> > >
>> > > TL;DR: It's causing confusion for our users to install pages that are
>> > > created in 2005/2009/etc. so we should avoid committing dates on git
>> that
>> > > users might end up installing.
>> > >
>> > > Reminder: Importing a document with empty dates will:
>> > > * Use the current date if the document is new (i.e. does not exist in
>> the
>> > > wiki)
>> > > * Use the existing dates if the document already exists in the wiki,
>> if
>> > > using backup import
>> > > * Use the current user and current date for the document update date,
>> if
>> > > imported using non-backup import of EM extension install
>> > >
>> > > Adel and myself have extended the xar:verify and xar:format goals of
>> the
>> > > xar plugin to check for the existence of date fields in the XML wiki
>> > pages
>> > > and to remove them. The fields are:
>> > > * date
>> > > * contentUpdateDate
>> > > * creationDate
>> > > * attachment/date
>> > >
>> > > See the PR https://github.com/xwiki/xwiki-commons/pull/44/
>> > >
>> > > This check (on both verify and format goals) is skippable entirely
>> with
>> > the
>> > > "xar.dates.skip property" (default to false) or
>> > > "xar.dates.skip.documentList" for individual documents (list of doc
>> > > references).
>> > >
>> > > I need your vote for accepting the existing PR and for removing the
>> > > document dates (e.g. https://github.com/xwiki/xwiki-platform/pull/792
>> )
>> > and
>> > > your feedback in case you know of any problems that this might create.
>> > >
>> > > Also, please mention if you would prefer for this behavior to be
>> skipped
>> > by
>> > > default (and explicitly enabled on XWiki Standard, so that 3rd party
>> code
>> > > is not impacted by this change).
>> > >
>> > > Here's my +1 (enabled by default and skippable if needed).
>> > >
>> > > Thanks,
>> > > Eduard
>> > >
>> >
>>
>>
>>
>> --
>> Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
>> Research & Development Engineer at XWiki SAS
>> Committer on the XWiki.org project
>>
>

Re: [xwiki-devs] [VOTE] Update the xar plugin and stop committing XML wiki page date fields

[Eduard Moraru]

Thanks for your votes.

No -1s. The vote has passed.

Done in https://jira.xwiki.org/browse/XCOMMONS-1447 and updated
https://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/XWikiXMLFilesCodeStyle/
.

Thanks,
Eduard


On Mon, Aug 13, 2018 at 11:04 AM Guillaume Delhumeau <
guillaume.delhum...@xwiki.com> wrote:

> +1
>
> 2018-08-07 10:48 GMT+02:00 Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com>:
>
> > +1
> >
> > Thanks,
> > Marius
> >
> > On Tue, Jul 31, 2018 at 7:43 PM, Eduard Moraru 
> > wrote:
> >
> > > Hi, devs.
> > >
> > > We have had 2 previous discussions on this topic:
> > > * July 2016 (discussion): https://markmail.org/thread/oodciq7pv6pj7eic
> > > * Jan 2018 (proposal): https://markmail.org/thread/ymwsebvr3k7voy3p
> > >
> > > And we have at least 2 issues on this topic:
> > > * Oct 2011: XWIKI-7058 <http://jira.xwiki.org/browse/XWIKI-7058>: Page
> > > creation date should be the date of the installation
> > > * Feb 2015: XCOMMONS-1447 <https://jira.xwiki.org/browse/XCOMMONS-1447
> >:
> > > XAR plugin should replace the dates with a common number
> > >
> > > TL;DR: It's causing confusion for our users to install pages that are
> > > created in 2005/2009/etc. so we should avoid committing dates on git
> that
> > > users might end up installing.
> > >
> > > Reminder: Importing a document with empty dates will:
> > > * Use the current date if the document is new (i.e. does not exist in
> the
> > > wiki)
> > > * Use the existing dates if the document already exists in the wiki, if
> > > using backup import
> > > * Use the current user and current date for the document update date,
> if
> > > imported using non-backup import of EM extension install
> > >
> > > Adel and myself have extended the xar:verify and xar:format goals of
> the
> > > xar plugin to check for the existence of date fields in the XML wiki
> > pages
> > > and to remove them. The fields are:
> > > * date
> > > * contentUpdateDate
> > > * creationDate
> > > * attachment/date
> > >
> > > See the PR https://github.com/xwiki/xwiki-commons/pull/44/
> > >
> > > This check (on both verify and format goals) is skippable entirely with
> > the
> > > "xar.dates.skip property" (default to false) or
> > > "xar.dates.skip.documentList" for individual documents (list of doc
> > > references).
> > >
> > > I need your vote for accepting the existing PR and for removing the
> > > document dates (e.g. https://github.com/xwiki/xwiki-platform/pull/792)
> > and
> > > your feedback in case you know of any problems that this might create.
> > >
> > > Also, please mention if you would prefer for this behavior to be
> skipped
> > by
> > > default (and explicitly enabled on XWiki Standard, so that 3rd party
> code
> > > is not impacted by this change).
> > >
> > > Here's my +1 (enabled by default and skippable if needed).
> > >
> > > Thanks,
> > > Eduard
> > >
> >
>
>
>
> --
> Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
>

Re: [xwiki-devs] [contrib] Page Preview Popover extension request

[Eduard Moraru]

Hi, Stephane.

On Tue, Aug 28, 2018 at 10:49 AM Stéphane Laurière 
wrote:

> Vincent Massol:
> > Hi Stephane,
> >
> >> On 28 Aug 2018, at 08:55, Stéphane Laurière 
> wrote:
> >>
> >> Hi all,
> >>
> >> I would like to contribute an extension that will display page preview
> popovers when hovering wiki links, similarly to what MediaWiki offers:
> >>
> >>   https://www.mediawiki.org/wiki/Page_Previews
> >>   https://blog.wikimedia.org/2018/05/09/page-previews-documentation/


Sounds like a nice extension!

However, how are you going to extract the "summary" of a page? In
Wikipedia, pages have a certain structure and, at the beginning of each
page, you have at least the first paragraph that is describing the
resource. Even the Wikipedia API allows you to get the "extract"
(summary/topic) of a page and that is what the Wikipedia feature is using
as text content to display in that preview popup.

In XWiki, the usecases are not defined and you could have anything inside a
page. Do you plan to show the entire page content inside that preview? Do
you plan to have an empirical approach in order to get some sort of summary
by e.g. displaying just the first paragraph as well? What's the approach?


>
> >
> > Sounds nice. Do you plan to implement it as a Rendering Transformation
> (similar to what the Glossary app do) or as Javascript code?
>

Definitely  JavaScript + REST API would be the way to go here, to avoid
rendering, at display time, all the linked pages on the server side. Each
preview should be obtained when the user asks for it, i.e. when displaying
the preview. Optimisations could be done to prefetch the data, but that
would also increase the network traffic and server load, while improving
the user experience (i.e. not having to wait for the preview popup to load
its content).


> Actually I had not considered the rendering transformation option. At
> first glance, plain JavaScript code seems more lightweight to me without
> any downside but if you see pros for using a transformation, please let me
> know. There's one issue with plain JavaScript at the moment though: the
> Bootstrap popover feature in version 3.x adds a div next to the clicked
> element. In our case, this means adding a div to the surrounding
> span.wikilink, which is not allowed in HTML5. However, Bootstrap 4 popovers
> work differently: they're added as direct childs of the body:
> https://getbootstrap.com/docs/4.0/components/popovers/ so the issue will
> be fixed once we migrate. What do you think? Can we live with a div in a
> span for now?
>

I'm not really sure what you mean. When the popover is displayed, a div is
indeed created with javascript and added as sibling to the popover trigger
element. If you make the "span" element the trigger instead of the link,
then you would get perfectly valid HTML. Example with Bootstrap 3:
http://jsfiddle.net/vqT5f/1322/

Thanks,
Eduard


>
> >> Its name could be 'application-page-preview-popover' - what do you
> think? As discussed with Caty yesterday, the extension will use the
> Bootstrap popovers. Should you have any need or suggestion, please let me
> know.
> >
> > So it depends on the technology you wish to use. If it’s a
> transformation, I would name it "transformation-preview”. If it’s
> JS/webjar, I guess you’ll need a JSX object to load it so I guess
> "application-page-preview” would be fine.
>
> I see, but in any case, with or without a transformation, I think we will
> need some JS + CSS code anyway, won't we? As far as I can see, the glossary
> extension is an application containing a transformation, so we could go for
> "application-page-preview" as well, with or without transformation, what do
> you think?
>
> Stéphane
>
>
> > Thanks
> > -Vincent
> >
> >> If the name is ok, can I ask you for the creation of a repository and
> JIRA project?
> >>
> >> Stéphane
> >>
> >>
> >> --
> >> Stéphane Laurière
> >> XWiki www.xwiki.com
> >> @slauriere
> >>
> >
>
>
> --
> Stéphane Laurière
> XWiki www.xwiki.com
> @slauriere
>
>

[xwiki-devs] [GSoC] Reminder: Final evaluation deadline on August 14, 16:00 UTC (less than 2 weeks)

[Eduard Moraru]

Hello, GSoC students and mentors.

A final reminder about the Final evaluation that is quickly coming up [1]:

  *August 6 at 16:00 UTC*: Student Final Evaluation period starts
  *August 6-14*: Students submit their Final Evaluation which includes:
  1) link to their work product (code) and
  2) their Final Evaluation of their Mentor
  *August 14 16:00 UTC*: Deadline for Students to submit their Final
Evaluation

Same as previous, make sure you are clear on the expectations and do not
forget to properly document and package your student "work product" (i.e.
everything you have worked on during the GSoC) and fill in the final
evaluation, when requested by Google.

Students and mentors need to work together and make sure the work package
respects the requirements [2]. Students should not submit the their final
evaluation before consulting with the mentor regarding the work package
link.

Also, as suggested in the requirements [2], this would be the perfect time
to blog about your experience and the work you've done during this summer.

Hope you've had a great time and, based on your evolution, to see you on
the list of successful students ;)

Thanks,
Eduard

--
[1] https://developers.google.com/open-source/gsoc/timeline
[2] https://developers.google.com/open-source/gsoc/help/work-product

[xwiki-devs] [VOTE] Update the xar plugin and stop committing XML wiki page date fields

[Eduard Moraru]

Hi, devs.

We have had 2 previous discussions on this topic:
* July 2016 (discussion): https://markmail.org/thread/oodciq7pv6pj7eic
* Jan 2018 (proposal): https://markmail.org/thread/ymwsebvr3k7voy3p

And we have at least 2 issues on this topic:
* Oct 2011: XWIKI-7058 : Page
creation date should be the date of the installation
* Feb 2015: XCOMMONS-1447 :
XAR plugin should replace the dates with a common number

TL;DR: It's causing confusion for our users to install pages that are
created in 2005/2009/etc. so we should avoid committing dates on git that
users might end up installing.

Reminder: Importing a document with empty dates will:
* Use the current date if the document is new (i.e. does not exist in the
wiki)
* Use the existing dates if the document already exists in the wiki, if
using backup import
* Use the current user and current date for the document update date, if
imported using non-backup import of EM extension install

Adel and myself have extended the xar:verify and xar:format goals of the
xar plugin to check for the existence of date fields in the XML wiki pages
and to remove them. The fields are:
* date
* contentUpdateDate
* creationDate
* attachment/date

See the PR https://github.com/xwiki/xwiki-commons/pull/44/

This check (on both verify and format goals) is skippable entirely with the
"xar.dates.skip property" (default to false) or
"xar.dates.skip.documentList" for individual documents (list of doc
references).

I need your vote for accepting the existing PR and for removing the
document dates (e.g. https://github.com/xwiki/xwiki-platform/pull/792) and
your feedback in case you know of any problems that this might create.

Also, please mention if you would prefer for this behavior to be skipped by
default (and explicitly enabled on XWiki Standard, so that 3rd party code
is not impacted by this change).

Here's my +1 (enabled by default and skippable if needed).

Thanks,
Eduard

Re: [xwiki-devs] [New extension request] Reference displayer application

[Eduard Moraru]

Yes, but where do you draw the line?

The same argument goes for any new feature. Do we handle new features as
part of the product or always as installable extensions?

For this case, as mentioned, we already had the issue and previous
investigation on it, so it only made sense to expect it to be part of the
product... hence my remark.

Let's see what others think...

Thanks,
Eduard

On Mon, Jul 30, 2018, 16:52 Clément Aubin  wrote:

> Hello hello,
>
> On 07/30/2018 12:56 AM, Eduard Moraru wrote:
> > Hi,
> >
> > Note that this should not really be done as an extension, since a product
> > issue already exists on it and previous iterations have been
> done/discussed.
> AFAIR the use case that we have is mostly to allow users working on old
> versions on XWiki to actually use the extension. We don't want them to
> upgrade XWiki just to get this functionality.
>
> Thanks,
> Clément
>
> > https://jira.xwiki.org/browse/XWIKI-13362
> >
> > Thanks,
> > Eduard
> >
> > On Fri, Jul 27, 2018 at 10:49 AM, Clément Aubin 
> > wrote:
> >
> >> Done, see :
> >>
> >> * https://github.com/xwiki-contrib/application-reference-displayer
> >> * https://jira.xwiki.org/projects/REFDISP
> >>
> >> Thanks,
> >> Clément
> >>
> >> On 07/27/2018 09:43 AM, Clément Aubin wrote:
> >>> Hi devs,
> >>>
> >>> Anca and I would like to create a new contrib extension named
> >>> "application-reference-displayer".
> >>>
> >>> The idea is quite simple : have a new block in the "information" tab of
> >>> a wiki document that shows the technical document reference (or page
> >>> reference is the wiki version fits).
> >>>
> >>> I'll take care of creating the GH repository / JIRA project myself.
> >>>
> >>> Thanks,
> >>> Clément
> >>>
> >>
>

Re: [xwiki-devs] [Proposal] Velocity Test Coverage strategy

[Eduard Moraru]

+1

It would also be nice to eventually have some kind of reporting UI, similar
to jacoco that allows you to drill down towards the affected pages/vm
files, preferably ending with some highlighted view of the covered/not
covered lines.

Thanks,
Eduard

On Sun, Jul 29, 2018 at 7:09 PM, Adel Atallah 
wrote:

> On Sun, Jul 29, 2018 at 5:56 PM, Vincent Massol 
> wrote:
> > Hi devs,
> >
> > During XWiki SAS’s hackathon last week, Simon and me worked on
> implementing test coverage computation for velocity code and more precisely
> to measure the code coverage we get in XWiki XML pages when running our
> tests.
> >
> > The rationale is that we know what’s our java test coverage but we have
> no clue about the velocity one. And we have a lot of code in velocity
> scripts in wiki pages. Thus we need a strategy for this too if we wish to
> increase our global code quality.
> >
> > So we have currently developed 2 mojos (xar:instrument and
> xar:reportCoverage) in the XAR plugin code and created a JIRA issue, see
> XCOMMONS-1448.
> >
> > Here’s the proposal I’d like your opinion on:
> > * Finish working on this to stabilize it and commit/push it
> > * Apply the same strategy we have with Jacoco for java test coverage,
> i.e. introduce a new xar:coverageCheck mojo that will fail the build if we
> get a global TPC under the threshold mentioned in the POM
> >
> > Consequences:
> > * It will mean that whenever we add new velocity scripts (especially
> when there are branches such as #if) we will need to improve or add XAR
> page tests. This can be done in 2 ways:
> > ** by writing/improving a functional UI test
> > ** by writing/improving a XAR unit test
> > * We will find places that have 0% coverage and these will be good
> candidates to add tests for
> >
> > My POV:
> > * We should have the minimum # of functional UI tests since they take
> very long to execute. We need them but we shouldn’t test the various
> branches with them IMO. Only one path.
> > * Instead we should focus on have more of XAR unit tests since they
> execute fast and are better suited (with mocks) to test the various branches
> > * The XAR unit test framework we have is still pretty new and it’s
> probably not to easy to write unit tests for wiki pages in some cases, we
> will need to work on that as we discover them. I’m happy to help on that.
> >
> > WDYT?
> >
> > Personally I’m ok to try it and see what happens.
> >
> > Thanks
> > -Vincent
>
> +1
>

Re: [xwiki-devs] [New extension request] Reference displayer application

[Eduard Moraru]

Hi,

Note that this should not really be done as an extension, since a product
issue already exists on it and previous iterations have been done/discussed.

https://jira.xwiki.org/browse/XWIKI-13362

Thanks,
Eduard

On Fri, Jul 27, 2018 at 10:49 AM, Clément Aubin 
wrote:

> Done, see :
>
> * https://github.com/xwiki-contrib/application-reference-displayer
> * https://jira.xwiki.org/projects/REFDISP
>
> Thanks,
> Clément
>
> On 07/27/2018 09:43 AM, Clément Aubin wrote:
> > Hi devs,
> >
> > Anca and I would like to create a new contrib extension named
> > "application-reference-displayer".
> >
> > The idea is quite simple : have a new block in the "information" tab of
> > a wiki document that shows the technical document reference (or page
> > reference is the wiki version fits).
> >
> > I'll take care of creating the GH repository / JIRA project myself.
> >
> > Thanks,
> > Clément
> >
>

Re: [xwiki-devs] First batch of the new experimental Page oriented APIs

[Eduard Moraru]

On Mon, Jul 9, 2018 at 11:45 AM, Vincent Massol  wrote:

> Hi Marius,
>
> > On 9 Jul 2018, at 10:24, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > On Sat, Jul 7, 2018 at 8:55 PM, Eduard Moraru 
> wrote:
> >
> >> Great to hear you're progressing on this topic, Thomas!
> >>
> >> My only note was also (as Vincent pointed out) on the link syntax. If we
> >> went with "/" instead of "." was because people were more accustomed to
> the
> >> URL syntax and also that they would be more tempted to copy the URL as a
> >> wiki link, instead of converting "/" to ".".
> >>
> >>
> >
> >> Now, why don't we apply the same logic to parameter separators (i.e.
> >> instead of ";" to use "&" and, hopefully, instead of "?" as the
> parameters
> >> separator).
> >>
> >
> > You are mixing the query string with the URL path parameters
> > https://doriantaylor.com/policy/http-url-path-parameter-syntax . The
> query
> > string is for the entire URL/path while each path segment can have its
> > parameters. In our case each entity reference from the chain can have its
> > own parameters.
>
> That’s a good rationalization :) I like it!
>
> Does Thomas’s implementation allows each entity reference in the chain to
> have parameters, such as for example:
>
> wiki:page1;a=b/page2;c=d/image.png;e
>

First time I see this syntax. I was not aware of these path-segment
parameters in the URI definitiion, however, I do not really find them
useful in XWiki's model and feel that they would only complicate things.

Let's take an example (the only one I managed to find that manages to make
some kind of sense):

[[wiki:TopPage/ChildPage;fr_FR/FinalPage;en_US||queryString="param1=value1"]]

What would this mean? That we want a link to the English translation of
"FinalPage" that is a child of the French translation of "ChildPage",
which, in turn, is a child of the (default translation or simply "page")
"TopPage"... and, for FinalPage, add the query string parameters
"param1=value1".

This does not make much sense to me, as we currently only have locale
parameters to EntityReferences, AFAIK. Also, what URL would this wiki link
be generating, since right now we don't have support for path-based
parameters in the URL handler. Do we plan to add it? IMO, it would scare
users even more than they are now :)

And finally, I am not sure it would be a good idea to parametrize the
individual EntityReferences (actually PageReferences themselves) that make
up the final PageReference, as it would exponentially increase the
complexity of the branches that would be possible in order to reach the
same page. Actually, I would kind of be against that:

[[wiki:TopPage/ChildPage;fr_FR/FinalPage]]
[[wiki:TopPage/ChildPage;en_US/FinalPage]]
[[wiki:TopPage;ro_RO/ChildPage;fr_FR/FinalPage]]
[[wiki;p1=v1:TopPage/ChildPage;fr_FR/FinalPage]]
etc.
...
(potentially, each path being a completely different page/entity; e.g. fr
content differs from the en content or wiki with parameter is something
else than wiki without)

Maybe we are missing a bit of context here, as Thomas did not explain the
need that generated this feature, together with some better example. From
his only example, I only concluded that he was talking about a query string
parameters syntax, hence my remark, to which I am still sticking:

Example:
[[wiki:TopPage/ChildPage/FinalPage?param1=value1=value2]]

Thanks,
Eduard


> ?
>
> Thanks
> -Vincent
>
> >
> >>
> >> Also, are we considering anchors as well (i.e. using "#MyHeading"
> instead
> >> of "|anchor='HMyHeading'")?
> >>
> >> Ideally, it would be awesome if we could say that copy/pasting the exact
> >> URL, right after the action part, would be supported when adding a wiki
> >> link.
> >>
> >> Slightly off-topic, but related to that last part, so it might not be a
> bad
> >> idea to talk about it:
> >> This actually gets me realising that we don't have a way to link in pure
> >> wiki syntax to a page in a specified mode/action (i.e. not only view,
> but
> >> also edit/create/delete/etc.). Sure, we have the "path:" type, but
> that's
> >> not exactly designed for that, but for whatever else we might need, and
> it
> >> require either writing, by hand, technical details or to use velocity
> (i.e.
> >> $xwiki.getURL($doc, 'mode')).
> >>
> >> Thanks,
> >> Eduard
> >>
> >> On Fri, Jun 29, 2018 at 7:20 PM, Thomas Mortagne <
>

[xwiki-devs] [GSoC] Reminder: 2nd evaluation deadline on July 13, 16:00 UTC (less than 1 week)

[Eduard Moraru]

Hello, GSoC students and mentors.

Quick reminder about the 2nd evaluation that is quickly coming up [1]:

  July 9 16:00 UTC Mentors and students can begin submitting Phase 2
evaluations
  July 13 16:00 UTC Phase 2 Evaluation deadline
Same as last time, make sure you are clear on the expectations and *do not
forget to fill in your evaluations* when asked by Google.

You should be quite far now into your projects and things should have
already begun taking shape. Don't be shy in sharing your progress ;)

As always, have fun and build cool stuff!

Thanks,
Eduard

--
[1] https://developers.google.com/open-source/gsoc/timeline

Re: [xwiki-devs] First batch of the new experimental Page oriented APIs

[Eduard Moraru]

Great to hear you're progressing on this topic, Thomas!

My only note was also (as Vincent pointed out) on the link syntax. If we
went with "/" instead of "." was because people were more accustomed to the
URL syntax and also that they would be more tempted to copy the URL as a
wiki link, instead of converting "/" to ".".

Now, why don't we apply the same logic to parameter separators (i.e.
instead of ";" to use "&" and, hopefully, instead of "?" as the parameters
separator).

Also, are we considering anchors as well (i.e. using "#MyHeading" instead
of "|anchor='HMyHeading'")?

Ideally, it would be awesome if we could say that copy/pasting the exact
URL, right after the action part, would be supported when adding a wiki
link.

Slightly off-topic, but related to that last part, so it might not be a bad
idea to talk about it:
This actually gets me realising that we don't have a way to link in pure
wiki syntax to a page in a specified mode/action (i.e. not only view, but
also edit/create/delete/etc.). Sure, we have the "path:" type, but that's
not exactly designed for that, but for whatever else we might need, and it
require either writing, by hand, technical details or to use velocity (i.e.
$xwiki.getURL($doc, 'mode')).

Thanks,
Eduard

On Fri, Jun 29, 2018 at 7:20 PM, Thomas Mortagne 
wrote:

> On Fri, Jun 29, 2018 at 3:10 PM, Vincent Massol 
> wrote:
> > Hi Thomas,
> >
> > Good work!
> >
> > See below
> >
> >> On 29 Jun 2018, at 14:29, Thomas Mortagne 
> wrote:
> >>
> >> Hi xwikiers,
> >>
> >> Some of us discussed that for a while and created/improved
> >> http://design.xwiki.org/xwiki/bin/view/Proposal/
> DeprecatingSpaceAndSpaceReference
> >> and I finally started working on it.
> >>
> >> So here is what I pushed on master already:
> >>
> >> = PAGE EntityType and Page*Reference classes
> >>
> >> First thing first we now have a few new type in EntityType and the
> >> corresponding typed Page*Reference helpers. One for each of the
> >> element you can have in a page:
> >> * PAGE
> >> * PAGE_ATTACHMENT
> >> * PAGE_OBJECT
> >> * PAGE_OBJECT_PROPERTY
> >> * PAGE_CLASS_PROPERTY
> >>
> >> = Corresponding resolvers/serializer/providers
> >>
> >> Each of the already existing DOCUMENT oriented resolvers and
> >> serializers have their PAGE oriented implementation.
> >>
> >> = Conversion from DOCUMENT to PAGE world
> >>
> >> The entity resolvers automatically convert from/to DOCUMENT from/to
> >> PAGE world references. Do yes using a resolver is the official way to
> >> do that conversion.
> >>
> >> = Model script service
> >>
> >> The $services.model API also got his own new helpers to manipulate pages
> >>
> >> = New syntax
> >>
> >> Last but not least: pages reference have a very different syntax.
> >>
> >> To summarize it's a filesystem path syntax with support for parameters.
> >>
> >> Here is are a few examples:
> >>
> >>wiki:page1/page2;param1=value1;param2=value2;en_US
> >>
> >>wiki:page1/page2/attachment
> >>
> >>../siblingpage
> >>
> >> * separator: "/" between all elements except WIKI which is still ":"
> >> * escaping: still "\"
> >> * current, parent support: like in a filesystem you can refer to the
> >> current page or parent page/wiki using "." and ".."
> >> * parameters: we now have syntax to express the parameters of an
> >> EntityReference. Each parameter is separated by a ";" at the end of
> >> the entity name
> >
> > Should we use “?” as the delimiter between reference and parameters to
> be closer to URI/URL syntax?
>
> This was my initial proposal but it was decided that ? was too common.
>
> >
> > 
> > Maybe we could even have a Page Reference be implemented as a
> hierarchical URI? (the wiki would be the scheme, the authority would be
> empty and fragments would be empty).
> >
> > In practice it would be hard since we need to have PageReference extends
> EntityReference. But if we were starting from scratch we would maybe use a
> URI or extend it.
> >
> > Sill it might make sense to at least be closer on the syntax aspect and
> thus use “?” for the delimiter.
> > 
> >
> >> * default parameter: the syntax have the concept of default parameter
> >> which mean a parameter for which you don't need to indicate the name.
> >> For example PAGE reference default parameter is “locale"
> >
> > "a parameter for which you don't need to indicate the name” —> does that
> mean for example:
> >
> > wiki:page1/page2;en_US
>
> Yes as you can see in the example I gave.
>
> >
> > ?
> >
> > What is the need? I’d find "wiki:page1/page2;locale=en_US” to be more
> explicit.
>
> You can write the name if you want. The idea is that right now that's
> actually our only really used parameter in reference and it's nicer to
> not have to write "local=" all the time
>
> >
> >> = TODO
> >>
> >> The next elements on the short term TODO list are:
> >>
> >> * support for page references in XWiki#getDocument (which essentially
> >> means add a fallback)
> >> * support for page references in various macros 

[xwiki-devs] [ANN] XWiki 10.5 released

[Eduard Moraru]

The XWiki development team is proud to announce the availability of XWiki
10.5.

This release improves the visibility of the save button in edit mode and
completes retro-compatibility of the new Notifications with the old
Activity Stream by handling messages. Admins get more options on deciding
how to protect extension pages from user modifications but also easy
customization options for the Navigation panel.

You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.5

Thanks for your support
-The XWiki dev team

[xwiki-devs] [GSoC] Reminder: First evaluation deadline on 15th of June 16:00 UTC (1 week)

[Eduard Moraru]

Hello, GSoC students and mentors.

I would like to remind you that the first evaluation deadline is
approaching at the end of next week. Below is an extract from the
timeline[1]:

  June 11 16:00 UTC Mentors and students can begin submitting Phase 1
evaluations
  June 15 16:00 UTC Phase 1 Evaluation deadline

As a result, please make sure students talk to their mentors and make sure
they are prepared and understand what is expected from them in order to
successfully pass the evaluation.

Very important:
Do not forget to actually fill in the evaluation, when asked by Google, as
not doing so (either by the student or the mentor) will cause the student
to be failed by default, even if they did a great job so far. So *both*
mentors and students need to fill in evaluations, and not only mentors!

Hope you're having a great time, learning and building cool stuff!

Thanks,
Eduard

--
[1] https://developers.google.com/open-source/gsoc/timeline

Re: [xwiki-devs] [Brainstorming] Best practices on indentation for rendering macros in scripts

[Eduard Moraru]

+1 for A-2, since I find it more consistent and logical for an element that
accepts inner content to indent that content, once it spans on multiple
lines (since you can also have the inline version). It would be consistent
with the indentation policy we apply for HTML as well.

I can't find many arguments for making an exception for them, other than
the fact that the velocity and HTML macros tend to be used quite loosely
(i.e. pages with entire content wrapped by a start and end velocity macro),
but we are talking generally about all rendering macros, so I think it
makes sense to indent. The SyntaxHighlighting enabled wiki editor also
helps in indenting multiple lines at the same time.

Note: One thing that I remember that needs fixing in the SH enabled editor
is the "decrease indentation" operation (i.e. SHIFT+TAB should decrease the
indentation of the selected lines by one level) which is now configured to
do "auto-indentation" instead (i.e. indent the lines to the level dictated
by the context, a bit similar to the "Auto-Formatting" option in Eclipse,
or other IDEs). However, I don't remember hearing many people complain
about this yet, so maybe it's not that painful, but would still need fixing.

Thanks,
Eduard

On Wed, Jun 6, 2018 at 12:59 PM, Thomas Mortagne 
wrote:

> I'm OK with both but I prefer A-2 which is more readable and more logical
> IMO.
>
> On Wed, Jun 6, 2018 at 11:49 AM, Vincent Massol 
> wrote:
> > Hi,
> >
> > Context 1: https://jira.xwiki.org/browse/WIKIEDITOR-58
> > Context 2: Fill the “velocity code style” section of
> http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/
> >
> > Option A-1: No top level indentation
> > =
> >
> > {{velocity}}
> > #set ($var = …)
> > #if (…)
> >   …
> >   #if (…)
> >   #end
> > #end
> > {{/velocity}}
> >
> > Nested example:
> >
> > {{velocity}}
> > #if ($doc.fullName != 'XWiki.AdminInlineSheet')
> >   #set($formname = 'inline')
> >   #set($saveaction = 'save')
> >   #set($previewenabled = true)
> >   #set($xnotification = $!request.getParameter('xnotification'))
> >   {{html}}
> >   
> > 
> > …
> > {{/velocity}}
> >
> > Pros:
> > * This is what we currently do which IMO means it’s the more natural way
> > * Makes content more visible when editing inside xwiki since it takes
> less horizontal space
> > * Less typing and less chance to make it wrong
> >
> > Option A-2: Top level indentation
> > 
> >
> > {{velocity}}
> >   #set ($var = …)
> >   #if (…)
> > …
> > #if (…)
> > #end
> >   #end
> > {{/velocity}}
> >
> > Nested example:
> >
> > {{velocity}}
> >   #if ($doc.fullName != 'XWiki.AdminInlineSheet')
> > #set($formname = 'inline')
> > #set($saveaction = 'save')
> > #set($previewenabled = true)
> > #set($xnotification = $!request.getParameter('xnotification'))
> > {{html}}
> >   
> > 
> > …
> > {{/velocity}}
> >
> > Pros:
> > * More logical since a macro is a container (even though it’s different
> syntax - wiki markup vs velocity - so it’s arguable)
> > * More legible?
> >
> > Cons
> > * This means slowly changing everywhere we use scripting.
> >
> > WDYT?
> >
> > I think my preference goes to A-1 FTM since I’ve never thought to myself
> that it was an issue all these years of using it.
> >
> > Thanks
> > -Vincent
> >
> >
>
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [Proposal] Display user messages in the notifications.

[Eduard Moraru]

Hi,

(sorry for not reading the discussions above, I hope to get to read them at
some point)

I just wanted to remind you that:
1. We (at least I did) have previously concluded that it was a *mistake* to
mix notifications with messages.
1.1 Notifications have transient lifecycle and can be easily discarded. The
previous ActivityStream implementation actually had a periodic
notifications/events cleaner that would automatically delete events older
than (e.g.) 30 days, for both storage and performance reasons.
1.2 Messages have a much longer lifecycle, some users choosing to never
delete them and keep record of all conversations they ever had with someone.
1.3 Mixing storage for the 2 is a recipe for disaster, IMO, and, if/when we
plan to handle it seriously, we should either implement or integrate a
separate solution for messaging, both on the storage and the UI level. IMO,
the biggest intersection between Notifications and Messaging is the ability
to receive a notification about the fact that you have received a message
from X. Reading the message and acting upon it (i.e. replying, etc.) should
be done in the dedicated UI of the Messaging Application (i.e. inbox/etc.).

2. We *don't have to* and *shouldn't* keep all the features of the previous
system. Instead, this was supposed to be a good opportunity to improve on
our previous mistakes, not repeat them, in a new and improved system.

3. The Network/Follow feature is still a nice feature to stay up to date
with the activity of some users of interest. The "Send message to
followers", however, is, IMO, outside the scope of Notifications.

4. When talking about Messaging, we can also distinguish 2 types of
messages: public and private.
4.1 Private messages should, IMO, necessarily be addressed with the
Messaging application detailed at 1. Also, private messages need to be
trustworthy, as they can/do usually contain sensitive information. The data
should not be deleted and it should be properly protected.
4.2 Public messages, that have a more transient nature, could be the scope
of some "Announcements" application, that could behave as Notifications.
Couple that with the ability to interact with events (i.e. reactions or
comments on the page displayed under the event) and you get a very live and
social environment.

Thanks,
Eduard

On Thu, May 31, 2018 at 7:19 PM, Vincent Massol  wrote:

>
>
> > On 31 May 2018, at 18:07, Clément Aubin  wrote:
> >
> > On 05/31/2018 05:44 PM, Vincent Massol wrote:
> >>
> >>
> >>> On 31 May 2018, at 17:28, Clément Aubin  wrote:
> >>>
> >>> On 05/31/2018 04:42 PM, Vincent Massol wrote:
> >>>
> >>> […]
> >>>
> > I'm here describing my own usage of collaborative platforms or social
> > networks. If it wasn't supported before today, maybe we should think
> > about it, because usually, people with only one friend to talk to are
> > rare. Having multiple conversation is something that we should at
> least
> > think about.
> 
>  Did I say we should not think about it?
> >>>
> >>> Oh I'm sure that you didn't said that, but this would need a more
> >>> in-depth investigation, and not just 2 days of implementation.
> >>
> >> No no this is out of scope for now.
> >>
> >>>
>  Also as I wrote you can send to a group and to everyone too so yes
> you can send to multiple people.
> >>>
> >>> I'm not talking about sending a message to groups, but to multiple
> >>> individuals.
> >>
> >> I know and out of scope for now.
> >>
> >>>
> > Also, as you mentioned it in the end of your previous mail, "if we do
> > nothing now, nothing will happen for at least 1 year", what makes you
> > think that we'll have the time to improve the feature later on, even
> if
> > we do need it ?
> 
>  Ok so we have a big disagreement:
>  * You say “displaying notifications in the proposed way is bad thing
> and there’s no use case for it”
> >>>
> >>> Please don't rephrase me like that :) . The current notifications are,
> >>> IMO correctly displayed (and we're not debating about how to display
> >>> notifications AFAIK).
> >>
> >> Sorry I meant ‘displaying messages in the notifications UI in the
> proposed way is a bad thing and there’s no use case for it”
> >>
> >>> However, I don't think that the notification
> >>> center has been crafted to correctly display user messages. Merging
> >>> events coming from the wiki and messages coming from the message stream
> >>> is tricky.
> >>
> >> Why? They’re both coming from the same location, i.e. event table…
> >
> > Mostly because user messages (as in private, user to user messages) can
> > be related from one to another (ie : the message B that you just sent me
> > is a response from the message A that I sent you). You will then need
> > some context to display the response from someone in your notification
> > center. I don't think that we have an easy way to do that now.
>
> We could actually (since the event stream allows for 4-5 custom params).
>
> However, I 

Re: [xwiki-devs] [Proposal] CAPTCHA module refactoring

[Eduard Moraru]

On Fri, May 25, 2018 at 4:55 PM, Vincent Massol <vinc...@massol.net> wrote:

> Hi Edy,
>
> > On 25 May 2018, at 14:02, Eduard Moraru <enygma2...@gmail.com> wrote:
> >
> > Hi,
> >
> > On Fri, May 25, 2018 at 10:32 AM, Vincent Massol <vinc...@massol.net>
> wrote:
> >
> >> I also agree about this point that that we provide by default should not
> >> access anything external.
> >>
> >> And I agree that other implementations (like google recaptcha) should be
> >> done as contrib extensions that can be installed in your wiki.
> >>
> >
> > I wouldn't directly say that I disagree with this statement, however I am
> > going to reiterate the conclusions we (at least I) had back when I did
> the
> > initial XWiki 7.0 CAPTCHA investigation regarding self hosted vs service
> > solution:
> >
> > The conclusion was that the need for a CAPTCHA system arises in a public
> > environment/website. There is no plausible scenario where a
> > company/organization would want to setup a CAPTCHA on a private intranet
> or
> > internal system because it would be poitless to try to protect your
> system
> > from, e.g., bots registering fake accounts from inside your company's VPN
> > (or something like that). So, if the usecase is public endpoints/systems
> > that need to be protected by CAPTCHAs, then using a public service (such
> as
> > Google's reCAPTCHA) is perfectly plausible and not creating any technical
> > problems, since the client has access to download the necessary
> javascript
> > and the server (most likely) has external access to validate the
> response.
>
> That’s a good point.
>
> > The above conclusion is also most likely the reason why self-hosted
> CAPTCHA
> > solutions have pretty much died out along the years, mostly due to
> Google's
> > reCAPTCHA that is enjoying a huge success, both in adoption and in
> > efficiency.
>
> Yes, unless you don’t want to use google services for various reasons.
>
> > I even found an asnwer from actual self-hosted CAPTCHA authors
> > recommending to use Google's service solution instead, even mentioning
> the
> > fact that it was helping (at some point) improve OCR on digializing text
> > books (now Google seems to have moved more to image recognition instead
> of
> > OCR, but still...).
> >
> > https://stackoverflow.com/questions/810493/recommendations-for-java-
> captcha-libraries
> > (check https://stackoverflow.com/a/4528230/5198689 for a reply from
> > SimpleCaptcha's author)
> >
> > SimpleCaptcha does seem to pop up in many discussions as the best Java
> > alternative so far. We might want to try and offer a contrib extension
> with
> > it as well.
> >
> > Clement's suggestion of custom CAPTCHA solutions is not bad either. They
> > should be much easier to implement and switch to, with the new system.
> > Maybe it would be more appropriate at a per-depoyment level, instead of
> at
> > a product level, though.
> >
> > If you ask me, it's Google's reCAPTCHA that we should use as a default
> > (since it's now the industry standard), while still bundling (at least
> for
> > a while) the old JCaptcha implementation (for backwards compatibility,
> > until users switch to the new system) and the new JCaptcha implementation
> > (with the new system). IMO, it would be nicer to offer the best solution
> as
> > a default and have the few cases that need the self-hosted solution
> switch
> > to JCaptcha or install some contrib extension based on SimpleCaptcha, or
> > whatever else is available.
> >
> > Now, as Thomas mentioned, it would make more sense to implement it as a
> > Contrib extension (so that, in the near future, changes to reCAPTCHA
> could
> > be still used by older vesions; older as in stil using the new system,
> i.e.
> > 10.5+, but not the latest XWiki version), so the only solution to have it
> > as default as well would mean for the Standard Flavor to bundle the
> > reCAPTCHA implementaion, as a Contrib extension. (Vincent, insert "-1"
> here
> > :) )
>
> So if we agree that captcha are only required in a public environment
> which has internet access then I think it would make sense to not have any
> Captcha implementation by default in XS and make it fully a contrib
> extension for those use cases (e.g. public web site use case).
>

Remember that Registration and Comments both allow enabling Captchas
individually, so it's a feature that XS still needs, at least at the
API/configuration level.


>
> And yes I wouldn’

Re: [xwiki-devs] [Proposal] CAPTCHA module refactoring

[Eduard Moraru]

gt; > an option (through a contrib extension to better follow Google captcha
> > API evolution).
> >
> > On Fri, May 25, 2018 at 12:37 AM, Clément Aubin <aubincl...@gmail.com>
> wrote:
> >> Hi,
> >>
> >> On 05/24/2018 05:15 PM, Eduard Moraru wrote:
> >>> Question:
> >>> e
> >>> Do we need the captcha module to function without the DB as well?
> >>>
> >>> This would make it more difficult to create the configuration UI (in
> >>> Administration) and would also mean that some captchas implementations
> >>> might not respect this constraint (i.e. choosing to implement their UI
> in a
> >>> wiki page instead).
> >>>
> >>> IMO, it's not really worth the trouble and we should proceed to
> extending
> >>> the current captcha module into 2 parts: -api and -ui (the current
> module
> >>> would be converted from "jar" to "pom" and the current code will be
> >>> deprecated and moved to the new -api module).
> >>
> >> The only reason we could not to depend on the DB would be to transfer
> >> parts of the captcha module to xwiki-commons IMO. For now, I don't see
> >> any particular use case that could support this migration.
> >>
> >>> Thanks,
> >>> Eduard
> >>>
> >>> On Tue, May 22, 2018 at 8:35 PM, Eduard Moraru <enygma2...@gmail.com>
> wrote:
> >>>
> >>>> Hi, devs,
> >>>>
> >>>> XWiki's current CAPTCHA module [1] is very old and outdated for a
> while
> >>>> now and this is not news for anyone.
> >>>>
> >>>> I see 2 major problems:
> >>>> 1) The obvious one is that we just need a technologically better
> CAPTCHA
> >>>> implementation that the current JCaptcha-based one and JCaptcha is
> >>>> discontinued.
> >>>> 2) The current architecture is outdated as well (i.e. wrapped around
> >>>> Struts actions and initializing the VelocityContext with a custom
> binding)
> >>>> and hard to use (i.e. you have to write your CAPTCHA UI every time
> you use
> >>>> it, there is no rendering helper).
> >>>>
> >>>> For 1), as both determined a few years ago [2] and also observed from
> >>>> practice, the industry standard is now Google's reCaptcha service
> (either
> >>>> its v2 or invisible version, or both), so we definitely need an
> >>>> implementation that makes it easy to use in XWiki [3].
> >>>>
> >>>> For 2), we need:
> >>>> * to allow CAPTCHA implementations to provide their own rendering
> >>>> ** Can be done using a template .vm file (rendered with the
> >>>> TemplateManager), a wiki page or directly from Java code.
> >>>> ** The implementation-specific parameters could be passed to
> >>>> control/customize a particular rendering.
> >>>> ** The syntax ID may not be needed, since the only relevant output
> would
> >>>> be html.
> >>>> * to move to a ScriptService-based system and to leave the resource
> >>>> (image/audio) accessing concern to the individual implementation
> (that may
> >>>> choose to continue with Struts actions, or may choose to use something
> >>>> lighter like a REST resource or even or even something more
> inventive, like
> >>>> temporary attachments on some fixed page).
> >>>> * an administration UI that configures the default CAPTCHA service
> and its
> >>>> configuration
> >>>> * to allow callers to use a different CAPTCHA than the default
> configured
> >>>> one, as long as it is available (i.e. installed)
> >>>>
> >>>> Examples:
> >>>>
> >>>> = Display
> >>>> $services.captcha.display() -- default implementation, current
> >>>> configuration
> >>>> $services.captcha.recaptcha.display() -- explicitly requested
> >>>> implementation, current/default configuration
> >>>> $services.captcha.recaptcha.display({'theme' : 'dark', 'size' :
> >>>> 'compact', 'sitekey' : 'xyz'}) -- explicitly requested implementation
> and
> >>>> custom configuration overwrites
> >>>> $services.captcha.jcaptcha.display() -- other implementation,
> >>>> current/default configuration
> >>>>
> >>>> 

Re: [xwiki-devs] [Proposal] CAPTCHA module refactoring

[Eduard Moraru]

Question:

Do we need the captcha module to function without the DB as well?

This would make it more difficult to create the configuration UI (in
Administration) and would also mean that some captchas implementations
might not respect this constraint (i.e. choosing to implement their UI in a
wiki page instead).

IMO, it's not really worth the trouble and we should proceed to extending
the current captcha module into 2 parts: -api and -ui (the current module
would be converted from "jar" to "pom" and the current code will be
deprecated and moved to the new -api module).

Thanks,
Eduard

On Tue, May 22, 2018 at 8:35 PM, Eduard Moraru <enygma2...@gmail.com> wrote:

> Hi, devs,
>
> XWiki's current CAPTCHA module [1] is very old and outdated for a while
> now and this is not news for anyone.
>
> I see 2 major problems:
> 1) The obvious one is that we just need a technologically better CAPTCHA
> implementation that the current JCaptcha-based one and JCaptcha is
> discontinued.
> 2) The current architecture is outdated as well (i.e. wrapped around
> Struts actions and initializing the VelocityContext with a custom binding)
> and hard to use (i.e. you have to write your CAPTCHA UI every time you use
> it, there is no rendering helper).
>
> For 1), as both determined a few years ago [2] and also observed from
> practice, the industry standard is now Google's reCaptcha service (either
> its v2 or invisible version, or both), so we definitely need an
> implementation that makes it easy to use in XWiki [3].
>
> For 2), we need:
> * to allow CAPTCHA implementations to provide their own rendering
> ** Can be done using a template .vm file (rendered with the
> TemplateManager), a wiki page or directly from Java code.
> ** The implementation-specific parameters could be passed to
> control/customize a particular rendering.
> ** The syntax ID may not be needed, since the only relevant output would
> be html.
> * to move to a ScriptService-based system and to leave the resource
> (image/audio) accessing concern to the individual implementation (that may
> choose to continue with Struts actions, or may choose to use something
> lighter like a REST resource or even or even something more inventive, like
> temporary attachments on some fixed page).
> * an administration UI that configures the default CAPTCHA service and its
> configuration
> * to allow callers to use a different CAPTCHA than the default configured
> one, as long as it is available (i.e. installed)
>
> Examples:
>
> = Display
> $services.captcha.display() -- default implementation, current
> configuration
> $services.captcha.recaptcha.display() -- explicitly requested
> implementation, current/default configuration
> $services.captcha.recaptcha.display({'theme' : 'dark', 'size' :
> 'compact', 'sitekey' : 'xyz'}) -- explicitly requested implementation and
> custom configuration overwrites
> $services.captcha.jcaptcha.display() -- other implementation,
> current/default configuration
>
> = Verification
> $services.captcha.isValid() -- default implementation, current
> configuration
> $services.captcha.recaptcha.isValid() -- explicitly requested
> implementation, current/default configuration
> $services.captcha.recaptcha.isValid({'secret' : 'xyz'}) -- explicitly
> requested implementation and custom configuration overwrites
> $services.captcha.jcaptcha.isValid() -- explicitly requested
> implementation and custom configuration overwrites
>
> Basically, the ScriptService API would be highly simplified to just
> displaying and validating, while the components would consist of 2 parts:
> * a generic Manager for the various implementations (listing,
> getting/setting the default)
> * various implementations, each responsible with rendering a form-friendly
> CAPTCHA input and using the current request for extracting the information
> they needs to read the user's answer and validate it.
>
> WDYT?
>
> Thanks,
> Eduard
>
> --
> [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Captcha%20Module
> [2] http://design.xwiki.org/xwiki/bin/view/Proposal/CAPTCHAinvestigation70
> [3] https://jira.xwiki.org/browse/XWIKI-12964
>

Re: [xwiki-devs] [Proposal] XS 10.7 roadmap on BFD+Test

[Eduard Moraru]

+1

Thanks,
Eduard

On Thu, May 24, 2018 at 11:20 AM, Thomas Mortagne  wrote:

> +1
>
> On Thu, May 24, 2018 at 9:34 AM, Vincent Massol 
> wrote:
> > Hi devs,
> >
> > We’re having a tough time maintaining the quality of XWiki Standard
> these days (not enough people).
> >
> > We used to be able to contain bugs and have as many bugs closed than
> created over 1600 days. We’ve now slipped back to 330+ bugs that have been
> opened vs created over 1600 days. +116 over 500 days. +96 over 365 days.
> And +49 over 120 days. BFD days have little impact with that many bugs
> (since there are about 1-2 devs participating to XS’s BFDs).
> >
> > In addition I’ve measure our Test Coverage since end of 2017 and we’ve
> lost coverage compared to before which is really bad (see my other emails).
> In short this means that we’re hurrying to finish work from the roadmaps
> without taking enough time to write the proper tests. This will have an
> important impact in the future if we don’t react.
> >
> > Thus I’d like to propose that we spend the XS 10.7 roadmap (1 month in
> August) on bug fixing and writing more tests. It’ll probably not be enough
> but it’ll help a lot.
> >
> > Let me know if someone has a counter-proposal or an issue with this
> proposal.
> >
> > Thanks
> > -Vincent
>
>
>
> --
> Thomas Mortagne
>

[xwiki-devs] [Proposal] CAPTCHA module refactoring

[Eduard Moraru]

Hi, devs,

XWiki's current CAPTCHA module [1] is very old and outdated for a while now
and this is not news for anyone.

I see 2 major problems:
1) The obvious one is that we just need a technologically better CAPTCHA
implementation that the current JCaptcha-based one and JCaptcha is
discontinued.
2) The current architecture is outdated as well (i.e. wrapped around Struts
actions and initializing the VelocityContext with a custom binding) and
hard to use (i.e. you have to write your CAPTCHA UI every time you use it,
there is no rendering helper).

For 1), as both determined a few years ago [2] and also observed from
practice, the industry standard is now Google's reCaptcha service (either
its v2 or invisible version, or both), so we definitely need an
implementation that makes it easy to use in XWiki [3].

For 2), we need:
* to allow CAPTCHA implementations to provide their own rendering
** Can be done using a template .vm file (rendered with the
TemplateManager), a wiki page or directly from Java code.
** The implementation-specific parameters could be passed to
control/customize a particular rendering.
** The syntax ID may not be needed, since the only relevant output would be
html.
* to move to a ScriptService-based system and to leave the resource
(image/audio) accessing concern to the individual implementation (that may
choose to continue with Struts actions, or may choose to use something
lighter like a REST resource or even or even something more inventive, like
temporary attachments on some fixed page).
* an administration UI that configures the default CAPTCHA service and its
configuration
* to allow callers to use a different CAPTCHA than the default configured
one, as long as it is available (i.e. installed)

Examples:

= Display
$services.captcha.display() -- default implementation, current configuration
$services.captcha.recaptcha.display() -- explicitly requested
implementation, current/default configuration
$services.captcha.recaptcha.display({'theme' : 'dark', 'size' : 'compact',
'sitekey' : 'xyz'}) -- explicitly requested implementation and custom
configuration overwrites
$services.captcha.jcaptcha.display() -- other implementation,
current/default configuration

= Verification
$services.captcha.isValid() -- default implementation, current configuration
$services.captcha.recaptcha.isValid() -- explicitly requested
implementation, current/default configuration
$services.captcha.recaptcha.isValid({'secret' : 'xyz'}) -- explicitly
requested implementation and custom configuration overwrites
$services.captcha.jcaptcha.isValid() -- explicitly requested implementation
and custom configuration overwrites

Basically, the ScriptService API would be highly simplified to just
displaying and validating, while the components would consist of 2 parts:
* a generic Manager for the various implementations (listing,
getting/setting the default)
* various implementations, each responsible with rendering a form-friendly
CAPTCHA input and using the current request for extracting the information
they needs to read the user's answer and validate it.

WDYT?

Thanks,
Eduard

--
[1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Captcha%20Module
[2] http://design.xwiki.org/xwiki/bin/view/Proposal/CAPTCHAinvestigation70
[3] https://jira.xwiki.org/browse/XWIKI-12964

Re: [xwiki-devs] [Question for the xwiki security feature] Hi xwiki security members

[Eduard Moraru]

On Fri, May 18, 2018 at 10:35 AM, Thomas Mortagne  wrote:

> On Thu, May 17, 2018 at 10:10 PM, Kwan Kim  wrote:
> >  I am Kwan Kim who works for the Rogosin Institute (medical research
> company specialized for Kidney disease in New York)
> >
> > Recently we tried to use xwiki as an our wiki server.
> >
> > So we configured the xwiki server on Redhat, MySQL & Glassfish
> environment and ask vulnerability test team to test.
> >
> > However they found several security issues.
> >
> > And I am not a expert for the xwiki so I am not sure whether xwiki
> already has a solution to fix the issues or not.
> >
> > That’s why I would like to ask you about the security features of xwiki.
> >
> > This is the security problems which the vulnerability team addressed
> below:
> >
> > 1. Cross Site Scripting (XSS): Script insertion at Name Field in the
> registration form.
> >
> > When new user register, there is first and last name field. thesis
> fields allow javascript code.
>
> It's not very clear to me what this mean. In which context exactly the
> javascript inserted in the user name is executed ?
>

https://jira.xwiki.org/browse/XWIKI-9658

Thanks,
Eduard


>
> >
> > Is there any way we can put the some validation to prevent the
> javascript code  ?
> >
> >
> > 2. No controls for Account Creation
> >
> > The  vulnerability test team think it is too easy to create new account
> >
> > Is there any way that new account need to get approval from admin user ?
>
> Its possible to disable registration and let admins create accounts
> but I don't think there is any support for admin validation of self
> registered users (but it's possible I missed it).
>
> >
> >
> > 3.Site discloses session tokens in multiple locations
> >
> > It seems xwiki use session token through URL(GET). The vulnerability
> test team suggest to use POST method instead GET.
> >
> > Is there any option to use POST method instead of GET method to transmit
> the session token information?
>
> It's not a really a all or nothing central place so we would need to
> know where exactly you have this issue to see if there is a way to fix
> it in a case by case basis.
>
> >
> >
> >
> > 4.Username retrieval with no verification
> >
> > When the user forget the username, the user can retrieve username with
> email address. However it is not sent to email but show in the site.
> >
> > The vulnerability test team think the hacker can get the username if
> they try many different combination of email.
> >
> > Is it possible xwiki only send the username by email instead of showing
> in the page ?
>
> Would be great if you could create an issue about that on
> http://jira.xwiki.org. Looks easy to fix, just need to discuss if we
> should do it or not. On my side I did not know we were displaying the
> user id in this page and I agree that it's probably not a good idea.
>
> >
> >
> >
> >
> > 5. Password Validation is weak
> >
> >  It seems xwiki allow weak password to register new user.
> >
> > Is it possible to use strong password only when new user registered in
> xwiki?
>
> It's possible to add a lot of constraint in the registration form. See
> http://extensions.xwiki.org/xwiki/bin/view/Extension/
> Administration%20Application#HValidationConstraints.
>
> >
> >
> >
> > These are the all issue they addressed.
> >
> > Please let me know the answer.
> >
> > Thank you and have a good day
> >
> > Kwan Kim
>
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [Brainstorming] Should we support multibranch translations?

[Eduard Moraru]

But what about the current (now old) translation process for LTS? AFAIR,
the RM was supposed to go through the translations and exclude some that
are OK for master, but not OK for LTS.

Did that ever happen in practice? Also, considering our translations
deprecation practice, what can go wrong at this point? If we deprecate a
translation on master and it ends up deprecated on LTS, it should still
work. Worst case, we end up with some new pages (new translations added on
master that are not relevant for LTS).

What I want to say is that it's not clear to me if we were in any way
better before than we are now (without any of the above proposed solutions).

Thanks,
Eduard

On Tue, May 22, 2018 at 2:59 PM, Adel Atallah 
wrote:

> On Tue, May 22, 2018 at 1:51 PM, Vincent Massol 
> wrote:
> > FTR this is what I discussed with Adel and I asked him to post it here
> so that we can agree.
> >
> >> On 22 May 2018, at 13:41, Adel Atallah  wrote:
> >>
> >> So for 1), we still need to decide how we merge new translations into
> >> LTS releases (or other branches).
> >
> > Idea 1:
> >
> >> An idea would be to write a script to let the RM apply new changes to
> >> a specific branch.
> >> One way to do it would be to write a script to find every translation
> >> commits since a date then review and apply them.
> >
> > More specifically this is about finding all commits done by a given user
> (the weblate user). In practice the commits are done under the translation
> contributor’s name so we would need to find the merge commit (done with the
> weblate user name) and find all associated commits (children?).
> >
> > Idea 2:
> >
> >> An other way would be to use the list of translation files that we
> >> already have and write a script to replace (checkout) those files from
> >> master to the specified branch.
> >
> > The problem with this approach is that we can have commits related to
> the translation files that are not related to translations and thus
> generate false positives.
> >
> >>
> >> WDYT?
> >
> > Idea 3: For each translation files in the known list, query weblate
> (using the REST API) to get the latest translation and apply them locally.
> >
> > In practice this will mean find keys in the translation file and replace
> with the value retrieved from weblate.
>
> I don't think we need API calls for that, we can write a script that
> will merge only the translations from two translation files (master
> and LTS). It's a bit of work to do though.
>
> >
> > One improvement is that we could parse the keys from the local files and
> file updated translations for them from weblate.
> >
> > The advantage of idea3 is that I don’t think there are false positives
> nor merge conflicts which can happen with ideas 1 and 2. The downside is
> that it may take a lot of time and a lot of REST calls to get them all.
> >
> > For all these ideas, it’ll the responsibility of the user (RM?) to check
> the diff and decide to merge/push on the branch the full translations or
> only a subpart of it.
> >
> > Aso note that we’re only talking about LTS here since we should not
> bother for the temporary branches (such as stable-10.4.x).
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
> >
> >>
> >> Thanks,
> >> Adel
> >> Adel Atallah
> >> Product developer intern
> >> adel.atal...@xwiki.com
> >> tel: +33 (0)6 12 96 35 06
> >>
> >>
> >> On Fri, May 18, 2018 at 6:47 PM, Ecaterina Moraru (Valica)
> >>  wrote:
> >>> +1 for 1)
> >>> Make sure the commit has a marker like "[Translations]" or "[Weblate]"
> for
> >>> the the step in the release process, so that we can look for them in
> the
> >>> history in order to apply them, in case we really need them.
> >>> In practice we don't commit translations for LTS, because usually we
> make
> >>> changes in UI and we don't want to manually check and validate each
> >>> translation.
> >>>
> >>> Thanks,
> >>> Caty
> >>>
> >>>
> >>> On Fri, May 18, 2018 at 5:47 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> >>> wrote:
> >>>
>  Option 2) would create too much of a mess on weblate side IMO (until
>  we can hide branches at least).
> 
>  I would go for 1) for now and follow progress on Weblate product to
>  provide a clean solution for this use case.
> 
>  That being said we need to find a solution for LTS (I don't think we
>  care about stable branch bugfixes releases and we could do it by hand
>  for RC branches since it's only 1 week usually). Here are some ideas:
>  a) it should not be hard to write a script which get all the weblate
>  commits from master since last weblate commit we can find in the
>  branch and cherry-pick them (probably also display a diff and ask for
>  confirmation for each of them). This would be executed before the
>  release by the release manager.
>  b) I guess it's possible to write or find a tool which automatically
>  

Re: [xwiki-devs] [Proposal] Get rid of sonar.xwiki.org?

[Eduard Moraru]

Hi,

On Fri, May 18, 2018 at 10:16 AM, Thomas Mortagne  wrote:

> Sure, but we need to add platform to it too.
>
> Still it's a pity to loose all the work done during the last GCI
> regarding false positives.
>

Any chance we could export those comments and maybe at least have a list of
the Confirmed false positives to compare them with their current status on
sonarcloud.io and see if they are still relevant or not?

Otherwise +1, for the same reasons expressed by Clement.

Thanks,
Eduard

>
> On Thu, May 17, 2018 at 10:01 PM, Vincent Massol 
> wrote:
> > Hi devs,
> >
> > Context:
> > * I lost the config on ci.xwiki.org to push maven results to
> sonar.xwiki.org. I can find them back for sure but will take me a bit of
> time.
> > * We don’t use sonar.xwiki.org that much
> > * We now have https://sonarcloud.io/organizations/xwiki/projects to
> which we can push results from our builds
> > * https://sonarcloud.io/organizations/xwiki/projects is always up to
> date in term of sonar version and we don’t need to maintain it
> >
> > So my proposal is to decommission sonar.xwiki.org and to configure
> https://sonarcloud.io/organizations/xwiki/projects the way we want (I
> already did that a bit but we can tune it more) and modify our maven build
> to push to it.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
>
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [XAR entry type] What about Mail.MailConfig

[Eduard Moraru]

On Wed, May 9, 2018 at 4:53 PM, Vincent Massol  wrote:

> Hi,
>
> > On 9 May 2018, at 15:46, Thomas Mortagne 
> wrote:
> >
> > Hi xwikiers,
> >
> > Denis expressed to me some concerns about the type that should be
> > associated to Mail.MailConfig since it contains configuration data.
> >
> > One important issue I see if that this page is primarily an admin
> > configuration UI
>
> I don’t understand this sentence. MailConfig is not an UI and it doesn’t
> contain configuration for UI. It contains config for the mail server, mail
> properties, etc. It contains mail configuration data. Not related to UI.
>
> > which happen to also contains configuration data
> > (would have been much cleaner to store the data in a generated
> > document…)
>
> Same, could you explain this more?
>
> > so I think the best for now is to keep the default type.
> > Since you are not supposed to go trough edit more to modify those
> > configuration data, the edit protection should not really affect users
> > in practice (no warning when using admin UI).
>
> We happen to have some Admin UI  that changes the MailConfig page so I’m
> fine to use ‘default’ (i.e. to warn the users when they try to edit it).
>
> The important aspect is that we don’t try to merge it when the admin
> upgrades the wiki and there’s been changes brought to it (through the Admin
> UI), and I believe “default” will achieve this.
>

Note that on the merge side, the purpose of "default" is to explicitly
merge any updates.

"default: used to force the default. Edit and delete are not allowed and a
3-way merge is applied to the document during upgrades."

Perhaps a more appropriate type for this page would be:

"configuration: a document containing configuration. Edit is allowed and
the document is never upgraded."

...since, after all, the main purpose of Mail.MailConfig is to be a
configuration page, with some stray (and rather static, i.e. don't change
often) UI elements in it (ConfigurationClass) that need to be extracted to
a different page (and *that* page will be set to type "default").


>
> Now we might have other *Config pages for which we’re currently lacking an
> Admin UI till we provide such a UI, we’ll need to mark those as “demo” for
> now.
>

Same here... semantically, those are "configuration" pages as well.



Side note: Now, I notice a weird thing in the definition of the
"configuration" type:

"Edit is allowed  and the document is never upgraded."

...and I kind of understand why Vincent might have suggested "demo", which
says:

"Edit and delete are allowed and the document is upgraded only if it's not
been customized."

...which is something that should, IMO, apply to "configuration" types as
well, since it would make sense to keep using the default configuration
values of an application (whichever those are and however they evolve
across time), until we start customizing them.

i.e. "configuration" should be: allow edit, disallow delete and only
upgrade if there were no changes.

WDYT?



Side note2: Just a quick reminder that for configuration, in the best case
scenario (where we have no mixing of code with configuration data), the
default actions should be to merge, like all the other package managers out
there.

Thanks,
Eduard


>
> So ok for me for MailConfig (if I understood correctly).
>
> Thanks
> -Vincent
>
> >
> > WDYT ?
> >
> > --
> > Thomas Mortagne
>
>

[xwiki-devs] [GSOC] Coding period has started

[Eduard Moraru]

Hello to our GSoC 2018 students,

The GSoC 2018 coding period has officially started.

I hope you have taken advantage of the bonding period to get up to speed
with the XWiki project, its code and documentation, and that you have a
pretty good idea of what you need to do to turn your project into a success.

As for tips and things that you need to do in the following (coding)
period, please make sure you read carefully the these 2 dedicated sections
[1][2] in the student guidelines [3], particularly:
* keeping your progress report page up to date [4]
* creating your design page as instructed [5]
* making your contribution to the XWiki project (pull request)

Working on your project is great, but it`s only half of the work that GSoC
involves. The other half is integrating into the community, letting people
know what your are working on, asking for help and learning to ask the
right questions, and generally communicating about yourself and your work.

In order to keep in touch, additionally to reading and being active on the
mailing list, you also need to be present on IRC as much as possible (at
least while you are working on your project) so that:
* people see you and can quickly get a hold of you
* you are exposed to everyday community activity that might spark your
interest
* get more occasions to ask questions
* get more occasions to help others with their problems should you know the
answer
* etc.

Hope you are finding XWiki to be an interesting project and that you are
enjoying your GSoC so far.

-The XWiki Development Team

--
[1]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HSuggestedwayofworkingforacceptedGSoCstudents
[2]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HConditionsforsuccess
[3] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines
[4]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentProgress
[5] http://design.xwiki.org/

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

[Eduard Moraru]

On Mon, May 14, 2018 at 12:46 PM, Vincent Massol <vinc...@massol.net> 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 <enygma2...@gmail.com> 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 <enygma2...@gmail.com>
> >> 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 <enygma2...@gmail.com
> >
> >>>> 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

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 <thomas.morta...@xwiki.com
> wrote:

> On Mon, May 14, 2018 at 10:49 AM, Eduard Moraru <enygma2...@gmail.com>
> 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 <enygma2...@gmail.com>
> >> 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 <vinc...@massol.net>
> >> 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-12

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 <enygma2...@gmail.com>
wrote:

> Correction, the above are Oracle builds, not OpenJDK :)
>
> On Mon, May 14, 2018 at 11:49 AM, Eduard Moraru <enygma2...@gmail.com>
> 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 <enygma2...@gmail.com>
>>> 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 <vinc...@massol.net>
>>> 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 

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 <enygma2...@gmail.com>
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 <enygma2...@gmail.com>
>> 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 <vinc...@massol.net>
>> 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 

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 <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 <enygma2...@gmail.com>
> 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 <vinc...@massol.net>
> 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

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 <vinc...@massol.net> wrote:

>
>
> > On 11 May 2018, at 14:22, Thomas Mortagne <thomas.morta...@xwiki.com>
> wrote:
> >
> > On Fri, May 11, 2018 at 11:00 AM, Vincent Massol <vinc...@massol.net>
> wrote:
> >> Hi Edy,
> >>
> >>> On 8 May 2018, at 12:38, Eduard Moraru <enygma2...@gmail.com> 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

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

[Eduard Moraru]

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.

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)

Thanks,
Eduard

On Mon, May 7, 2018 at 7:26 PM, Vincent Massol  wrote:

>
>
> > On 7 May 2018, at 18:18, Thomas Mortagne 
> wrote:
> >
> > On Mon, May 7, 2018 at 5:02 PM, Vincent Massol 
> wrote:
> >>
> >>
> >>> On 7 May 2018, at 16:48, Thomas Mortagne 
> wrote:
> >>>
> >>> On Mon, May 7, 2018 at 4:33 PM, Vincent Massol 
> wrote:
>  Hi,
> 
>  It seems we forgot to handle mail template pages. For example
> XWiki.ResetPasswordMailContent
> 
>  We need to decide the type: demo, default, etc.
> 
>  WDYT about demo (i.e. as soon as the user starts modifying it, we
> don’t upgrade it anymore)?
> 
>  Thanks
>  -Vincent
> 
> >>>
> >>> All types with allowed edit prevent upgrade.
> >>
> >> I’m not sure we need more than 1 such type. See other mail thread.
> >>
> >>> I think a more important question is: is it OK to delete it ?
> >>
> >> We could. See below
> >>
> >>>
> >>> Seems to me delete is not OK in this context. Unless it's possible to
> >>> change the mail template used for password reset ?
> >>
> >> Re delete, I think there’s another thread discussing it, no? I don’t
> remember the discussion too well and don’t master all the details but AFAIR
> my preference was to not prevent deletion in general (I’m worried about
> unplanned use cases requiring a delete, like renaming the page to another
> place to save it, and then import some XAR containing the new mail
> template).
> >>
> >> IMO all pages should be deletable without endangering the system. In
> this case we could imagine:
> >> * if the template is missing then the password reset page would mention
> it with the ability to create a default mail template
> >> * and/or report a mail error in the admin UI when sending the email
> (since the template doesn’t exist). This means that the template factory
> for emails should check the existence of the page. This should be handled
> here: https://github.com/xwiki/xwiki-platform/blob/
> 6e281a093d3751666fdcd3fb3a69cb638cca9b59/xwiki-platform-
> core/xwiki-platform-mail/xwiki-platform-mail-send/
> xwiki-platform-mail-send-default/src/main/java/org/
> xwiki/mail/internal/factory/template/DefaultMailTemplateManager.java#L143
> AFAICS it will currently report a NPE….
> >
> > As you said, deleting that page would break reset password feature and
> > since I don't plan to rewrite it right now it means delete should be
> > protected IMO. If someone improve this feature later then the type can
> > be changed to "demo".
> >
> >>
> >> Have we decided what we do about deletes in general?
> >
> > There hasn't been such discussion.
>
> I’m referring to http://markmail.org/message/kjtyzvjp5zzh4gyf (and I’m
> sure I saw another discussion about that but cannot find it ATM).
>
> I still don’t understand why we’re mixing upgradability with deletability
> (and trying to find names that represent both). Aren’t they 2 different
> topics?
>
> Thanks
> -Vincent
>
> > I don't even understand what this
> > mean, it's obvious to me that deleting some pages don't break anything
> > while for others you are going to create a huge mess.
> >
> >>
> >> Thanks
> >> -Vincent
> >>
> >>> --
> >>> Thomas Mortagne
> >>
> >
> >
> >
> > --
> > Thomas Mortagne
>
>

Re: [xwiki-devs] Onboarding feedback

[Eduard Moraru]

That's actually pretty cool, Sergiu! Thanks for sharing!

Vincent/others, WDYT about merging this?

Thanks,
Eduard

On Fri, Apr 20, 2018 at 11:11 PM, Sergiu Dumitriu  wrote:

> On 04/19/2018 06:50 AM, Vincent Massol wrote:
> > Thanks for the feedback Adel
> >
> >> On 19 Apr 2018, at 11:05, Adel Atallah  wrote:
> >>
> >> Hello everyone,
> >>
> >> I've been following the onboarding tracks 1 and 2 on the past days,
> here is
> >> what I can say:
> >> The first track really helped me to get started in XWiki contributions
> as I
> >> could easily pick a jira issue to work on. The issue description was
> clear
> >> even though we had to discuss it on the chat. Speaking of the chat, it
> has
> >> been a very valuable tool, people have been very responsive and I was
> >> rarely stuck. I found the development practice a bit inconvenient at
> first,
> >> having to make changes in the vm files of my XWiki instance and then
> report
> >> the changes to the sources. I would have love to see a way to link my
> >> source files (especially for vm/js/css files) with the one of my XWiki
> >> instance to avoid errors when I copy past my changes (and get benefit
> of my
> >> git ecosystem).
> >
> >
> > For XAR dev I’d really like to have a “mvn xar:push” and “mvn xar:pull”
> mojos to sync your XML with an XWiki instance.
>
> Sounds like you want this:
>
> https://github.com/xwiki/xwiki-commons/compare/master...sebialex:GetMojo
>
> > We could imagine something similar for template files.
> >
> > Thanks
> > -Vincent
> >
> >
> >> The second track is a good introduction to some XWiki concepts, I don't
> >> have much to say for this one. A link to a real application could maybe
> >> give a better understanding.
> >>
> >> Thanks again for the help I had!
> >>
> >>  *Adel Atallah*
> >> *Product developer intern*
> >> adel.atal...@xwiki.com 
> >> tel: +33 (0)6 12 96 35 06
> >
>
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu
>

Re: [xwiki-devs] [Proposal] Using JUnit5 from now on?

[Eduard Moraru]

+1 (still have to catch up on the changes in JUnit5)

For example if we need to add a method to a JUnit4 test, we convert it to
> JUnit5 and then add the new test method. It’s pretty simple to do the
> conversion.


This, however, is most likely going to be a PITA.

Thanks,
Eduard

On Wed, May 2, 2018 at 3:01 PM, Ecaterina Moraru (Valica)  wrote:

> +0
>
> Thanks,
> Caty
>
> On Wed, May 2, 2018 at 11:18 AM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>
> > +1
> >
> > Thanks,
> > Marius
> >
> > On Sun, Apr 29, 2018 at 3:52 PM, Vincent Massol 
> > wrote:
> >
> > > Hi devs,
> > >
> > > I’ve recently worked on converting our JUnit4 @Rule rules into JUnit5
> > > equivalent.
> > >
> > > There are now equivalent for:
> > > - MockitoComponentManagerRule,
> > > - ComponentManagerRule
> > > - AllLogRule
> > > - MockitoOldcoreRule
> > >
> > > See http://dev.xwiki.org/xwiki/bin/view/Community/Testing#
> > HJavaUnitTesting
> > > for examples of how to use them.
> > >
> > > Feel free to ask here if you have questions or if you have ideas on how
> > to
> > > better integrate with JUnit5 (I’m sure we’ll need to perform some
> tuning
> > > and there are use cases that I have forgotten that we’ll need to
> > support).
> > >
> > > I’m thus proposing that from now on, we start writing new tests as
> JUnit5
> > > tests and that we start converting old JUnit3/4 tests into JUnit5 ones.
> > For
> > > example if we need to add a method to a JUnit4 test, we convert it to
> > > JUnit5 and then add the new test method. It’s pretty simple to do the
> > > conversion.
> > >
> > > WDYT?
> > >
> > > Thanks
> > > -Vincent
> > >
> > >
> > >
> >
>

[xwiki-devs] [GSoC] Community Bonding Period ending on 14th of May. PRs needed!

[Eduard Moraru]

Hello, GSoC students,

As you all know, we are in the middle of the "Community Bonding" period of
the GSoC 2018 program's timeline [1].

This is a very important period in which you are supposed to get familiar
with the XWiki project, read documentation (APIs, processes, development
practices, etc.), setup tooling and development environments, figure out
the way the project is organized and what is the best approach for you to
make an impact. At the end of this period, you should be ready and
productive to start working on your cool project. (Nobody will complain if
you have already started ;) ).

Even more so, the community bonding period is about getting to know the
community and helping the community to know you. So, if you have not yet
introduced yourself or did not get the chance to exchange some initial
thoughts with your mentor(s), now is the time to do it. You need to
remember that GSoC is not a bounty program, but a community building one,
so the main objective is not simply to deliver, at a certain deadline, a
feature, but to be integrated in the open source community you have joined
and help it grow (through your contributions).

As such, on the technical side, your objective for this period is to get at
least 1 of your Pull Requests (average size/complexity, must contain a few
lines of code) to get reviewed and accepted either in the main repositories
(platform/commons/rendering) or in one of the existing Contrib extensions.
The PR needs to be associated to an existing Jira issue (bug/improvement).

Make sure you read and follow the Student Guidelines, specifically the
section dedicated to accepted students [2].


Reminder1: The deadline is the 14th of May.

Reminder2: The community bonding period is also an eliminatory period.
Students that choose to stay silent may be considered for elimination from
the program.


Thanks,
Eduard

--
[1] https://developers.google.com/open-source/gsoc/timeline
[2]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HSuggestedwayofworkingforacceptedGSoCstudents

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Eduard Moraru]

On Thu, Apr 26, 2018 at 3:40 PM, Guillaume Delhumeau <
guillaume.delhum...@xwiki.com> wrote:

> 2018-04-26 14:13 GMT+02:00 Eduard Moraru <enygma2...@gmail.com>:
>
> > Hi, Vincent,
> >
> > On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <vinc...@massol.net>
> > wrote:
> >
> > > Hi Edy,
> > >
> > > Thanks for your input, see below.
> > >
> > > > On 26 Apr 2018, at 11:42, Eduard Moraru <enygma2...@gmail.com>
> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I'm sorry, but nothing related to configuration inside pages looks
> very
> > > > "wiki-like" to me.
> > >
> > > [snip]
> > >
> > > > You should not need a developer
> > > > (possibly the original developer of the project/customizations) in
> > order
> > > to
> > > > make a really basic operation such as an upgrade. Maybe I'm saying
> > > > "sometimes less is more"? :)
> > >
> > > I’m just reacting to this part, hence the snipping :)
> > >
> > > For me approach 1 is both the complex approach by far and completely
> > > unwiki-like. The wiki way is to be able to make easy edits and be able
> to
> > > rollback, see diffs, etc. That’s natural and fast. That’s why wikis are
> > > great and this is what we do everywhere in XWiki, including
> > configurations
> > > since all configs are stored inside wiki pages (XWikiPreferences,
> > *Config,
> > > etc). And we’re not going to change that now.
> > >
> >
> > You missed something from those snips where I explained the way I saw
> this
> > and what might cause some confusion:
> >
> > "IMO, the important part to distinguish the fact that the configuration
> > part (for a regular, non-dev) is choosing *which* color theme to use,
> while
> > the customization (i.e. coding, done by someone that understands
> CSS/LESS,
> > in this case) part is editing/customizing your own version of a color
> > theme."
> >
> > i.e. Themes are not configuration, but actual code.
> >
>
> That is actually sad. We already have the "Skin" concept as the "complex
> stuff people are not supposed to touch". As opposed to this, I have always
> seen the "Theme" as the "little stuff you can change easily to change some
> color of the big skin". I agree that themes can now contain a bit of "less"
> code. But if both Skin and Themes are seens as "complex stuff regular users
> should not change (because it's code)", it's very sad for the
> user-friendlyness, and it's probably time to make things better.
>
> Copying a theme when someone wants to edit is indeed breaking the wiki
> workflow and it's again something complex. I would prefer a simple button
> in the theme to "revert colors to factory default".
>
>
Yeah, you're right. Themes do go almost entirely into a configuration
domain rather than a code domain, specifically since they have dedicated UI
for each configurable variable. The LESS part is more for advanced stuff
that a regular user would normally ignore.

So it would more about configuring which "demo" configurations you want to
use.

Thanks,
Eduard

>
> >
> >
> > > It would be the first time we copy something before allowing changing
> it
> > > and that’s not logical and not consistent.
> > >
> >
> > The whole discussion is about not allowing to edit something, which is a
> > first indeed, but we are moving in that direction, so of course there
> will
> > be some changes to the way XWiki works.
> >
> >
> > >
> > > In addition we would make a bigger mess since not only users would be
> > > directed to making copies of color themes pages but they would still be
> > > able to make modifications to current color theme pages…
> >
> >
> > > The more I think about it, the more I’m convinced that approach 2 is
> both
> > > the simplest (and I agree that “less is more” :)) and the most logical.
> > >
> > > You mentioned upgrade being a problem but I don’t think this is correct
> > > since approach 2 means that the color theme pages are “demo” pages
> > meaning
> > > that there will never be any upgrade conflict. When we do new XWiki
> cycle
> > > versions, we will still be able to provide new color themes and since
> > those
> > > are new (like Iceberg this year) users will be able to switch to them
> > > easily (there’s no

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Eduard Moraru]

On Fri, Apr 27, 2018 at 12:05 PM, Vincent Massol <vinc...@massol.net> wrote:

> Hi Edy,
>
> > On 26 Apr 2018, at 14:13, Eduard Moraru <enygma2...@gmail.com> wrote:
> >
> > Hi, Vincent,
> >
> > On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <vinc...@massol.net>
> wrote:
> >
> >> Hi Edy,
> >>
> >> Thanks for your input, see below.
> >>
> >>> On 26 Apr 2018, at 11:42, Eduard Moraru <enygma2...@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'm sorry, but nothing related to configuration inside pages looks very
> >>> "wiki-like" to me.
> >>
> >> [snip]
> >>
> >>> You should not need a developer
> >>> (possibly the original developer of the project/customizations) in
> order
> >> to
> >>> make a really basic operation such as an upgrade. Maybe I'm saying
> >>> "sometimes less is more"? :)
> >>
> >> I’m just reacting to this part, hence the snipping :)
> >>
> >> For me approach 1 is both the complex approach by far and completely
> >> unwiki-like. The wiki way is to be able to make easy edits and be able
> to
> >> rollback, see diffs, etc. That’s natural and fast. That’s why wikis are
> >> great and this is what we do everywhere in XWiki, including
> configurations
> >> since all configs are stored inside wiki pages (XWikiPreferences,
> *Config,
> >> etc). And we’re not going to change that now.
> >>
> >
> > You missed something from those snips where I explained the way I saw
> this
> > and what might cause some confusion:
> >
> > "IMO, the important part to distinguish the fact that the configuration
> > part (for a regular, non-dev) is choosing *which* color theme to use,
> while
> > the customization (i.e. coding, done by someone that understands
> CSS/LESS,
> > in this case) part is editing/customizing your own version of a color
> > theme."
> >
> > i.e. Themes are not configuration, but actual code.
> >
> >
> >> It would be the first time we copy something before allowing changing it
> >> and that’s not logical and not consistent.
> >>
> >
> > The whole discussion is about not allowing to edit something, which is a
> > first indeed, but we are moving in that direction, so of course there
> will
> > be some changes to the way XWiki works.
>
> For me XWiki has a huge advantage over any other software we know: it’s
> the ability to track changes to configuration and code. Not a lot of
> software do this. For ex, imagine I change a setting in JIRA or in Jenkins.
> There’s no way you’ll know about it, nor be able to see the diff of what
> was changed, nor be able to roll it back. That’s an enormous advantage and
> we shouldn’t remove it.
>

Of course, but I'm not sure how is that related to what I said.
Configuration is and still will be editable and traceable in history. My
concern is only about *code*, specifically code that is written, maintained
and periodically released by someone other than the person currently
editing it, thus introducing a high potential for conflicts. I share your
grief for software not keeping a history of changes done in the configs.


>
> >
> >>
> >> In addition we would make a bigger mess since not only users would be
> >> directed to making copies of color themes pages but they would still be
> >> able to make modifications to current color theme pages…
> >
> >
> >> The more I think about it, the more I’m convinced that approach 2 is
> both
> >> the simplest (and I agree that “less is more” :)) and the most logical.
> >>
> >> You mentioned upgrade being a problem but I don’t think this is correct
> >> since approach 2 means that the color theme pages are “demo” pages
> meaning
> >> that there will never be any upgrade conflict. When we do new XWiki
> cycle
> >> versions, we will still be able to provide new color themes and since
> those
> >> are new (like Iceberg this year) users will be able to switch to them
> >> easily (there’s no upgrade issue either here).
> >>
> >
> > Going again through the page types (specifically the "demo" one) and
> > through the options, I agree that, at least of the Color Themes case,
> > approach 2 should do the job. Of course, all of this being possible with
> > the contract that we don't update color themes and we always publish new
> > ones, of which I'm a bit skeptical.
>
> It’ll work

Re: [xwiki-devs] [NEW API] XAR entry type

[Eduard Moraru]

On Thu, Apr 26, 2018 at 3:35 PM, Thomas Mortagne <thomas.morta...@xwiki.com>
wrote:

> On Thu, Apr 26, 2018 at 1:45 PM, Eduard Moraru <enygma2...@gmail.com>
> wrote:
> > Hi, Thomas,
> >
> > I'm having some difficulties understanding the available types and their
> > intent.
> >
> >- default: used to force the default. Edit and delete are not allowed
> >and a 3-way merge is applied to the document during upgrades.
> >
> > Shouldn't the default upgrade action be "keep new", specially if edit and
> > delete is restricted on the page? The assumption would be that it's a
> code
> > page and any unsaved modifications (e.g. as a fork extension) should be
> > overridden by the new version of the extension's code.
>
> On upgrade side I much prefer to have the default being what always
> been the default and introduce new behavior in new types. Also think
> this is what we want for the majority of pages, there is stuff that
> you could add to a page without really thinking about it as a
> customization, that you will want to keep and which are not dangerous
> for merge (like comments, restrict access to some application, etc.).
>

I do get where you are coming from. However, if you consider that "default"
restricts editing, you should normally not end up with unwanted stuff like
comments on a code page.

Regarding rights, that's a more realistic problem we have in the current
model. Until we come up with a solution that does not store rights as
objects inside the page, we don't have much choice.
However, this opens up another question: How does this (setting rights on a
code page that has "default" type) work with the lack of edit rights on the
page (i.e. you would not be able to set the rights in the first place,
because the page can't be edited)? Or maybe when you say "not allowed to
edit/delete", you simply refer to the small "warning" curtain in the UI
that only discourages the user to do the operation, but he can force it
anyway?


> Simply to keep merging as safe as possible you get a string warning
> when going trough standard editing of those pages where you could have
> an impact on what constitute the hearth of what this page is supposed
> to do.
>
> >
> >- configuration: a document containing configuration. Edit is allowed
> >and the document is never upraded.
> >
> > Normally, configuration is among the only things you might actually want
> to
> > make a choice on, as someone running an upgrade. It does not make much
> > sense to never upgrade a configuration document, specifically when you
> have
> > just added a new feature. Thinking of package managers (i.e. apt's dpkg),
> > they allow specifying beforehand or even answering interactively on the
> > action to take (merge/new/old) for the configuration files of a package
> > being upgraded. Also, the general default for config files is "merge" and
> > not "keep old".
>
> There is different ways of seeing this. First dpkg is not really an
> accurate comparison IMO, I think you missed the fact that
> "configuration" here is for configuration data only usually, the
> assumptions is that the class and administration UI for example would
> be in a different documents so you do get new properties during
> upgrade. But the behavior supposedly stay the same after upgrade, i.e.
> it's not modified by a change in the provided default configuration
> (the idea being to allow the extension author to change default
> configuration for new install without disturbing old ones). This is
> exactly what happen with application that are using generated
> configuration page right now, one of the ideas behind this type is
> that you can use it instead of a (sometimes complex) configuration
> generation logic.
>
> But yes there is not only one kind of configuration and the point of
> me listing the quick types I introduced in 10.3 is also to ask for new
> ones to have a good coverage of various common use cases even if
> extension can also come with their own type too.
>
> >
> >- home: a wiki home page. Edit is allowed and the document is upgraded
> >only if it's not been customized.
> >- demo: a document which purpose is to provide demo data. Edit and
> >delete are allowed and the document is upgraded only if it's not been
> >customized.
> >
> > I don't really understand the distinction between "home" and "demo".
> AFAICS
> > from the definition, "home" is not supposed to be deleted, but why would
> we
> > want to enforce such a restriction? If we are talking about wiki
> homepages,
>

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Eduard Moraru]

Hi, Vincent,

On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <vinc...@massol.net> wrote:

> Hi Edy,
>
> Thanks for your input, see below.
>
> > On 26 Apr 2018, at 11:42, Eduard Moraru <enygma2...@gmail.com> wrote:
> >
> > Hi,
> >
> > I'm sorry, but nothing related to configuration inside pages looks very
> > "wiki-like" to me.
>
> [snip]
>
> > You should not need a developer
> > (possibly the original developer of the project/customizations) in order
> to
> > make a really basic operation such as an upgrade. Maybe I'm saying
> > "sometimes less is more"? :)
>
> I’m just reacting to this part, hence the snipping :)
>
> For me approach 1 is both the complex approach by far and completely
> unwiki-like. The wiki way is to be able to make easy edits and be able to
> rollback, see diffs, etc. That’s natural and fast. That’s why wikis are
> great and this is what we do everywhere in XWiki, including configurations
> since all configs are stored inside wiki pages (XWikiPreferences, *Config,
> etc). And we’re not going to change that now.
>

You missed something from those snips where I explained the way I saw this
and what might cause some confusion:

"IMO, the important part to distinguish the fact that the configuration
part (for a regular, non-dev) is choosing *which* color theme to use, while
the customization (i.e. coding, done by someone that understands CSS/LESS,
in this case) part is editing/customizing your own version of a color
theme."

i.e. Themes are not configuration, but actual code.


> It would be the first time we copy something before allowing changing it
> and that’s not logical and not consistent.
>

The whole discussion is about not allowing to edit something, which is a
first indeed, but we are moving in that direction, so of course there will
be some changes to the way XWiki works.


>
> In addition we would make a bigger mess since not only users would be
> directed to making copies of color themes pages but they would still be
> able to make modifications to current color theme pages…


> The more I think about it, the more I’m convinced that approach 2 is both
> the simplest (and I agree that “less is more” :)) and the most logical.
>
> You mentioned upgrade being a problem but I don’t think this is correct
> since approach 2 means that the color theme pages are “demo” pages meaning
> that there will never be any upgrade conflict. When we do new XWiki cycle
> versions, we will still be able to provide new color themes and since those
> are new (like Iceberg this year) users will be able to switch to them
> easily (there’s no upgrade issue either here).
>

Going again through the page types (specifically the "demo" one) and
through the options, I agree that, at least of the Color Themes case,
approach 2 should do the job. Of course, all of this being possible with
the contract that we don't update color themes and we always publish new
ones, of which I'm a bit skeptical.

So +0.5 for approach 2.

Thanks,
Eduard


>
> Thanks
> -Vincent
>
> > Thanks,
> > Eduard
> >
> > On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea <
> > mariusdumitru.flo...@xwiki.com> wrote:
> >
> >> On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne <
> >> thomas.morta...@xwiki.com>
> >> wrote:
> >>
> >>> So it seems that 2) is currently leading with Ecaterina and Vincent.
> >>>
> >>> Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think
> >>> about delete ?).
> >>>
> >>>
> >>
> >>> Marius, does your proposal means you are more for 1) but with the
> >>> difference that the default color theme would be allowed for edit ?
> >>>
> >>
> >> Yes, but I'm ok with 2)
> >>
> >>
> >>>
> >>> Any other point of view input ?
> >>>
> >>> On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica)
> >>> <vali...@gmail.com> wrote:
> >>>> On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <
> >>> thomas.morta...@xwiki.com>
> >>>> wrote:
> >>>>
> >>>>> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <vinc...@massol.net
> >
> >>>>> wrote:
> >>>>>> To give my opinion, I’m hesitating about 2 approaches:
> >>>>>>
> >>>>>> Approach 1: “standard"
> >>>>>> ==
> >>>>>>
> >>>>>> * We should have “Default Color Theme” be a copy from the Iceberg
> &

Re: [xwiki-devs] [NEW API] XAR entry type

[Eduard Moraru]

Hi, Thomas,

I'm having some difficulties understanding the available types and their
intent.

   - default: used to force the default. Edit and delete are not allowed
   and a 3-way merge is applied to the document during upgrades.

Shouldn't the default upgrade action be "keep new", specially if edit and
delete is restricted on the page? The assumption would be that it's a code
page and any unsaved modifications (e.g. as a fork extension) should be
overridden by the new version of the extension's code.

   - configuration: a document containing configuration. Edit is allowed
   and the document is never upraded.

Normally, configuration is among the only things you might actually want to
make a choice on, as someone running an upgrade. It does not make much
sense to never upgrade a configuration document, specifically when you have
just added a new feature. Thinking of package managers (i.e. apt's dpkg),
they allow specifying beforehand or even answering interactively on the
action to take (merge/new/old) for the configuration files of a package
being upgraded. Also, the general default for config files is "merge" and
not "keep old".

   - home: a wiki home page. Edit is allowed and the document is upgraded
   only if it's not been customized.
   - demo: a document which purpose is to provide demo data. Edit and
   delete are allowed and the document is upgraded only if it's not been
   customized.

I don't really understand the distinction between "home" and "demo". AFAICS
from the definition, "home" is not supposed to be deleted, but why would we
want to enforce such a restriction? If we are talking about wiki homepages,
we can already configure that in the wiki descriptor as "Main.WebHome" is
not really a fixed entrypoint/API. For application homepages, I fail to see
the need to edit them, so I believe they should use "demo" instead of
"home".

IMO, "Main.WebHome" should be set to "demo" since that is what it really
is. We expect the admin to edit it with his needs.

AFAIU, "demo" makes sense and "configuration" is mostly something that the
admin might choose, with a default of "merge".

Thanks,
Eduard


On Wed, Apr 25, 2018 at 7:49 PM, Thomas Mortagne 
wrote:

> By the way this is not only about XWiki Standard. We also need to
> think about entry type in contrib extensions you know.
>
> On Mon, Apr 23, 2018 at 1:40 PM, Thomas Mortagne
>  wrote:
> > As I indicated it would be better if you could send other mail to
> > discuss those pages separately (there is already one for the the
> > themes) :)
> >
> > On Mon, Apr 23, 2018 at 12:39 PM, Ecaterina Moraru (Valica)
> >  wrote:
> >> Dashboard.WebHome should be editable.
> >> FlamingoThemes.* should be editable in order for users to set custom
> logos.
> >> XWiki.DefaultSkin should be editable for the same logo reason.
> >>
> >> Thanks,
> >> Caty
> >>
> >> On Mon, Apr 23, 2018 at 1:27 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> >> wrote:
> >>
> >>> Hi devs,
> >>>
> >>> When dealing with extension pages protection we ended up with a very
> >>> visible issue: EVERYONE customize the home page so it does not make
> >>> much sense to warn every user trying to edit it that it's dangerous
> >>> and might break the extensions.
> >>>
> >>> Since it's not the only use case 10.3 introduce the concept of XAR
> >>> entry type which allow controlling a bit more edit/delete and upgrade
> >>> behavior. See http://extensions.xwiki.org/
> xwiki/bin/view/Extension/XAR+
> >>> Module+Specifications#Hpackage.xml
> >>> for more details.
> >>>
> >>> On component side it's possible to decide the default type of a page
> >>> reference (that's where "Main.WebHome" type come from currently). It's
> >>> also possible to override the upgrade behavior for a specific type or
> >>> even a specific reference for more exotic use cases.
> >>>
> >>> So it's now possible to control the type you want for a page at XAR
> >>> descriptor level. I already typed a few page, for example
> >>> "Main.WebHome" is now of type "home" which means "it's OK to edit it
> >>> and you should only upgrade it if no customization have been made".
> >>>
> >>> Cool home page is covered but we now entered a new era of endless
> >>> debates to decide of what type some page should be and what other
> >>> types to introduce :)
> >>>
> >>> We are not going to discuss all these in this mail so everyone with a
> >>> doubt should start a discussion for a standard page (or a set of
> >>> standard page which are obviously very similar like color themes).
> >>>
> >>> Currently, protected page produce a warning that you can force. The
> >>> plan in 10.4 is to keep the warning only for advanced completely
> >>> prevent basic user to modify protected pages by default and also allow
> >>> configuring all that (indicate in your profile that you don't want to
> >>> be bothered with that, override edit/delete right even for advanced
> >>> users, 

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Eduard Moraru]

Hi,

I'm sorry, but nothing related to configuration inside pages looks very
"wiki-like" to me. We're not talking about content pages here, but rather
about a preset/pack of preferences (I would actually call them more code
than configuration, to be honest, since we're talking about CSS and LESS)
which have an identity. Once you start changing their values, they lose
their identity and you can't call them "Iceberg" or "Charcoal" (etc.)
anymore. Once you customize them, they are "CustomIceberg" or "MyIceberg"
(etc.), if you really want to preserve a hint of the base of your
customizations.

IMO, we should have a distinction between the default color themes and the
user contributed ones (this also includes customized copies of default
ones). I believe this would actually help the user in getting a better
understanding of what is going on instead of asking them to digg through
the document history, look at diffs, etc. Nobody wants to do that.

I don't like (-0) the idea of DefaultColorTheme being a useless copy of
Iceberg. If we want, we could store in an unexposed property of the
FlamingoThemes application what is the default color theme, so that the
user can have a "default" option or a "Reset to default" when choosing what
theme to use. Also, new versions of XWiki could update that property's
value (as part of the code), for when we will want to introduce a new
"default" theme for future versions of XWiki. I believe users need to be
able to see and easily experience new features, without asking them to drop
their customizations or write code (i.e. compared to what they would get if
they intall a new/clean XWiki instance with the latest version).

I do like (+1) the other 2 bullet points of Approach 1 ("standard").
Hitting "Customize" when using a standard theme should generate you a copy
for your customization which you can then select from the list and apply.
Heck, we could even make a nice distinction in the UI (or at least in the
Select input) between the standard themes and the custom(-ized) ones.

IMO, the important part to distinguish the fact that the configuration part
(for a regular, non-dev) is choosing *which* color theme to use, while the
customization (i.e. coding, done by someone that understands CSS/LESS, in
this case) part is editing/customizing your own version of a color theme.
Should be easy to make the choice if we look at it this way, since it would
be similar to what we do for other parts of XWiki that need either
configuration (i.e. choosing *what* to use) and that might need also some
customization (i.e. modifying or defining *how* that choice will perform
its job).


General note/rant/reiteration: I am very much in favor of resisting the
urge to "edit everything" (that's what actually got us to the current
"problem"), even if it is a wiki at heart, since no software maintainers
can provide you any time of support or upgrade paths that can factor in the
fact that you are just barging in and making a beautiful mess of the code
they developed. IMO, we just need to draw the line where the software ends
and the wiki begins, otherwise users will be trapped/stuck with outdated
and un-upgradable XWiki versions and will be regretting their choice. We
need to think of the admins as well, and not only from the POV of the dev
that wants to make everything possible. You should not need a developer
(possibly the original developer of the project/customizations) in order to
make a really basic operation such as an upgrade. Maybe I'm saying
"sometimes less is more"? :)


Thanks,
Eduard

On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> wrote:
>
> > So it seems that 2) is currently leading with Ecaterina and Vincent.
> >
> > Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think
> > about delete ?).
> >
> >
>
> > Marius, does your proposal means you are more for 1) but with the
> > difference that the default color theme would be allowed for edit ?
> >
>
> Yes, but I'm ok with 2)
>
>
> >
> > Any other point of view input ?
> >
> > On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica)
> >  wrote:
> > > On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <
> > thomas.morta...@xwiki.com>
> > > wrote:
> > >
> > >> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol 
> > >> wrote:
> > >> > To give my opinion, I’m hesitating about 2 approaches:
> > >> >
> > >> > Approach 1: “standard"
> > >> > ==
> > >> >
> > >> > * We should have “Default Color Theme” be a copy from the Iceberg
> > color
> > >> theme page. I think I’d prefer the copy to be done at runtime; for
> > example
> > >> if the currently defined color theme page doesn’t exist when going to
> > the
> > >> L > Themes admin page, create it by copying Iceberg. This provides a
> > self
> > >> healing feature if the color theme page has been 

Re: [xwiki-devs] [Discussion] Coding practice for location of internal package name

[Eduard Moraru]

+1 for the definition of "module" (in "module name") as general maven
module and not only top level modules.

i.e. a package name
"org.xwiki.module.submodule1.submodule2.submoduleN.*internal*.package1.package2.packageN"
corresponding to a maven artifact with ID
"org.xwiki.module.submodule1.submodule2.submoduleN".

Thanks,
Eduard

On Wed, Apr 18, 2018 at 7:59 PM, Thomas Mortagne 
wrote:

> On Wed, Apr 18, 2018 at 6:43 PM, Clément Aubin 
> wrote:
> > Hi devs,
> >
> > On 04/18/2018 10:45 AM, Marius Dumitru Florea wrote:
> >> I think I prefer having the internal package closer to the root (so that
> >> it's easier to spot it) but I may have made the same "error" like
> Guillaume
> >> and Thomas in the past.
> >
> > IMO, the current rule is incomplete as we do not take into account
> > submodules (which are the root cause of this conversation).
> >
> > In the example given by Vincent, the package
> > org.xwiki.notifications.preferences.internal is part of the module
> > xwiki-platform-notifications-preferences : if we consider that the name
> > of the module is notification-preferences, then it's logical to put the
> > internal subpackage here.
> >
> > Note that this is the same idea for org.xwiki.job.handler.internal,
> > which is in the submodule xwiki-platform-job-handler.
>
> Yep that's the idea.
>
> The rule I usually apply IS "org.xwiki.(module name).internal." from
> my point of view or to me more accurate the rule way I see it would be
> better described as "everything in the module have the same package
> prefix" so "org.xwiki.job.handler" in that example. The thing is you
> interpret "module name" as "top level module name" which I don't
> really agree with.
> http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/
> JavaCodeStyle/#HPackagenames
> is not really explicit about submodules in practice.
>
> >
> > We then have to choose either to accept this format or totally discard
> > submodules.
> >
> >> On Mon, Apr 16, 2018 at 7:28 PM, Vincent Massol 
> wrote:
> >>
> >>> Hi devs,
> >>>
> >>> On Matrix/IRC, I’ve posted the following:
> >>>
> >>> "
> >>> * Guillaume Delhumeau: BTW your naming is strange for the internal
> package
> >>> * for ex: package org.xwiki.notifications.preferences.internal.email;
> >>> * normally we put internal just after the main package part
> >>> * ie.
> >>> * org.xwiki.notifications.internal.*
> >>> * and org.xwiki.notifications.* for public classes
> >>> * see http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/
> >>> JavaCodeStyle/#HPackagenames
> >>> * General rule is org.xwiki.(module name).internal.
> >>> * I see thomas has done the same “error" for
> >>> org.xwiki.job.handler.internal and org.xwiki.job.handler.
> internal.question
> >>> . So maybe there's something to discuss/change
> >>> * I guess we have a mix of both now so we should discuss it and adjust
> our
> >>> rules if need be
> >>> “
> >>>
> >>> So I think we don’t have all the same rules/understanding of the
> >>> definition at http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/
> >>> JavaCodeStyle/#HPackagenames
> >>>
> >>> I’d like to discuss with you to see what you prefer and adjust our
> rules
> >>> so that it matches what we do in practice.
> >>>
> >>> Any take in this?
> >>>
> >>> Thanks
> >>> -Vincent
>
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] Skipping XWiki 10.3 Release Candidate 1 and releasing 10.3 Final next week

[Eduard Moraru]

Also, this means we have to make sure to *hold our commits on master* and
avoid adding anything that is not supposed to go into 10.3 Final.

The reason is obviously because we do not have a "safe" stable-10.3.x
branch and master is not yet associated with 10.4-SNAPSHOT, but still on
10.3-SNAPSHOT until the final release.

Thanks,
Eduard

On Mon, Apr 16, 2018 at 7:42 PM, Eduard Moraru <enygma2...@gmail.com> wrote:

> Done:
> * moving jira issues
> * removing the 10.3RC1 Release Plan page
>
> TODO (for the RM of 10.3 Final):
> * @since annotations
> * existing release notes from http://www.xwiki.org/xwiki/
> bin/view/ReleaseNotes/Data/XWiki/10.3RC1/ need to be moved to the Release
> Notes of 10.3 Final and the corresponding jira issues need to update their
> documentation links
>
> Thanks,
> Eduard
>
> On Mon, Apr 16, 2018 at 6:08 PM, Eduard Moraru <enygma2...@gmail.com>
> wrote:
>
>> Hi,
>>
>> Today was supposed to be the release of 10.3 RC1. However, due to various
>> reasons (the stabilization of the release resulted in reverting the most
>> important part of the work done for this release, missing documentation,
>> etc.) and to avoid spending more time on almost empty releases instead of
>> the features themselves, we have decided that it's best to skip the 10.3
>> RC1 release and jump directly to 10.3 Final, next week.
>>
>> I will be updating the version on jira as well to remove 10.3 RC1 and
>> move the existing issues to 10.3.
>>
>> Some code changes need to be done as well for the @Since annotations
>> mentioning 10.3RC1 that will have to be switched to 10.3. (will leave
>> that to the devs that added them)
>>
>> Thanks and sorry for the inconvenience,
>> Eduard
>>
>
>

Re: [xwiki-devs] Skipping XWiki 10.3 Release Candidate 1 and releasing 10.3 Final next week

[Eduard Moraru]

Done:
* moving jira issues
* removing the 10.3RC1 Release Plan page

TODO (for the RM of 10.3 Final):
* @since annotations
* existing release notes from
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.3RC1/ need
to be moved to the Release Notes of 10.3 Final and the corresponding jira
issues need to update their documentation links

Thanks,
Eduard

On Mon, Apr 16, 2018 at 6:08 PM, Eduard Moraru <enygma2...@gmail.com> wrote:

> Hi,
>
> Today was supposed to be the release of 10.3 RC1. However, due to various
> reasons (the stabilization of the release resulted in reverting the most
> important part of the work done for this release, missing documentation,
> etc.) and to avoid spending more time on almost empty releases instead of
> the features themselves, we have decided that it's best to skip the 10.3
> RC1 release and jump directly to 10.3 Final, next week.
>
> I will be updating the version on jira as well to remove 10.3 RC1 and move
> the existing issues to 10.3.
>
> Some code changes need to be done as well for the @Since annotations
> mentioning 10.3RC1 that will have to be switched to 10.3. (will leave
> that to the devs that added them)
>
> Thanks and sorry for the inconvenience,
> Eduard
>

[xwiki-devs] Skipping XWiki 10.3 Release Candidate 1 and releasing 10.3 Final next week

[Eduard Moraru]

Hi,

Today was supposed to be the release of 10.3 RC1. However, due to various
reasons (the stabilization of the release resulted in reverting the most
important part of the work done for this release, missing documentation,
etc.) and to avoid spending more time on almost empty releases instead of
the features themselves, we have decided that it's best to skip the 10.3
RC1 release and jump directly to 10.3 Final, next week.

I will be updating the version on jira as well to remove 10.3 RC1 and move
the existing issues to 10.3.

Some code changes need to be done as well for the @Since annotations
mentioning 10.3RC1 that will have to be switched to 10.3. (will leave that
to the devs that added them)

Thanks and sorry for the inconvenience,
Eduard

Re: [xwiki-devs] [Proposal] Invest in a new translation service

[Eduard Moraru]

On Mon, Mar 26, 2018 at 1:11 PM, Guillaume Delhumeau <
guillaume.delhum...@xwiki.com> wrote:

> 2018-03-26 12:05 GMT+02:00 Eduard Moraru <enygma2...@gmail.com>:
>
> > Hi,
> >
> > I am a bit skeptical about such a platform that:
> > * we'd need our users to register to (yet another account for the XWiki
> > contributor)
> >
>
> Maybe we could use an LDAP/SSO connector, just as we do for the Forum.
>
>
> > * we'd need to twist and turn so that it bends to our needs
> > * (and probably other things caused by the fact that I did not get to
> read
> > too much about it yet :) )
> >
> > You mentioning PRs made me wonder if we couldn't simply ask contributors
> to
> > submit a standard PR for translation changes. That would take care of
> many
> > things and also give the author proper attributions.
> >
> > The minimum requirements for this would be, IMO:
> > * the list of all translation files (i.e. links on GitHub; either
> manually
> > managed, automatically extracted or a mix) and
> > * the ability to search for a key or translation and find the relevant
> file
> > (most likely this would involve us indexing or caching the translation
> > files content somewhere on xwiki.org, kept up to date with webhooks? --
> > maybe on a very light translations dedicated wiki; a light l10n?).
> > * the ability to create a new language for a translation page, if it does
> > not already exist (to help the edge case when the language file is not
> > already there).
> >
> > Something like this could even be done without an xwiki.org account, as
> > long as the user has a github account for editing (even with GitHub's web
> > edit UI) and submitting the PR.
> >
>
> You just said it was a problem to use an other account that the xwiki.org
> account :) You assume most people have a Github account, but I'm not sure
> concerning translators.
>

Yes, I did realize that :), but I did assume that the github account has
more value and has a higher chance of already existing for the contributor
(code or translations contributor), than some weblate service account.

Even comparing xwiki.org ot github accounts, there is still a higher chance
that some contributor has the github account already in place :)

Thanks,
Eduard

>
>
> >
> > Most importantly, IMO, the translations could become part of the
> > development process and not just a step at release time. A clear
> > consequence would be that snapshots would benefit from new and integrated
> > translations, added since the last release and we won't be seeing them
> just
> > after the release. AFAIU, weblate supports this as well, but by using its
> > own github account and submitting PRs in the name of the author (which
> > would not be the same effect as the actual author, but then again, only
> > actual GitHub users would care about this).
> >
>
> > WDYT? Would it be too hard to use for non-techical users? Would we need
> > more that the described, in terms of UI (and would it justify the
> > effort/cost)?
> >
> > Thanks,
> > Eduard
> >
> >
> > On Fri, Mar 23, 2018 at 11:56 AM, Vincent Massol <vinc...@massol.net>
> > wrote:
> >
> > > Hi devs,
> > >
> > > We started discussing this yesterday on the xwiki chat.
> > >
> > > Here’s the rationale for changing:
> > >
> > > * l10n is slow and is preventing users to contribute translations (it’s
> > > much harder than it should be)
> > > * it’s costing us maintenance that we shouldn’t have to do (it’s not
> our
> > > role to maintain a translation service, even though it was nice to eat
> > our
> > > own dog food initially). I see this very similar to when we switched
> from
> > > our GWT-based WYSIWYG editor to CKEditor.
> > > * It’ll allow us to benefit from new features/bug fixes the external
> > > service develops
> > > * Right now it’s taking an hour or more every time we release to
> > integrate
> > > the translation changes and this slows us down to increase our release
> > > delivery speed
> > > * We’re putting the onus on the RM only to validate that the proposed
> > > translations are good. So only 1 pair of eyes.
> > > * We have no time to fix any translation if they’re not correct. A
> system
> > > where when someone proposes a new translation generates a PR that we
> > apply
> > > as they come in would be much better and solve both the review and
> > lateness
> > > issues.
> > >
> > > Of course it’ll me

Re: [xwiki-devs] [Proposal] Invest in a new translation service

[Eduard Moraru]

Hi,

I am a bit skeptical about such a platform that:
* we'd need our users to register to (yet another account for the XWiki
contributor)
* we'd need to twist and turn so that it bends to our needs
* (and probably other things caused by the fact that I did not get to read
too much about it yet :) )

You mentioning PRs made me wonder if we couldn't simply ask contributors to
submit a standard PR for translation changes. That would take care of many
things and also give the author proper attributions.

The minimum requirements for this would be, IMO:
* the list of all translation files (i.e. links on GitHub; either manually
managed, automatically extracted or a mix) and
* the ability to search for a key or translation and find the relevant file
(most likely this would involve us indexing or caching the translation
files content somewhere on xwiki.org, kept up to date with webhooks? --
maybe on a very light translations dedicated wiki; a light l10n?).
* the ability to create a new language for a translation page, if it does
not already exist (to help the edge case when the language file is not
already there).

Something like this could even be done without an xwiki.org account, as
long as the user has a github account for editing (even with GitHub's web
edit UI) and submitting the PR.

Most importantly, IMO, the translations could become part of the
development process and not just a step at release time. A clear
consequence would be that snapshots would benefit from new and integrated
translations, added since the last release and we won't be seeing them just
after the release. AFAIU, weblate supports this as well, but by using its
own github account and submitting PRs in the name of the author (which
would not be the same effect as the actual author, but then again, only
actual GitHub users would care about this).

WDYT? Would it be too hard to use for non-techical users? Would we need
more that the described, in terms of UI (and would it justify the
effort/cost)?

Thanks,
Eduard


On Fri, Mar 23, 2018 at 11:56 AM, Vincent Massol  wrote:

> Hi devs,
>
> We started discussing this yesterday on the xwiki chat.
>
> Here’s the rationale for changing:
>
> * l10n is slow and is preventing users to contribute translations (it’s
> much harder than it should be)
> * it’s costing us maintenance that we shouldn’t have to do (it’s not our
> role to maintain a translation service, even though it was nice to eat our
> own dog food initially). I see this very similar to when we switched from
> our GWT-based WYSIWYG editor to CKEditor.
> * It’ll allow us to benefit from new features/bug fixes the external
> service develops
> * Right now it’s taking an hour or more every time we release to integrate
> the translation changes and this slows us down to increase our release
> delivery speed
> * We’re putting the onus on the RM only to validate that the proposed
> translations are good. So only 1 pair of eyes.
> * We have no time to fix any translation if they’re not correct. A system
> where when someone proposes a new translation generates a PR that we apply
> as they come in would be much better and solve both the review and lateness
> issues.
>
> Of course it’ll mean some plugins/customizations to develop in the service
> we will use since it’s not going to support some custom formats we have
> such as our XAR XML format. So we need to pick a tool that allows for this.
>
> The proposal:
> * Start investing in implementing XWiki translation using an external tool.
> * Start  by looking at weblate: https://weblate.org/en/ since
> ** it seems to offer lots of features we need (automatic PR - see
> https://docs.weblate.org/en/latest/vcs.html#github, quality checks,
> plugins). See https://weblate.org/en/features/
> ** it’s open source itself and in case the service goes down we can ask
> XWiki SAS to host it for us (see https://github.com/WeblateOrg/weblate).
> ** We need to ask them if they can host us, see https://weblate.org/en/
> hosting/ and the part about "Hosting for free software”.
> ** We could also ask XWiki SAS if they’d accept paying a “Basic” plan (200
> euros/year which is affordable IMO vs hosting it ourselves)
> ** There’s a REST API so that if we want we can provide a view/status of
> the translations from xwiki.org: https://docs.weblate.org/en/
> latest/api.html . We could even imagine using this API to convert from a
> format to our own format, if need be.
> * Propose to have a developer work on this in an upcoming roadmap (to be
> defined but as early as possible since l10n is not in good shape)
> * Fix l10n as much as we can without spending too much time on it, until
> we have the new translation service ready to be used
>
> Things to look at:
> * Ability to register custom formats or more generally how to handle our
> custom format
> * How do we handle deprecated translations keys
> * How do we handle global rename/move of keys from one resource file to
> another
> * 
>
> WDYT?
>
> 

Re: [xwiki-devs] [VOTE] Add new check to measure quality of tests

[Eduard Moraru]

Sounds interesting,
+1.

Thanks,
Eduard

On Thu, Mar 15, 2018 at 12:26 PM, Thomas Mortagne  wrote:

> +1
>
> On Thu, Mar 15, 2018 at 9:30 AM, Vincent Massol 
> wrote:
> > Hi devs,
> >
> > As part of the STAMP research project, we’ve developed a new tool
> (Descartes, based on Pitest) to measure the quality of tests. It generates
> a mutation score for your tests, defining how good the tests are. Technical
> Descartes performs some extreme mutations on the code under test (e.g.
> remove content of void methods, return true for methods returning a
> boolean, etc - See https://github.com/STAMP-project/pitest-descartes). If
> the test continues to pass then it means it’s not killing the mutant and
> thus its mutation score decreases.
> >
> > So in short:
> > * Jacoco/Clover: measure how much of the code is tested
> > * Pitest/Descartes: measure how good the tests are
> >
> > Both provide a percentage value.
> >
> > I’m proposing to compute the current mutation scores for xwiki-commons
> and xwiki-rendering and fail the build when new code is added that reduce
> the mutation score threshold (exactly the same as our jacoco threshold and
> strategy).
> >
> > I consider this is an experiment to push the limit of software
> engineering a bit further. I don’t know how well it’ll work or not. I
> propose to do the work and test this for over 2-3 months and see how well
> it works or not. At that time we can then decide whether it works or not
> (i.e whether the gains it brings are more important than the problems it
> causes).
> >
> > Here’s my +1 to try this out.
> >
> > Some links:
> > * pitest: http://pitest.org/
> > * descartes: https://github.com/STAMP-project/pitest-descartes
> > * http://massol.myxwiki.org/xwiki/bin/view/Blog/ControllingTestQuality
> > * http://massol.myxwiki.org/xwiki/bin/view/Blog/MutationTestingDescartes
> >
> > If you’re curious, you can see a screenshot of a mutation score report
> at http://massol.myxwiki.org/xwiki/bin/download/Blog/
> MutationTestingDescartes/report.png
> >
> > Please cast your votes.
> >
> > Thanks
> > -Vincent
>
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [GSoC] XWiki has been selected as a Google Summer of Code 2018 mentor organization!

[Eduard Moraru]

Right. So let me rephrase that last part (guidelines page updated as well):

"
...
Another thing you can help with is to increase the list of "Onboarding"
issues that we know about on jira.xwiki.org. You can use the label
"Onboarding" and apply it to jira issues which you know for a fact that
they would be easy to fix by someone new to XWiki. We`ve currently labeled
quite a few issues with the "Onboarding" JIRA label [3] and are listing
them on the guidelines [4] page to help students discover them more easily.

--
...
[3] https://jira.xwiki.org/issues/?jql=labels%3DOnboarding
...
"

Thanks,
Eduard

On Tue, Feb 13, 2018 at 9:26 AM, Vincent Massol <vinc...@massol.net> wrote:

> Hi Edy,
>
> > On 12 Feb 2018, at 18:55, Eduard Moraru <enygma2...@gmail.com> wrote:
> >
> > Hi devs,
> >
> > As most of you already know, XWiki has been accepted to Google Summer of
> > Code 2018!
>
> yeeepp! :)
>
> > We currently have 12 project proposals and 8 mentors [1].
> >
> > There is 1 month left [2] before the student application period begins,
> so
> > if others want to sign up as mentors and/or propose new GSoC projects for
> > the students, please do so on the ideas list [1].
> >
> > During this period, students are supposed to ask questions about the
> > proposed projects so please don`t hesitate to welcome and help them out!
> >
> > Another thing you can help with is to increase the list of "Trivial"
> issues
> > that we know about on jira.xwiki.org. You can to set the "Difficulty"
> field
> > of a jira issues to "Trivial" if you know for a fact that it would be
> > something easy for someone new to XWiki to fix. We`re currently using a
> > JIRA filter [3] to gather all these "Trivial" issues and listing them on
> > the guidelines [4] page to help students discover them more easily.
>
> Shouldn’t we change this now that we have the new onboarding process?
>
> We might need to update gsoc.xwiki.org to reflect the new onboarding +
> the new jira issues (labelled onboarding).
>
> Thanks
> -Vincent
>
>
> >
> > Thanks,
> > Eduard
> >
> > --
> >
> > [1] http://gsoc.xwiki.org
> > [2] https://developers.google.com/open-source/gsoc/timeline
> > [3] https://jira.xwiki.org/issues/?filter=10534
> > [4]
> > http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#
> HIncreasingyourchancesofbeingacceptedasastudent
>
>

[xwiki-devs] [GSoC] XWiki has been selected as a Google Summer of Code 2018 mentor organization!

[Eduard Moraru]

Hi devs,

As most of you already know, XWiki has been accepted to Google Summer of
Code 2018!

We currently have 12 project proposals and 8 mentors [1].

There is 1 month left [2] before the student application period begins, so
if others want to sign up as mentors and/or propose new GSoC projects for
the students, please do so on the ideas list [1].

During this period, students are supposed to ask questions about the
proposed projects so please don`t hesitate to welcome and help them out!

Another thing you can help with is to increase the list of "Trivial" issues
that we know about on jira.xwiki.org. You can to set the "Difficulty" field
of a jira issues to "Trivial" if you know for a fact that it would be
something easy for someone new to XWiki to fix. We`re currently using a
JIRA filter [3] to gather all these "Trivial" issues and listing them on
the guidelines [4] page to help students discover them more easily.

Thanks,
Eduard

--

[1] http://gsoc.xwiki.org
[2] https://developers.google.com/open-source/gsoc/timeline
[3] https://jira.xwiki.org/issues/?filter=10534
[4]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HIncreasingyourchancesofbeingacceptedasastudent

[xwiki-devs] [GSOC] XWiki is applying for GSoC 2018. Proposals and mentors needed!

[Eduard Moraru]

Hello fellow XWiki community members,

This year XWiki is planning to participate once more at Google's Summer of
Code [1].

The organization registration period has already started (January 4, 2018)
and the deadline is
January 23, 2018 [2] (in 1.5 weeks).

1. We need to provide by then a list of proposals and assign mentors for
the students that are going to implement them.

I would like to ask everybody that wants to participate as a mentor from
the XWiki organization to review the proposals [3] list (when projects are
being added) and add as many interesting proposals as possible.
The proposals can be either new, or they can be revived from previous
years. Just navigate to the previous years [4], find the proposal you like
and know about, go to its proposal page (click it) and press the "Clone to
this year" link. Now you can assign yourself as lead for that project,
update it's description if needed and wait for the student applications to
start pouring

2. We also need to submit the actual application [5] of the XWiki
organization to participate to the GSoC 2018 project so I would also like
to ask you to review it so that we have a better chance of being selected
into the program.

3. If you feel that you would like to help on improving XWiki's GSoC guides
and application forms, please find tips for students [6] on XWiki's GSoC
page, the student application form [7] and the lessons learned [8] from
previous years participations.

Thanks for your help,
Eduard

--

[1] https://summerofcode.withgoogle.com/
[2] https://summerofcode.withgoogle.com/how-it-works/#timeline
[3]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/#HProposedProjects2829
[4]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HPreviousGSoCeditions
[5]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/OrganizationApplicationForm
[6] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines
[7]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/student+application+form
[8] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/LessonsLearned

[xwiki-devs] [Proposal] [CodeStyle] Committing XML wiki page date changes

[Eduard Moraru]

Hi devs,

These are the current code style rules for committed XML wiki pages:
http://dev.xwiki.org/xwiki/bin/view/Community/XWikiXMLFilesCodeStyle

= Proposal 1 =

I was personally not aware we had documented these practices that we had
been applying since forever. It's good that we have them, but there seems
to be no mention about committing changes for the "creationDate", "date"
and "contentUpdateDate" fields.

Part of the committers (including myself) are applying the old practice of
omitting changes to the date fields when committing a change to an XML wiki
page. However, since this practice is not written and agreed upon, its
usage is not consistent.

So, the proposal is to include the rule of not committing changes on the
date fields of XML wiki pages.

The rationale, AFAIR, includes:
* After an upgrade, users should not see "ghost" modifications in their
wiki (e.g. when sorting by date in the Page Index). This affects even more
manual imports with the "as backup" option enabled.
* On release, any date changes of a default translation XML page will
produce N other XML page changes, for each translation of the modified page
(due to the way l10n exports the translations based on the latest version
of the default language of that page).
* others?

= Proposal 2 =

Now, building on this, I would like to make a second proposal (which I
don't believe deserves a separate thread):
1) Let's remove all date fields from committed XML wiki pages in our source
repository
2) Let's make sure that the XAR import properly handles empty or missing
date fields and falls back on the current date
3) Let's update the xar:format goal to remove the date fields
(configurable, since it could they might still be needed by some content
projects, etc.)
4) Let's make the build fail (xar:verify) if the XML wiki pages contain
date fields (again configurable, as above)

Note: All the above still depend on the first proposal of not committing
date changes to XML files (which will be simplified by point 3) above).

The rationale for this is that we have always wanted to fix our "dates
problem", since after installation, the wiki is populated with pages
created in 2009, which is extremely odd to users that have just installed
XWiki. This second proposal sounds to me like a solution for that.

WDYT?

Thanks,
Eduard

[xwiki-devs] [ANN] XWiki 9.11.1 released

[Eduard Moraru]

The XWiki development team is proud to announce the availability of XWiki
9.11.1.
This is a bugfix release that covers important issues that we have
discovered since 9.11 has been released.

You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.11.1

Thanks for your support
-The XWiki dev team

Re: [xwiki-devs] [Idea] Look at Thymeleaf as an optional templating language?

[Eduard Moraru]

On Wed, Jan 3, 2018 at 11:01 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> From the home page it looks very HTML oriented, which is not good for us. I
> think we need a general purpose templating language that can be used to
> generate anything (JSON, XML, CSV, etc.) not just HTML.
>

Yeah, my first impression was that it looks very similar to JSF, maybe a
bit simplified and less configuration needy.

Thanks,
Eduard

>
> On Tue, Jan 2, 2018 at 11:48 PM, Vincent Massol 
> wrote:
>
> > See http://www.thymeleaf.org/
> >
> > With this, users could combine HTML and scripting which could be a nice
> > option when using the {{html}} macro for example.
> >
> > {{html}}
> > {{thymeleaf}}
> > …
> > {{/thymeleaf}}
> > {{/html}}
> >
> > Related:
> > * https://dzone.com/articles/template-engines-review-after-
> > deprecated-velocity
> >
> > Thanks
> > -Vincent
> >
> >
>

Re: [xwiki-devs] A subtle problem with the Workflow Application and nested pages

[Eduard Moraru]

Hi,

Yes, this makes sense because in the previous "doc:PageB" version, the link
was in relative form (no space specified) and it was resolved to the
current space (which was "Public" when PageA was in the "Public" space).
After NS, using "doc:Draft.PageB.WebHome" means using a very explicit and
absolute reference that does no resolution so it will behave the same,
regardless of the context where PageA(.WebHome) is located (hence, it will
link to the "Draft" space).

There are a couple of cases where you could get away with it without any
refactoring and using advanced knowledge on xwiki's link syntax resolution
algorithm. TL;DR; These are the ones that involve links coming from higher
in the hierarchy towards pages lower in the hierarchy or when linking
between sibling pages (i.e. same level in the hierarchy).
You can find more details on
http://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/XWikiSyntax/?syntax=2.1=Links
(see the "[[.PageA]]" and "[[.PageA.PageB]]" examples and then the details
on the resolution of "Untyped" links).

Now, I have mentioned this just for the sake of completeness on the matter
and would not really advise to rely on these "relative" links, since they
are currently more of a side effect of our current model than a feature
that is well-thought and recommended (e.g. we don't have support for
relative links upper in the hierarchy like "../../PageX").

Given the proper support for relative links in our syntax, indeed, the
listener and link fixing solution would be the recommended one.

Hope this helps,
Eduard

On Sat, Dec 16, 2017 at 2:06 PM, Anca Luca  wrote:

> Hello Clemens,
>
> Indeed, this is _one_ of the problems that the workflow application has on
> a "nested" environment.
>
> I think it's a good approach for the fix, the only thing that you should
> try to take care of is to make this as generic as possible wrt the
> configured draft space in the publication workflow config of the document
> being published (fix links relative to this space). Don't hesitate, if
> needed, to add a configuration of the "default publication space" in the
> publication workflow config, I found the need for it in other situations as
> well, so it won't hurt.
>
> Also, one issue I can think of (which is related to the other issues that
> publication workflow has on nested) is that the page to which the link is
> might not yet be published, and in this case, imo, the link should be
> refactored and be a "broken link" until the target page gets published.
>
> Thanks for working on this,
> Anca
>
> On Thu, Nov 30, 2017 at 12:10 AM, Clemens Robbenhaar <
> c.robbenh...@posteo.de
> > wrote:
>
> > Hi Devs,
> >
> >  some users reported a problem to me concerning the Publication Workflow
> > Application and the nested pages feature.
> > The problem is as follows:
> >
> >  In their old instance (some 6.4.x) they had a draft space and a public
> > space and workflows attaching each page in the draft space with a page in
> > the public space in an 1:1 manner, like:
> >
> >   Draft.WebHome --> Public.WebHome
> >   Draft.PageA   --> Public.PageA
> >   Draft.PageB   --> Public.PageB
> >
> > Now if a link in, say, PageA in the Draft space points to another page,
> > e.g. PageB, this is done via a relative link like [[link
> text>>doc:PageB]]
> > After publishing PageA, the link of the published variant points to the
> > published variant of PageB (and not the variant in the Draft space),
> which
> > is the desired effect from the users point of view.
> >
> > Now after migration to 9.10 the situation is as follows:
> >
> >   Draft.WebHome--> Public.WebHome
> >   Draft.PageA.WebHome  --> Public.PageA.WebHome
> >   Draft.PageB.WebHome  --> Public.PageB.WebHome
> >
> > Now a link to PageB in PageA looks like: [[link
> > text>>doc:Draft.PageB.WebHome]] because both pages are no longer in the
> > same space, but each in their own space.
> > Publishing the draft makes the link in the published variant point back
> to
> > the Draft space, of course. However this is different from the behavior
> > before nested pages and the users experience this as a bug.
> >
> > A manual solution would be to edit all pages and make the links point to
> > the published variant of the pages. However this is not only a cumbersome
> > and error prone task, but also the users are used to the "automatic" link
> > conversion that made links in the published variant point to published
> > pages and are wont to continue setting links to pages in the draft space,
> > expecting them to point to the "right place" after publishing.
> > The fact that now titles are used throughout in the navigation tree, and
> > the titles of the draft and published variant are usually the same and
> thus
> > indistinguishable complicates the problem even more.
> >
> > To fix this I could write a separate extension that listens to Publish
> > events send from the Workflow extension, and which converts the links in
> > the 

Re: [xwiki-devs] [Proposal] Login button for desktop

[Eduard Moraru]

+1 for Vincent's point.
* The Login/avatar transition from Guest to logged in user makes perfect
sense, even if it looks a bit awkward for guests.
** This also goes in line with a previous discussion we had on
Notifications which concluded that Search should be the left-most icon, due
to its expansion when clicked and the fact that it would shift anything to
its left and we don't want users to be chasing our buttons.
* The textual "Log-in" is justified, as Caty proposes, to remove any
ambiguity caused by an icon and is a very used practice on the web

I find more points in favor of this than against it and tend to believe
that it will behave well in practice.

Here's a screenshot of how it would look like now (made by Caty):
https://jira.xwiki.org/secure/attachment/34756/Proposition5.1.png

Side Note: Thinking ahead, this might also be extended at some point to
have a drop-down login form when clicking the Log-In button from the top
menu, instead of redirecting to the login action, making the process much
smoother than it is right now.

Thanks,
Eduard

On Wed, Dec 13, 2017 at 10:57 AM, Thomas Mortagne  wrote:

> I'm fine with 2, 3 and 5. 5 indeed looks better (yes I find it obvious
> enough :)).
>
> On Tue, Dec 12, 2017 at 4:36 PM, Ecaterina Moraru (Valica)
>  wrote:
> > How about https://jira.xwiki.org/secure/attachment/34754/Proposition5.
> png ?
> >
> > Not sure why you want to add that button border, which is not consistent
> > with any button we have in the platform.
> >
> > WDYT?
> >
> > Thanks,
> > Caty
> >
> > On Tue, Dec 12, 2017 at 5:04 PM, Guillaume Delhumeau <
> > guillaume.delhum...@xwiki.com> wrote:
> >
> >> Hi Devs,
> >>
> >> Currently, the login button is inside the drawer menu, which is quite
> >> standard on mobile phones. However, on desktop, a lot of people are
> >> confused and cannot find how to login/register.
> >>
> >> I propose to add a login button in the top menu, like this:
> >> https://jira.xwiki.org/secure/attachment/34731/Proposition3.png
> >>
> >> Related JIRA: https://jira.xwiki.org/browse/XWIKI-14881#
> >>
> >> That could be nice to have it in addition to the current links, for
> 9.11.
> >>
> >> Note: we also need to put a "register" link in the login form, so that
> >> people can register from there without the need to also add a register
> >> button on the top menu (that would be too much IMO).
> >>
> >> WDYT?
> >>
> >> Thanks,
> >>
> >> --
> >> Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> >> Research & Development Engineer at XWiki SAS
> >> Committer on the XWiki.org project
> >>
>
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] Extension documents edit protection and Main.WebHome

[Eduard Moraru]

The second topic of interest was the extension pages that are designed to
be modified, like the demo AWM apps or intro blog post, homepage, etc.

1) IMO, all these pages should be separated from the code pages of an
extension and moved to a "-content" extension. At this point, we could
introduce a flag on a XAR extension that its pages are modifiable and all
the above described limitations will not be enforced and, on upgrade, the
user would be free to choose what happens to the changes (i.e. discard,
backup or even merge).

2) The second option would be to explicitly mark (in the extension
descriptor ?) modifiable pages inside a XAR extension, so to continue
mixing code pages with content pages, but I would prefer we would not
continue to do it. I guess this would be towards proposal 3) from Thomas,
but I think I would prefer it to be done from an extension level, and not
page level (since that would imply editing the page and might collide with
previous decisions).

Thanks,
Eduard

On Tue, Nov 7, 2017 at 4:43 PM, Eduard Moraru <enygma2...@gmail.com> wrote:

> Hi,
>
> One option I was discussion with Caty that would cover the need to not
> have code pages modified, while also allowing devs (including us) to work
> and experiment is that we only add a warning/banner in edit mode on pages
> belonging to an extension, informing the user that their changes *will be
> discarded when upgrading* and what he could do instead, to keep them.
>
> So, when upgrading to a new version, we would have the following
> directions to decide on:
>
> 1) We could show the list of modified extensions with options for each
> extensions (not each document) to:
> a) discard changes
> b) backup changes
> c) merge changes (I would personally not be in favor of keeping this,
> since it will be too tempting for everyone to abuse it and we would be back
> at the current state when upgrades take a very long time and are hard to do)
>
> 2) We could simply discard any modifications done on the extensions and
> upgrade to the newest version (i.e. never do the 3-way merge)
>
>
> The main idea is that you are free to do changes and experiment, but if
> you want your work to be used in production or to survive an upgrade, you
> need to do one of the following things:
>
> A) Contribute your changes so that they are included in the next version
> of the application.
>
> B) Publish your changes as a fork of the application. Optionally, it could
> be a light fork which only contains the modified pages and has a fixed
> version dependency on the standard application. It will be your job to keep
> your fork up to date, otherwise you will be stuck using an older version of
> the application. If the application is part of the Standard Flavor and
> because of the fixed dependency version, it will mean you will not be able
> to upgrade XWiki either until you update your fork first. If you don't use
> a fixed version dependency, you risk upgrading the standard application to
> a version that is no longer compatible with your changes.
>
> Thanks,
> Eduard
>
> On Tue, Nov 7, 2017 at 4:16 PM, Thomas Mortagne <thomas.morta...@xwiki.com
> > wrote:
>
>> On Tue, Nov 7, 2017 at 1:02 PM, Ecaterina Moraru (Valica)
>> <vali...@gmail.com> wrote:
>> > On Tue, Nov 7, 2017 at 1:00 PM, Thomas Mortagne <
>> thomas.morta...@xwiki.com>
>> > wrote:
>> >
>> >> Hi devs,
>> >>
>> >> We started to think about https://jira.xwiki.org/browse/XWIKI-14377
>> >> with Caty and she noticed that it might not be as simple as "all
>> >> extensions pages are protected" because there is extensions pages that
>> >> are almost always supposed to be modified: first example is
>> >> Main.WebHome which is modified 99% of the time but another good one is
>> >> Sandbox or Quicklinks panel.
>> >>
>> >> So what do we do about it ?
>> >>
>> >> I'm not fully sure yet but here are some ideas :
>> >>
>> >> 1) So what ? It's still extension pages and you might still have
>> >> conflicts during next upgrade. If you want standard pages to be
>> >> modified then generate them during install.
>> >>
>> >> 2) Only show the warning when a page is hidden and consider all non
>> >> hidden pages as OK to modify
>> >>
>> >> 3) Explicitly mark each standard page that is OK to be modified with
>> >> some xobject
>> >> 3.a) EM XAR handler behave with these pages as it always did
>> >> 3.b) EM XAR handler has a special support for these pages controlled
>> >> by one of the xobject fields (skip the do

Re: [xwiki-devs] Extension documents edit protection and Main.WebHome

[Eduard Moraru]

Hi,

One option I was discussion with Caty that would cover the need to not have
code pages modified, while also allowing devs (including us) to work and
experiment is that we only add a warning/banner in edit mode on pages
belonging to an extension, informing the user that their changes *will be
discarded when upgrading* and what he could do instead, to keep them.

So, when upgrading to a new version, we would have the following directions
to decide on:

1) We could show the list of modified extensions with options for each
extensions (not each document) to:
a) discard changes
b) backup changes
c) merge changes (I would personally not be in favor of keeping this, since
it will be too tempting for everyone to abuse it and we would be back at
the current state when upgrades take a very long time and are hard to do)

2) We could simply discard any modifications done on the extensions and
upgrade to the newest version (i.e. never do the 3-way merge)


The main idea is that you are free to do changes and experiment, but if you
want your work to be used in production or to survive an upgrade, you need
to do one of the following things:

A) Contribute your changes so that they are included in the next version of
the application.

B) Publish your changes as a fork of the application. Optionally, it could
be a light fork which only contains the modified pages and has a fixed
version dependency on the standard application. It will be your job to keep
your fork up to date, otherwise you will be stuck using an older version of
the application. If the application is part of the Standard Flavor and
because of the fixed dependency version, it will mean you will not be able
to upgrade XWiki either until you update your fork first. If you don't use
a fixed version dependency, you risk upgrading the standard application to
a version that is no longer compatible with your changes.

Thanks,
Eduard

On Tue, Nov 7, 2017 at 4:16 PM, Thomas Mortagne 
wrote:

> On Tue, Nov 7, 2017 at 1:02 PM, Ecaterina Moraru (Valica)
>  wrote:
> > On Tue, Nov 7, 2017 at 1:00 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > wrote:
> >
> >> Hi devs,
> >>
> >> We started to think about https://jira.xwiki.org/browse/XWIKI-14377
> >> with Caty and she noticed that it might not be as simple as "all
> >> extensions pages are protected" because there is extensions pages that
> >> are almost always supposed to be modified: first example is
> >> Main.WebHome which is modified 99% of the time but another good one is
> >> Sandbox or Quicklinks panel.
> >>
> >> So what do we do about it ?
> >>
> >> I'm not fully sure yet but here are some ideas :
> >>
> >> 1) So what ? It's still extension pages and you might still have
> >> conflicts during next upgrade. If you want standard pages to be
> >> modified then generate them during install.
> >>
> >> 2) Only show the warning when a page is hidden and consider all non
> >> hidden pages as OK to modify
> >>
> >> 3) Explicitly mark each standard page that is OK to be modified with
> >> some xobject
> >> 3.a) EM XAR handler behave with these pages as it always did
> >> 3.b) EM XAR handler has a special support for these pages controlled
> >> by one of the xobject fields (skip the document from any merge if
> >> there is any customization, always overwrite any customization, etc.)
> >>
> >> WDYT ?
> >>
> >> 1) might be too harsh, generating Main.WebHome might be doable (but
> >> still a pain to maintain) but it's quite a pain to generate the whole
> >> Sandbox space (and not even talking about maintaining it...)
> >>
> >
> > Don't forget that some of these pages are localized.
>
> And there is that too which makes this option even more difficult to apply.
>
> >
> >
> >>
> >> 2) we might still want to see some application home pages in the
> >> search result and most of them should really not be modified
> >>
> >> 3.a) will still have the "what should I do" effect sometime for pages
> >> that user is allowed to modify
> >>
> >> 3.b) has my preference right now, sounds like the nicest from user and
> >> author point of view, can even be used for other use cases than edit
> >> protection control
> >>
> >
> > Not sure how hard would be technically, but instead of an exception
> list, I
> > would like an inclusion list.
>
> Since 90% of the pages coming from extensions ares stuff nobody should
> touch I really don't think this is a good idea.
>
> > We talked so much in the past about Application Descriptor and we also
> have
> > some patterns put in place, like placing the code inside a Code space and
> > mark the technical pages hidden.
> >
> > I believe all the content pages of an application should be editable by
> > user and should be ignored during an upgrade, but all the technical /
> code
> > pages should not be encouraged to edit and they will need to be upgraded
> on
> > new releases.
> >
> > Instead of marking what pages should be ignored, we should mark what
> 

Re: [xwiki-devs] [Proposal][UX] Notifications Improvements 9.8+

[Eduard Moraru]

Hi,

I was wondering if we could identify the center point of an notification by
considering the action that the current user (receiving the notification)
did to subscribe to that event, i.e. what actually interests the current
user.

1) Now, if we consider the Watchlist approach where a user goes to a
page/wiki and clicks "watch"/"subscribe", then we could see the point of
interest as the content... since the user wants to be notified when changes
are made to that content... by whoever.
... in this case, it makes sense to see the events of, say the recent 24
hours, grouped by pages and only in their details to see which users and
what even types they performed.

2) If we consider going to the user profile and clicking "follow", then the
current user is interested in the getting notifications of the changes done
by that particular user, no matter the page.
... in this case, I would imagine the user expecting to see events in the
last 24 hours grouped by users "i.e. user X worked on 5 pages" and, when
expanding, to see which pages and what type of events...

3) Finally, there are applications, where events could be sent by either
users of the application (e.g. Blog, AWM, etc.) or by the application
itself (e.g. Meeting Manager/Calendar sending a reminder to the
participants, 30 minutes before, about an upcoming meeting/event).
... in this case, the user subscribes to the application (or is
automatically subscribed and can unsubscribe).

Not sure if this helps to the discussion, just thought I'd share.

Thanks,
Eduard

On Thu, Oct 5, 2017 at 4:58 PM, Ecaterina Moraru (Valica)  wrote:

> On Wed, Oct 4, 2017 at 4:04 PM, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
>
> > 2017-10-03 17:34 GMT+02:00 Ecaterina Moraru (Valica)  >:
> >
> > > On Tue, Oct 3, 2017 at 11:27 AM, Thomas Mortagne <
> > > thomas.morta...@xwiki.com>
> > > wrote:
> > >
> > > > On Tue, Oct 3, 2017 at 9:54 AM, Guillaume Delhumeau
> > > >  wrote:
> > > > > So your proposal focuses a lot more on the users instead of the
> apps
> > > > (like
> > > > > facebook for example). It's OK for me, but I think the type icon
> > > (create,
> > > > > edit, comment, etc...) is too small compared to the user face.
> > > > >
> > > > > Actually when I see these screenshot, my first impression is that
> the
> > > > user
> > > > > has been modified :) Would it be nice to have the type icon bigger
> > than
> > > > the
> > > > > user face? To me, what happened is more important than who made it,
> > but
> > > > > maybe it's only my feeling.
> > > >
> > > > Pretty much the same comments on my side. I find weird to focus that
> > > > much on users, I would have preferred images corresponding on the
> > > > change made.
> > > >
> > >
> > > Depends on what we want to focus on and also on what are user's
> > > expectations.
> > > If you look at the majority of notifcations in the wild, the user is
> the
> > > focus.
> > > People want to know who did what, on what page, when.
> > >
> >
> > But Facebook, for example, is a social network. It focuses on people by
> > nature. On XWiki, it is not that evident. In the case of a knowledge
> base,
> > you focus more on the content (the knowledge) than on the people. On
> > xwiki.org, I guess you prefer seeing what's change instead of who made
> > some
> > changes...
> >
> >
> I know the pages are important, that's why the first link and item
> displayed is the page name.
> I want to know if a spam user did something.
>
> Thanks,
> Caty
>
>
> > If we define XWiki as a collaboration tool, then you collaborate to
> create
> > something and so the focus is naturally more on that "something".
> >
> > Just my 2 cents :)
> >
> >
> >
> > >
> > >
> > > >
> > > > >
> > > > > Nice work anyway, as usual :)
> > > > >
> > > > > Guillaume
> > > > >
> > > > > 2017-10-03 9:50 GMT+02:00 Guillaume Delhumeau <
> > > > guillaume.delhum...@xwiki.com
> > > > >>:
> > > > >
> > > > >>
> > > > >>
> > > > >> 2017-10-02 18:09 GMT+02:00 Vincent Massol :
> > > > >>
> > > > >>>
> > > > >>> > On 2 Oct 2017, at 18:08, Vincent Massol 
> > > wrote:
> > > > >>> >
> > > > >>> >
> > > > >>> >> On 2 Oct 2017, at 18:05, Vincent Massol 
> > > wrote:
> > > > >>> >>
> > > > >>> >> Another feedback/questions:
> > > > >>> >>
> > > > >>> >> * Is the avatar icon clickable and leading to the user
> profile?
> > > > >>> >> * We need a way to link directly to the diff, at least for
> page
> > > > events
> > > > >>> so that the user can see what was modified (as we have currently
> in
> > > > the AS)
> > > > >>> >
> > > > >>> > * Maybe “2 hours ago” is not precise enough. In your example I
> > see
> > > I
> > > > >>> created and modified the Roadmap page but they both say “2 hours
> > > ago”.
> > > > >>> Shouldn’t I be able to see how far away both events were done?
> > > > >>>
> > > > >>> My understanding is that events are grouped 

Re: [xwiki-devs] [VOTE] Release xwiki-commons and xwiki-rendering directly on Maven Central

[Eduard Moraru]

+1, sounds good to me.

Also, if we could setup Nexus to clone just the org.xwiki artifacts from
maven central, that might be a good compromise, but I could live without it
also.

Thanks,
Eduard

On Mon, Oct 2, 2017 at 11:21 AM, Thomas Mortagne 
wrote:

> On Mon, Oct 2, 2017 at 10:17 AM, Vincent Massol 
> wrote:
> > Hi Thomas,
> >
> >> On 2 Oct 2017, at 10:14, Thomas Mortagne 
> wrote:
> >>
> >> Hi devs,
> >>
> >> To remove a big step from the release I would like to modify a bit our
> >> setup and deploy released xwiki-commons and xwiki-rendering artifacts
> >> on Maven Central instead of nexus.xwiki.org/maven.xwiki.org.
> >>
> >> PRO:
> >> * speed up releases
> >> * less stuff to store on our side
> >> * only one artifact for a specific version (right now they are built
> >> twice which produce two different JARs in pratice)
> >>
> >> CONS:
> >> * depends more on Maven Central
> >>
> >> In practice we already depend on Maven Central for many things so if
> >> Maven Central ever end up dead the fact that we don't have the
> >> artifact on our side is going to be the least of our issues :)
> >>
> >> So WDYT ?
> >>
> >> +1 on my side
> >
> > +1 to automate the release on Maven Central for commons/rendering.
> >
> > -0 (close to -1) to not releasing/copying commons/rendering artifacts on
> maven.xwiki.org. I think it’s important that we can have the full list of
> XWiki artifacts in a single place and I’d like that to be our place. If we
> were publishing all our artifacts on Maven Central, I wouldn’t have this
> problem but it’s not the case.
>
> You do have all our artifacts in one place (at least from browser
> point of view) trough nexus.xwiki.org.
>
> >
> > Thanks
> > -Vincent
> >
> >>
> >> --
> >> Thomas Mortagne
> >
>
>
>
> --
> Thomas Mortagne
>

[xwiki-devs] [ANN] XWiki 9.8 released

[Eduard Moraru]

The XWiki development team is proud to announce the availability of XWiki
9.8.

This release introduces a new feature for the Notifications: Watched
Entities. It is an experimental feature that will soon replace the
Watchlist Application. To try it out and get familiar with it, you need to
enable it, since it is currently disabled by default.

For users, we now have more usable notification filter settings, a nice
helper when you edit a "Database List" field and a feature that was missing
from the CKEditor integration, which is office import.

For developers, it is easier to propose an extension containing REST
resources, or to customize the Flamingo LESS code. We have also exposed
more database columns in the Query Module for users who don't have
programming rights. The notification filters AST (Abstract Syntax Tree)
proposes new types of nodes to create complex filter queries. There are
also new facilities to avoid using SyntaxFactory, to make Extension Manager
faster, or to have more control over some skin elements (CSS IDs and layout
variables).

You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.8

Thanks for your support
-The XWiki dev team

Re: [xwiki-devs] [Proposal] Deprecate platform.xwiki.org and enterprise.xwiki.org

[Eduard Moraru]

+1 for hiding just the comments.

Users should be encouraged to edit the pages instead of leaving comments.

So I would suggest to hide the comments tab (because we need the other
ones, like attachments) right away and then, as time allows, progressively
go through the existing comments, removing them and including/integrating
relevant documentation as much as possible in their associated document.

Even if I would prefer to integrate as much as possible, I am personally ok
even with dropping the comments entirely if we can't do the integration.

Thanks,
Eduard

On Fri, Sep 1, 2017 at 5:57 PM, Vincent Massol  wrote:

>
> > On 1 Sep 2017, at 16:38, Ecaterina Moraru (Valica) 
> wrote:
> >
> > What about hiding the #docextra ?
> >
> > There are some very old comments (from 2006, 2011, etc.) that are
> > deprecated and make the website look abandoned. We have now the forum for
> > this types of questions.
> > So I would like to hide the comments as a very minimum change, or even
> the
> > whole docextra. WDYT?
>
> If we hide them then we’re also loosing all the information in them (ie
> users who added warnings, extra doc, etc). Are we prepared to loose that?
>
> Thanks
> -Vincent
>
> >
> > Thanks,
> > Caty
> >
> > On Wed, Aug 30, 2017 at 12:36 PM, Marius Dumitru Florea <
> > mariusdumitru.flo...@xwiki.com> wrote:
> >
> >> +1
> >>
> >> Thanks,
> >> Marius
> >>
> >> On Tue, Aug 29, 2017 at 9:49 PM, Vincent Massol 
> >> wrote:
> >>
> >>> Hi devs,
> >>>
> >>> Caty and I would like to work on improving xwiki.org and the first big
> >>> items that we’d like to do is:
> >>>
> >>> * Move all content from platform.xwiki.org & enterprise.xwiki.org to
> >>> xwiki.org (i.e. the main wiki)
> >>> * When moving pages, use redirects
> >>> * Deprecate platform.xwiki.org & enterprise.xwiki.org by adding a
> banner
> >>> (After Header UIX)
> >>> * Move all pages to 3 locations on the main wiki:
> >> Documentation.UserGuide,
> >>> Documentation.DevGuide and Document.AdminGuide
> >>> * We also replace “XWiki Enterprise” with “XWiki” and be as generic as
> >>> possible
> >>>
> >>> WDYT?
> >>>
> >>> Thanks
> >>> -Vincent
> >>
>
>

Re: [xwiki-devs] [Proposal] Deprecate platform.xwiki.org and enterprise.xwiki.org

[Eduard Moraru]

+1

Thanks,
Eduard

On Wed, Aug 30, 2017 at 11:07 AM, Alexandru Cotiuga <
alexandru.coti...@xwiki.com> wrote:

> +1
>
> Thanks,
> Alex
>
> On Wed, Aug 30, 2017 at 11:02 AM, Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
>
> > +1, excellent initiative
> >
> > 2017-08-30 1:25 GMT+02:00 Sergiu Dumitriu :
> >
> > > +1.
> > >
> > > On 08/29/2017 02:49 PM, Vincent Massol wrote:
> > > > Hi devs,
> > > >
> > > > Caty and I would like to work on improving xwiki.org and the first
> big
> > > items that we’d like to do is:
> > > >
> > > > * Move all content from platform.xwiki.org & enterprise.xwiki.org to
> > > xwiki.org (i.e. the main wiki)
> > > > * When moving pages, use redirects
> > > > * Deprecate platform.xwiki.org & enterprise.xwiki.org by adding a
> > > banner (After Header UIX)
> > > > * Move all pages to 3 locations on the main wiki:
> > > Documentation.UserGuide, Documentation.DevGuide and Document.AdminGuide
> > > > * We also replace “XWiki Enterprise” with “XWiki” and be as generic
> as
> > > possible
> > > >
> > > > WDYT?
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > >
> > >
> > > --
> > > Sergiu Dumitriu
> > > http://purl.org/net/sergiu/
> > >
> >
> >
> >
> > --
> > Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
> >
>

Re: [xwiki-devs] [Proposal] Notifications : Add "in-context" switches

[Eduard Moraru]

+1 to stay within the notifications UIX area for notifications related
tasks and not add new elements to the immediately visible UI. This also
helps in not spreading a feature in multiple places and makes it easier for
the user to find it.

Thanks,
Eduard

On Tue, Aug 8, 2017 at 11:59 AM, Vincent Massol  wrote:

>
> > On 8 Aug 2017, at 10:54, Clément Aubin  wrote:
> >
> > On 08/08/2017 10:09 AM, Vincent Massol wrote:
> >> Hi Clement,
> >>
> >>> On 8 Aug 2017, at 10:03, Clément Aubin 
> wrote:
> >>>
> >>> Hi devs !
> >>>
> >>> So, about a month ago, Guillaume Delhumeau started this thread in order
> >>> to determine how we could implement the "in-context" switches of the
> >>> notification center. For those who don’t want to read the original
> mail,
> >>> it’s about moving the current watchlist mechanism inside of the
> >>> notification center (and by "moving", I mean "rewriting it in a more
> >>> scalable and performant way").
> >>>
> >>> We talked a lot about how those switches should act if a user is
> >>> subscribed to the page he’s on, or if he is subscribed to a parent
> page.
> >>> Today, with Guillaume, we managed to implement exclusive notification
> >>> filters that allows us to reproduce the comportment of the current
> >>> watchlist ; so this subject is somehow resolved.
> >>>
> >>> But, we didn’t talked about how the "in-context" switches should look
> >>> like in practice. Here is what we proposed at the time :
> >>>
>   - In each page, add a button to subscribe to the current location:
>   https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
> >>>
> >>> With this solution, this would mean removing the current watchlist
> >>> indicators present in the notification tray
> >>> (https://pasteboard.co/GEFyXkR.png).
> >>>
> >>> What do you think ? Should we keep using those switches or moving them
> >>> in the breadcrumb ?
> >>>
> >>> Here is my point of view :
> >>>
> >>> The alert bell in the breadcrumb looks more modern that the toggles
> that
> >>> we currently have for the watchlist but we have to add a new UIX for
> the
> >>> breadcrumb if we want to do that.
> >>>
> >>> Therefore, if we keep the same kind of switches in the notification
> >>> tray, maybe we could profit from this occasion to make them more
> modern.
> >>
> >> Thanks for asking. Here’s my POV:
> >>
> >> * I would really like that we don’t add an additional visual cue to the
> UI. We’re already too crowded and we’re trying to reduce the clutter and
> make it as lean as possible.
> >
> > I do agree that the UI is a bit crowded, but the idea would be to move
> > the switches of the watchlist in one single bell, so in the end, we gain
> > one icon and we loose 3 switches.
>
> The idea is not to remove features; it doesn’t matter if we have more
> features provided the UI you see at all instant is not more complex.
>
> Gaining one icon that’s 100% visible all the time is a big UI clutter and
> it’s definitely not the same as 3 switches behind a menu/button.
>
> If you prefer the bell UI, I’m fine with having something similar in the
> Alert zone too but I think it’s less explicit and more magical and that
> you’d be reducing the usability a bit by doing so.
>
> >
> >> * In addition having 2 bells makes it even more complex to understand
> what is doing what for a new user.
> >
> > I don’t get what you mean, the idea was to have one bell that changes
> > regarding the context (the idea came from what YouTube does, see
> > https://pasteboard.co/GEFTyTe.png and https://pasteboard.co/GEFTOzJ.png
> ).
>
> How do you name the icon in the top bar that represents the Alert zone?
> (what does it represent?) :)
>
> >
> >> * I don’t think that users need to know at every moment if the current
> page is being watched or not. I feel it’s perfectly acceptable if this info
> is hidden under one click as it is now in the Alert zone in the top nav bar.
> >
> > I agree.
> >
> >> * The on/off bell idea only allows 2 states but doesn’t allow choices
> such as: watching only this page, watching page + children or watching the
> current wiki.
> >
> > We could display the watch parameters when the user is hovering the bell.
>
> Less explicit. A bit magical but possible. You’d need 3 different icons
> representing the 3 states though.
>
> Thanks
> -Vincent
>
> >
> >>
> >> So I’d really like that we find a solution that doesn’t involve adding
> a new UI element.
> >>
> >> For me the current solution with the 3 switches in the Alert zone is
> good and has the big advantage of not introducing a new UI element.
> >>
> >> Thanks
> >> -Vincent
> >>
> >>> Thanks,
> >>>
> >>> On 07/11/2017 06:26 PM, Guillaume Delhumeau wrote:
>  *TL;DR*
> 
>   - Add a button in each page that will allow you to subscribe to all
>   events that happens to that page.
>   - When you subscribe to a page with this "in-context" bell, it must
> not
>   affect your other 

Re: [xwiki-devs] [VOTE] Bundle the blame-api as core extension

[Eduard Moraru]

8 +1, 0 +0, 0 -1.

Vote passed, PR merged.

Thanks,
Eduard

On Thu, Aug 3, 2017 at 6:09 PM, Thomas Mortagne <thomas.morta...@xwiki.com>
wrote:

> +1
>
> Le 1 août 2017 14:57, "Eduard Moraru" <enygma2...@gmail.com> a écrit :
>
> > Hi, devs,
> >
> > During a hackathon session, I have done a refresh on XWiki's code viewer
> > ("code.vm") and integrated the Blame API [1] developed by Denis to add
> > line-by-line blame information, just like GitHub's blame feature.
> >
> > Please see the associated Jira issue that also includes before and after
> > screenshots:
> > https://jira.xwiki.org/browse/XWIKI-14578
> >
> > The Blame API module is a commons module since 2014 but not bundled
> neither
> > in the WAR nor in the flavor, so, in order to go along and merge my work,
> > I'd need it to be available as a core extension (to be also usable by
> > code.vm).
> >
> > I have not studied it deeply, but the module seems to be doing its job
> well
> > and the result is very nice and it is very generic.
> >
> > Being able to perform a blame analysis builds upon the diff module and
> both
> > are features of XWiki's versioning capabilities, so, IMO, both should be
> > considered core extensions (and not only the diff module, which already
> is
> > core).
> >
> > The PR is available at https://github.com/xwiki/xwiki-platform/pull/605
> >
> > Here is my (obvious) +1 to bundle the blame-api and merge the PR which
> > includes the UI.
> >
> > Thanks,
> > Eduard
> >
> > --
> > [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Blame%20Module
> >
>

Re: [xwiki-devs] [VOTE] Bundle the blame-api as core extension

[Eduard Moraru]

Hi, Vincent,

I believe most of your questions are answered in the jira issue I've
mentioned, specifically in the attached comment that includes screenshots:
https://jira.xwiki.org/browse/XWIKI-14578?focusedCommentId=95833=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-95833

The default is the new code viewer. You have to click a button to get the
blame view, so that's not by default.

In terms of performance, yes, there is an obvious penalty, but only when
loading the blame view. The blame view navigates through all the revisions
of a document, incrementally building the annotated data (line-by-line). We
can limit how far back in the revisions it should drill down to (as it is
done in the blame API example, to the last 10 revisions), but that would
produce suboptimal results IMO and, since it's an explicit user-requested
action, I believe it's worth the penalty.

In terms of numbers, I've used 2 older pages to test it out using the
?debug=true parameter and looking at the time (ms) spent on code.vm on the
server side.

http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI
* 1255 lines
* 132 versions
* No caching, just after wiki restart, browser cache refresh: 3912
* Just browser cache refresh: 2884, 2586, 2756, 2466
* Caches enabled, simple browser refresh: 2183, 2065, 2057, 2112, 2209, 2082

http://platform.xwiki.org/xwiki/bin/view/Features/PageEditing
* 212 lines
* 332 versions
* No caching, just after wiki restart, browser cache refresh: 2158
* Just browser cache refresh: 1542, 1419 ,1322, 1131, 1445
* Caches enabled, simple browser refresh: 1048, 1165, 1025, 1100

The versions number includes minor versions.

These documents are either large or have many revisions, so the numbers
should be good enough to make an approximation on real-world waiting times
to compute the blame. AFAICT, the number of lines has a bigger hit on
performance than the revisions have.

Thanks,
Eduard

On Wed, Aug 2, 2017 at 1:28 PM, Vincent Massol <vinc...@massol.net> wrote:

> Hi Edy,
>
> Actually I have some additional questions:
>
> * How well does it perform? Imagine that there’s a 300 lines document and
> 300 revisions, each one changing one line from the document. How long does
> it take to display the blame view?
> * AFAIK our JRCS API is not very performant and thus I’m worried about
> performance.
> * I can imagine 2 things to help with this:
> ** 1) Do not display the blame view by default when going to the source
> view (let the user click a “show blame view” button)
> ** 2) Use a progress bar to compute the blame UI. I hope that the Java API
> has provision for this.
>
> WDYT? Could you share with us some stats on performance?
>
> Thanks
> -Vincent
>
> > On 1 Aug 2017, at 14:57, Eduard Moraru <enygma2...@gmail.com> wrote:
> >
> > Hi, devs,
> >
> > During a hackathon session, I have done a refresh on XWiki's code viewer
> > ("code.vm") and integrated the Blame API [1] developed by Denis to add
> > line-by-line blame information, just like GitHub's blame feature.
> >
> > Please see the associated Jira issue that also includes before and after
> > screenshots:
> > https://jira.xwiki.org/browse/XWIKI-14578
> >
> > The Blame API module is a commons module since 2014 but not bundled
> neither
> > in the WAR nor in the flavor, so, in order to go along and merge my work,
> > I'd need it to be available as a core extension (to be also usable by
> > code.vm).
> >
> > I have not studied it deeply, but the module seems to be doing its job
> well
> > and the result is very nice and it is very generic.
> >
> > Being able to perform a blame analysis builds upon the diff module and
> both
> > are features of XWiki's versioning capabilities, so, IMO, both should be
> > considered core extensions (and not only the diff module, which already
> is
> > core).
> >
> > The PR is available at https://github.com/xwiki/xwiki-platform/pull/605
> >
> > Here is my (obvious) +1 to bundle the blame-api and merge the PR which
> > includes the UI.
> >
> > Thanks,
> > Eduard
> >
> > --
> > [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Blame%20Module
>
>

Re: [xwiki-devs] [VOTE] Bundle the blame-api as core extension

[Eduard Moraru]

Hi, Vincent,

It's nothing fancy right now, as you can see from the PR:
https://github.com/xwiki/xwiki-platform/pull/605/files#diff-68b60a2e4f248894705d2d063e2b0c9e

Basically there's code.vm that gets the document content and handles a
request variable. It either uses the Blame API to produce the annotated
line content and build the blame-enabled UI OR it just splits the content
by lines and builds the simple UI.

I guess it could be done with an UIXP and then code.vm could provide only
the simple UI when no UIX is detected or when explicitly asked by the user.
If the UIX is detected, then code.vm could show the toggle button and
render the UIX instead of the simple UI, when the user asks for it. Then it
would be a matter of adding an xwiki-platform-blame-ui module to the
standard flavor that implements the UIX and brings in the dependency on the
commons-blame-api module, so it wouldn`t have to be a core extension. The
CSS would also have to be broken in 2, with some of it going to this
blame-ui module.

This also results in the conclusion that the blame feature is optional and
that it would not be available in an empty wiki, where only the simple view
source UI would be available.

This refactoring would require about another half a day of work. Will need
to see when I could do it.

Would you consider the effort worth it? The UIXP itself is not really
valuable, the only advantage is in not having to add another core extension.

WDYT?

Thanks,
Eduard

On Tue, Aug 1, 2017 at 5:01 PM, Vincent Massol <vinc...@massol.net> wrote:

> Hi Edy,
>
> +1 in general. Ideally, even though we should bundle it by default in our
> base flavor, it would be nice if it could be optional (i.e. if the blame
> API/UI modules are present in the WAR then clicking “view source” would
> display the blame view and if not, it would default to basic source
> viewing). Is that how you coded it? I’m saying “ideally” since it’s
> probably more work to do this (might even possibly require a UIX - or the
> whole source VM should be a UIX, I don’t know - BTW that might be cool to
> have automatic UIX based on template names to unify skins and UIX but
> that’s another topic ;)) and at this stage I’m already very happy that
> we’re getting this feature and you may not want to spend more time on it
> right now! :)
>
> Nice work!
>
> Thanks
> -Vincent
>
> > On 1 Aug 2017, at 14:57, Eduard Moraru <enygma2...@gmail.com> wrote:
> >
> > Hi, devs,
> >
> > During a hackathon session, I have done a refresh on XWiki's code viewer
> > ("code.vm") and integrated the Blame API [1] developed by Denis to add
> > line-by-line blame information, just like GitHub's blame feature.
> >
> > Please see the associated Jira issue that also includes before and after
> > screenshots:
> > https://jira.xwiki.org/browse/XWIKI-14578
> >
> > The Blame API module is a commons module since 2014 but not bundled
> neither
> > in the WAR nor in the flavor, so, in order to go along and merge my work,
> > I'd need it to be available as a core extension (to be also usable by
> > code.vm).
> >
> > I have not studied it deeply, but the module seems to be doing its job
> well
> > and the result is very nice and it is very generic.
> >
> > Being able to perform a blame analysis builds upon the diff module and
> both
> > are features of XWiki's versioning capabilities, so, IMO, both should be
> > considered core extensions (and not only the diff module, which already
> is
> > core).
> >
> > The PR is available at https://github.com/xwiki/xwiki-platform/pull/605
> >
> > Here is my (obvious) +1 to bundle the blame-api and merge the PR which
> > includes the UI.
> >
> > Thanks,
> > Eduard
> >
> > --
> > [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Blame%20Module
>
>

[xwiki-devs] [VOTE] Bundle the blame-api as core extension

[Eduard Moraru]

Hi, devs,

During a hackathon session, I have done a refresh on XWiki's code viewer
("code.vm") and integrated the Blame API [1] developed by Denis to add
line-by-line blame information, just like GitHub's blame feature.

Please see the associated Jira issue that also includes before and after
screenshots:
https://jira.xwiki.org/browse/XWIKI-14578

The Blame API module is a commons module since 2014 but not bundled neither
in the WAR nor in the flavor, so, in order to go along and merge my work,
I'd need it to be available as a core extension (to be also usable by
code.vm).

I have not studied it deeply, but the module seems to be doing its job well
and the result is very nice and it is very generic.

Being able to perform a blame analysis builds upon the diff module and both
are features of XWiki's versioning capabilities, so, IMO, both should be
considered core extensions (and not only the diff module, which already is
core).

The PR is available at https://github.com/xwiki/xwiki-platform/pull/605

Here is my (obvious) +1 to bundle the blame-api and merge the PR which
includes the UI.

Thanks,
Eduard

--
[1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Blame%20Module

Re: [xwiki-devs] [GSoC] Extension Repository Connector - Pypi released!

[Eduard Moraru]

Sounds pretty cool! I`m sure Python fans will be grateful for this!

Thanks,
Eduard

On Thu, Jul 27, 2017 at 11:17 PM, Krzysiek Płachno <
krzysiekplac...@gmail.com> wrote:

> Hey!
>
> I'm happy to announce that Extension Repository Connector - Pypi is
> released -
> http://extensions.xwiki.org/xwiki/bin/view/Extension/
> Extension%20Repository%20Connector%20-%20Pypi/
>
> XWiki has possibility to scirpt on its pages in Python. Under the hood it's
> Java Scripting API and Jython that takes care of running this script and
> returning result to page. Jython has implementation only for standard
> libraries. That's why Extension Repository Connector - Pypi is created - to
> be able to import to XWiki other (non-standard) python packages that are
> hosted on pypi: https://pypi.python.org/pypi.
>
> I'd be grateful for any feedback :)
>
> Best,
> Krzysztof
>

Re: [xwiki-devs] [ANN] Two new committers: Alex and Clement

[Eduard Moraru]

Congrats to the both of you!

-Eduard

On Wed, Jul 26, 2017 at 11:17 PM, Vincent Massol  wrote:

> Hi all,
>
> I’m pleased to announce that the XWiki Core Committers have voted 2 new
> committers:
> * Alex Cotiuga
> * Clement Aubin
>
> Congrats guys! You’ll now have the pleasure of being able to commit
> without waiting for someone else to apply it. Note that when you’re not
> sure and want to request a review, you can still do PRs if you want. It’s
> now your choice :)
>
> I’ve sent you invitations for the XWiki Github org.
>
> I’ve also added you to the committers group on xwiki.org.
>
> Make sure to read http://dev.xwiki.org/xwiki/bin/view/Community/
> Committership :)
>
> Last but not least, I’ve added you to the Release Manager roster:
> http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/#HNextReleaseManagers
> (let me know if you really don’t want to be a RM and I’ll remove you!).
>
> Thank you very much for your interest in making XWiki progress and be
> better every day.
>
> Thanks
> -Vincent
>
>

Re: [xwiki-devs] [Proposal] Bundle Syntax Highlighting Extension in the Standard flavor

[Eduard Moraru]

Big +1.

There might be some nooks and cracks, but we can sort them out with all the
visibility and testing it would get by being in the Standard Flavor.

Thanks,
Eduard

On Fri, Jul 14, 2017 at 3:28 PM, Vincent Massol  wrote:

> Hi devs,
>
> I’d like to propose that we bundle the Syntax Highlighting Extension in
> the Standard flavor, starting with XWiki 9.7RC1.
>
> Rationale:
> * No impact for simple users (ie the default)
> * For advanced users, it makes editing pages using the wiki editor much
> nicer
> * It’s already a recommended extension on e.x.o and I’m willing to
> continue supporting it (and I’m sure Edy is interested in doing that too -
> Right Edy?)
>
> See http://extensions.xwiki.org/xwiki/bin/view/Extension/Syntax%
> 20Highlighting%20Application for more details.
>
> TBH I don’t really understand why we haven’t bundled this a long time ago.
>
> Does anyone see any issue in bundling it?
>
> Thanks
> -Vincent

Re: [xwiki-devs] [PROPOSAL] So which Standard flavor dependencies should be optional

[Eduard Moraru]

On Fri, Jul 7, 2017 at 1:16 PM, Thomas Mortagne <thomas.morta...@xwiki.com>
wrote:

> I really don't understand how you end up with this reasoning.
>
> The only one that knows if a dependency is optional is the developer
> of the extension so what is a workaround here is the huge mess
> generator you are proposing.
>
> As I already said 99% of our dependencies are really not optional, in
> practice only a few flavor dependencies are and one or two other use
> cases.
>
> There is two different subjects that get mixed up here:
> * clearly state in an extension what is absolutely required to work
> and what is a nice to have, this is standard stuff and this is what we
> are talking about here
> * hack your way in the extension index to remove an extension without
> removing the extension claiming to require that, this is at best
> something for http://extensions.xwiki.org/xwiki/bin/view/Extension/
> Extension+Tweak


Are you saying that you have never had to fix a dependency problem in your
Linux distribution caused by some bad commit of a developer or by a
desynchronization of the repository you installed or just updated stuff
from? How you you feel if you were unable to uninstall a dependency from
your system that you know for sure you are not using or, even worse, if you
know it has a sever bug that can fry your system, even if some important
other modules/extensions function very well in practice without it? It
makes no sense to deny this power to an admin by design, except if you have
some technical limitations/problems in implementing it.

The same reasoning applies for the linux "sudo" command. The more control
we give people, the more they will love XWiki, not the other way around.
Sure, they can end up creating a mess, but it's their mess and we should,
at best, warn them about the danger, but that's it. It's basically simple
and advanced mode, but for EM.

Also, extensions can be anything, not only java code. Sometimes it can even
be about a XAR extension or even a webjar (js) that you can really live
without, might want a different (even older) version (because you know it
does not have a certain bug, or some other reason).

More generically, EM now supports adding, removing and upgrading extensions
with dependencies. It should, at some point, be able to perform the same
operations ignoring dependencies (i.e. affecting a single extension) with
the appropriate warnings.

Maybe that helps a bit to explain my reasoning.

Side note/Wishful thinking: Probably as an extension or as part of the
Extension Tweak app, it would be awesome to have a (navigable?) dependency
graph of the installed extensions. Maybe we should have that as a GSoC
project :)

Thanks,
Eduard

>
>
> On Fri, Jul 7, 2017 at 12:01 PM, Eduard Moraru <enygma2...@gmail.com>
> wrote:
> > Hi,
> >
> > It`s very nice to hear we are progressing on this topic, but I`m not very
> > fond of the current solution. Marking dependencies as optional still puts
> > the responsibility on the developer to actually do that and makes the
> admin
> > dependent on the developer's choice and discipline. Feels more like a
> > workaround that we will end up having to support.
> >
> > Working for building whitelists is a tedious process and we will surely
> > miss things, and this is only about things that we control in the
> standard
> > flavor. What about extensions and their dependencies?
> >
> > Sure, as Caty suggests, one option is to make everything optional by
> > default and only have to explicitly specify if a dependency is mandatory.
> >
> > Hoping we can get to a point where all the power is to the admin running
> > XWiki, not the developer.
> >
> > Getting past the above "critique", it's still very nice to hear that we
> > will now have one solution to this old problem.
> >
> > Thanks,
> > Eduard
> >
> > On Wed, Jul 5, 2017 at 6:43 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > wrote:
> >
> >> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <vinc...@massol.net>
> wrote:
> >> > Hi Thomas,
> >> >
> >> >> On 5 Jul 2017, at 17:00, Thomas Mortagne <thomas.morta...@xwiki.com>
> >> wrote:
> >> >>
> >> >> Hi everyone,
> >> >>
> >> >> I just implemented https://jira.xwiki.org/browse/XCOMMONS-1229 which
> >> >> allows to indicate that a dependency will be installed by default but
> >> >> does not have a string dependency link with the extension, meaning
> >> >> that uninstalling it won't impact the backward dependencies (so they
> >> >> are not really backward dependencies in that case :)).

Re: [xwiki-devs] [Brainstorming] Location of login/Register buttons

[Eduard Moraru]

Hi,

So the main idea would be to show the user avatar even for guest users? We
are currently only showing it for logged-in users.
For the guest we could have a specific avatar (like the noavatar.png but
redesigned with some question mark inside it) to differentiate it from a
logged-in user that has no avatar set (like a new user).

Additionally, we`d have to consider what happens when you click on it.

Option1:
It could activate the drawer and show the login/register (for guest) and
profile and logout (for logged-in users) links.

Option2:
Take the user to the login screen. Additionally, the login screen should
have a link to registration -- this is something that does not make sense
to be separated (as it is now).

Option3:
Move the user related controls (currently located under/inside the drawer)
to a drop-down under the user avatar of the top menu.

Option 3 is more suited and intuitive/expected for desktop browsers but
options 1/2 are more mobile friendly (where the user is usually hidden in
the drawer, as Caty points out in an offline discussion).

Option 2 would be in the middle and probably the simplest to implement,
based on what we have now. I think I prefer it as well.

WDYT?

Thanks,
Eduard

On Thu, Jul 6, 2017 at 3:49 PM, Thomas Mortagne 
wrote:

> On Thu, Jul 6, 2017 at 2:48 PM, Thomas Mortagne
>  wrote:
> > Sure public website is an valid use case but it's way too far from
> > being the main XWiki use case to justify using it as reference for UIX
> > decisions IMO.
>
> s/public website/public readonly website/
>
> >
> > On Thu, Jul 6, 2017 at 1:21 PM, Vincent Massol 
> wrote:
> >> Hi Caty/All,
> >>
> >>> On 6 Jul 2017, at 13:00, Ecaterina Moraru (Valica) 
> wrote:
> >>>
> >>> The problem comes from the multiple Flavors.
> >>> For example on Intranets, the content cannot be read by Anonymous, so
> the
> >>> first think you need to do and see is the login page.
> >>>
> >>> What you are describing is problems with websites that have public
> >>> documentation and where people log in, only when wanting to contribute.
> >>>
> >>> Having the Log-in visible or under an user menu, are both patterns
> that are
> >>> recommended and we tried both.
> >>
> >> Indeed there are several use cases:
> >>
> >> 1) Public web sites that are read only (except for admins or a group of
> people maintaining it for example)
> >> 2) Collaborative public web sites (want to promote registration/logging
> in) (e.g. xwiki.org)
> >> 3) Intranets (also want to promote logging)
> >>
> >> The standard flavor is neutral and the simplest is probably to have
> either an Admin UI option to configure the location (technically it could
> be a UIX parameter that specifies where the login and/or register options
> are located - Or we could keep it as 2 UIX with an option to disable it).
> >>
> >> Now since XWiki by default is a wiki and thus about promoting
> collaboration, I’d make the icon visible by default and let admins of use
> case 1) the need to configure it in the Admin.
> >>
> >> WDYT?
> >>
> >> Thanks
> >> -Vincent
> >>
> >>>
> >>> On Thu, Jul 6, 2017 at 12:05 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> >>> wrote:
> >>>
>  in a use case like xwiki.org is really not great that users don't see
>  anymore that they can register.
> 
>  On Thu, Jul 6, 2017 at 11:02 AM, Vincent Massol 
>  wrote:
> > Hi devs,
> >
> > We’ve moved the register/login buttons inside the drawer. However one
>  consequence is that users don’t notice it anymore.
> >
> > I’d like this thread to be a brainstorming about what we could do
> about
>  it and whether you agree it’s an issue that we need to fix.
> >
> > Ideas?
> >
> > One idea could to reuse the Avatar image location to have some icon
> to
>  register/login when not logged in.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> 
> 
> 
>  --
>  Thomas Mortagne
> 
> >>
> >
> >
> >
> > --
> > Thomas Mortagne
>
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [PROPOSAL] So which Standard flavor dependencies should be optional

[Eduard Moraru]

Hi,

It`s very nice to hear we are progressing on this topic, but I`m not very
fond of the current solution. Marking dependencies as optional still puts
the responsibility on the developer to actually do that and makes the admin
dependent on the developer's choice and discipline. Feels more like a
workaround that we will end up having to support.

Working for building whitelists is a tedious process and we will surely
miss things, and this is only about things that we control in the standard
flavor. What about extensions and their dependencies?

Sure, as Caty suggests, one option is to make everything optional by
default and only have to explicitly specify if a dependency is mandatory.

Hoping we can get to a point where all the power is to the admin running
XWiki, not the developer.

Getting past the above "critique", it's still very nice to hear that we
will now have one solution to this old problem.

Thanks,
Eduard

On Wed, Jul 5, 2017 at 6:43 PM, Thomas Mortagne 
wrote:

> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol  wrote:
> > Hi Thomas,
> >
> >> On 5 Jul 2017, at 17:00, Thomas Mortagne 
> wrote:
> >>
> >> Hi everyone,
> >>
> >> I just implemented https://jira.xwiki.org/browse/XCOMMONS-1229 which
> >> allows to indicate that a dependency will be installed by default but
> >> does not have a string dependency link with the extension, meaning
> >> that uninstalling it won't impact the backward dependencies (so they
> >> are not really backward dependencies in that case :)).
> >
> > This is very nice. What if I want to uninstall an extension which is NOT
> marked as optional (ie force uninstall at your own risks)?
>
> If it's not optional then... it's not optional and require to
> uninstall backward dependency.
>
> >
> >> Now we need to decide what exactly is optional in Standard flavor.
> >>
> >> Here are some ideas:
> >>
> >> * application-help-center
> >
> >> * xwiki-platform-menu-ui
> >
> >> * xwiki-platform-wiki-ui-mainwiki
> >
> >> * xwiki-platform-office-ui
> >> * xwiki-platform-invitation-ui
> >> * xwiki-platform-appwithinminutes-ui
> >
> > I think it needs some refactoring first since the pages it generates
> still need some pages from AWM.
>
> Actually I tough about that and IMO if an extension has AWM pages it
> should have a non optional dependency on AWM (i.e. it would be
> optional from flavor point of view but non optional from other
> extension point of view).
>
> >
> >> * xwiki-platform-linkchecker-ui
> >> * xwiki-platform-sandbox
> >
> >> * xwiki-platform-sharepage-ui
> >> * xwiki-platform-distribution-flavor-tour
> >> * application-templates-ui
> >
> >>
> >> I did not actually tried to uninstall those so it's possible it's not
> >> a good idea to uninstall some of them right now (hardcoded use
> >> somewhere maybe).
> >>
> >> WDYT ?
> >
> > The list sounds good to start with (we need to test remove them first
> ofc).
> >
> > Thanks
> > -Vincent
> >
> >> --
> >> Thomas Mortagne
> >
>
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [Proposal] Make users list readonly?

[Eduard Moraru]

On Thu, Jun 22, 2017 at 6:52 PM, Thomas Mortagne <thomas.morta...@xwiki.com>
wrote:

> On Thu, Jun 22, 2017 at 5:01 PM, Thomas Mortagne
> <thomas.morta...@xwiki.com> wrote:
> > On Thu, Jun 22, 2017 at 4:19 PM, Eduard Moraru <enygma2...@gmail.com>
> wrote:
> >> I would really like to still be able to use 1 tool, i.e. currently the
> mail
> >> client, to read the mails for either devs or users. Sure, answering to
> >> users should be done on discourse, but I would not like to have to
> juggle
> >> yet another service.
> >
> > This does not have much to do with the users mailing list. As I
> > explained to you on IRC you can very well receive all discourse
> > messages by mail if you want which is exactly what I do (I never go to
> > forum.xwiki.org directly, only from some mail I received).
> >
> >>
> >> I understand that what you describe seems like a bug. Did we try to
> report
> >> it to discourse? On a quick google I'm unable to find such a behavior
> >> described. We could try reporting it otherwise.
> >>
>
> >> P.S.: I have re-enabled the "Enable mailing list mode" option to the
> >> discourse mailman user. Will watch it to see when/if it gets disabled
> again.
>
> I'm not a big fan of getting an close to unreadable duplicate of all
> the discourse mails which is what I get right now.
>
> We moved to a forum so let's live with it and let people decide if
> they want mails not. If you want mails just enable them in your
> profile.
>
> Receiving all messages from forum.xwiki.org without having an account
> there is really not a valid use case. If we want to store discourse
> messages on markmail then let's give direct markmail mail to discourse
> instead of going trough users mailing list which does not make any
> sense.
>

Sorry for the trouble, Thomas.

However, we could look at it the other way as well. If you have moved to
another way of receiving user emails (user setting on your forum profile),
maybe one option would be to unsubscribe from us...@xwiki.org (once the
setup is complete and it is read-only). This would allow us to keep the
list archived and in use by people that still prefer it, while allowing
people that prefer direct mails from discourse to avoid being spammed by
both solutions.

WDYT?

Thanks,
Eduard

>
> >>
> >> Thanks,
> >> Eduard
> >>
> >>
> >>
> >> On Thu, Jun 22, 2017 at 3:36 PM, Vincent Massol <vinc...@massol.net>
> wrote:
> >>
> >>>
> >>> > On 22 Jun 2017, at 14:35, Vincent Massol <vinc...@massol.net> wrote:
> >>> >
> >>> >
> >>> >> On 22 Jun 2017, at 14:09, Eduard Moraru <enygma2...@gmail.com>
> wrote:
> >>> >>
> >>> >> Guys, I thought we were going to make the users list read-only, not
> >>> disable
> >>> >> it completely. This is now what was discussed, AFAIK.
> >>> >
> >>> > Where did you see that? At least that’s not my proposal. My proposal
> is
> >>> to make it read only.
> >>> >
> >>> >> Right now, I haven't received a mail on the users list since 12th of
> >>> June.
> >>> >
> >>> > I haven’t made it readonly yet so I don’t know if it’s normal or not.
> >>>
> >>> FTR just noticed 2 users have contacted me telling me they cannot post
> to
> >>> the user list anymore. So someone must have changed something on the
> user
> >>> list, but it’s not me :)
> >>>
> >>> Thanks
> >>> -Vincent
> >>>
> >>> >
> >>> >> AFAIR, a proposed flow was to receive mails of the discussions and,
> if
> >>> you
> >>> >> want to reply, you'd follow the reply link in the mail an open the
> >>> >> discourse browser window.
> >>> >>
> >>> >> So, only discourse could be able to publish to the list, all other
> list
> >>> >> users would get rejected.
> >>> >
> >>> > The proposal was:
> >>> > * Make the list readonly except for a given discourse user who’d have
> >>> u...@xwiki.org as its email so that we can still archive discussions
> done
> >>> with discourse on markmail, nabble, etc.
> >>> >
> >>> > However:
> >>> > * I have configured a user having u...@xwiki.org as its email and in
> >>> “mailing list mode” but after it sends its first

Re: [xwiki-devs] [Proposal] Make users list readonly?

[Eduard Moraru]

On Thu, Jun 22, 2017 at 7:07 PM, Vincent Massol <vinc...@massol.net> wrote:

>
> > On 22 Jun 2017, at 17:52, Thomas Mortagne <thomas.morta...@xwiki.com>
> wrote:
> >
> > On Thu, Jun 22, 2017 at 5:01 PM, Thomas Mortagne
> > <thomas.morta...@xwiki.com> wrote:
> >> On Thu, Jun 22, 2017 at 4:19 PM, Eduard Moraru <enygma2...@gmail.com>
> wrote:
> >>> I would really like to still be able to use 1 tool, i.e. currently the
> mail
> >>> client, to read the mails for either devs or users. Sure, answering to
> >>> users should be done on discourse, but I would not like to have to
> juggle
> >>> yet another service.
> >>
> >> This does not have much to do with the users mailing list. As I
> >> explained to you on IRC you can very well receive all discourse
> >> messages by mail if you want which is exactly what I do (I never go to
> >> forum.xwiki.org directly, only from some mail I received).
> >>
> >>>
> >>> I understand that what you describe seems like a bug. Did we try to
> report
> >>> it to discourse? On a quick google I'm unable to find such a behavior
> >>> described. We could try reporting it otherwise.
> >>>
> >
> >>> P.S.: I have re-enabled the "Enable mailing list mode" option to the
> >>> discourse mailman user. Will watch it to see when/if it gets disabled
> again.
> >
> > I'm not a big fan of getting an close to unreadable duplicate of all
> > the discourse mails which is what I get right now.
>
> That could be fixed easily:
> * Once the users list is read only we can remove the prefix in the mail
> * We can also configure the list to support HTML
>
> > We moved to a forum so let's live with it and let people decide if
> > they want mails not. If you want mails just enable them in your
> > profile.
>
> Yep
>
> > Receiving all messages from forum.xwiki.org without having an account
> > there is really not a valid use case.
>
> I agree
>
> > If we want to store discourse
> > messages on markmail then let's give direct markmail mail to discourse
> > instead of going trough users mailing list which does not make any
> > sense.
>
> It has the advantages of distributing the archiving:
> * markmail
> * nabble
> * gmane
> * xwiki mailman archives
> * etc
>
> I don’t think there’s such a markmail email…
>
> However, there’s a problem with Discourse as I mentioned (unless Edy found
> a solution).
>

Did not look more, as right now the setting still seems to be on.

Thanks,
Eduard


>
> Personally I’m fine with not archiving discourse discussions through
> mailing list archives. It makes a bit harder for users to search in one
> place but quickly over time it’ll be ok. It’ll also be a bit harder for
> stats but I guess we can handle that too…
>
> Thanks
> -Vincent
>
> >
> >>>
> >>> Thanks,
> >>> Eduard
> >>>
> >>>
> >>>
> >>> On Thu, Jun 22, 2017 at 3:36 PM, Vincent Massol <vinc...@massol.net>
> wrote:
> >>>
> >>>>
> >>>>> On 22 Jun 2017, at 14:35, Vincent Massol <vinc...@massol.net> wrote:
> >>>>>
> >>>>>
> >>>>>> On 22 Jun 2017, at 14:09, Eduard Moraru <enygma2...@gmail.com>
> wrote:
> >>>>>>
> >>>>>> Guys, I thought we were going to make the users list read-only, not
> >>>> disable
> >>>>>> it completely. This is now what was discussed, AFAIK.
> >>>>>
> >>>>> Where did you see that? At least that’s not my proposal. My proposal
> is
> >>>> to make it read only.
> >>>>>
> >>>>>> Right now, I haven't received a mail on the users list since 12th of
> >>>> June.
> >>>>>
> >>>>> I haven’t made it readonly yet so I don’t know if it’s normal or not.
> >>>>
> >>>> FTR just noticed 2 users have contacted me telling me they cannot
> post to
> >>>> the user list anymore. So someone must have changed something on the
> user
> >>>> list, but it’s not me :)
> >>>>
> >>>> Thanks
> >>>> -Vincent
> >>>>
> >>>>>
> >>>>>> AFAIR, a proposed flow was to receive mails of the discussions and,
> if
> >>>> you
> >>>>>> want to rep

Re: [xwiki-devs] [Proposal] Make users list readonly?

[Eduard Moraru]

I would really like to still be able to use 1 tool, i.e. currently the mail
client, to read the mails for either devs or users. Sure, answering to
users should be done on discourse, but I would not like to have to juggle
yet another service.

I understand that what you describe seems like a bug. Did we try to report
it to discourse? On a quick google I'm unable to find such a behavior
described. We could try reporting it otherwise.

P.S.: I have re-enabled the "Enable mailing list mode" option to the
discourse mailman user. Will watch it to see when/if it gets disabled again.

Thanks,
Eduard



On Thu, Jun 22, 2017 at 3:36 PM, Vincent Massol <vinc...@massol.net> wrote:

>
> > On 22 Jun 2017, at 14:35, Vincent Massol <vinc...@massol.net> wrote:
> >
> >
> >> On 22 Jun 2017, at 14:09, Eduard Moraru <enygma2...@gmail.com> wrote:
> >>
> >> Guys, I thought we were going to make the users list read-only, not
> disable
> >> it completely. This is now what was discussed, AFAIK.
> >
> > Where did you see that? At least that’s not my proposal. My proposal is
> to make it read only.
> >
> >> Right now, I haven't received a mail on the users list since 12th of
> June.
> >
> > I haven’t made it readonly yet so I don’t know if it’s normal or not.
>
> FTR just noticed 2 users have contacted me telling me they cannot post to
> the user list anymore. So someone must have changed something on the user
> list, but it’s not me :)
>
> Thanks
> -Vincent
>
> >
> >> AFAIR, a proposed flow was to receive mails of the discussions and, if
> you
> >> want to reply, you'd follow the reply link in the mail an open the
> >> discourse browser window.
> >>
> >> So, only discourse could be able to publish to the list, all other list
> >> users would get rejected.
> >
> > The proposal was:
> > * Make the list readonly except for a given discourse user who’d have
> u...@xwiki.org as its email so that we can still archive discussions done
> with discourse on markmail, nabble, etc.
> >
> > However:
> > * I have configured a user having u...@xwiki.org as its email and in
> “mailing list mode” but after it sends its first mail, the “mailing list
> mode” is automatically disabled and I don’t know why.
> >
> > Conclusion so far:
> > * We need to make the list readonly. I’ll do this next week when I find
> some time.
> > * I don’t know how to fix the issue listed above
> > * In any case I don’t think it’s that important that we don’t archive
> discourse discussions on markmail so I’m fine with dropping this part.
> >
> > Thanks
> > -Vincent
> >
> >
> >>
> >> Thanks,
> >> Eduard
> >>
> >> On Fri, Jun 2, 2017 at 8:55 PM, Vincent Massol <vinc...@massol.net>
> wrote:
> >>
> >>>
> >>>> On 2 Jun 2017, at 19:50, Marius Dumitru Florea <
> >>> mariusdumitru.flo...@xwiki.com> wrote:
> >>>>
> >>>> On Fri, Jun 2, 2017 at 2:14 AM, Vincent Massol <vinc...@massol.net>
> >>> wrote:
> >>>>
> >>>>> Hi devs,
> >>>>>
> >>>>> Now that our forum is working well I’d like to propose to make the
> users
> >>>>> list readonly and move all users to the forum.
> >>>>>
> >>>>
> >>>> It's a small thing but very annoying: is there a way to reply in-line?
> >>> When
> >>>> the post you want to reply to is long it's pretty hard to keep
> context if
> >>>> you can't reply in-line. The alternative is to copy and quote the part
> >>> that
> >>>> you are referring to, but it's not that nice.
> >>>
> >>> Yes it’s possible and very easy to do: simply select the text you wish
> to
> >>> reply to and you’ll see the option to reply to it :)
> >>>
> >>> Thanks
> >>> -Vincent
> >>>
> >>>>
> >>>> Thanks,
> >>>> Marius
> >>>>
> >>>>
> >>>>>
> >>>>> So the plan I’m proposing is:
> >>>>> * On Monday, make the users list readonly
> >>>>> * Send a last message on it, inviting users to move to the forum
> >>>>>
> >>>>> Note that we’ve already been putting a notice to all messages sent on
> >>> the
> >>>>> users lists inviting users to move to the forum and this has been
> >>> running
> >>>>> for 2 weeks already.
> >>>>>
> >>>>> My feeling is that we need to finalize the move now and prevent too
> much
> >>>>> scattering of user posts both on the users list and on the forum and
> >>> have
> >>>>> them all on the forum ASAP.
> >>>>>
> >>>>> WDYT?
> >>>>>
> >>>>> Thanks
> >>>>> -Vincent
> >>>>>
> >>>>>
> >>>
> >>>
> >
>
>

Re: [xwiki-devs] [Proposal] Make users list readonly?

[Eduard Moraru]

Guys, I thought we were going to make the users list read-only, not disable
it completely. This is now what was discussed, AFAIK.

Right now, I haven't received a mail on the users list since 12th of June.

AFAIR, a proposed flow was to receive mails of the discussions and, if you
want to reply, you'd follow the reply link in the mail an open the
discourse browser window.

So, only discourse could be able to publish to the list, all other list
users would get rejected.

Thanks,
Eduard

On Fri, Jun 2, 2017 at 8:55 PM, Vincent Massol  wrote:

>
> > On 2 Jun 2017, at 19:50, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > On Fri, Jun 2, 2017 at 2:14 AM, Vincent Massol 
> wrote:
> >
> >> Hi devs,
> >>
> >> Now that our forum is working well I’d like to propose to make the users
> >> list readonly and move all users to the forum.
> >>
> >
> > It's a small thing but very annoying: is there a way to reply in-line?
> When
> > the post you want to reply to is long it's pretty hard to keep context if
> > you can't reply in-line. The alternative is to copy and quote the part
> that
> > you are referring to, but it's not that nice.
>
> Yes it’s possible and very easy to do: simply select the text you wish to
> reply to and you’ll see the option to reply to it :)
>
> Thanks
> -Vincent
>
> >
> > Thanks,
> > Marius
> >
> >
> >>
> >> So the plan I’m proposing is:
> >> * On Monday, make the users list readonly
> >> * Send a last message on it, inviting users to move to the forum
> >>
> >> Note that we’ve already been putting a notice to all messages sent on
> the
> >> users lists inviting users to move to the forum and this has been
> running
> >> for 2 weeks already.
> >>
> >> My feeling is that we need to finalize the move now and prevent too much
> >> scattering of user posts both on the users list and on the forum and
> have
> >> them all on the forum ASAP.
> >>
> >> WDYT?
> >>
> >> Thanks
> >> -Vincent
> >>
> >>
>
>

[xwiki-devs] [ANN] XWiki 9.5 Release Candidate 1 released

[Eduard Moraru]

The XWiki development team is proud to announce the availability of XWiki
9.5 Release Candidate 1.

This release features a major restructuring of the XWiki Enterprise
distribution by converting it into the XWiki Standard Flavor. User features
cover notifications by email, attachments list showing icons and image
previews, recommended template at page creation, LiveTable date and
multilist filters, and minor visual improvements. Admins can more easily
customize the look and feel by the extended use of Icon Themes and the
improvements done to setting the wiki logo. Finally, devs have a new API
for working with wiki components, new icon theme mappings and notifications
API improvements.

You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.5RC1

Thanks for your support
-The XWiki dev team