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

[Sergiu Dumitriu]

;> given
>> tag, EVEN IF THE PAGE WAS EXCLUDED BY THE USER. Example of use-case: "I
>> don't
>> want to receive notifications about wiki A except for pages marked with
>> the tag
>> T".
>>
>> And it is not working. First because it is difficult to write a SQL query
>> for
>> that. It requires to make a join clause with the document and the object
>> tables,
>> which our SQL injection mechanism does not support. Even if it were
>> possible,
>> creating a SQL join with the document table will de-facto filter events
>> that do
>> not concern any pages or pages that do not have any objects: so many other
>> filters will be broken. I also don't consider creating a SQL subquery, I
>> think
>> the whole query would became too big. So I decided to just not inject any
>> SQL
>> code for this filter and only implement the post-filtering mechanism.
>>
>> But the other filter "EXCLUDE WIKI A" generates a SQL injection such as
>> "WIKI <> 'WIKI A'" so the events concerning the wiki A are not fetched
>> from the
>> database. Consequence: the tag filter never see the events that it is
>> supposed
>> to keep. It would be actually possible to by-pass the first SQL injections
>> by
>> injecting something like "OR 1=1". But doing something like this is like
>> dropping the all SQL injections mechanism.
>>
>> I see some solutions for this problem:
>>
>>   A/ For each tag, create a permanent list of pages that hold it. So I can
>>  inject "OR document IN (that_list)". I think this is heavy.

Definitely not. You'll have to maintain this list in parallel to the
canonical storage for tags, the xwikidoc table itself, with all the
headaches that data duplication brings.

>>   B/ Drop the SQL injection mechanism and only rely on the post-filtering
>>  mechanism. It would require to load from the database A LOT of events,
>>  but maybe we could cache this.

Nope, filtering millions of events by inspecting them one by one is a
performance nightmare.

>>   C/ Don't drop the SQL injection mechanism completely but use it as
>> little as
>>  possible (for example, do not use it for LOCATION filtering). Seems
>> hard to
>>  determine when a filter should use this feature or not.

I think location filtering should still happen in the query itself,
since it is a lot faster.

>>   D/ Don't implement the "tags" filter, since it is the root of the issue.
>> But
>>  it is like sweeping dirt under the carpet!

Well, not implementing something is always the fastest, least intrusive
solution to any problem...

Humor aside, I think that in this case it is the best approach.

>> Since we have the OutOfMemory problem with the SQL injections becoming too
>> huge,
>> I am more in favor of solution B or C. But I'm not sure for now, since I
>> do not
>> know how much it would impact the performances and the scalability of the
>> whole
>> notifications feature.
>>
>> This is a complex topic, but I hope this message will inspire you some
>> suggestions or things I have not seen with my own eyes.
>>
>> Thanks for your help,
>>
>> Guillaume
>>
> 
> 
> 
Other options:

E/ Drop SQL altogether, move the event stream into a nosql database, and
do stream filtering; kind of like the B proposal

F/ Drop SQL and querying altogether, switch to a pub-sub mechanism where
a subscriber is created for every user and his filters, and matching
events are placed in a queue until they are all sent (consumed) in a
notification. Obviously, this only works for email notifications, not
for browsing past events in a webpage.

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

Re: [xwiki-devs] [Proposal] Weblate as XWiki's translation platform

[Sergiu Dumitriu]

On 04/24/2018 09:44 AM, Clément Aubin wrote:
> On 04/23/2018 12:18 PM, Adel Atallah wrote:
>> Hello everyone,
> 
> Hi,
> 
> AFAICS Weblate looks nice, but haven't we looked at other alternatives ?
> 
> Here are some of them :
> 
> * http://jabylon.org/ (uses Java, so it might be easier to integrate)
> * http://zanata.org/
> * http://pootle.translatehouse.org/
> * https://pontoon.mozilla.org/

I've been quite happy with https://crowdin.com/ , which handles
ApplicationResources.properties very well, but isn't ideal for the .xml
translations. It's free for open source projects.

The problem with the .xml files is that apart from the translatable
content, which it handles well, it tries to commit the exact same XML
markup as in the "source" file, which doesn't really work for XWiki. As
a workaround, I just cat|sed the contents of the XML files and upload it
as a non-github-tracked resource. The alternative is to
rebase-interactive each pull request it creates to discard the commits
that try to re-format the XML files, but that gets tedious after a while.

> Also, I think that it has already been discussed, either on
> https://xwiki.markmail.org/search/?q=weblate or on IRC, but being able
> to use xwiki.org as an identity provider on our translation platform
> would be neat, so it could be something to look for in the possible
> solutions.
> 
>> As you may already know, we have thought about replacing the l10n platform
>> which is becoming too slow. Weblate seems to be a good replacement choice,
>> as it will able contributors to have their name in the commits and it has
>> every features needed to make translations.
>>
>> One problem is that XWiki doesn't use a standard method to process
>> translation files. We can solve that by creating some scripts to convert
>> XWiki translation files into one that Weblate can understand.
>>
>> A detailed solution can be found here :
>> http://design.xwiki.org/xwiki/bin/view/Proposal/WeblateasXWikistranslationplatform
> 
> We'll indeed need to convert our translation files to a more "standard"
> format, but I fear that using Python might decrease the maintainability
> of those scripts.
> 
> WDYT ?
> 
>> Feel free to discuss it by responding here or directly in the design page.
>>
>> Thanks,
>> <http://www.xwiki.com/> *Adel Atallah*
>> *Product developer intern*
>> adel.atal...@xwiki.com <corina.lu...@xwiki.com>
>> tel: +33 (0)6 12 96 35 06
>>
> 
> Thanks,
> Clément
> 


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

Re: [xwiki-devs] Onboarding feedback

[Sergiu Dumitriu]

On 04/19/2018 06:50 AM, Vincent Massol wrote:
> Thanks for the feedback Adel
> 
>> On 19 Apr 2018, at 11:05, Adel Atallah <adel.atal...@xwiki.com> 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!
>>
>> <http://www.xwiki.com/> *Adel Atallah*
>> *Product developer intern*
>> adel.atal...@xwiki.com <corina.lu...@xwiki.com>
>> tel: +33 (0)6 12 96 35 06
> 


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

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

[Sergiu Dumitriu]

+1 to what Eduard said.

On 04/20/2018 05:34 AM, Eduard Moraru wrote:
> +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 <thomas.morta...@xwiki.com>
> wrote:
> 
>> On Wed, Apr 18, 2018 at 6:43 PM, Clément Aubin <aubincl...@gmail.com>
>> 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 <vinc...@massol.net>
>> 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
>>


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

Re: [xwiki-devs] [VOTE] Drop support for Internet Explorer 10/11 + Adding support for Edge

[Sergiu Dumitriu]

Same as Vincent.

On 10/09/2017 07:52 AM, Vincent Massol wrote:
> Hi Caty,
> 
>> On 6 Oct 2017, at 16:55, Ecaterina Moraru (Valica) <vali...@gmail.com> wrote:
>>
>> Hi devs,
>>
>> This mail is about:
>> A. Dropping support for IE10
>> B. Dropping support for IE11
>> C. Adding support for Microsoft Edge
>>
>> ---
>>
>> If you read our Browser Support Strategy (
>> http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy ) we
>> are still supporting Internet Explorer 10.
>>
>> We started its support since Jun 17, 2015. In practice we don't perform
>> full tests on IE10, focusing mostly on IE11. The last performed tests for
>> IE10 where in Jan 2017, for XWiki 8.4.4 (
>> http://test.xwiki.org/xwiki/bin/view/QA/XWiki%208.4.4#|t=qa=1=15=test=asc=10
>> ).
>>
>> On another note, Microsoft Edge replaced Internet Explorer as the default
>> web browser since the release of Windows 10 (launched Jul 2015). Internet
>> Explorer 11 is maintained on Windows 10 for compatibility purposes, but is
>> deprecated in favor of Edge and is no longer actively developed.
>>
>> Instead of supporting "Internet Explorer 10.x-Latest" + "We support IE
>> browsers, starting with version 10." we actually should say (in case the
>> vote is passing) "Internet Explorer 11 + Microsoft Edge".
>>
>> We might even considered dropping support for IE 11 and just keep Microsoft
>> Edge, since that's the latest version of Windows supported browser.
>> Although, IE11 currently still has a better usage than Microsoft Edge. I
>> could not found any performed tests for Microsoft Edge on our test wiki.
>>
>> ---
>>
>> In terms of xwiki.org website usage for the past 12 months, we have:
>> - 5.46% sessions for Internet Explorer
>> -- IE11: 91.50%
>> -- IE10: 2.80%
>> - 1.43% sessions for Edge (multiple versions)
>>
>> In terms of worldwide market share for the past 12 months (according to
>> http://gs.statcounter.com/browser-market-share/desktop/ ), for desktops, we
>> have:
>> - 8.21% IE
>> - 4.3% Edge
>>
>> Usage example for August 2017:
>> - 7.1% for IE11
>> - 2.26% for Edge 15
>> - 1.37% for Edge 14
>> - 0.2% for Edge 13
>>
>> ---
>>
>> So my votes are:
>> A. Dropping support for IE10
>> +1
>>
>> B. Dropping support for IE11
>> -0, because of bigger usage compared to Microsoft Edge. Still, I don't
>> think we have the man-power to support tests on both browsers types.
>>
>> C. Adding support for Microsoft Edge
>> +1, because this is the latest supported browser for Windows
> 
> We  also have limited manpower and we need to limit the # of versions we 
> support.  However because of the large marketshare of IE11it wouldn’t be good 
> to drop its support FTM IMO.
> 
> So I think we should try to support both Edge + IE11 and see how complex it 
> is. If too complex we can think of dropping IE11 or delaying support for Edge.
> 
> So, I’m:
> 
> A +1
> B -1 for now
> C +1
> 
> Thanks
> -Vincent
> 
>>
>> Thanks,
>> Caty
> 


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

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

[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/

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

[Sergiu Dumitriu]

+1.

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

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


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

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

[Sergiu Dumitriu]

+1.

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


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

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

[Sergiu Dumitriu]

On 05/24/2017 05:51 AM, Thomas Mortagne wrote:
> Hi devs,
> 
> I'm getting closer to finish with the hard work around new platform
> flavor which is going to replace XE.
> 
> Need to decide what user will see in the Flavor picker when installed XWiki 
> now.
> 
> As a reminder we decided that this would be a generic flavor, not tied
> to any specific use case (so forget about "Knwonledge Base Flavor"
> :)).
> 
> Here is a few ideas gathered in previous mails:
> * "XWiki Flavor"
> * "Default XWiki Flavor"
> * "Generic XWiki Flavor"
> * "Base XWiki Flavor"

A few more ideas:

* Classic
* Raw
* Starter

> "Generic" is probably a way too technical term.
> 
> "Base" would be misleading IMO since it's not really a base flavor.
> Its primary goal is not to be used as a dependency (of course it's
> fine to have it as dependency if you just want to add pre installed
> extensions to the default flavor). It's a -1 for me.
> 
> Frankly I would simply go for "XWiki Flavor". I know, it's not going
> to be the only flavor for XWiki but it's obvious when you actually see
> severals of those in the picker anyway and I find it nicer than
> "Default XWiki Flavor" which basically means the same thing since the
> XWiki core project does not plan to provide any other flavor. I'm also
> fine with "Default XWiki Favor" if others think it's a better name.
> 
> WDYT ?
> 


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

Re: [xwiki-devs] [Proposal] GitHub code reviews and protected branches

[Sergiu Dumitriu]

Hi Vincent,

On 05/17/2017 09:30 AM, Vincent Massol wrote:
> Hi Sergiu,
> 
>> On 16 May 2017, at 07:36, Sergiu Dumitriu <ser...@xwiki.org> wrote:
>>
>> Hi devs,
>>
>> A while ago GitHub introduced several features that I think can help
>> boost even more the code quality, reduce the bus factor, and make it
>> more attractive to contribute to the project.
>>
>> = Protected branches =
>>
>> Branches can be configured as protected in several ways:
>> * Require pull request reviews before merging
>> ** no direct commits are allowed, everything must go through a pull request
>> ** a pull request must be reviewed by at least one other trusted
>> committer before it is allowed to be merged
>>
>> * Require status checks to pass before merging
>> ** pull requests must pass automated checks, for example by being
>> successfully built by a CI service
>>
>> * Restrict who can push to this branch
>> ** official branches (master + stable-x.y) could be restricted to
>> approved committers, but we could grant write access to all other
>> interested developers more easily
>>
>>
>> = Reviews for pull requests =
>>
>> Comments on all commits as well on pull requests have been supported
>> since the early days of GitHub, but more recently it is easier to submit
>> (and request) actual reviews for pull requests. Instead of simply
>> commenting, and changing that special field on Jira, an official pull
>> request status is supported, with three states:
>>
>> - review required
>> - changes requested
>> - approved
>>
>> PR authors can either await for reviews from anybody, or request someone
>> in particular for a review.
>>
>> Committers can filter PRs by their status, and they can also show only
>> the PRs that require their review.
>>
>>
>> = Getting more eyeballs on the code =
>>
>> As Linus' Law states, "given enough eyeballs, all bugs are shallow".
>> We've been experimenting with mandatory pull requests for a while in my
>> other XWiki-based project, with great success so far. So here's a
>> proposal for a different development workflow:
>>
>> 1. Set up 2 teams, one with master (senior) committers, fully vetted
>> committers that have proven they understand the XWiki code, as well as
>> the XWiki product, and one with junior committers
> 
> How is that different from what we’re currently doing? 
> 
> Right now we have:
> * Committers (they’ve been voted committers because they have proven their 
> knowledge on our platform + long term dedication to the project). They’re the 
> “senior” of your team
> * Contributors, who need to go through PR to get their code in. They’re the 
> “juniors” of your other team.

It's different because:
- they are part of the XWiki organization, not just some forkers; people
may care about the list of organizations that's displayed on their profile
- they can commit code in the official repository, so everybody else can
see their commits in one place (including through notification emails),
and every other committer can contribute to their branches

>> 2. Protect the master branch. Require pull requests and reviews before
>> any code is merged in it. Restrict push only to the master committers.
> 
> Main pros for me:
> * we can ask for the CI to pass before merging, thus disturbing less other 
> committers.
> * easier to converge for releases but *only* if we’re ready to drop features. 
> If we’re not then it’s the opposite and makes it harder to converge.
> 
> Main cons: 
> * takes a LOT of time before code is merged. You can be sure that it’ll need 
> several hours before it gets merged and that you’ll have moved on to 
> something else when the comment comes in. And since your new work has an 
> important chance of being related you might end up chaining the PRs.
> 
>> 3. Everybody works on separate branches
> 
> How does the CI ensure that all branches are merged before the tests are 
> executed?

Why all branches? I'm not sure I understand this...

Jenkins has a GitHubPullRequestBuilder plugin, which can build every
pull request, after every new push to the PR branch, and this should say
if the build will work after merging that particular pull request. It
used to be fragile several years ago, but it's working great now.

> Example: I’m working on something and I’m modifying some @Unstable API. 
> Someone else is working with the previous API. We’ll only discover the issue 
> late when both PRs are merged.

There's nothing new, the same thing may happen with everybody committing
directly to master. Either there's a conflict, in which case the

[xwiki-devs] [Proposal] GitHub code reviews and protected branches

[Sergiu Dumitriu]

Hi devs,

A while ago GitHub introduced several features that I think can help
boost even more the code quality, reduce the bus factor, and make it
more attractive to contribute to the project.

= Protected branches =

Branches can be configured as protected in several ways:
* Require pull request reviews before merging
** no direct commits are allowed, everything must go through a pull request
** a pull request must be reviewed by at least one other trusted
committer before it is allowed to be merged

* Require status checks to pass before merging
** pull requests must pass automated checks, for example by being
successfully built by a CI service

* Restrict who can push to this branch
** official branches (master + stable-x.y) could be restricted to
approved committers, but we could grant write access to all other
interested developers more easily


= Reviews for pull requests =

Comments on all commits as well on pull requests have been supported
since the early days of GitHub, but more recently it is easier to submit
(and request) actual reviews for pull requests. Instead of simply
commenting, and changing that special field on Jira, an official pull
request status is supported, with three states:

- review required
- changes requested
- approved

PR authors can either await for reviews from anybody, or request someone
in particular for a review.

Committers can filter PRs by their status, and they can also show only
the PRs that require their review.


= Getting more eyeballs on the code =

As Linus' Law states, "given enough eyeballs, all bugs are shallow".
We've been experimenting with mandatory pull requests for a while in my
other XWiki-based project, with great success so far. So here's a
proposal for a different development workflow:

1. Set up 2 teams, one with master (senior) committers, fully vetted
committers that have proven they understand the XWiki code, as well as
the XWiki product, and one with junior committers
2. Protect the master branch. Require pull requests and reviews before
any code is merged in it. Restrict push only to the master committers.
3. Everybody works on separate branches
4. Once the code is almost done, make a pull request and require reviews
from two junior committers
4a. Or, instead of requesting, let committers volunteer themselves, but
it's less likely that someone will volunteer on time
5. The junior committers must then carefully review the code, and either
require changes, just comment, or approve the pull request
6. Once the junior committers have approved the pull request, the PR
author must request review from a senior committer
7. The senior committer can either approve and merge the pull request,
or send it back to step 3.
e. We can define allowed exceptions: don't require PRs from senior
committers if the fixes are really small and obvious, like fixing typos,
or small and important bugfixes that must be merged quickly, but these
should really be rare exceptions

While it does sound like more work for an already overworked team, this
has many benefits:
* the code will have better quality
* awareness of:
** what's new / changing
** how others are approaching a problem (especially juniors learning
from seniors by being exposed to more code)
** the existing code, since the codebase is large and otherwise people
have few occasions to look at many of the parts of XWiki
* this means a larger bus factor for new code, and slowly increasing it
for existing code that's being touched by one and reviewed by many
* theoretically, less time spent doing reviews, since all committers
should look over every commit anyway, but this way they are explicitly
told when they should look, instead of wasting time reviewing work in
progress
* larger community, since people can more quickly become junior
committers instead of having to invest many months of years of forkwork
before committership
* easier collaboration on code, since it's very hard to work on someone
else's fork branches, but easy to work on an origin branch


So, what do you think?
-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/

Re: [xwiki-devs] [Brainstorming] Provide a single distribution packaging WAR using winstone

[Sergiu Dumitriu]

On 05/11/2017 07:19 AM, Vincent Massol wrote:
> Hi,
> 
> The idea would be to do the same as what Jenkins is doing and provide an 
> executable XWiki WAR using winstone:
> https://github.com/jenkinsci/winstone (it’s using Jetty).
> 
> This is the install doc of Jenkins: https://jenkins.io/doc/:
> "
> • Download Jenkins.
> • Open up a terminal in the download directory and run "java -jar jenkins.war"
> • Browse to http://localhost:8080 and follow the instructions to complete the 
> installation.
> “
> 
> Actually what could be nice is that we could release a single WAR packaging 
> for XWiki and:
> * Users could execute it as an executable WAR with java -jar xwiki.war (it 
> would run Jetty)
> * Users could deploy it in their servlet container (in this case the embedded 
> Jetty wouldn’t be used)
> 
> This would allow to release a single packaging and simplify things. It would 
> also work on all OSes and don’t even need users to unzip anything!
> 
> WDYT?
> 

For a regular computer user, running "java -jar xwiki.war" sounds even
more complicated than double-clicking a .zip file, then double-clicking
a .bat file (or just double-clicking a .jar file). Most Windows and
MacOS people don't even know about the command line.

So, I would say that having just a war isn't easier, but harder for
users to start up on a desktop.

On a Linux server, there are system-provided servlet container packages,
which usually come with other nice things such as:
- the ability to start automatically after a reboot, as a daemon
- update more easily, especially after a security issue is fixed
- configurations for logrotate, firewall, selinux...

So, for a server the best package is a native one, (.rpm, .deb, or other
formats), available in a repository. Or, the trend now is to have
containers.


A different question: is it a good idea to have a quick-try standalone
package? I don't know how XWiki users treat the standalone package, but
from my experience with PhenoTips, often users start with the standalone
package on their computer, and then try to use it as a server
application, and get in trouble when trying to:
- share access with others
- upgrade to a new version
- transfer data between instances
- move real data to a server

An alternative is to only offer server-ready packages, and have online
cloud demos for trying out the product. In this case, the standalone
package may only be useful for devs, but for that scenario we could
provide a mvn target that starts up Jetty.


Anyway, back to this proposal:
- I don't think it makes it easier to try out XWiki on a desktop, on the
contrary
- It may make it easier for an inexperienced sysadmin to quickly install
and start XWiki on a server
- But it also makes it harder to maintain the app long term
- It bulks up the .war, but size is no longer a concern nowadays

A single executable .war works for Jetty, Nexus, or other such apps
because they're clearly server tools, only useful on a network, where
most of the "clients" are other programs, and data comes from other
machines. That's not true for XWiki, where a single user can start it on
his desktop and play with it.

So, a -0 to replace the .zip package, and a reluctant +0 to make the
.war executable.

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

Re: [xwiki-devs] [PROPOSAL] New extensions package

[Sergiu Dumitriu]

Users are very bad at reading or following instructions. It's likely
that they will download the file, double click it, and expect it to be
installed automatically.

If the extension is .zip, then the OS will silently unpack it, and the
user won't know what to do next. But since at least something happened,
they might actually think that the file installed itself, then wonder
why it still doesn't work.

If the extension is something special, then the OS won't know what to do
with it, and present a dialog warning that the file can't be opened, and
the user is more likely to search for information about how that file
can be installed.

The downside of it not being a .zip file is that when the user should
unzip it, it's a bit more difficult to do it.

+1 for .xip, it seems that nobody else is using it.

https://fileinfo.com/extension/xip

On 05/02/2017 10:43 AM, Vincent Massol wrote:
> 
>> On 2 May 2017, at 16:36, Thomas Mortagne <thomas.morta...@xwiki.com> wrote:
>>
>> On Tue, May 2, 2017 at 4:28 PM, Vincent Massol <vinc...@massol.net> wrote:
>>
>>> Hi,
>>>
>>>> On 2 May 2017, at 16:05, Thomas Mortagne <thomas.morta...@xwiki.com>
>>> wrote:
>>>>
>>>> Hi devs,
>>>>
>>>> I'm currently working on a new package format to package a bunch of
>>>> extensions into a single file.
>>>>
>>>> The first use case is to make offline install easier. We can't count on
>>> all
>>>> in one XAR anymore (plus all in one XAR prduces very crappy extensions)
>>> so
>>>> I was thinking about providing a generic package containing all the
>>>> extensions you need in it. It will simply be a zip containing extensions
>>> in
>>>> the same format than Extension Manager local repository so that you can
>>>> unzip it it there (or later use some UI to "import" it).
>>>>
>>>> So now I need a name for this new package. Since extension descriptor
>>> file
>>>> extension is "xed" (for "XWiki Extension Descriptor") I was thinking
>>> about
>>>> naming it XEP (for "XWiki Extension Package"). Any better idea ?
>>>>
>>>> For now my plan is to provide the following:
>>>> * a new Maven handler for xep
>>>> * a new Maven mojo "xep" in the existing extension Maven plugin
>>>> * start using it with the new platform flavor which is supposed to
>>> replace
>>>> XE so that people can have something to use for offline installs
>>>>
>>>> WDYT ?
>>>
>>> Sounds good.
>>>
>>> Regarding the naming, assuming we need a file extension other than ZIP,
>>> "XWiki Extension Package” seems like a package for a single XWiki Extension.
>>>
>>> Some ideas. Why not something in the name that suggest it’s a repository.
>>>
>>> For example: XWiki Extension Repository Archive or XWiki Repository
>>> Archive for short, which, using a 3LA, would translate into XRA.
>>>
>>> XAR = XWiki Archive = a single extension
>>> XRA = XWiki Repository Archive = a repository of extensions = several
>>> extensions
>>>
>>> We could also have XWiki Extension Repository, i.e. “XER”, which would
>>> also be one letter change from XAR:
>>>
>>> XAR = XWiki Archive = a single extension
>>> XER = XWiki Extension Repository = a repository of extensions = several
>>> extensions
>>>
>>
>> I'm fine with XER.
>>
>>
>>> Now since the users will need to unzip this binary and they won’t import
>>> it (as they do for XAR), it would be better for it to be ZIP as otherwise
>>> it’ll harder to unzip (no double-clicking on it for ex).
>>>
>>
>> As I said I think we'll have a UI for it at some point. I just don't think
>> I will have time to work on that in the new platform flavor scope (or maybe
>> just a quick tool in
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Tweak).
> 
> I know you said that but IMO the primary usage is for users to unzip into a 
> given directory and the easiest is to provide a ZIP to them. Even if we have 
> an import UI, we can still offer the ZIP to that UI…
> 
> So at this point, I don’t fully understand why we’d need something other than 
> zip.
> 
> Sounds like we might be overcomplicated things. On the maven side, we could 
> use the maven assembly plugin to generate the zip.
> 
> Am I missing something?
> 
> Thanks
> -Vincent
> 
>> Thanks
>>> -Vincent
>>>
>>>>
>>>> --
>>>> Thomas Mortagne
>>>
>>>
>>
>>
>> -- 
>> Thomas Mortagne
> 


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

Re: [xwiki-devs] [PROPOSAL] Yet another new platform flavor proposal or how to get rid of XWiki Enterprise

[Sergiu Dumitriu]

On 04/15/2017 08:17 AM, Vincent Massol wrote:
> Hi Sergiu,
> 
>> On 15 Apr 2017, at 13:44, Sergiu Dumitriu <ser...@xwiki.org> wrote:
>>
>> On 04/14/2017 06:08 PM, Vincent Massol wrote:
>>>
>>>> On 14 Apr 2017, at 22:34, Sergiu Dumitriu <ser...@xwiki.org> wrote:
>>>>
>>>> On 04/14/2017 09:51 AM, Thomas Mortagne wrote:
>>>>> Here is a new proposal on this subject.
>>>>>
>>>>> This supersets the following threads:
>>>>> * http://markmail.org/message/mhhurc7lbyfanph7
>>>>> * http://markmail.org/message/nav5a77hzmhq4gq6
>>>>> * http://markmail.org/message/fd5ijxdquzdhtykw
>>>>>
>>>>> We discussed with other committers (Vincent and Ludovic) and came to
>>>>> the conclusion that it was not core dev team job to provide a specific
>>>>> flavor like Knowledge Base and that we should focus only on a very
>>>>> generic one (pretty much XE without the Blog).
>>>>>
>>>>> Here are the details:
>>>>>
>>>>> = One flavor
>>>>>
>>>>> We develop only 1 flavor located in xwiki-platform repository. It's a
>>>>> generic flavor not targeting any specific use case (the first version
>>>>> with be XE without the Blog). We will discuss the name in another
>>>>> thread later, let's call it "Wiki Flavor" for now.
>>>>>
>>>>> Of course everyone is free and welcomed to build lots of contrib
>>>>> flavors which will be proposed when you install XWiki ("Development
>>>>> Flavor", "Demo Flavor", "Blog Flavor", etc.).
>>>>>
>>>>> = No "Base flavor"
>>>>>
>>>>> But platform will provide an extension that can be used as dependency
>>>>> by various flavors to get "core" UI extensions that we think make
>>>>> sense in any kind of flavor.
>>>>>
>>>>> = Demo package
>>>>>
>>>>> We currently have a jetty/hsqldb based package in platform which let
>>>>> you choose which flavor you want. We will show it in the download
>>>>> page.
>>>>>
>>>>> We will add another one with the Wiki Flavor already installed in it
>>>>> (pretty much like the XE jetty/hsqldb package). Listed on the download
>>>>> page too.
>>>>
>>>> Why? Is it that bad to always let the user choose the flavor? We can
>>>> split flavors into three levels:
>>>>
>>>> - The "Raw XWiki" flavor is on top, pre-selected
>>>> - Recommended flavors are next, in a list
>>>> - All flavors behind a "browse more" button
>>>>
>>>> The only case when leaving the standalone package empty might fail is in
>>>> a no-internet environment, but for this we can have a workaround: make
>>>> the jars, xars and poms needed for installing the base flavor available
>>>> in the package.
>>>
>>> Yes the reason is for the offline test use case.
>>>
>>> Bundling all flavors could be a solution indeed but it seems a bit overkill 
>>> to me, especially if the user only wants a single one, don’t you think?
>>
>> Indeed, that's why I said "needed for installing the _base_ flavor". If
>> XWiki detects that it can't fetch the list of flavors from the internet,
>> instead of displaying the "select flavor to install" screen, it will
>> display an alternative "no internet connection detected, install a base
>> wiki or leave the wiki completely empty" screen.
> 
> Ok I get it. That could work but we would need to implement it and always use 
> the locally available flavor extensions even if there’s an internet 
> connection since installing from internet is much longer (several additional 
> minutes) and we need to offer the best possible testing/first-time experience.

Depending on how this is implemented, this can also solve another issue:
installing war snapshots. This is something that some of the PhenoTips
users have been asking about, and while possible, it's not as easy as
just putting the war in Tomcat and running the distribution wizard.

> And sponsoring companies must be also be able to provide a ZIP with their 
> flavor pre-installed or locally available. We would provide a link to their 
> page providing the download.
> 
> It could indeed save us one packaging.
> 
> @Thomas: WDYT?
> 
> Thanks
> -Vincent
> 
>> Thanks
>>> -Vincent
>>>
>>>> Everything else sounds good, +1.
>>>>
>>>>> We don't maintain exe/jar installers anymore in platform, they die
>>>>> with XWiki Enterprise. They are a real pain to maintain and we are
>>>>> actually failing since they don't really work properly everywhere they
>>>>> are supposed to work. It does not worth the trouble for what is not a
>>>>> production ready package and it's better anyway to make more clear
>>>>> XWiki is a server thing.
>>>>>
>>>>> WDYT ?
> 


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

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

Re: [xwiki-devs] [Proposal][UX] Explicit content actions

[Sergiu Dumitriu]

On 04/12/2017 01:47 PM, Ecaterina Moraru (Valica) wrote:
> Hi devs,
> 
> Some users have complained that the content actions are too abstract /
> ambiguous and they don't see/understand them so they don't know how to Edit
> or Create content in the first minutes of interaction.
> 
> More details about this problem can be found at
> http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaLabeledActions
> 
> There I've suggested 2 possible proposals:
> Proposal 1: JS Tooltips
> Proposal 2: Labeled actions
> 
> Which one do you prefer?
> 
> Thanks,
> Caty
> 
> P.S: This was a recurrent topic and we change several things over the
> years. I guess we will continue iterating until we reach the sweet spot :)
> 

IMHO, 1 doesn't solve anything. The buttons already have classic
tooltips, and adding "improved" tooltips adds little to the
discoverability of the actions. If someone is looking for the "edit"
button, they scan the screen for that text with their eyes, they
wouldn't just hover everything with the mouse.

So, the question is:

- is it better to clutter the screen to help a few first-time users that
can't interpret the pencil icon?
- is it OK to leave things as they are for a cleaner UI?
- are there better icons to suggest these actions? And by changing them
now, will current users be disoriented?

The deciding factor is exactly how many users have a problem with the
current UI.
-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/

Re: [xwiki-devs] [PROPOSAL] Yet another new platform flavor proposal or how to get rid of XWiki Enterprise

[Sergiu Dumitriu]

On 04/14/2017 06:08 PM, Vincent Massol wrote:
> 
>> On 14 Apr 2017, at 22:34, Sergiu Dumitriu <ser...@xwiki.org> wrote:
>>
>> On 04/14/2017 09:51 AM, Thomas Mortagne wrote:
>>> Here is a new proposal on this subject.
>>>
>>> This supersets the following threads:
>>> * http://markmail.org/message/mhhurc7lbyfanph7
>>> * http://markmail.org/message/nav5a77hzmhq4gq6
>>> * http://markmail.org/message/fd5ijxdquzdhtykw
>>>
>>> We discussed with other committers (Vincent and Ludovic) and came to
>>> the conclusion that it was not core dev team job to provide a specific
>>> flavor like Knowledge Base and that we should focus only on a very
>>> generic one (pretty much XE without the Blog).
>>>
>>> Here are the details:
>>>
>>> = One flavor
>>>
>>> We develop only 1 flavor located in xwiki-platform repository. It's a
>>> generic flavor not targeting any specific use case (the first version
>>> with be XE without the Blog). We will discuss the name in another
>>> thread later, let's call it "Wiki Flavor" for now.
>>>
>>> Of course everyone is free and welcomed to build lots of contrib
>>> flavors which will be proposed when you install XWiki ("Development
>>> Flavor", "Demo Flavor", "Blog Flavor", etc.).
>>>
>>> = No "Base flavor"
>>>
>>> But platform will provide an extension that can be used as dependency
>>> by various flavors to get "core" UI extensions that we think make
>>> sense in any kind of flavor.
>>>
>>> = Demo package
>>>
>>> We currently have a jetty/hsqldb based package in platform which let
>>> you choose which flavor you want. We will show it in the download
>>> page.
>>>
>>> We will add another one with the Wiki Flavor already installed in it
>>> (pretty much like the XE jetty/hsqldb package). Listed on the download
>>> page too.
>>
>> Why? Is it that bad to always let the user choose the flavor? We can
>> split flavors into three levels:
>>
>> - The "Raw XWiki" flavor is on top, pre-selected
>> - Recommended flavors are next, in a list
>> - All flavors behind a "browse more" button
>>
>> The only case when leaving the standalone package empty might fail is in
>> a no-internet environment, but for this we can have a workaround: make
>> the jars, xars and poms needed for installing the base flavor available
>> in the package.
> 
> Yes the reason is for the offline test use case.
> 
> Bundling all flavors could be a solution indeed but it seems a bit overkill 
> to me, especially if the user only wants a single one, don’t you think?

Indeed, that's why I said "needed for installing the _base_ flavor". If
XWiki detects that it can't fetch the list of flavors from the internet,
instead of displaying the "select flavor to install" screen, it will
display an alternative "no internet connection detected, install a base
wiki or leave the wiki completely empty" screen.

> Thanks
> -Vincent
> 
>> Everything else sounds good, +1.
>>
>>> We don't maintain exe/jar installers anymore in platform, they die
>>> with XWiki Enterprise. They are a real pain to maintain and we are
>>> actually failing since they don't really work properly everywhere they
>>> are supposed to work. It does not worth the trouble for what is not a
>>> production ready package and it's better anyway to make more clear
>>> XWiki is a server thing.
>>>
>>> WDYT ?
>>
>>
>> -- 
>> Sergiu Dumitriu
>> http://purl.org/net/sergiu/
> 


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

Re: [xwiki-devs] [PROPOSAL] Yet another new platform flavor proposal or how to get rid of XWiki Enterprise

[Sergiu Dumitriu]

On 04/14/2017 09:51 AM, Thomas Mortagne wrote:
> Here is a new proposal on this subject.
> 
> This supersets the following threads:
> * http://markmail.org/message/mhhurc7lbyfanph7
> * http://markmail.org/message/nav5a77hzmhq4gq6
> * http://markmail.org/message/fd5ijxdquzdhtykw
> 
> We discussed with other committers (Vincent and Ludovic) and came to
> the conclusion that it was not core dev team job to provide a specific
> flavor like Knowledge Base and that we should focus only on a very
> generic one (pretty much XE without the Blog).
> 
> Here are the details:
> 
> = One flavor
> 
> We develop only 1 flavor located in xwiki-platform repository. It's a
> generic flavor not targeting any specific use case (the first version
> with be XE without the Blog). We will discuss the name in another
> thread later, let's call it "Wiki Flavor" for now.
> 
> Of course everyone is free and welcomed to build lots of contrib
> flavors which will be proposed when you install XWiki ("Development
> Flavor", "Demo Flavor", "Blog Flavor", etc.).
> 
> = No "Base flavor"
> 
> But platform will provide an extension that can be used as dependency
> by various flavors to get "core" UI extensions that we think make
> sense in any kind of flavor.
> 
> = Demo package
> 
> We currently have a jetty/hsqldb based package in platform which let
> you choose which flavor you want. We will show it in the download
> page.
> 
> We will add another one with the Wiki Flavor already installed in it
> (pretty much like the XE jetty/hsqldb package). Listed on the download
> page too.

Why? Is it that bad to always let the user choose the flavor? We can
split flavors into three levels:

- The "Raw XWiki" flavor is on top, pre-selected
- Recommended flavors are next, in a list
- All flavors behind a "browse more" button

The only case when leaving the standalone package empty might fail is in
a no-internet environment, but for this we can have a workaround: make
the jars, xars and poms needed for installing the base flavor available
in the package.

Everything else sounds good, +1.

> We don't maintain exe/jar installers anymore in platform, they die
> with XWiki Enterprise. They are a real pain to maintain and we are
> actually failing since they don't really work properly everywhere they
> are supposed to work. It does not worth the trouble for what is not a
> production ready package and it's better anyway to make more clear
> XWiki is a server thing.
> 
> WDYT ?


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

Re: [xwiki-devs] [VOTE] Move from our mailing lists and use Discourse instead

[Sergiu Dumitriu]

Looked over the features, seems to cover most of my concerns except one:
migrating the current mailing list archives (at least I couldn't see it
in the features list). Do we care about that? Can it be scripted using
the API?

Anyway, +1.

On 02/24/2017 06:18 AM, Vincent Massol wrote:
> Hi devs,
> 
> I’m proposing to vote for moving away from our users and devs mailing list 
> and instead to use the Discourse open source tool:
> 
> * Home page: http://www.discourse.org/
> * License: GPL v2
> * FAQ: http://www.discourse.org/faq/
> * Awesome feature list: http://www.discourse.org/about/
> 
> What is especially interesting for us:
> * It works with mailing lists (you can receive mails and send mails to the 
> forum).
> * Works as a forum. BTW if you want to see a real life instance, check the 
> gradle instance at https://discuss.gradle.org/
> 
> Nice things:
> * Works on mobile
> * Comprehensive API (would allow us to integrate it with xwiki.org)
> * Badges/user metrics
> 
> So here’s my +1 to try it out and ask XWiki SAS if they could host an 
> instance.
> 
> WDYT? Do you see any negative point (I don’t ATM)? :)
> 
> Please cast your votes!
> 
> Thanks
> -Vincent
> 


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

Re: [xwiki-devs] [Proposal] Use to improve the HTML produced by the XHTML renderer for tables

[Sergiu Dumitriu]

Note that only one  is allowed, but in our wiki markup we can use
as many header rows and cells as we want. And it's not guaranteed that
the first row only has header cells. For example, what should happen
with the following table:

|=head|normal cell
|normal cell|=head

So, I'm +1 for the following rule:

If the table starts with one or more rows containing only header cells,
then put those rows in a . If the table ends with one or more
rows containing only header cells, then put those rows in a . If
other header cells are encountered in the table, or if the first/last
row contains both header and regular cells, then those cells are put as
 cells in a regular  row.

Not sure what to do with: if the table contains only header cells, then...?

On 02/19/2017 05:35 AM, Vincent Massol wrote:
> Hi devs,
> 
> For the following XWiki Syntax 2.1 input:
> 
> |=head11|=head12
> |cell11|cell12
> 
> We generate the following XHTML 1.0 output:
> 
> 
>   
> 
>   head11
>   head12
> 
> 
>   cell11
>   cell12
> 
>   
> 
> 
> I think it would be better to generate:
> 
> 
>   
> 
>   head11
>   head12
> 
>   
>   
> 
>   cell11
>   cell12
> 
>   
> 
> 
> Arguments:
> 
> * More standard. 
> * In addition I read I the XHTML spec that "Table rows may be grouped into a 
> table head, table foot, and one or more table body sections, using the thead, 
> tfoot and tbody elements, respectively. This division enables user agents to 
> support scrolling of table bodies independently of the table head and foot. 
> When long tables are printed, the table head and foot information may be 
> repeated on each page that contains table data.”
> 
> I haven’t checked but hopefully it should relatively painless for our CSS 
> (unless we use a rule for tbody/tr/th instead of tr/th or th). However even 
> if it changes our CSS I still fee it’s the right thing to do with a note in 
> the Release Notes for the unlikely chances that it would break something.
> 
> Note tat
> I know that for example for the 
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Datatables+Macro 
> extension, we cannot use xwiki syntax because of this issue (this is why the 
> example is using the html macro).
> 
> WDYT?
> 
> Thanks
> -Vincent
> 
> PS: our XHTML parser already supports this as can be verified with the 
> following test:
> 
> {{groovy}}
> def input = '''
> 
>   
> 
>   head11
>   head12
> 
>   
>   
>     
>   cell11
>   cell12
> 
>   
> 
> '''
> def xdom = services.rendering.parse(input, 'xhtml/1.0')
> println "{{{"
> println services.rendering.render(xdom, 'xwiki/2.1')
> println "}}}"
> {{/groovy}}
> 
> 
> 
> 
> 


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

Re: [xwiki-devs] Help Center

[Sergiu Dumitriu]

On 02/09/2017 09:54 AM, Marius Dumitru Florea wrote:
> On Thu, Feb 9, 2017 at 4:31 PM, Vincent Massol <vinc...@massol.net> wrote:
> 
>> 1) What are those 4 gifs doing? Do they require maintenance? Can we reduce
>> their size?
>>
> 
> Caty used a tool (I don't remember the name) to record the steps needed to
> perform some action (e.g. insert and edit a wiki macro through the WYSIWYG)
> as a GIF. Similar to what Guillaume did for
> http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/8.4.2/#HLocalizationSection
> . Now, I see that Guillaume's GIF is 400kb (compared to Caty's 2-3Mb) so
> maybe there's a way to generate smaller GIFs, but it may require reducing
> the quality. In any case, I think they are useful, but they do require
> maintenance..
> 

gifsicle does lossless GIF optimization, give it a try.

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

Re: [xwiki-devs] So what do we do about https://jira.xwiki.org/browse/XWIKI-14016

[Sergiu Dumitriu]

On 02/08/2017 10:05 AM, Thomas Mortagne wrote:
> On Wed, Feb 8, 2017 at 3:53 PM, Sergiu Dumitriu <ser...@xwiki.org> wrote:
>> I wouldn't want to have empty revisions.
>>
>> If you want to change the import, then you can manually call
>> doc.setContentDirty(true).
> 
> "So the question is do we force metadata dirty to true all the time in
> the instance output filter"
> 
> Again the subject here is default import mode only. We are not talking
> about XWiki#saveDocument and I would be -1 to force new revision all
> the time since we have use cases for this.

Yep, and I was agreeing.

>>
>> On 02/08/2017 08:33 AM, Thomas Mortagne wrote:
>>> Hi devs,
>>>
>>> We have a unintended regression in the standard import: if what you
>>> import is identical to what is already in the database (including the
>>> author) it won't add a new version (if you use the default option "Add
>>> a new version to the existing page").
>>>
>>> What happen in practice is that if you keep calling XWikiDocument#set*
>>> methods with the same data it won't update the metadata or content
>>> dirty flags. This flags are what hibernate store look at to know if it
>>> should add a new version or not.
>>>
>>> You can reproduce the same behavior with a simple script which load a
>>> document, always set the same content and save. You will notice that
>>> the history of that document does not change.
>>>
>>> So the question is do we force metadata dirty to true all the time in
>>> the instance output filter or do we keep this feature (in which case
>>> we should optimize it a bit to not do the useless XWiki#saveDocument
>>> but that's another subject).
>>>
>>> WDYT ?
>>>
>>> It could be seen as a nice feature but in practice my first reaction
>>> was WTF and you often want to be sure the import actually did
>>> something so I'm +1 to force metadata dirty. But I'm +0 to keep the
>>> current behavior if there is a majority for it.
>>>
>>
>>
>> --
>> Sergiu Dumitriu
>> http://purl.org/net/sergiu
> 
> 
> 


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

Re: [xwiki-devs] So what do we do about https://jira.xwiki.org/browse/XWIKI-14016

[Sergiu Dumitriu]

I wouldn't want to have empty revisions.

If you want to change the import, then you can manually call
doc.setContentDirty(true).

On 02/08/2017 08:33 AM, Thomas Mortagne wrote:
> Hi devs,
> 
> We have a unintended regression in the standard import: if what you
> import is identical to what is already in the database (including the
> author) it won't add a new version (if you use the default option "Add
> a new version to the existing page").
> 
> What happen in practice is that if you keep calling XWikiDocument#set*
> methods with the same data it won't update the metadata or content
> dirty flags. This flags are what hibernate store look at to know if it
> should add a new version or not.
> 
> You can reproduce the same behavior with a simple script which load a
> document, always set the same content and save. You will notice that
> the history of that document does not change.
> 
> So the question is do we force metadata dirty to true all the time in
> the instance output filter or do we keep this feature (in which case
> we should optimize it a bit to not do the useless XWiki#saveDocument
> but that's another subject).
> 
> WDYT ?
> 
> It could be seen as a nice feature but in practice my first reaction
> was WTF and you often want to be sure the import actually did
> something so I'm +1 to force metadata dirty. But I'm +0 to keep the
> current behavior if there is a majority for it.
> 


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

Re: [xwiki-devs] [Proposal] Extend the ack section of the Release Notes

[Sergiu Dumitriu]

Same as Thomas.

On 02/06/2017 04:39 AM, Thomas Mortagne wrote:
> +1 for adding any source of contributions as long as it's automated or
> close to automated (like executing one command/request and
> copy/pasting the result)
> 
> On Mon, Feb 6, 2017 at 10:26 AM, Marius Dumitru Florea
> <mariusdumitru.flo...@xwiki.com> wrote:
>> +1
>>
>> Thanks,
>> Marius
>>
>> On Sun, Feb 5, 2017 at 12:07 PM, Vincent Massol <vinc...@massol.net> wrote:
>>
>>> Hi devs,
>>>
>>> Right now we’ve started acknowledging the committers in the Release notes.
>>>
>>> I’d like to propose to extend that try to ack everyone who participates in
>>> one way or another to a release, and not just developers.
>>>
>>> I can think of 3 more items to add:
>>>
>>> A) All the JIRA issue reporters that have had an issue fixed for the
>>> release (bug, improvement, new feature, etc). They took the time to report
>>> an issue and thus they’ve helped the committers to improve the quality of
>>> the release and thus they should be acknowledged. This allows us to also
>>> ack QA. We could decide to exclude the reporters who’ve also been
>>> committers or leave them in.
>>>
>>> B) The people who’ve contributed translations done after the start of the
>>> release development.
>>>
>>> Ideally we would also ack:
>>>
>>> C) The people who’ve helped on the list for the release
>>> D) The people who’ve helped on the Design and made proposals that made it
>>> to the release. I’m thinking of Caty for example. Luckily Caty also commits
>>> some code and often she’s recognised through commits.
>>>
>>> The problem with C) and D) is that they’re hard to gather. But we could do
>>> it on an ad-hoc basis by adding them to the RN during the development (when
>>> they help) instead of doing it at the end.
>>>
>>> In any case I’d like to focus on A) and B) FTM and I’m proposing to add
>>> them to the Release Plan since they’re easy to find out.
>>>
>>> WDYT?
>>>
>>> Thanks
>>> -Vincent
>>>
>>>
> 
> 
> 


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

Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Sergiu Dumitriu]

er .commenttools a
a.tag-delete
.tag-add a

>> #commentform, .xwikitabbar li, #Historyshortcut, #Informationshortcut,
>> .separator,
>> .commentheader .commenttools a, a.tag-delete , .tag-add a {
>>   display: none !important;
>> }
>>
>> * Browser-dependent result. True. In addition we’d need to ensure that
>> browser offer a print to PDF feature. I know this is true on Mac and also
>> on FF in unix (on Thomas’s computer and I think Thomas told me he didn’t
>> have any add on). Haven’t checked other combinations. Denis mentioned that
>> it’s not the default in Windows < 10.
>>
>> Research
>> 
>>
>> The following alternatives to FOP exist but have their own limitations
>> (see Denis answer for details):
>> * PDF Clown
>> * PDFBox
>> * wkhtmltopdf
>> * pdfkit
>> * iText
>> * Flying saucer, see http://flyingsaucerproject.github.io/flyingsaucer/r8/
>> guide/users-guide-R8.html#pdf
>>
>> Conclusions
>> =
>>
>> I feel there are several main use cases:
>>
>> * Wanting to print the current page. The browser print feature could work
>> fine for this if we were to improve a bit our print.css (inherit from
>> view.css for example)
>> * Wanting to have some professional quality PDF export. There’s no doubt
>> that the best solution for this is ATM our FOP-based PDF export and w
>> * Scripted PDF exports (to generate invoices automatically for example).
>> Again our FOP-based PDF export is the best answer.
>>
>> So I agree with all of you who said that CSS3-page is not ready yet. The
>> FOP2 spec has been stopped and the future seems to be CSS3-page but it’s
>> not moving fast right now.
>>
>> So I propose that we:
>> * Marginally improve our print.css for page printing
>> * Continue to improve our FOP-based solution and possibly send PR to this
>> project and if they’re not applied quick-enough, then fork it and took some
>> ownership of it. However we just need to acknowledge that this is going to
>> be substantial work and we still have a sizeable number of open issue for
>> the PDF generation.
>>
> 
> For tables layouting (XWIKI-5627), which seems to be our biggest problem
> right now, i've seen implemented, in the past, some control the sizes of
> the columns, but "manually" - as in, the size would not be computed
> automatically depending on the content of the table. Set in a certain way
> (I need to remember exactly how), the sizes of the columns can be imposed
> to the pdf.
> So, if table autolayout is such a pain (and there is serious proof to
> support that it is), maybe we can offer a intermediate solution, such as a
> "helper" for the user preparing the document: something like a macro or
> even a wiki syntax snippet or something, that users could use to control
> the sizes of the columns of a specific table. This would obviously not
> cover all cases, but I think it could cover the usecase of Olivier Seres
> (afaik the usecase is something like this: "he prepared a document for
> print, he wanted to print it and realized that the tables were incorrect on
> print". From my point of view, using this macro or snippet could be part of
> the preparation of a document for print, and we could have it by default in
> the wiki - if it's a macro - or as an FAQ if it's a snippet).
> Lemme know if you're interested in this idea, as I will need to try to find
> the code we used to do this.
> 
> Thanks,
> Anca
> 
> 
>>
>> Thanks
>> -Vincent
>>
>>> On 18 Jan 2017, at 14:54, Vincent Massol <vinc...@massol.net> wrote:
>>>
>>> Hi devs,
>>>
>>> We have plenty of existing limitations in our PDF export (table
>> autoresize, etc) which comes from FOP and our usage of it. And it’s hard to
>> improve it.
>>>
>>> I’d like to propose the following:
>>>
>>> * Promote the browser’s print to PDF feature instead of our PDF Export
>> by triggering the browser’s print feature when clicking on Export > PDF in
>> the UI.
>>> * Work on our print.css so that it has all the styles we have in view
>> mode (right now for ex, info boxes for ex do not have a nice style).
>>> * Move our PDF Export java code out of xwiki-platform and into an
>> optional extension that we move into xwiki-contrib. The use case for it
>> would be when you need to generate PDF from scripts.
>>>
>>> WDYT?
>>>
>>> Thanks
>>> -Vincent
>>
>>


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

Re: [xwiki-devs] [VOTE] Move all Confuence related modules to contrib

[Sergiu Dumitriu]

On 01/25/2017 10:53 AM, Thomas Mortagne wrote:
> Hi devs,
> 
> I would like to give Confluence filter input and syntaxes modules
> there own life on xwiki-contrib pretty much on the same model than
> what I did for MediaWiki (https://github.com/xwiki-contrib/mediawiki/)
> since it's exactly the same use case.
> 
> The main reasons are:
> * those modules are not embedded (for the input) or enabled (for the
> syntaxes) by default
> * those modules need to follow Confluence evolution more than XWiki
> 
> WDYT ?
> 
> Here is my +1
> 

+1 as well. Extra syntaxes are a nice bragging point, but having them in
the package by default is just bloatware.

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

Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Sergiu Dumitriu]

On 01/18/2017 03:43 PM, Vincent Massol wrote:
> 
>> On 18 Jan 2017, at 21:23, Sergiu Dumitriu <ser...@xwiki.org> wrote:
>>
>> I think this is a good idea for the future, but not right now. There are
>> several things that current browsers don't support yet, such as the
>> ability to specify page size and orientation
> 
> I’ve just tested it and I could select the orientation, paper size, margins, 
> whether header/footers are printed, etc.

It's not about selecting them manually from the browser, but specifying
it in the CSS. The CSS print module contains rules for this, but not all
browsers implement them.

>> , setting custom headers and
>> footers, and we'd need to work more to generate the cover and ToC. With
>> FOP we can control exactly how things work in all browsers, while
>> leaving this part to the browser is guaranteed to lead to inconsistent
>> and buggy output.
> 
> Well that’s the problem and the reason why I sent this email: right now FOP 
> doesn’t allow us to control much because it’s limited and buggy. We have 
> plenty of open jira issues related to FOP and we’ve worked hard (too hard) to 
> fix issues in the past and we’re stuck on several of them (I can think of 
> table auto layout).
>
> When I’ve tried to export a wiki page both with the browser print button and 
> with our PDF export, I’ve had a better result (by better I mean that 
> corresponds more to what the user is viewing) with the browser print button. 
> Of course our print.css is lacking a lot of styles but that’s easily fixable 
> (BTW I don’t understand why we don’t use view styles by default, most of them 
> should work just fine).
> 
> The other advantage is that browsers work all the time to improve this and 
> thus we delegate the work to them (we reduce our maintenance).
> 
> Note that I’m not suggesting to drop what we’re doing now but to not make it 
> the default since it’s of lower quality than the browser print result.

"Better quality" is subjective... But with enough work on either side
(pdf.css or print.css) we can improve the look of the PDF. The main
problem is that nobody considered it a high enough priority to spend
time on making the PDF look nice. At a hackathon during 2012's XWiki
seminar, IIRC, there was some work for this, but I don't think that ever
got committed.

Long term, it does make sense to stop spending time on the FOP export
and into browser's print stylesheet.

> What we could  do right now is:
> * Run some factual tests on various wiki pages and compare them with both 
> solutions and see which are best.
> * Quickly try to improve our print.css to match our style.css more.

print.css shouldn't be an alternative to style.css, but something on top
of it, improving certain things for printing.

> Thanks
> -Vincent
> 
>> On 01/18/2017 08:54 AM, Vincent Massol wrote:
>>> Hi devs,
>>>
>>> We have plenty of existing limitations in our PDF export (table autoresize, 
>>> etc) which comes from FOP and our usage of it. And it’s hard to improve it.
>>>
>>> I’d like to propose the following:
>>>
>>> * Promote the browser’s print to PDF feature instead of our PDF Export by 
>>> triggering the browser’s print feature when clicking on Export > PDF in the 
>>> UI.
>>> * Work on our print.css so that it has all the styles we have in view mode 
>>> (right now for ex, info boxes for ex do not have a nice style).
>>> * Move our PDF Export java code out of xwiki-platform and into an optional 
>>> extension that we move into xwiki-contrib. The use case for it would be 
>>> when you need to generate PDF from scripts.
>>>
>>> WDYT?
>>>
>>> Thanks
>>> -Vincent
>>>
>>
>>
>> -- 
>> Sergiu Dumitriu
>> http://purl.org/net/sergiu
> 


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

Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Sergiu Dumitriu]

On 01/18/2017 12:05 PM, Anca Luca wrote:
> For the problems of Apache FOP, does anyone have any idea what libraries do
> other software use for this kind of functionality? (maybe there is a more
> cool lib that we haven't found out about)

There are commercial alternatives, but those are out of the question due
to the license.

There's the programmatic PDF generation option with PDFBox, but that
will require a MAJOR redesign of the export.

Then there's the option of building our own patched version of FOP with
https://issues.apache.org/jira/browse/FOP-2469 included. It wouldn't be
the first time we use a patched library, and it seems to be the solution
with the least amount of work needed.

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

Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Sergiu Dumitriu]

I think this is a good idea for the future, but not right now. There are
several things that current browsers don't support yet, such as the
ability to specify page size and orientation, setting custom headers and
footers, and we'd need to work more to generate the cover and ToC. With
FOP we can control exactly how things work in all browsers, while
leaving this part to the browser is guaranteed to lead to inconsistent
and buggy output.

On 01/18/2017 08:54 AM, Vincent Massol wrote:
> Hi devs,
> 
> We have plenty of existing limitations in our PDF export (table autoresize, 
> etc) which comes from FOP and our usage of it. And it’s hard to improve it.
> 
> I’d like to propose the following:
> 
> * Promote the browser’s print to PDF feature instead of our PDF Export by 
> triggering the browser’s print feature when clicking on Export > PDF in the 
> UI.
> * Work on our print.css so that it has all the styles we have in view mode 
> (right now for ex, info boxes for ex do not have a nice style).
> * Move our PDF Export java code out of xwiki-platform and into an optional 
> extension that we move into xwiki-contrib. The use case for it would be when 
> you need to generate PDF from scripts.
> 
> WDYT?
> 
> Thanks
> -Vincent
> 


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

Re: [xwiki-devs] [PROPOSAL] Make extension pages author superadmin when current user have programming right

[Sergiu Dumitriu]

Oh, forgot this one:

system::migrator(R8XWIKI12345)
system::extension-upgrade(org.xwiki.contrib:cool-app:1.2.3)
system::password-reset(ip:1.2.3.4)

On 01/17/2017 02:14 PM, Sergiu Dumitriu wrote:
> I'd like something more complex, and more flexible at the same time.
> Instead of having simple user names, I'd like to see a more powerful
> "principal" mechanism in XWiki, with roles and delegates.
> 
> A first usecase is separating users and their admin privileges. Instead
> of automatically granting admin privileges to users all the time, there
> should be a "sudo" equivalent. This gives a bit of safety against
> cross-XYZ / XYZ-injection attacks, since normally a user browsing the
> wiki wouldn't have admin/scripting/programming privileges, unless
> manually entering "admin mode". There wouldn't be an "Admin" user
> anymore, just users that can switch to "Administrator" mode, and this
> would be recorded as (for example):
> 
> delegate::role(user::xwiki:Users.jdoe|role::administrator)
> delegate::role(user::xwiki:Users.jdoe|role::developer)
> 
> When asking for the current principal, this is what would be returned,
> and stored as the author of a document after a change. We still know
> that it was "jdoe" performing the changes. Checking for scripting rights
> later is done both on the source user (if it's denied) and on the target
> role (if it's allowed).
> 
> return  ? false : 
> 
> 
> Another usecase would be an admin logging in as another user, to
> experience what the user sees without having to ask (or temporarily
> change) the user's password. Jira has this feature, and it's very useful
> for debugging rights. This can also be recorded as a delegate principal:
> 
> delegate::su(user::xwiki:Users.tanderson|user::xwiki:Users.neo)
> 
> 
> A third usecase, which doesn't make much sense in the base XWiki, but
> which is needed in more complex applications where there's a more
> pronounced emphasis on groups, is when a group member acts on behalf of
> the group:
> 
> delegate::member(user::xwiki:Users.padams|group::xwiki.Groups.Pediatricians)
> 
> Here, Patch Adams is acting on behalf of the group of pediatricians when
> writing a press release.
> 
> 
> Another one: more info about guests. Instead of pretending that there's
> only one special "XWikiGuest" user, we can record more information:
> 
> role::guest(ip:192.168.0.123|visit:42)
> 
> Later, we can see everything this guest did.
> 
> 
> That's on the "who am I" end, but this also extends to "who should I be"
> part, i.e. setting rights for special roles.
> 
> allow admin for role::administrator
> allow scripting for role::developer
> deny scripting for group::xwiki:Groups.TheBadGuys
> allow delete for role::creator
> deny view for role::guest
> allow sudo for group::xwiki:Groups.Administrators
> deny vote for karma::lt(100)
> 
> The last one shows that the types of principals can be customized by new
> component implementations, and evaluating if the current principal
> matches a target principal can be more complex than what's there now,
> "is the same user" or "is member of a group". Also, the rights should be
> extensible, right now adding a new right is not impossible, but not very
> easy either.
> 
> I've been working on designing and implementing this on and off for the
> past year, but there's still a long way to go.
> 
> 
> Just some food for thought, -0 for the proposed change.
> 
> On 01/17/2017 10:54 AM, Thomas Mortagne wrote:
>> Hi devs,
>>
>> I'm thinking since a long time that maybe we should automatically make
>> superadmin the author of the pages when installing a XAR as long as
>> the current user (and current author) have programming right (i.e. has
>> the same rights than superadmin when the extension is installed). I
>> don't really see anything against it these days and it's easy to do so
>> why not.
>>
>> Basically the goal is to reduce the possibility to break extensions
>> when you play with existing users/groups/rights. Common user case
>> being to get rid of some old adminsys leaving the company.
>>
>> WDYT ?
>>
>> Note: to be complete we could imagine the same kind of thing for admin
>> user but that require the introduction of a virtual admin right user
>> like superadmin is a vitual programming right user. But let's not
>> discuss too many thing at once.
>>
> 
> 


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

Re: [xwiki-devs] [PROPOSAL] Make extension pages author superadmin when current user have programming right

[Sergiu Dumitriu]

I'd like something more complex, and more flexible at the same time.
Instead of having simple user names, I'd like to see a more powerful
"principal" mechanism in XWiki, with roles and delegates.

A first usecase is separating users and their admin privileges. Instead
of automatically granting admin privileges to users all the time, there
should be a "sudo" equivalent. This gives a bit of safety against
cross-XYZ / XYZ-injection attacks, since normally a user browsing the
wiki wouldn't have admin/scripting/programming privileges, unless
manually entering "admin mode". There wouldn't be an "Admin" user
anymore, just users that can switch to "Administrator" mode, and this
would be recorded as (for example):

delegate::role(user::xwiki:Users.jdoe|role::administrator)
delegate::role(user::xwiki:Users.jdoe|role::developer)

When asking for the current principal, this is what would be returned,
and stored as the author of a document after a change. We still know
that it was "jdoe" performing the changes. Checking for scripting rights
later is done both on the source user (if it's denied) and on the target
role (if it's allowed).

return  ? false : 


Another usecase would be an admin logging in as another user, to
experience what the user sees without having to ask (or temporarily
change) the user's password. Jira has this feature, and it's very useful
for debugging rights. This can also be recorded as a delegate principal:

delegate::su(user::xwiki:Users.tanderson|user::xwiki:Users.neo)


A third usecase, which doesn't make much sense in the base XWiki, but
which is needed in more complex applications where there's a more
pronounced emphasis on groups, is when a group member acts on behalf of
the group:

delegate::member(user::xwiki:Users.padams|group::xwiki.Groups.Pediatricians)

Here, Patch Adams is acting on behalf of the group of pediatricians when
writing a press release.


Another one: more info about guests. Instead of pretending that there's
only one special "XWikiGuest" user, we can record more information:

role::guest(ip:192.168.0.123|visit:42)

Later, we can see everything this guest did.


That's on the "who am I" end, but this also extends to "who should I be"
part, i.e. setting rights for special roles.

allow admin for role::administrator
allow scripting for role::developer
deny scripting for group::xwiki:Groups.TheBadGuys
allow delete for role::creator
deny view for role::guest
allow sudo for group::xwiki:Groups.Administrators
deny vote for karma::lt(100)

The last one shows that the types of principals can be customized by new
component implementations, and evaluating if the current principal
matches a target principal can be more complex than what's there now,
"is the same user" or "is member of a group". Also, the rights should be
extensible, right now adding a new right is not impossible, but not very
easy either.

I've been working on designing and implementing this on and off for the
past year, but there's still a long way to go.


Just some food for thought, -0 for the proposed change.

On 01/17/2017 10:54 AM, Thomas Mortagne wrote:
> Hi devs,
> 
> I'm thinking since a long time that maybe we should automatically make
> superadmin the author of the pages when installing a XAR as long as
> the current user (and current author) have programming right (i.e. has
> the same rights than superadmin when the extension is installed). I
> don't really see anything against it these days and it's easy to do so
> why not.
> 
> Basically the goal is to reduce the possibility to break extensions
> when you play with existing users/groups/rights. Common user case
> being to get rid of some old adminsys leaving the company.
> 
> WDYT ?
> 
> Note: to be complete we could imagine the same kind of thing for admin
> user but that require the introduction of a virtual admin right user
> like superadmin is a vitual programming right user. But let's not
> discuss too many thing at once.
> 


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

Re: [xwiki-devs] Finding the oldest commit of XWiki in git?

[Sergiu Dumitriu]

Here's a bit of trivia, the first version of XWiki had less than 6MB
(uncompressed and including its libraries).

On 01/10/2017 03:17 AM, Sergiu Dumitriu wrote:
> That is indeed the first commit that can be traced from master, but you
> can get to the older history by checking the log of older tags. For
> example: "git log XWIKI_1_0_0" shows commits starting with 2005-04-15,
> when you did another directory reorganization, while "git log
> XWIKI_0_1_10" goes back to 2003-12-15, a commit named "Initial revision"
> (yay!).
> 
> The problem is that things kept changing in SVN, from /trunk to
> /trunk/xwiki to /xwiki/trunk and then to /xwiki-platform/trunk, and
> while git can detect most SVN renames, I guess this kind of transitions
> really confused the migration process.
> 
> On 01/09/2017 11:33 AM, Vincent Massol wrote:
>> Hi devs,
>>
>> I was trying to find the oldest commit and couldn’t. Maybe we made a mistake 
>> while moving from CVS to SVN and then from SVN to Git at some point?
>>
>> On xwiki-platform, running “git log —reverse” gives me as the oldest:
>>
>> "
>> commit fd92841151ac9d81da39babdb82516dbb7e4add7
>> Author: vmassol <vinc...@massol.net>
>> Date:   Fri Oct 13 13:57:10 2006 +
>>
>> XWIKI-12: Reorganize directory structure to match Maven2 best practices 
>> and cleanup build
>> 
>> * Started creating the core/ module and added the first version of a m2 
>> build.
>> * Please note that that the m2 is NOT working at this time as more work 
>> needs to be done to sort out the dependencies.
>> * I'm committing this to show to everyone the path I'm taking, to gather 
>> comments and possibly help too... :-)
>> 
>> git-svn-id: https://svn.xwiki.org/svnroot/xwiki/xwiki/trunk/core@1387 
>> f329d543-caf0-0310-9063-dda96c69346f
>> “
>>
>> But this is definitely not the oldest. There are commits from Ludo in 2003. 
>> We used to be able to see them in svnsearch but that service has been 
>> decommissioned. On 
>> https://web.archive.org/web/20130625112738/http://svnsearch.org/svnsearch/repos/XWIKI/search
>>  we can still see that there were 7 commits in Dec 2003 for example.
>>
>> So my guess right now is that we lost history at some point. Is that so?
>>
>> Thanks
>> -Vincent
>>
> 
> 


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

Re: [xwiki-devs] Finding the oldest commit of XWiki in git?

[Sergiu Dumitriu]

That is indeed the first commit that can be traced from master, but you
can get to the older history by checking the log of older tags. For
example: "git log XWIKI_1_0_0" shows commits starting with 2005-04-15,
when you did another directory reorganization, while "git log
XWIKI_0_1_10" goes back to 2003-12-15, a commit named "Initial revision"
(yay!).

The problem is that things kept changing in SVN, from /trunk to
/trunk/xwiki to /xwiki/trunk and then to /xwiki-platform/trunk, and
while git can detect most SVN renames, I guess this kind of transitions
really confused the migration process.

On 01/09/2017 11:33 AM, Vincent Massol wrote:
> Hi devs,
> 
> I was trying to find the oldest commit and couldn’t. Maybe we made a mistake 
> while moving from CVS to SVN and then from SVN to Git at some point?
> 
> On xwiki-platform, running “git log —reverse” gives me as the oldest:
> 
> "
> commit fd92841151ac9d81da39babdb82516dbb7e4add7
> Author: vmassol <vinc...@massol.net>
> Date:   Fri Oct 13 13:57:10 2006 +
> 
> XWIKI-12: Reorganize directory structure to match Maven2 best practices 
> and cleanup build
> 
> * Started creating the core/ module and added the first version of a m2 
> build.
> * Please note that that the m2 is NOT working at this time as more work 
> needs to be done to sort out the dependencies.
> * I'm committing this to show to everyone the path I'm taking, to gather 
> comments and possibly help too... :-)
> 
> git-svn-id: https://svn.xwiki.org/svnroot/xwiki/xwiki/trunk/core@1387 
> f329d543-caf0-0310-9063-dda96c69346f
> “
> 
> But this is definitely not the oldest. There are commits from Ludo in 2003. 
> We used to be able to see them in svnsearch but that service has been 
> decommissioned. On 
> https://web.archive.org/web/20130625112738/http://svnsearch.org/svnsearch/repos/XWIKI/search
>  we can still see that there were 7 commits in Dec 2003 for example.
> 
> So my guess right now is that we lost history at some point. Is that so?
> 
> Thanks
> -Vincent
> 


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

Re: [xwiki-devs] [xwiki-users] [UX][Proposal] Administration Overview

[Sergiu Dumitriu]

Ah, finally something useful instead of duplicating the menu. Some
suggestions:

- The version alone is not enough; which product, and what flavor?

- The proposed status is too "static", IMHO. It describes the size of
the wiki, but not its health. I'd like to see active status as well:
* 123 users (3 active in the last week)
** Perhaps also mention groups?
* 67 pages (7 updated in the last week)
* 12324 page views (143 in the last week)
* 562 visitors (42 in the past week)
* Top 10 popular pages
I know that not all this information is easy to compute (or even
possible), so it's just a "nice to have" list

- This should be extensible, so that extensions can add their own
summary information.

- Should apps be allowed to list their own summary? Like: "23 blog posts
(2 new in the last week)" if the blog application is installed.

- Typo: paid, not payed

- What exactly is the community address? Is it the users list, or
something new?

- It would be nice to display security information here:
* Updates available
* Weak settings (the Admin password is still "admin", "superadmin" is
enabled, cookie encryption keys are not randomized, public comments
enabled...)
* Many failed passwords detected
* Comment spam detected

On 12/09/2016 11:05 AM, Ecaterina Moraru (Valica) wrote:
> http://design.xwiki.org/xwiki/bin/view/Proposal/AdministrationOverview
> 
> On Fri, Dec 9, 2016 at 6:04 PM, Ecaterina Moraru (Valica) <vali...@gmail.com
>> wrote:
> 
>> Hi,
>>
>> This is a idea proposal for an Administration Overview that:
>> A. Provides generic/global information about the instance like 'version',
>> 'instance id', etc.
>> B. Provides a summary of usage listing count of major entities (wikis,
>> users, pages, extensions, etc.)
>> C. Lists demo content installed in the wiki
>> D. Provides a way for administrators to subscribe to the XWiki Community
>>
>> I'm curios which of the above section sounds interesting to you and would
>> like to see inside the product. Also maybe you have other ideas of what is
>> missing or could be represented better.
>>
>> Thanks,
>> Caty
>>


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

Re: [xwiki-devs] [BackwardCompatibility] Breakage in translations for Copy/Rename/Move

[Sergiu Dumitriu]

This has been there for a lng time:
http://dev.xwiki.org/xwiki/bin/Community/L10N+Conventions#HUpdatingtranslations

On 12/08/2016 07:46 AM, Vincent Massol wrote:
> Hi devs,
> 
> The story
> 
> 
> 1) We introduced some new translations keys in 
> https://github.com/xwiki/xwiki-platform/commit/5c50e2e88bb7cf592c1ecedcf0f34781e1fbc81f#diff-fffbf37334c4d7a178b13f4ccc313f86R746
> 
> That was done in XWIKI-12431 (Adapt the "rename" action for nested 
> documents), i.e. in 7.2M3
> 
> 2) We modified the keys in 
> https://github.com/xwiki/xwiki-platform/commit/12ec17d1c486935162581d47bbf1077693c401e6
> 
> That was done in XWIKI-13067 ("Rename: Change the label to make it clear that 
> both links and backlinks are updated or have 2 separate options”), i.e. in 
> XWiki 8.0-rc-1, 7.4.3
> 
> 3) The consequence is that all translations got broken, resulting in problems 
> such as http://jira.xwiki.org/browse/XINFRA-219. However this issue reports 
> the issue only for French but it’s likely that it broke the translations for 
> other languages.
> 
> The learnings
> ===
> 
> 1) We must never change the format of existing translation keys. This is the 
> equivalent of breaking an API. Instead we need to go through deprecation of 
> existing keys and introduction of new keys, even though it’s a pain. 
> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTranslationBestPractices
>  would probably benefit from additional explanations too.
> 
> 2) We would need a tool in the quality profile of our build/CI that would 
> break the build if someone changes the format of a translation.Easiest would 
> be a tool that compares the English translations on master vs the last 
> released version and breaks if there’s a difference in parameter (i.e. {N} 
> syntax).
> 
> 3) We need to decide if A) we keep the current change done in XWIKI-13067 or 
> B) revert them and revert/adapt the changes already brought to some 
> translations keys (as it was done for FR). For this we need to evaluate the 
> extent of the damage.
> 
> Any volunteer for 3)? :)
> 
> Thanks
> -Vincent
> 
> 
> 
> 
> 


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

Re: [xwiki-devs] Ability to show/hide documents quickly (was Re: [Proposal][UX] Change the user type for the Admin user to 'simple')

[Sergiu Dumitriu]

On 11/28/2016 09:35 AM, Vincent Massol wrote:
>>>> I believe a "Developer" user is what we really need.
>>>
>>> Actually that wouldn’t solve the problem I had either since it would mean
>>> having to navigate to the user profile, make the change, go back to where
>>> you were, check the hidden docs, then go back again to your user profile,
>>> put back the profile again and navigate back… Doesn’t work!
>>>
>>
>> Of course the "Developer" user would have the "show hidden docs" option
>> enabled, and would be an "advanced user", so all you would have to do is to
>> log-in as "Developer”.
> 
> Yes but Developers are not the only category of people who may need to see 
> hidden docs easily.
> 

I don't quite agree. Why would a non-developer be interested in a code
page? I can think of three reasons:

- the page shouldn't have been hidden if users want to reach it
- the user is trying to change something in the code, which is actually
a developer task, so even if the user isn't an actual developer, he acts
as one temporarily
- the user is trying to adjust something, which means that there's a
configuration missing; still, I'd argue that this is also a developer task

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

Re: [xwiki-devs] Why are extensions of same version removed when installing a new extension?

[Sergiu Dumitriu]

On 11/20/2016 05:47 AM, Vincent Massol wrote:
> Hi Sergiu,
> 
>> On 20 Nov 2016, at 05:26, Sergiu Dumitriu <ser...@xwiki.org> wrote:
>>
>> Are you perhaps installing as a farm extension?
> 
> Yes, I am. There’s a namespace constraint of {root} in the pom for some 
> modules I’m installing.
> 
>> As to why are some extensions removed but not installed, that's simple.
>> Removing Tree Macro also removes all its dependants, like the Document
>> Tree Macro.
> 
> Yes but why is the Tree Macro removed?

It's removed as a wiki extension, and installed as a farm extension,
probably to avoid conflicts.

>> But there's no indication left that those dependants are to
>> be installed back.
> 
> Yep that’s the strange part.
> 
> Thanks
> -Vincent
> 
>> On 11/19/2016 07:27 AM, Vincent Massol wrote:
>>> Actually there are even extensions listed that will be removed and not 
>>> reinstalled…
>>>
>>> Why is that? Looks very wrong.
>>>
>>> FTR I’m on XWiki 8.4.
>>>
>>> Thanks
>>> -Vincent
>>>> On 19 Nov 2016, at 13:26, Vincent Massol <vinc...@massol.net> wrote:
>>>>
>>>> Hi devs,
>>>>
>>>> When trying to install a new extension I was surprised to see that EM is 
>>>> saying that it’ll removed existing installed extensions to replace them 
>>>> with the same extension in the same version.
>>>>
>>>> See screenshot:
>>>> https://www.evernote.com/l/AHfLVOUhq8ZIrpItBgPWw1KOQ7E2uvCukTU
>>>>
>>>> Any idea? Is that a known bug/limitation?
>>>>
>>>> Thanks
>>>> -Vincent
>>

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Why are extensions of same version removed when installing a new extension?

[Sergiu Dumitriu]

Are you perhaps installing as a farm extension?

As to why are some extensions removed but not installed, that's simple.
Removing Tree Macro also removes all its dependants, like the Document
Tree Macro. But there's no indication left that those dependants are to
be installed back.

On 11/19/2016 07:27 AM, Vincent Massol wrote:
> Actually there are even extensions listed that will be removed and not 
> reinstalled…
> 
> Why is that? Looks very wrong.
> 
> FTR I’m on XWiki 8.4.
> 
> Thanks
> -Vincent
>> On 19 Nov 2016, at 13:26, Vincent Massol  wrote:
>>
>> Hi devs,
>>
>> When trying to install a new extension I was surprised to see that EM is 
>> saying that it’ll removed existing installed extensions to replace them with 
>> the same extension in the same version.
>>
>> See screenshot:
>> https://www.evernote.com/l/AHfLVOUhq8ZIrpItBgPWw1KOQ7E2uvCukTU
>>
>> Any idea? Is that a known bug/limitation?
>>
>> Thanks
>> -Vincent

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Evolution of the Blog Application

[Sergiu Dumitriu]

+1 for moving even more of the functionality in Java, not just this
listener.

On 11/17/2016 07:00 AM, Guillaume Delhumeau wrote:
> Hi.
> 
> The Blog Application is one of our main applications. It has been fully
> written in Velocity, so that even users who don't have programing rights
> can install it on their wiki.
> 
> However, I am currently working on XWIKI-13861 [1]. It is about marking the
> blog documents as hidden when they are not "published" so that visitors
> won't find them by mistake with the search engine. To accomplish it, I've
> created a listener that change the document visibility when a blog post is
> saved.
> 
> To implement this listener, we have 2 options, with both benefits and
> drawbacks:
> 
> A: Write the listener with Java and introduce an xwiki-platform-blog-api
> module.
> ===
> 
> Pros:
> * It follows our Best Practices.
> * We use a nice and powerful language: Java.
> 
> Cons:
> * It make the Blog Application dependent to a Java Module, so the wiki
> administrator needs the PR to install it if the JAR is not already
> installed in the WAR.
> * Note that this JAR would be bundled in the XE's WAR while the Blog
> Application is part of the main wiki flavor, so XE users won't see the
> change right now.
> 
> B: Write the listener with Groovy directly on a wiki page.
> ==
> 
> Pros:
> * Blog Application remains a full XAR extension that you can install
> without PR, as it has always been.
> 
> Cons:
> * We need to use the groovy macro, which is not consistent with our Best
> Practices.
> * We need a bit of plumbing to register the listener (what we really need
> is to be able to write listeners easily with an XObject).
> * If the user has not the PR, the listener will not be registered, so the
> new behavior introduced by XWIKI-13861 won't be applied. It's a kind of
> nice degradation but we need to explain it to the user, which will be
> technical and not user-friendly (we already have lacks on this domain).
> 
> C: Don't write a listener, but make all changes in Velocity
> =
> 
> Pros:
> * It remains a full XAR extension.
> * No degradation
> 
> Cons:
> * We need to make the business logic of hiding the blog document in a
> velocity service and in the blog post sheet.
> * It is less safe than the listener because a user can still change the
> "hidden" and the "published" values of the XObjects and bypass the
> synchronization.
> * We cannot write an automatic migrator that would be executed only on wiki
> events.
> 
> Conclusion
> 
> 
> My preference goes to A, because:
> * I don't really like the degradation principle for technical reasons that
> the user might not understand.
> * It's simple & safe.
> * If I would have written the Blog App myself, I would have made a Script
> Service in Java to put the business logic away from Velocity.
> * We have plenty of extensions having Java modules. A better approach would
> be to authorize the installation of approved and/or signed modules even
> when the admin has not the programming right.
> 
> Since we need a collegial decision, I am asking you your opinion :)
> 
> Thanks,
> 
> [1] http://jira.xwiki.org/browse/XWIKI-13861
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [xwiki-users] Lots of disabled Yahoo email addresses on the xwiki.org lists

[Sergiu Dumitriu]

Or actually it's because you sent the mail directly to me, and I see a
copy that hasn't been through mailman. Everybody else got it in the Spam
folder, with the broken signature.

On 11/08/2016 09:50 AM, Sergiu Dumitriu wrote:
> It's not your fault, it's XWiki's Mailman's fault.
> 
> The signature verifies that your original email is valid.
> 
> But Mailman appends the following to the bottom of the mails:
> 
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> 
> By adding this, the signature now fails. Since yahoo now says that mails
> without a valid signature aren't trusted, your email becomes untrusted.
> 
> I see now that your mail doesn't have this signature anymore (hurray
> XWiki infra!), and is now considered valid:
> 
> Authentication-Results: mx.google.com;
>dkim=pass header.i=@yahoo.fr;
>dmarc=pass (p=REJECT dis=NONE) header.from=yahoo.fr
> 
> On 11/08/2016 03:40 AM, Pascal BASTIEN wrote:
>> Hello,
>> It is strange because my emails have a DKIM signature like here (piece of 
>> header from a mail I sent from my xwiki email to myself at another adress).
>> Is it sympa who's altering this signature?
>> Can I fix it (if it is "my fault")?
>> Thxs
>>
>> Pascal
>> --
>> Received: from nm43-vm5.bullet.mail.gq1.yahoo.com 
>> (nm43-vm5.bullet.mail.gq1.yahoo.com [67.195.87.220])
>> xxx
>> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s2048; 
>> t=1478593132; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; 
>> h=Date:From:Reply-To:To:Subject:References:From:Subject; 
>> b=N6C8UltuP6jp4mZaWG43Y1ngel4R75RdftqTuXxYHngnseuGe5/2k2/H5pwVcJVe34gjtB33vMZm1j4yZ56M8++zNl4Asb4xV/6wwF+JL+ZGlcXTmfJdGlx5+GdukOzN6bX9Dz9Lvp5GpsYHZnWE8eANw0SeJ9t9wcvzKmNOYW+t9S53N27nfRfjYAwm7iZVmUsgbbZlpnW3NYrPOLoBGZX67aq6gsq877LKUyLLgLP5oszQnx3cUZAsgmjRuSYIIzjF42vfzjVjs7rOoO7royNl5O8BeFlgpevF/BDk2g2K7KXRTkkKtmDM
>>
>>
>> 
>> En date de : Lun 7.11.16, Sergiu Dumitriu <ser...@xwiki.org> a écrit :
>>
>>  Objet: Re: [xwiki-users] Lots of disabled Yahoo email addresses on the 
>> xwiki.org lists
>>  À: "XWiki Users" <us...@xwiki.org>, "XWiki Developers" <devs@xwiki.org>
>>  Date: Lundi 7 novembre 2016, 15h40
>>  
>>  By the way, all of
>>  Pascal's and Julio's emails (and other yahoo
>>  users)
>>  end up in my spam folder because of
>>  the broken DKIM signatures.
>>  
>>  On
>>  11/07/2016 09:24 AM, Sergiu Dumitriu wrote:
>>  > This is partially XWiki's
>>  infrastructure fault, too.
>>  > 
>>  > DMARC doesn't work well with mailing
>>  lists, since they tend to break
>>  > DKIM
>>  signatures. The only way to fix the problem (at least for
>>  the
>>  > majority of emails) is to remove
>>  the footer from the configuration.
>>  > 
>>  > So, options:
>>  > 
>>  > - remove the footer, which means that
>>  "incompetent" users will have a
>>  > hard time finding information about
>>  unsubscribing, but allows users from
>>  >
>>  modern email providers to subscribe
>>  > -
>>  keep the footer, which makes it harder for legitimate users
>>  to stay
>>  > subscribed
>>  >
>>  
>>
> 
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [xwiki-users] Lots of disabled Yahoo email addresses on the xwiki.org lists

[Sergiu Dumitriu]

It's not your fault, it's XWiki's Mailman's fault.

The signature verifies that your original email is valid.

But Mailman appends the following to the bottom of the mails:

devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

By adding this, the signature now fails. Since yahoo now says that mails
without a valid signature aren't trusted, your email becomes untrusted.

I see now that your mail doesn't have this signature anymore (hurray
XWiki infra!), and is now considered valid:

Authentication-Results: mx.google.com;
   dkim=pass header.i=@yahoo.fr;
   dmarc=pass (p=REJECT dis=NONE) header.from=yahoo.fr

On 11/08/2016 03:40 AM, Pascal BASTIEN wrote:
> Hello,
> It is strange because my emails have a DKIM signature like here (piece of 
> header from a mail I sent from my xwiki email to myself at another adress).
> Is it sympa who's altering this signature?
> Can I fix it (if it is "my fault")?
> Thxs
> 
> Pascal
> --
> Received: from nm43-vm5.bullet.mail.gq1.yahoo.com 
> (nm43-vm5.bullet.mail.gq1.yahoo.com [67.195.87.220])
> xxx
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s2048; 
> t=1478593132; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; 
> h=Date:From:Reply-To:To:Subject:References:From:Subject; 
> b=N6C8UltuP6jp4mZaWG43Y1ngel4R75RdftqTuXxYHngnseuGe5/2k2/H5pwVcJVe34gjtB33vMZm1j4yZ56M8++zNl4Asb4xV/6wwF+JL+ZGlcXTmfJdGlx5+GdukOzN6bX9Dz9Lvp5GpsYHZnWE8eANw0SeJ9t9wcvzKmNOYW+t9S53N27nfRfjYAwm7iZVmUsgbbZlpnW3NYrPOLoBGZX67aq6gsq877LKUyLLgLP5oszQnx3cUZAsgmjRuSYIIzjF42vfzjVjs7rOoO7royNl5O8BeFlgpevF/BDk2g2K7KXRTkkKtmDM
> 
> 
> --------
> En date de : Lun 7.11.16, Sergiu Dumitriu <ser...@xwiki.org> a écrit :
> 
>  Objet: Re: [xwiki-users] Lots of disabled Yahoo email addresses on the 
> xwiki.org lists
>  À: "XWiki Users" <us...@xwiki.org>, "XWiki Developers" <devs@xwiki.org>
>  Date: Lundi 7 novembre 2016, 15h40
>  
>  By the way, all of
>  Pascal's and Julio's emails (and other yahoo
>  users)
>  end up in my spam folder because of
>  the broken DKIM signatures.
>  
>  On
>  11/07/2016 09:24 AM, Sergiu Dumitriu wrote:
>  > This is partially XWiki's
>  infrastructure fault, too.
>  > 
>  > DMARC doesn't work well with mailing
>  lists, since they tend to break
>  > DKIM
>  signatures. The only way to fix the problem (at least for
>  the
>  > majority of emails) is to remove
>  the footer from the configuration.
>  > 
>  > So, options:
>  > 
>  > - remove the footer, which means that
>  "incompetent" users will have a
>  > hard time finding information about
>  unsubscribing, but allows users from
>  >
>  modern email providers to subscribe
>  > -
>  keep the footer, which makes it harder for legitimate users
>  to stay
>  > subscribed
>  >
>  
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [xwiki-users] Lots of disabled Yahoo email addresses on the xwiki.org lists

[Sergiu Dumitriu]

By the way, all of Pascal's and Julio's emails (and other yahoo users)
end up in my spam folder because of the broken DKIM signatures.

On 11/07/2016 09:24 AM, Sergiu Dumitriu wrote:
> This is partially XWiki's infrastructure fault, too.
> 
> DMARC doesn't work well with mailing lists, since they tend to break
> DKIM signatures. The only way to fix the problem (at least for the
> majority of emails) is to remove the footer from the configuration.
> 
> So, options:
> 
> - remove the footer, which means that "incompetent" users will have a
> hard time finding information about unsubscribing, but allows users from
> modern email providers to subscribe
> - keep the footer, which makes it harder for legitimate users to stay
> subscribed
> 
> On 11/02/2016 07:57 AM, Vincent Massol wrote:
>> Hi everyone,
>>
>> Just to let you know that on the 28th of October, there were 234 members of 
>> the xwiki users list who’ve been automatically disabled (ie they’re not 
>> going to receive mails). This is apparently caused by a change in Yahoo’s 
>> email policy:
>>
>> <gum...@gmail.com>: host gmail-smtp-in.l.google.com[74.125.133.27] said:
>>550-5.7.1 Unauthenticated email from yahoo.com.br is not accepted due to
>>550-5.7.1 domain's DMARC policy. Please contact the administrator of
>>550-5.7.1 yahoo.com.br domain if this was a legitimate mail. Please visit
>>550-5.7.1  https://support.google.com/mail/answer/2451690 to learn about
>>the 550 5.7.1 DMARC initiative. o3si17254181wjx.109 - gsmtp (in reply to
>>end of DATA command)
>>
>> So if you’re in that case, please contact Yahoo as mentioned in the message 
>> above.
>>
>> Thanks
>> -Vincent
> 
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [xwiki-users] Lots of disabled Yahoo email addresses on the xwiki.org lists

[Sergiu Dumitriu]

Forgot to mention the second component of DMARC, SPF, which is also
partially broken by XWiki's infrastructure. The problem with SPF is that
mails for @xwiki.org are forwarded by xwiki.org to xwiki.com
(gmail.com in reality), and this forwarding isn't allowed by a strictly
configured SPF domain. There's no easy fix for this, the only solution
would be to replace self-hosted mailing lists with Google Groups, so
that xwiki.org also becomes an alias for gmail.com

On 11/07/2016 09:24 AM, Sergiu Dumitriu wrote:
> This is partially XWiki's infrastructure fault, too.
> 
> DMARC doesn't work well with mailing lists, since they tend to break
> DKIM signatures. The only way to fix the problem (at least for the
> majority of emails) is to remove the footer from the configuration.
> 
> So, options:
> 
> - remove the footer, which means that "incompetent" users will have a
> hard time finding information about unsubscribing, but allows users from
> modern email providers to subscribe
> - keep the footer, which makes it harder for legitimate users to stay
> subscribed
> 
> On 11/02/2016 07:57 AM, Vincent Massol wrote:
>> Hi everyone,
>>
>> Just to let you know that on the 28th of October, there were 234 members of 
>> the xwiki users list who’ve been automatically disabled (ie they’re not 
>> going to receive mails). This is apparently caused by a change in Yahoo’s 
>> email policy:
>>
>> <gum...@gmail.com>: host gmail-smtp-in.l.google.com[74.125.133.27] said:
>>550-5.7.1 Unauthenticated email from yahoo.com.br is not accepted due to
>>550-5.7.1 domain's DMARC policy. Please contact the administrator of
>>550-5.7.1 yahoo.com.br domain if this was a legitimate mail. Please visit
>>550-5.7.1  https://support.google.com/mail/answer/2451690 to learn about
>>the 550 5.7.1 DMARC initiative. o3si17254181wjx.109 - gsmtp (in reply to
>>end of DATA command)
>>
>> So if you’re in that case, please contact Yahoo as mentioned in the message 
>> above.
>>
>> Thanks
>> -Vincent
> 
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [xwiki-users] Lots of disabled Yahoo email addresses on the xwiki.org lists

[Sergiu Dumitriu]

This is partially XWiki's infrastructure fault, too.

DMARC doesn't work well with mailing lists, since they tend to break
DKIM signatures. The only way to fix the problem (at least for the
majority of emails) is to remove the footer from the configuration.

So, options:

- remove the footer, which means that "incompetent" users will have a
hard time finding information about unsubscribing, but allows users from
modern email providers to subscribe
- keep the footer, which makes it harder for legitimate users to stay
subscribed

On 11/02/2016 07:57 AM, Vincent Massol wrote:
> Hi everyone,
> 
> Just to let you know that on the 28th of October, there were 234 members of 
> the xwiki users list who’ve been automatically disabled (ie they’re not going 
> to receive mails). This is apparently caused by a change in Yahoo’s email 
> policy:
> 
> <gum...@gmail.com>: host gmail-smtp-in.l.google.com[74.125.133.27] said:
>550-5.7.1 Unauthenticated email from yahoo.com.br is not accepted due to
>550-5.7.1 domain's DMARC policy. Please contact the administrator of
>550-5.7.1 yahoo.com.br domain if this was a legitimate mail. Please visit
>550-5.7.1  https://support.google.com/mail/answer/2451690 to learn about
>the 550 5.7.1 DMARC initiative. o3si17254181wjx.109 - gsmtp (in reply to
>end of DATA command)
> 
> So if you’re in that case, please contact Yahoo as mentioned in the message 
> above.
> 
> Thanks
> -Vincent


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Add authclass property to the XWikiPreferences class

[Sergiu Dumitriu]

I really don't like that only one authenticator can be enabled at a
time. This forces more specialized authenticators to explicitly inherit
another type of authenticator that should also be supported (see for
example NTLMAuthServiceImpl -> XWikiLDAPAuthServiceImpl ->
XWikiAuthServiceImpl). Ideally, we should have only one root
authenticator, which shouldn't be configurable at all, and which doesn't
authenticate itself but delegates to a dynamic list of pluggable
authenticators.

But this would take a lot longer to design and implement, so I'm just
going to vote +0 for your incremental improvement proposal.

On 10/21/2016 02:57 AM, Alexandru Cotiuga wrote:
> Hi devs,
> 
> I'm proposing to add this new property to the *XWikiPreferences* class
> since there are many authenticators, listed on
> http://platform.xwiki.org/xwiki/bin/view/Features/Authentication and most
> of them require the overriding of the *xwiki.authentication.authclass*
> property in the *WEB-INF/xwiki.cfg* file and the restart of the wiki. So
> the *authclass* is meant to keep the value of the
> *xwiki.authentication.authclass
> *property*.*
> 
> Please keep in mind that *xwiki.cfg* was the historical file containing the
> configuration options, we're moving away from it and this can be the moment
> to improve this functionality by removing the *restart wiki* step which is
> often a pain for the user.
> 
> Thanks,
> Alex


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Disable Message Stream by default in platform distribution + XE

[Sergiu Dumitriu]

+1.

On 10/15/2016 05:10 AM, Vincent Massol wrote:
> Hi devs,
> 
> I’m working on http://jira.xwiki.org/browse/XWIKI-10543 and it’s been 
> reported by Nicolas that all the users he’s seen use XWiki don’t use the 
> Message Stream feature and moreover they even ask him to remove it.
> 
> One specific issue he’s raised is that the messages are sent to the AS 
> (either the global one or the user’s one) and the messages are drowned with 
> the page updates.
> 
> Basically we’d need to polish this feature better to make it really useful.
> 
> I agree with this POV. I also agree that in order to make XWiki simpler and 
> less cluttered, this feature could be disabled.
> 
> Thus I’m proposing to still bundle it but to disable it, since we already 
> have a Message Stream Admin UI config.
> 
> WDYT?
> 
> Thanks
> -Vincent
> 

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [xwiki-users] Fw : Re: Issues when I upgraded my xwiki 7.0.1 to xwiki 8.2.1: search feature

[Sergiu Dumitriu]

Something like this:
https://github.com/phenotips/phenotips/blob/b5fd2933480bcdeaca0194840b1c84585e763452/components/vocabularies/api/src/main/java/org/phenotips/vocabulary/internal/solr/DefaultSolrVocabularyResourceManager.java#L88-L113

On 10/04/2016 05:56 AM, Vincent Massol wrote:
> 
>> On 04 Oct 2016, at 11:54, Pascal BASTIEN <pbasnews-xw...@yahoo.fr> wrote:
>>
>> Thanks, you are right I forgot to removed solr subdirectory before upgrade.
>>
>> stop + rm + start xwiki = xwiki work again like a charm
>> (sorry ;-) )
> 
> cool
> 
> you don’t need to be sorry. We need to improve this. Like forcing 
> automatically the removal when we upgrade solr and there’s been some schema 
> changes.
> 
> -Vincent
> 
>> Thxs
>>
>> --- En date de : Mar 4.10.16, Vincent Massol <vinc...@massol.net> a écrit :
>>
>>> De: Vincent Massol <vinc...@massol.net>
>>> Objet: Re: [xwiki-users] Issues when I upgraded my xwiki 7.0.1 to xwiki 
>>> 8.2.1: search feature
>>> À: "XWiki Users" <us...@xwiki.org>
>>> Date: Mardi 4 octobre 2016, 11h36
>>> Hi,
>>>
>>> Try removing your solr index.
>>>
>>> Thanks
>>> -Vincent
>>>
>>>>
>>> On 04 Oct 2016, at 11:26, Pascal BASTIEN <pbasnews-xw...@yahoo.fr>
>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> After upgrading my
>>> xwiki 7.0.1 to 8.2.1, i encoutered another issue: xwiki
>>> search feature doesn't work anymore.
>>>> I use Tomcat 8.0.33 + Postrgesqk 9.3 and
>>> attachments in file system and connected with Admin
>>> account.
>>>>
>>>> On page
>>> ./bin/view/Main/Search?text=test_type=DOCUMENT_locale=fr_locale==1
>>> , I have this ugly error message displayed:
>>>> "Failed to execute the [velocity]
>>> macro. Cause: [The resolver parameter doesn't contain an
>>> Entity Reference of type [SPACE]]. Click on this message for
>>> details."
>>>>
>> ___
>> users mailing list
>> us...@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/users
> 
> ___
> users mailing list
> us...@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Sergiu Dumitriu]

On 10/06/2016 11:36 AM, Vincent Massol wrote:
> Hi Sergiu,
> 
>> On 06 Oct 2016, at 17:30, Sergiu Dumitriu <ser...@xwiki.org> wrote:
>>
>> The way I do this for another similar feature, using UIX objects, is to
>> add two new parameters, "enabled" and "order". When displaying the
>> extensions for a particular point, I request them ordered by the "order"
>> parameter, and then manually skip those for which the "enabled"
>> parameter is set to "false" -- if the parameter is missing, it's
>> considered enabled by default.
>>
>> We can define that the order should have a value between 0 and 100, and
>> each extension can choose it's own relative number, as an expected
>> percentage, with the actual order depending on which other extensions
>> are installed and enabled, and their requested order.
> 
> Yes but IMO this wouldn’t work here for this use case because the information 
> as to whether a given app is displayed or not should not come from the UIX 
> itself (the app doesn’t know that info and shouldn’t set this). It should 
> come from the admin or from the flavor for this case at hand.
> 
> Also I don’t think that modifying the UIX of an app by the Application Panel 
> admin UI is a good thing. The storage if this info should go in the App Panel 
> config page instead IMO.
> 
> WDYT?

True, I was just presenting another approach, which, by the way, also
has limitations that are making me look for improvements.

I don't agree that the application shouldn't know whether it's suitable
for being displayed or not. Who knows that an extension is too technical
to be displayed? Certainly not the Panels application, and flavors can't
know beforehand all the extensions that may be installed. I think that
the application developers are the ones that should decide if their
application is to be displayed by default or not.

And these are just initial hints, the admins can then choose to change
the default and manually hide/show/reorder applications.

Now, for the fact that the parameters are stored *only* in the
extension, that does indeed cause several problems:

- modifying them may cause extension upgrade conflicts
- only one global setting, no user or space settings
- flavors can't override these settings

How about this: we define a way of overriding extension parameters using
custom objects:

XWiki.UIExtensionParameterOverridesClass
- extensionPointId
- name
- parameters

extensionPointId and name must match an UIX, and parameters override the
extension's parameters.

Depending on where the object it placed, it can be valid for:
- the whole wiki if placed in XWiki.XWikiPreferences
- a space if placed in .WebPreferences
- a certain user if placed in XWiki.
- any other page, and have a way of telling the uix manager that we want
to apply the parameter overrides in that page
- not sure what to do for flavors, is XWiki.XWikiPreferences good, or is
there a flavor-specific configuration page?

How does that sound?

> Thanks
> -Vincent
> 
>> As a more advanced feature, in PhenoTips we also have a wizard that
>> allows enabling/disabling and manually reordering extensions, by
>> modifying the extension parameters.
>>
>> I didn't have time for this yet, but in the future I'd like to add
>> support for ordering and enable/disable flags in the core UIX module, so
>> that extensions are automatically filtered and ordered.
>>
>> On 10/05/2016 05:37 AM, Vincent Massol wrote:
>>> Hi devs,
>>>
>>> With the recent introduction of the Applications Index (see 
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Application/)
>>>  we need to agree on a few things.
>>>
>>> In the past we had:
>>> * We wanted all new app that you installed to automatically be visible in 
>>> the Applications Panel
>>> * This is why the Applications Panel config had a blacklist (and not a 
>>> white list)
>>>
>>> What we’ve done:
>>> * We add the Applications Index
>>> * We removed some apps from the Applications Panel. Namely: Invitation, 
>>> Panels, Scheduler, User Directory and Tour applications. this was done 
>>> using hardcoded blacklist xobjects in 
>>> PanelsCode.ApplicationsPanelConfiguration.
>>>
>>> The need:
>>> * We need to remove this hack. It’s not normal for the Panels module to 
>>> know all the apps that shouldn’t be listed in it!
>>>
>>> Proposal:
>>> * Replace the blacklist configuration of the Applications Panel by a 
>>> whitelist one
>>> * When a new app is installed, list it in the Applications Index but don’t 
>>> add it to the Applications Panel
>>> * If an admin wants to add this new for his users, he’ll need to add it in 
>>> the Admin UI for the Applications Panel.
>>>
>>> WDYT?
>>>
>>> Thanks
>>> -Vincent
>>>
>>

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [PROPOSAL] Stabilize filesystem templates rights

[Sergiu Dumitriu]

+1 for 1.

On 10/05/2016 05:29 AM, Thomas Mortagne wrote:
> Hi devs,
> 
> Right now (and since forever) the default behavior for templates is to
> be executed with the right of the current document content author
> (it's not really explicit, it's just how PR works when there is no
> sdoc). This means that unless you explicitly indicate an author for
> your template (possible since 7.x) you don't really have any idea
> which right it's going to have at runtime. It also make harder to
> properly execute templates outside of main rendering thread where the
> "current document" often don't really make much sense.
> 
> I think we should make the default more stable.
> 
> I can think of two possibilities:
> 
> 1) with what we got right now the only real possibility is to execute
> the filesystem template with superadmin right (which is only an option
> right now). Makes it consistent with the "code is executed with the
> right of its author" rule we have for wiki pages
> 2) introduce some new virtual user (like "templateauthor" or
> "scripter" or whatever) which only have script right and use that as
> filesystem template author if we absolutely want template to not have
> too many rights by default (even if modifying a filesystem template
> require much more access than superadmin in practice)
> 
> +1 for 1)
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change of behavior for Applications Panel and app registration in general

[Sergiu Dumitriu]

The way I do this for another similar feature, using UIX objects, is to
add two new parameters, "enabled" and "order". When displaying the
extensions for a particular point, I request them ordered by the "order"
parameter, and then manually skip those for which the "enabled"
parameter is set to "false" -- if the parameter is missing, it's
considered enabled by default.

We can define that the order should have a value between 0 and 100, and
each extension can choose it's own relative number, as an expected
percentage, with the actual order depending on which other extensions
are installed and enabled, and their requested order.

As a more advanced feature, in PhenoTips we also have a wizard that
allows enabling/disabling and manually reordering extensions, by
modifying the extension parameters.

I didn't have time for this yet, but in the future I'd like to add
support for ordering and enable/disable flags in the core UIX module, so
that extensions are automatically filtered and ordered.

On 10/05/2016 05:37 AM, Vincent Massol wrote:
> Hi devs,
> 
> With the recent introduction of the Applications Index (see 
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Application+Index+Application/)
>  we need to agree on a few things.
> 
> In the past we had:
> * We wanted all new app that you installed to automatically be visible in the 
> Applications Panel
> * This is why the Applications Panel config had a blacklist (and not a white 
> list)
> 
> What we’ve done:
> * We add the Applications Index
> * We removed some apps from the Applications Panel. Namely: Invitation, 
> Panels, Scheduler, User Directory and Tour applications. this was done using 
> hardcoded blacklist xobjects in PanelsCode.ApplicationsPanelConfiguration.
> 
> The need:
> * We need to remove this hack. It’s not normal for the Panels module to know 
> all the apps that shouldn’t be listed in it!
> 
> Proposal:
> * Replace the blacklist configuration of the Applications Panel by a 
> whitelist one
> * When a new app is installed, list it in the Applications Index but don’t 
> add it to the Applications Panel
> * If an admin wants to add this new for his users, he’ll need to add it in 
> the Admin UI for the Applications Panel.
> 
> WDYT?
> 
> Thanks
> -Vincent
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Issue with installed count on e.x.o overflowing the AS + too many versions

[Sergiu Dumitriu]

On 08/15/2016 12:39 PM, Vincent Massol wrote:
> Hi Sergiu,
> 
>> On 15 Aug 2016, at 18:18, Sergiu Dumitriu <ser...@xwiki.org> wrote:
>>
>> Why does that value have to be stored in the wiki document?
> 
> Sure, we could use another store. However the goal of XWiki is also to 
> provide a generic store which can be used to store metadata (through 
> xobjects) related to wiki pages. And install count for an extension really 
> looks like a good metadata candidate for a wiki page. Using another store 
> would also be more work.
> 
> So, I’d prefer if we could find a way to support this use case which seems 
> legitimate. We have several such use cases, which consist in having some 
> system user perform modifications to wiki pages:
> * scheduler which updates scheduled jobs with the last fire time xproperty
> * this extension scheduler which updates install counts
> * (I’m sure we have more examples but I can’t find one right now ;))
> 
> My personal POV is that long term we should have:
> * Introduce a proper reserved (you cannot create a user named after it) and 
> virtual “System” user (and don’t use “Admin” or “superadmin” which are users 
> which should be used by admins)
> * Filter out System user changes by default in Activity Stream, History, etc 
> (with options to display them)
> * Refactor the Versioning store (and possibly get get rid of JRCS) to have a 
> scalable system which supports an unlimited number of revisions without 
> impacting performances
> * Add an API to merge several revisions into one (this could be useful for 
> auto save too). This is related to what you called “pseudoversion” too: 
> http://extensions.xwiki.org/xwiki/bin/view/Extension/XWiki+Publication+Workflow+Application

I agree, but as you said, this is "long term".

Perhaps I'm missing something, but I though the count is already stored
someplace else. Is the scheduler task that updates these counts not
fetching the data from an external place? What I'm proposing, as a quick
solution that doesn't require reimplementing the entire storage, user
management and activity stream, is that instead of getting the numbers
regularly from another service and storing them in the wiki, just let
them be fetched directly from there when requested.

>> Personally, I'd make it a Computed Field, and always get the current
>> value from an external service. This has the disadvantage that the
>> livetable can't filter/order by the number of installations.
>>
>> If the cost of fetching data from an external service is a concern, then
>> add a TTL cache.
> 
> Thanks
> -Vincent
> 
>> On 08/15/2016 06:54 AM, Vincent Massol wrote:
>>> Hi Thomas and all,
>>>
>>> Back from holidays! :)
>>>
>>> I’ve noticed that the new feature of counting installed extensions on e.x.o 
>>> is having a drawback: it saturates the activity stream, making it very hard 
>>> to see real edits by users. Every day the scheduler modifies lots of wiki 
>>> pages to set the new install count. See for example: 
>>> http://www.xwiki.org/xwiki/bin/view/Main/News
>>>
>>> I think a simple change would be for the scheduler to make modifications as 
>>> minor edits. This should prevent the edits from being visible in the AS.
>>>
>>> WDYT?
>>>
>>> Now this is going to cause another real issue very soon: pages will soon 
>>> start to have a lot of revisions and we know this is currently a 
>>> performance issue. It’s also hiding real edits in the history making the 
>>> history a bit less clean.
>>>
>>> I guess an option would be for the scheduler to delete the last revision 
>>> after it updates a page. Although not very nice, it could work for now. 
>>> WDYT?
>>>
>>> Thanks
>>> -Vincent
>>
>>
>> -- 
>> Sergiu Dumitriu
>> http://purl.org/net/sergiu
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Issue with installed count on e.x.o overflowing the AS + too many versions

[Sergiu Dumitriu]

Why does that value have to be stored in the wiki document?

Personally, I'd make it a Computed Field, and always get the current
value from an external service. This has the disadvantage that the
livetable can't filter/order by the number of installations.

If the cost of fetching data from an external service is a concern, then
add a TTL cache.

On 08/15/2016 06:54 AM, Vincent Massol wrote:
> Hi Thomas and all,
> 
> Back from holidays! :)
> 
> I’ve noticed that the new feature of counting installed extensions on e.x.o 
> is having a drawback: it saturates the activity stream, making it very hard 
> to see real edits by users. Every day the scheduler modifies lots of wiki 
> pages to set the new install count. See for example: 
> http://www.xwiki.org/xwiki/bin/view/Main/News
> 
> I think a simple change would be for the scheduler to make modifications as 
> minor edits. This should prevent the edits from being visible in the AS.
> 
> WDYT?
> 
> Now this is going to cause another real issue very soon: pages will soon 
> start to have a lot of revisions and we know this is currently a performance 
> issue. It’s also hiding real edits in the history making the history a bit 
> less clean.
> 
> I guess an option would be for the scheduler to delete the last revision 
> after it updates a page. Although not very nice, it could work for now. WDYT?
> 
> Thanks
> -Vincent


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Discussion] Committing date changes on document XML files

[Sergiu Dumitriu]

t;>>>
>>>>>> You can see some arguments on the discussion[1], but I also wanted to
>>>>>> mention that this practice goes in line with what we do for document
>>>>>> versions (which is handled by the xar:format maven plugin goal which
>> we
>>>>>> execute every time, before committing XML pages). If we are to update
>> doc
>>>>>> dates, then we should also increment doc versions, otherwise it does
>> not
>>>>>> make any sense.
>>>>>>
>>>>>> The idea was, AFAIR, that XWIki`s code pages should not generate any
>>>>>> updates in the user`s wiki content, in any way, and that and update
>> of
>>>>> the
>>>>>> code of a "system"/XWiki page should not show up as an update of *the
>>>>>> user's content*, since it would otherwise confuse him.
>>>>>>
>>>>>> What we are currently missing from xar:format is exactly this: the
>> reset
>>>>> of
>>>>>> XML page dates to have a clearer and more consistent date for XWiki`s
>>>>> code
>>>>>> pages.
>>>>>>
>>>>>> Your input is appreciated and the result of this discussion would be
>> the
>>>>>> update of our Development Practices [2] and Application Development
>> Best
>>>>>> Practices [3] pages.
>>>>>>
>>>>>> Thanks,
>>>>>> Eduard
>>>>>>
>>>>>> --
>>>>>> [1]
>>>>>>
>>>>>
>>
>> https://github.com/xwiki/xwiki-platform/commit/1938dd18e1d25b8c03e4cb22286273bffdea5530#commitcomment-18375907
>>>>>> [2]
>> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices
>>>>>> [3]
>>>>>>
>>>>>
>>
>> http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPractices
>>>>>> ___
>>>>>> devs mailing list
>>>>>> devs@xwiki.org
>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>
>>>>> ___
>>>>> devs mailing list
>>>>> devs@xwiki.org
>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>
>>>> ___
>>>> devs mailing list
>>>> devs@xwiki.org
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>>> ___
>>> devs mailing list
>>> devs@xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] xwiki.org Governance change for paying extensions

[Sergiu Dumitriu]

+1.

On 07/26/2016 07:49 AM, Vincent Massol wrote:
> Hi devs,
> 
> I’d like to propose some changes to the governance related to paying 
> extensions and extensions.xwiki.org and the Extension Manager.
> 
> * Make extensions.xwiki.org an extension repo for free and open source 
> extensions only. This is the case till now but during the last governance 
> change VOTE we had said we could allow non-free versions. After more thinking 
> I believe it’s better that companies who want to have paying apps provide 
> them through their own extension repository. One issue is that these 
> companies will need to have users register and log in and we cannot do that 
> on xwiki.org.
> 
> * Allow top sponsoring companies to have their extension repository defined 
> in the default XWiki configuration (in xwiki.properties). I’m proposing that 
> sponsoring companies require 3 active committers to be able to have their 
> stores listed by default in the XWiki config. The same would be done on 
> nexus.xwiki.org which would proxy any maven repo from a top sponsoring 
> company. Note that any company (even one not participating to the development 
> of the XWiki project can provide an extension repository with some 
> instructions for users to add their repo to their config - This point here is 
> only about having some repos by default).

I think 3 is a pretty high number. I'd vote for 2, although personally
I'm OK with 1 as well.

> * Allow the top sponsoring company (TSC) an advertising space on the home 
> page of extensions.xwiki.org to advertise extensions it wishes to promote.
> 
> Please cast your votes.
> 
> Here’s my +1
> 
> Thanks
> -Vincent
> 

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Velocity 2.0 and DeprecatedCheckUberspector

[Sergiu Dumitriu]

One thing that would be nice to have is the custom whitespace filter
that the {{velocity}} macro has: see
http://extensions.xwiki.org/xwiki/bin/view/Extension/Velocity+Macro#HParametersdefinition
and
http://extensions.xwiki.org/xwiki/bin/view/Extension/Velocity+Macro+Filter

Basically, Velocity only supports literal whitespace processing, with
every space and newline going into the output, while we like to be able
to indent our sources without padding the output with lots of extra spaces.

On 07/22/2016 02:49 AM, Vincent Massol wrote:
> Hi Claude,
> 
>> On 21 Jul 2016, at 17:26, Claude Brisson <cla...@renegat.net> wrote:
>>
>> Hi.
>>
>> I'm currently working on Velocity 2.0 packaging.
>>
>> If that's OK with you, I would like to incorporate 
>> DeprecatedCheckUberspector.java into Velocity, but I need a statement from 
>> your part to be able to change its licence to Apache 2.0 (LGPL and Apache 
>> 2.0 licences aren't compatible).
> 
> Thanks for reaching out. A big +1 from me too. The more we can move to 
> Velocity the better it is.
> 
>> By the way, I take this opportunity to tell you that if there is another 
>> specific part of xwiki-commons-velocity that you think should be integrated 
>> on our side, or an important missing feature you'd like to insist on, don't 
>> hesitate. I already integrated VELOCITY-825, for instance, so String->Enum 
>> constant conversions are now handled by Velocity. There may be other 
>> important conversion cases you'd like to see handled.
> 
> Ok cool.
> 
> On your side, if you see other issues that you’d be willing to integrate let 
> us know.
> 
> Thanks
> -Vincent
> 
>> Regards,
>>
>>  Claude

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Velocity 2.0 and DeprecatedCheckUberspector

[Sergiu Dumitriu]

+1 from me.

On 07/21/2016 11:26 AM, Claude Brisson wrote:
> Hi.
> 
> I'm currently working on Velocity 2.0 packaging.
> 
> If that's OK with you, I would like to incorporate
> DeprecatedCheckUberspector.java into Velocity, but I need a statement
> from your part to be able to change its licence to Apache 2.0 (LGPL and
> Apache 2.0 licences aren't compatible).
> 
> By the way, I take this opportunity to tell you that if there is another
> specific part of xwiki-commons-velocity that you think should be
> integrated on our side, or an important missing feature you'd like to
> insist on, don't hesitate. I already integrated VELOCITY-825, for
> instance, so String->Enum constant conversions are now handled by
> Velocity. There may be other important conversion cases you'd like to
> see handled.
> 
> Regards,
> 
>   Claude

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Use {{html clean="false"}} as a best practice when developing applications

[Sergiu Dumitriu]

+0.95, depending on where it is actually used.

If it's about content (mostly forms) that the XWiki developers write as
part of applications, without any user-generated content, then +1.

If user content is involved, then always clean it.

If it's both, then I'd use two {{html}} macros, non-cleaned for our
content, cleaned for the user content, although this will rarely be
needed, since user content is already processed by the doc.display and
related methods.

On 07/15/2016 10:13 AM, Marius Dumitru Florea wrote:
> Hi devs,
> 
> I'd like to propose that we use, from now on, {{html clean="false"}} when
> developing applications, because:
> 
> * HTML cleaning is an extra step that can increase page loading time
> * the HTML cleaner can have bugs (like any other code) or unexpected
> behaviour (like removing some elements or some attributes when you don't
> expect it)
> * when I make a mistake in my HTML code I'd like to detect it as soon as
> possible, instead of letting the cleaner silently "fix" it for me. Note
> that we would still have the webstandards validation tests as a safety net
> (only for the default distribution though)
> 
> We should keep clean=true by default because we don't want the XWiki users
> to break the XWiki UI too easily when they copy some HTML from the web and
> paste it inside the HTML macro.
> 
> Here's my +1
> 
> WDYT?
> 
> Thanks,
> Marius

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Saving page name with accented character?

[Sergiu Dumitriu]

It may be. Can you configure the tomcat start script to also pass this
option to the java command:

-Dfile.encoding=utf-8

I'm not sure how to do that on Windows, maybe this can help:

http://stackoverflow.com/a/11343571/620249

On 06/27/2016 11:54 AM, Julio Brum wrote:
> Sergiu,
> 
> the operating system encoding is "Cp1252". Is this the problem?
> 
> Cordialment,
> Julio
> 
> 2016-06-25 9:51 GMT-03:00 Sergiu Dumitriu <ser...@xwiki.org>:
> 
>> What is the operating system encoding? Try putting this in a new wiki
>> page and view it:
>>
>> {{groovy}}
>> print System.getProperty('file.encoding')
>> {{/groovy}}
>>
>> On 06/23/2016 06:38 PM, Julio Brum wrote:
>>> I am using the XWiki version 7.4.1 with UTF-8 in Xwiki, tomcat8 and
>>> Postgres, but every time than I save a page with accent in the name,
>> XWiki
>>> change the name. For example, I try to save a page with the name "é" and
>>> XWiki save "%25C3%25A9" Please, why this happens?
>>>
>>>
>>>
>>> *My settings in windows:*
>>>
>>> *tomcat\conf\server.xml:*
>>>
>>> >>   URIEncoding="UTF-8"
>>>
>>> *xwiki.cfg:*
>>>
>>> xwiki.encoding=UTF-8
>>>
>>> *PostgreSQL:*
>>>
>>> CREATE DATABASE wiki
>>>   WITH OWNER = postgres
>>>ENCODING = 'UTF8'
>>>TABLESPACE = pg_default
>>>LC_COLLATE = 'Portuguese_Brazil.1252'
>>>LC_CTYPE = 'Portuguese_Brazil.1252'
>>>CONNECTION LIMIT = -1;
>>>
>>> Thanks,
>>> Julio
>>
>> --
>> Sergiu Dumitriu
>> http://purl.org/net/sergiu/
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Saving page name with accented character?

[Sergiu Dumitriu]

What is the operating system encoding? Try putting this in a new wiki
page and view it:

{{groovy}}
print System.getProperty('file.encoding')
{{/groovy}}

On 06/23/2016 06:38 PM, Julio Brum wrote:
> I am using the XWiki version 7.4.1 with UTF-8 in Xwiki, tomcat8 and
> Postgres, but every time than I save a page with accent in the name, XWiki
> change the name. For example, I try to save a page with the name "é" and
> XWiki save "%25C3%25A9" Please, why this happens?
> 
> 
> 
> *My settings in windows:*
> 
> *tomcat\conf\server.xml:*
> 
>URIEncoding="UTF-8"
> 
> *xwiki.cfg:*
> 
> xwiki.encoding=UTF-8
> 
> *PostgreSQL:*
> 
> CREATE DATABASE wiki
>   WITH OWNER = postgres
>ENCODING = 'UTF8'
>TABLESPACE = pg_default
>LC_COLLATE = 'Portuguese_Brazil.1252'
>    LC_CTYPE = 'Portuguese_Brazil.1252'
>CONNECTION LIMIT = -1;
> 
> Thanks,
> Julio

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Remove old Radeox macros from e.x.o?

[Sergiu Dumitriu]

+1 for this.

On 05/26/2016 03:18 AM, Thomas Mortagne wrote:
> i.e. making 
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Old+XWiki+1.0+syntax+renderer
> a space and just moving those pages there (without their
> ExtensionClass object)
> 
> On Thu, May 26, 2016 at 9:17 AM, Thomas Mortagne
> <thomas.morta...@xwiki.com> wrote:
>> We could move the documentation of those macros under
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Old+XWiki+1.0+syntax+renderer
>> to not loose it (but yes not make them extensions from e.x.o. point of
>> view).
>>
>> On Thu, May 26, 2016 at 9:07 AM, Vincent Massol <vinc...@massol.net> wrote:
>>> Hi devs,
>>>
>>> WDYT about removing the old Radeox macros from e.x.o?
>>>
>>> Rationale: they’re confusing (since Radeox has been removed from the 
>>> platform) and I don’t think anyone is interested in them anymore. Note that 
>>> if you install the 1.0 rendering you’ll still get them anyway. They just 
>>> won’t be documented but I don’t feel it’s a big deal at all. An alternative 
>>> (more work) would be to move the page on some old.xwiki.org wiki...
>>>
>>> Thanks
>>> -Vincent
>>>
>>> ___
>>> devs mailing list
>>> devs@xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>>
>> --
>> Thomas Mortagne
> 
> 
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

[Sergiu Dumitriu]

On 04/18/2016 11:28 AM, abtv wrote:
> yes, actual name is RavenAuthorizationSettler, so error message and java
> class are the same. I just renamed it before (just not depend on real name)
> 
> Docs say:
> The component hint of the AuthorizationSettler may be configured from the
> ConfigurationSource (xwiki.properties) using the key
> security.authorization.settler. The default hint "default" is implemented by
> the DefaultAuthorizationSettler.
> 
> What is hint in this context?

The hint is what you put here:

@Named("MyAuthorizationSettler")

So try this:

security.authorization.settler=MyAuthorizationSettler

(or RavenAuthorizationSettler if you also changed the hint of the class)

Note that the actual cause of the problem is near the end of the
stacktrace, the first one is just the tip of the iceberg that doesn't
provide any useful debugging information.

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

[Sergiu Dumitriu]

On 04/18/2016 06:03 AM, abtv wrote:
> I received the following error:
> 2016-04-18 12:46:11,599 [main] ERROR .o.i.DefaultObservationManager - Failed
> to lookup listeners 
> org.xwiki.component.manager.ComponentLookupException: Failed to lookup
> component [role = [interface org.xwiki.observation.EventListener] hint =
> [default]]
> 
> I implemented the following component:
> 
> @Component
> @Named("MyAuthorizationSettler")
> @Singleton
> public class MyAuthorizationSettler implements AuthorizationSettler {
> 
> @Override
> public SecurityAccessEntry settle(UserSecurityReference
> userSecurityReference, Collection collection,
> Deque deque) {
> System.out.println("settle");
> System.out.println("name");
> System.out.println(userSecurityReference.getName());
> System.out.println("space name");
>
> System.out.println(userSecurityReference.getOriginalReference().getLastSpaceReference().getName());
> 
> return new SecurityAccessEntry() {
> @Override
> public UserSecurityReference getUserReference() {
> return userSecurityReference;
> }
> 
> @Override
> public SecurityAccess getAccess() {
> return null;
> }
> 
> @Override
> public SecurityReference getReference() {
> return null;
> }
> };
> }
> }
> 
> I added the folowing line 
> 0:com.raven.xwiki.auth.RavenAuthorizationSettler 
> to components.txt file. 
> 
> Then I added to xwiki.properties file the following line: 
> security.authorization.settler=com.raven.xwiki.auth.MyAuthorizationSettler
> 
> What should I need to implement else?
> 

Quick check, the code says "MyAuthorizationSettler" but the
configuration says "RavenAuthorizationSettler". Is that wrong in the
email only, or in the actual code?

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [xwiki-users] DocumentDeletingEvent

[Sergiu Dumitriu]

On 04/13/2016 03:10 AM, Thomas Mortagne wrote:
> On Tue, Apr 12, 2016 at 10:11 PM, Vincent Massol <vinc...@massol.net> wrote:
>> Hi Peter,
>>
>>> On 05 Apr 2016, at 19:28, Peter Huisman <p.huis...@ximm.nl> wrote:
>>>
>>> From the XWiki source code, I see there is a difference in passing a 
>>> document to the evenmanager:
>>>
>>> The DocumentDeletingEvent is passing a “new 
>>> XWikiDocument(doc.getDocumentReference())"
>>> The DocumentUpdatedEvent (as an example) is passing the doc (the actual 
>>> XWikiDocument)
>>>
>>> The difference is, that the Document passed in the DeleteEvent is a new 
>>> XWikiDocument and not the XWikiDocument that is about to be deleted.
>>>
>>> Is there a reason why this difference exists?
>>
>> he code in the XWiki class doing the notify has been there for a long time 
>> AFAICS:
>>
>> om.notify(new DocumentDeletingEvent(doc.getDocumentReference()),
>> new XWikiDocument(doc.getDocumentReference()), context);
>>
>> However, I think it’s not correct. I think it should pass the document and 
>> not a clone, because an Event Listener should be able to modify the instance 
>> that’s going to be saved.
> 
> It's a delete not a save so modifying it would be useless. I guess the
> intend here was to have the same kind of data than what you get with
> DocumentDeletedEvent.
> 
> What is wrong and should be fixed is that the document sent with the
> event should have the real one as original document (exactly like it's
> done for DocumentDeletedEvent).

Thomas is right, the data sent in the event is supposed to be what the
database will contain after the event is done, and that's what will
(apparently, but not actually) be in the database after the delete: a
new blank document, and doc.originalDoc should be what was before the
change in the database. At least this was the original intention, all
events should behave like this, so that a diff can be computed between
doc and originalDoc regardless of what action happened to the document.

However, the Javadoc for DocumentDeletingEvent is misleading:
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-bridge/src/main/java/org/xwiki/bridge/event/DocumentDeletingEvent.java#L31

>>
>> So I’d open a bug for this. Let’s see if the others agree.
>>
>> Thanks
>> -Vincent
>>


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

[Sergiu Dumitriu]

w/Extension/Security+Module#HRightsandaccessdecisions
> .
> 
> If your need is better solved by injecting custom security rules, you may
> also want to override the bridge part. The security module is completely
> agnostic to XWiki itself, and the junction is made by the security bridge
> module. This where you will found the default SecurityEntryReader.
> 
> When you need to override a component that does not have a dedicated
> configuration, during your development or when installed as an extension,
> you have to unregister the existing component (to be polite), and register
> yours in replacement, see
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HComponentRegistration
> about
> component registration.
> If you end up packaging the component in a custom war, you may want to use
> the priority override solution, as describe in
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HOverrides
> 
> I hope this answer your questions, I encourage you to read the Javadoc of
> the security module for explanation about each roles and how they could
> influence the whole system, as I said, a lot can be done without having to
> rewrite the whole thing, which is a tough task.
> Regards,
> 
> 
> On Tue, Apr 12, 2016 at 10:16 AM, abtv <andreybu...@mail.ru> wrote:
> 
>> When I use XWikiCachingRightService I register it in xwiki.cfg file. Where
>> should I register my implementation of ContextualAuthorizationManager
>> interface? What is a relation between ContextualAuthorizationManager and
>> AuthorizationSettler?
>>

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Java 8 doclint features: issue with unknown tags

[Sergiu Dumitriu]

See https://github.com/phenotips/build-tools/tree/master/taglets and
https://github.com/phenotips/phenotips/blob/master/pom.xml#L920-L949

On 04/11/2016 03:24 AM, Vincent Massol wrote:
> Hi devs,
> 
> FYI, I was correcting the java 8 doclint errors over the weekend and I’ve 
> noticed an issue: doclint fails the compilation when there’s an “unknown” 
> javadoc tag. For example on the XAR Maven Plugin, the @parameter javadoc tag 
> was making it fail. I’ve fixed it by converting the plugin to use annotation 
> but still this is potentially a problem for other places.
> 
> I haven’t found any option to turn this off specifically. We can turn off 
> some group of features but apparently it’s not possible to turn off only this 
> feature.
> 
> See http://docs.oracle.com/javase/8/docs/technotes/tools/unix/javadoc.html
> 
> I’m mentioning this FYI and also in case someone knows of a solution (ofc 
> finding the corresponding doclint group and turning it off for the failing 
> module is an option albeit not a perfect one).
> 
> Thanks
> -Vincent

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Set the standard java.lang.Package fields in the MANIFEST

[Sergiu Dumitriu]

On 04/07/2016 03:40 AM, Thomas Mortagne wrote:
> Hi devs,
> 
> The is a very easy way to get information about a jar trough Package
> class. Unfortunately we did not configured Maven to set most of the
> standard fields that Package expect (Specification-* and
> Implementation-* fields).
> 
> Once enabled it mean you can get the version of your module (or the
> module of any class as easily) by doing
> 
> this.getClass().getPackage().getImplementationVersion().
> 
> See https://maven.apache.org/shared/maven-archiver/examples/manifest.html
> for more.
> 
> WDYT about enabling that in Maven Jar plugin ?
> 
> Here is my +1.
> 

+1.
-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Modify "xhtml/1.0" renderer to generate valid XHTML and introduce a new "xhtmlfragment/1.0" renderer

[Sergiu Dumitriu]

On 04/02/2016 09:38 AM, Vincent Massol wrote:
> Hi devs,
> 
> One issue we have ATM is that the xhtml/1.0 parser requires valid XHTML but 
> the xhtml/1.0 renderer generates invalid XHTML (it generates fragments only). 
> This causes https://jira.xwiki.org/browse/XWIKI-13278 for example.
> 
> I’m proposing to:
> * Modify "xhtml/1.0" renderer to generate valid XHTML (i.e. xml declaration + 
> doctype + html element)
> * Introduce a new "xhtmlfragment/1.0” renderer
> * Have annotated versions of both for the WYSIWYG editor
> 
> WDYT?
> 

Isn't this an incompatible change? Why not change the parser to accept a
fragment?

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling (Take 2)

[Sergiu Dumitriu]

I think that it's a good idea for script services to throw somewhat
expected exceptions, signalling invalid usage attempts (user not
authorized, wrong arguments...) that would then be caught in Velocity.
But deeper platform issues (DB errors, unexpected NPE, OOM...) should be
handled outside the user's code itself, at the skin level (view.vm).

On 04/01/2016 05:45 AM, Vincent Massol wrote:
> So far we have the following devs who agree:
> - thomas
> - marius
> - vincent
> 
> What about Edy, Sergiu and the others?
> 
> Thanks
> -Vincent
> 
>> On 31 Mar 2016, at 14:17, Vincent Massol <vinc...@massol.net> wrote:
>>
>> Guys, I’d like that we progress on this.
>>
>> I didn’t get any agreement or disagreement to this proposal.
>>
>> Any take?
>>
>> Thanks
>> -Vincent
>>
>>
>>> On 18 Jan 2016, at 11:03, vinc...@massol.net wrote:
>>>
>>> Hi devs,
>>>
>>> After a lot of thinking and experimentation (see the thread’s details), I 
>>> have found that this first proposal is not a good idea. I’m thus proposing 
>>> to replace it with the following best practice:
>>>
>>> * Let our script services generate exceptions
>>> * If the velocity scripts with to handle the exceptions, then they should 
>>> use the #try() directive. If they don’t want to, they don’t have to do 
>>> anything since the MacroTransformation or the template (contentvars.vm for 
>>> example) will catch it and display it to the user.
>>>
>>> More precisely I’m proposing that:
>>>
>>> * Existing Script APIs in Java should not be modified as that would break 
>>> backward compatibility. New signatures can be added and old one deprecated 
>>> and moved to the legacy modules. After new signatures have been introduced, 
>>> existing velocity scripts can be updated to use the new signatures and to 
>>> use the #try directive if needed.
>>> * New Script APIs must use the new best practices (if agreed :)), i.e. 
>>> throw Exceptions, and new velocity scripts must use the #try() directive if 
>>> they need to handle exceptions.
>>>
>>> WDYT?
>>>
>>> Thanks
>>> -Vincent
>>>
>>>
>>> On 14 Jan 2016 at 17:51:04, vinc...@massol.net 
>>> (vinc...@massol.net(mailto:vinc...@massol.net)) wrote:
>>>
>>>> Hi devs, 
>>>>
>>>> Right now our strategy is for script services and script APIs in general 
>>>> to catch exceptions, store them and offer a getLastError() method to get 
>>>> them (see 
>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Script+Module#HBestPractices)
>>>>  
>>>>
>>>> However it would be much nicer to: 
>>>> * Let our script services generate exceptions
>>>> * Offer a velocity script service to get the last exception raised by a 
>>>> java call from velocity
>>>> * Implement this uberspector to catch the exceptions and to set them in 
>>>> the execution context
>>>>
>>>> That should be quite easy to implement IMO. 
>>>>
>>>> WDYT? 
>>>>
>>>> Thanks 
>>>> -Vincent
>>>>
>>>> PS: This is http://jira.xwiki.org/browse/XWIKI-2374 
>>
> 
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Add Sandbox in the app bar + Remove Quick Links Panel + Add Tip Panel

[Sergiu Dumitriu]

On 03/30/2016 08:24 AM, Vincent Massol wrote:
> 
>> On 30 Mar 2016, at 14:02, Thomas Mortagne <thomas.morta...@xwiki.com> wrote:
>>
>> On Wed, Mar 30, 2016 at 12:04 PM, Vincent Massol <vinc...@massol.net> wrote:
>>>
>>>> On 30 Mar 2016, at 11:58, Thomas Mortagne <thomas.morta...@xwiki.com> 
>>>> wrote:
>>>>
>>>> On Wed, Mar 30, 2016 at 11:53 AM, Marius Dumitru Florea
>>>> <mariusdumitru.flo...@xwiki.com> wrote:
>>>>> On Tue, Mar 29, 2016 at 5:14 PM, Vincent Massol <vinc...@massol.net> 
>>>>> wrote:
>>>>>
>>>>>> Hi devs,
>>>>>>
>>>>>> I’d like to go on with https://jira.xwiki.org/browse/XWIKI-8919 (which
>>>>>> incidentally is a solution for https://jira.xwiki.org/browse/XWIKI-8917
>>>>>> and in general brings consistency).
>>>>>>
>>>>>> This proposal is about:
>>>>
>>>>>> * Adding Sandbox in the app bar: https://jira.xwiki.org/browse/XWIKI-8919
>>>>>> * Removing Sandbox from the Quick Links Panel and thus the Quick Links
>>>>>> Panel which becomes empty by default
>>>>
>>>> No conflict UI but it will be unselected by default in the list of
>>>> pages to delete at the end.
>>>
>>> I’m not going to delete the QuickLinks Panel. It’ll just be modified and 
>>> not used by default.
>>
>> OK then Marius comments is valid :)
>>
>> I read it too quickly and tough you wanted to simply remove it since
>> it wasn't used anymore.
> 
> Indeed it doesn’t have much value and it could be a good idea to remove it 
> (would generate less merge conflicts in the future). The only potential 
> pitfall is if we need to have a Quick Links panel in the future, but I guess 
> we had one because we were missing places in the UI where to put various 
> stuff and over time we reduce it to the minimum and now that we have a place 
> for Sandbox too, it’s not useful anymore…
> 
> Who would be in favor of removing it altogether?

+1 for removal from the platform. Maybe move it to an extension?

> thanks
> -Vincent
> 
>> Thanks
>>> -Vincent
>>>
>>>>
>>>>>> * Adding a new Tip panel instead to not loose the CTRL+G tip (which was
>>>>>> not very well placed in the Quick Links panel) + take the opportunity to
>>>>>> add a few more tips: https://jira.xwiki.org/browse/XWIKI-13270
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>
>>>>> We need to mention in the release notes that:
>>>>>
>>>>> * the Distribution Wizard may detect a merge conflict on the Quick Links
>>>>> panel if this panel was customized
>>>>> * the Quick Links panel may disappear after an upgrade to 8.1M1+. The user
>>>>> can add it back from the administration if she needs it (e.g. if it has
>>>>> been customized)
>>>>>
>>>>> +1
>>>>>
>>>>> Thanks,
>>>>> Marius
>>>>>
>>>>>
>>>>>> Thanks
>>>>>> -Vincent
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Remove the "xwiki.usedefaultweb" configuration parameter

[Sergiu Dumitriu]

On 03/29/2016 11:44 AM, Vincent Massol wrote:
> 
>> On 29 Mar 2016, at 17:42, Sergiu Dumitriu <ser...@xwiki.org> wrote:
>>
>> On 03/29/2016 11:40 AM, Sergiu Dumitriu wrote:
>>> On 03/29/2016 11:32 AM, Vincent Massol wrote:
>>>>
>>>>> On 29 Mar 2016, at 16:53, Vincent Massol <vinc...@massol.net> wrote:
>>>>>
>>>>>
>>>>>> On 29 Mar 2016, at 16:46, Sergiu Dumitriu <ser...@xwiki.org> wrote:
>>>>>>
>>>>>> It is working, but only if the default action is missing as well. So
>>>>>> indeed /bin/view/Page doesn't work ('view' is considered the space), but
>>>>>> /bin/Page does work. And as far as I know, it always worked this way.
>>>>>
>>>>> Ok, thanks for remembering this! So only when xwiki.showviewaction=0
>>>>>
>>>>>> When not considering nested spaces, I'm -0 for its removal, it's a
>>>>>> setting that's useful for shorter URLs in a mostly read only site (e.g.
>>>>>> public website).
>>>>>
>>>>> Only if you put your documents in the Main space… If you need short URLs 
>>>>> it’s better to use a shorturl strategy as described at 
>>>>> http://platform.xwiki.org/xwiki/bin/view/Main/ShortURLs (notice that 
>>>>> xwiki.usedefaultweb is not even mentioned there).
>>>>>
>>>>>> I don't have a clear grasp of how nested spaces work,
>>>>>> so I'm not sure how this setting affects nested spaces.
>>>>>
>>>>> I’ll do some tests but I’m pretty sure that the combination of 
>>>>> xwiki.showviewaction=1 + xwiki.usedefaultweb=1 + Nested Pages is not 
>>>>> currently working.
>>>>
>>>> So indeed this got broken in 7.2M1 when we refactored URL parsing for 
>>>> Nested Spaces/Pages (XWIKI-12169).
>>>>
>>>> The problem is that this conflicts with the strategy we’ve used to access 
>>>> top level Nested Pages. In the URL parsing code we have:
>>>>
>>>> // Normally the last segment is always the page name but we want to handle 
>>>> a special case when we
>>>> // have "/view/something" and we wish in this case to consider that 
>>>> "something" is the space. This
>>>> // is to handle Nested Documents, so that the user can have a top level 
>>>> Nested Document
>>>> // (something.WebHome) and access it from /view/something. If we didn't 
>>>> handle this special case
>>>> // the user would get Main.something and thus wouldn't be able to access 
>>>> something.WebHome. He'd
>>>> // need to use /view/something/ which is not natural in the Nested 
>>>> Document mode.
>>>>
>>>> So right now when we see /bin/view/something or /bin/something, we 
>>>> consider “something” to be the space name and the page is “WebHome”.
>>>>
>>>> So this conflicts with the previous behavior of xwiki.usedefaultweb=1 & 
>>>> xwiki.showviewaction=0
>>>>
>>>> We need to decide what we want. I personally prefer removing 
>>>> xwiki.usedefaultweb which was already strange (since it worked only with  
>>>> xwiki.showviewaction and only shortens URLs if the doc is in the Main 
>>>> space) and keep the ability to access top-level Nested Documents easily.
>>>>
>>>> WDYT?
>>>
>>> Sounds good, +1. There was an old issue, debating whether /bin/Something
>>> should resolve to Something.WebHome or Main.Something, and the popular
>>> opinion was Something.WebHome, so it's good that this was finally solved.
>>>
>>> http://jira.xwiki.org/browse/XWIKI-4643
>>> http://jira.xwiki.org/browse/XWIKI-3844
>>
>> Question, are nested spaces optional? If yes, should the current
>> behavior be kept for backwards compatibility?
> 
> No, Nested Spaces are not optional.
> 

Indeed, I was thinking about the parent-child hierarchy which is now
optional.

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Remove the "xwiki.usedefaultweb" configuration parameter

[Sergiu Dumitriu]

On 03/29/2016 11:40 AM, Sergiu Dumitriu wrote:
> On 03/29/2016 11:32 AM, Vincent Massol wrote:
>>
>>> On 29 Mar 2016, at 16:53, Vincent Massol <vinc...@massol.net> wrote:
>>>
>>>
>>>> On 29 Mar 2016, at 16:46, Sergiu Dumitriu <ser...@xwiki.org> wrote:
>>>>
>>>> It is working, but only if the default action is missing as well. So
>>>> indeed /bin/view/Page doesn't work ('view' is considered the space), but
>>>> /bin/Page does work. And as far as I know, it always worked this way.
>>>
>>> Ok, thanks for remembering this! So only when xwiki.showviewaction=0
>>>
>>>> When not considering nested spaces, I'm -0 for its removal, it's a
>>>> setting that's useful for shorter URLs in a mostly read only site (e.g.
>>>> public website).
>>>
>>> Only if you put your documents in the Main space… If you need short URLs 
>>> it’s better to use a shorturl strategy as described at 
>>> http://platform.xwiki.org/xwiki/bin/view/Main/ShortURLs (notice that 
>>> xwiki.usedefaultweb is not even mentioned there).
>>>
>>>> I don't have a clear grasp of how nested spaces work,
>>>> so I'm not sure how this setting affects nested spaces.
>>>
>>> I’ll do some tests but I’m pretty sure that the combination of 
>>> xwiki.showviewaction=1 + xwiki.usedefaultweb=1 + Nested Pages is not 
>>> currently working.
>>
>> So indeed this got broken in 7.2M1 when we refactored URL parsing for Nested 
>> Spaces/Pages (XWIKI-12169).
>>
>> The problem is that this conflicts with the strategy we’ve used to access 
>> top level Nested Pages. In the URL parsing code we have:
>>
>> // Normally the last segment is always the page name but we want to handle a 
>> special case when we
>> // have "/view/something" and we wish in this case to consider that 
>> "something" is the space. This
>> // is to handle Nested Documents, so that the user can have a top level 
>> Nested Document
>> // (something.WebHome) and access it from /view/something. If we didn't 
>> handle this special case
>> // the user would get Main.something and thus wouldn't be able to access 
>> something.WebHome. He'd
>> // need to use /view/something/ which is not natural in the Nested Document 
>> mode.
>>
>> So right now when we see /bin/view/something or /bin/something, we consider 
>> “something” to be the space name and the page is “WebHome”.
>>
>> So this conflicts with the previous behavior of xwiki.usedefaultweb=1 & 
>> xwiki.showviewaction=0
>>
>> We need to decide what we want. I personally prefer removing 
>> xwiki.usedefaultweb which was already strange (since it worked only with  
>> xwiki.showviewaction and only shortens URLs if the doc is in the Main space) 
>> and keep the ability to access top-level Nested Documents easily.
>>
>> WDYT?
> 
> Sounds good, +1. There was an old issue, debating whether /bin/Something
> should resolve to Something.WebHome or Main.Something, and the popular
> opinion was Something.WebHome, so it's good that this was finally solved.
> 
> http://jira.xwiki.org/browse/XWIKI-4643
> http://jira.xwiki.org/browse/XWIKI-3844

Question, are nested spaces optional? If yes, should the current
behavior be kept for backwards compatibility?

>> Thanks
>> -Vincent
>>
>>
>>> Thanks
>>> -Vincent
>>>
>>>> On 03/29/2016 09:35 AM, Vincent Massol wrote:
>>>>> Hi devs,
>>>>>
>>>>> I was reading the comment from Marius on 
>>>>> https://jira.xwiki.org/browse/XWIKI-13223 and indeed it seems that the 
>>>>> “xwiki.usedefaultweb” config parameter has not been working for a very 
>>>>> long time (Marius says at least before 2.7). Locally I’ve tested a 5.2.4 
>>>>> version and indeed it’s not working.
>>>>>
>>>>> For Main.AllDocs the generated URL is:
>>>>> http://localhost:8080/xwiki/bin/view/AllDocs
>>>>>
>>>>> Maybe at some point we were counting the number of path segments after 
>>>>> the action and if it was 1 and xwiki.usedefaultweb was set to true we 
>>>>> would add “Main” as the space. 
>>>>>
>>>>> However that’s not the case in XWiki 5.2.4 and probably earlier.
>>>>>
>>>>> In addition, with Nested Pages we’ve implemented the support of a single 
>>>>> path element after the action. FTR, from 
>>>&g

Re: [xwiki-devs] [Proposal] Remove the "xwiki.usedefaultweb" configuration parameter

[Sergiu Dumitriu]

On 03/29/2016 11:32 AM, Vincent Massol wrote:
> 
>> On 29 Mar 2016, at 16:53, Vincent Massol <vinc...@massol.net> wrote:
>>
>>
>>> On 29 Mar 2016, at 16:46, Sergiu Dumitriu <ser...@xwiki.org> wrote:
>>>
>>> It is working, but only if the default action is missing as well. So
>>> indeed /bin/view/Page doesn't work ('view' is considered the space), but
>>> /bin/Page does work. And as far as I know, it always worked this way.
>>
>> Ok, thanks for remembering this! So only when xwiki.showviewaction=0
>>
>>> When not considering nested spaces, I'm -0 for its removal, it's a
>>> setting that's useful for shorter URLs in a mostly read only site (e.g.
>>> public website).
>>
>> Only if you put your documents in the Main space… If you need short URLs 
>> it’s better to use a shorturl strategy as described at 
>> http://platform.xwiki.org/xwiki/bin/view/Main/ShortURLs (notice that 
>> xwiki.usedefaultweb is not even mentioned there).
>>
>>> I don't have a clear grasp of how nested spaces work,
>>> so I'm not sure how this setting affects nested spaces.
>>
>> I’ll do some tests but I’m pretty sure that the combination of 
>> xwiki.showviewaction=1 + xwiki.usedefaultweb=1 + Nested Pages is not 
>> currently working.
> 
> So indeed this got broken in 7.2M1 when we refactored URL parsing for Nested 
> Spaces/Pages (XWIKI-12169).
> 
> The problem is that this conflicts with the strategy we’ve used to access top 
> level Nested Pages. In the URL parsing code we have:
> 
> // Normally the last segment is always the page name but we want to handle a 
> special case when we
> // have "/view/something" and we wish in this case to consider that 
> "something" is the space. This
> // is to handle Nested Documents, so that the user can have a top level 
> Nested Document
> // (something.WebHome) and access it from /view/something. If we didn't 
> handle this special case
> // the user would get Main.something and thus wouldn't be able to access 
> something.WebHome. He'd
> // need to use /view/something/ which is not natural in the Nested Document 
> mode.
> 
> So right now when we see /bin/view/something or /bin/something, we consider 
> “something” to be the space name and the page is “WebHome”.
> 
> So this conflicts with the previous behavior of xwiki.usedefaultweb=1 & 
> xwiki.showviewaction=0
> 
> We need to decide what we want. I personally prefer removing 
> xwiki.usedefaultweb which was already strange (since it worked only with  
> xwiki.showviewaction and only shortens URLs if the doc is in the Main space) 
> and keep the ability to access top-level Nested Documents easily.
> 
> WDYT?

Sounds good, +1. There was an old issue, debating whether /bin/Something
should resolve to Something.WebHome or Main.Something, and the popular
opinion was Something.WebHome, so it's good that this was finally solved.

http://jira.xwiki.org/browse/XWIKI-4643
http://jira.xwiki.org/browse/XWIKI-3844

> Thanks
> -Vincent
> 
> 
>> Thanks
>> -Vincent
>>
>>> On 03/29/2016 09:35 AM, Vincent Massol wrote:
>>>> Hi devs,
>>>>
>>>> I was reading the comment from Marius on 
>>>> https://jira.xwiki.org/browse/XWIKI-13223 and indeed it seems that the 
>>>> “xwiki.usedefaultweb” config parameter has not been working for a very 
>>>> long time (Marius says at least before 2.7). Locally I’ve tested a 5.2.4 
>>>> version and indeed it’s not working.
>>>>
>>>> For Main.AllDocs the generated URL is:
>>>> http://localhost:8080/xwiki/bin/view/AllDocs
>>>>
>>>> Maybe at some point we were counting the number of path segments after the 
>>>> action and if it was 1 and xwiki.usedefaultweb was set to true we would 
>>>> add “Main” as the space. 
>>>>
>>>> However that’s not the case in XWiki 5.2.4 and probably earlier.
>>>>
>>>> In addition, with Nested Pages we’ve implemented the support of a single 
>>>> path element after the action. FTR, from 
>>>> BinEntityResourceReferenceResolverTest:
>>>>
>>>> // Test when single space segment, to be Nested Document friendly.
>>>> // Normally the last segment is always the page name but we want to handle 
>>>> a special case when we
>>>> // have "/view/something" and we wish in this case to consider that 
>>>> "something" is the space. This
>>>> // is to handle Nested Documents, so that the user can have a top level 
>>&

Re: [xwiki-devs] [Proposal] Remove the "xwiki.usedefaultweb" configuration parameter

[Sergiu Dumitriu]

It is working, but only if the default action is missing as well. So
indeed /bin/view/Page doesn't work ('view' is considered the space), but
/bin/Page does work. And as far as I know, it always worked this way.

When not considering nested spaces, I'm -0 for its removal, it's a
setting that's useful for shorter URLs in a mostly read only site (e.g.
public website). I don't have a clear grasp of how nested spaces work,
so I'm not sure how this setting affects nested spaces.

On 03/29/2016 09:35 AM, Vincent Massol wrote:
> Hi devs,
> 
> I was reading the comment from Marius on 
> https://jira.xwiki.org/browse/XWIKI-13223 and indeed it seems that the 
> “xwiki.usedefaultweb” config parameter has not been working for a very long 
> time (Marius says at least before 2.7). Locally I’ve tested a 5.2.4 version 
> and indeed it’s not working.
> 
> For Main.AllDocs the generated URL is:
> http://localhost:8080/xwiki/bin/view/AllDocs
> 
> Maybe at some point we were counting the number of path segments after the 
> action and if it was 1 and xwiki.usedefaultweb was set to true we would add 
> “Main” as the space. 
> 
> However that’s not the case in XWiki 5.2.4 and probably earlier.
> 
> In addition, with Nested Pages we’ve implemented the support of a single path 
> element after the action. FTR, from BinEntityResourceReferenceResolverTest:
> 
> // Test when single space segment, to be Nested Document friendly.
> // Normally the last segment is always the page name but we want to handle a 
> special case when we
> // have "/view/something" and we wish in this case to consider that 
> "something" is the space. This
> // is to handle Nested Documents, so that the user can have a top level 
> Nested Document
> // (something.WebHome) and access it from /view/something. If we didn't 
> handle this special case
> // the user would get Main.something and thus wouldn't be able to access 
> something.WebHome. He'd
> // need to use /view/something/ which is not natural in the Nested Document 
> mode.
> testCreateResource("http://localhost/bin/space;, "view",
> buildEntityReference("wiki", Arrays.asList("space"), null), 
> fullSingleSpaceReference, EntityType.DOCUMENT);
> 
> I also don’t think it’s a big help for users to be able to omit the Main 
> space since they need to keep the other spaces in the URL anyway.
> 
> So I’m proposing to officially drop support for this parameter and remove it 
> from xwiki.cfg since it has not worked for ages.
> 
> WDYT? Have I missed something?
> 
> Thanks
> -Vincent
> 
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Turn on filesystem attachment store by default in XWiki 8.1

[Sergiu Dumitriu]

On 03/24/2016 08:02 AM, Thomas Mortagne wrote:
> On Thu, Mar 24, 2016 at 12:48 PM, Denis Gervalle <d...@softec.lu> wrote:
>> +0
>>
>> As Thomas said, it would be better to also fix the issues, this should not
>> be that hard.
>> There is also other aspects that deserve attention:
> 
>>  - migrating users, that should be warned and provided better way to
>> migrate than a snippet IMO.
> 
> Indeed.

https://github.com/phenotips/phenotips/tree/master/components/storage-migrators

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] How to setup 'Prevent unregistered users from viewing pages' in config or programmatically?

[Sergiu Dumitriu]

Yes, using the standard APIs for interacting with documents.

XWikiDocument doc = xcontext.getWiki().getDocument(, xcontext);
doc.setIntValue(,
"authenticate_view", 1);
doc.setIntValue(,
"authenticate_edit", 1);
xcontext.getWiki().saveDocument(doc, xcontext);


Or, shorter and without using the deprecated old core APIs:

@Inject
private DocumentAccessBridge bridge;
...
bridge.setProperty(, , "authenticate_view", 1);


On 03/22/2016 03:33 AM, abtv wrote:
> It's good idea, but I would prefer to use java code in xwiki instead of REST
> call from outside of xwiki. Is it possible?
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] How to setup 'Prevent unregistered users from viewing pages' in config or programmatically?

[Sergiu Dumitriu]

Oh, and the value must be 1 to enable.

On 03/21/2016 08:29 AM, Sergiu Dumitriu wrote:
> That's an object property, so you can use a normal page REST call to set it.
> 
> page: XWiki.XWikiPreferences
> object: XWiki.XWikiPreferences[0]
> property: authenticate_view / authenticate_edit
> 
> On 03/21/2016 08:07 AM, abtv wrote:
>> I would like to deny seen pages for unregistered users. I can do it via the
>> following:
>>
>> Choose `Administration` -> `Users & Groups` -> `Rights` then select 
>> `Prevent unregistered users from viewing pages, regardless of the page or
>> space rights` and 
>> `Prevent unregistered users from editing pages, regardless of the page or
>> space rights`.
>>
>> But I would like to automate it while deploying xwiki. It means no user
>> interactions with UI. Is there any way to do it? Maybe, config file or via
>> java extension?
>>
> 
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] New governance rule for xwiki.org: hosted XWiki options

[Sergiu Dumitriu]

+1

On 03/01/2016 07:48 AM, vinc...@massol.net wrote:
> Hi devs,
> 
> Our rule for what we allow on xwiki.org is documented at 
> http://dev.xwiki.org/xwiki/bin/view/Community/Governance
> 
> The spirit is that we want to keep xwiki.org an open source project but we 
> also want that:
> - it’s used to the maximum 
> - the max number of companies invest in committers to help develop the project
> 
> Thus we’ve agreed to have several parts of xwiki.org when companies having 
> active committers on the project can advertise for business solutions 
> (professional support, etc).
> 
> In order to try to increase downloads and to improve our download page Caty 
> and I are working on proposing some new designs (she’s already posted some 
> and will post some more soon). See 
> http://markmail.org/message/6wgmvwxl6h6pvogr and 
> http://markmail.org/message/ibur6fpkyx7sq7s2
> 
> As part of this effort and in order to make it even simpler to start using 
> XWiki (and to list all options), we’d like to refactor a bit xwiki.org so 
> that people who come on xwiki.org and who want to use XWiki/XE can be 
> proposed 2 alternatives:
> 1) download an install XWiki on premises
> 2) use XWiki in the cloud or as a hosted solution
> 
> For 2) the idea is to propose playground.xwiki.org to try xwiki, myxwiki.org 
> (for non profit and non supported), and solutions from companies with active 
> committers, such as XCS from XWiki SAS (in the order with the most committers 
> listed first, as usual).
> 
> Please cast your vote.
> 
> Here’s my +1
> 
> Thanks
> -Vincent
> 
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] First set of extensions to move out of wiki-platform (RESULT)

[Sergiu Dumitriu]

On 02/12/2016 05:26 AM, vinc...@massol.net wrote:
> 
> 
> On 10 Feb 2016 at 13:28:51, vinc...@massol.net 
> (vinc...@massol.net(mailto:vinc...@massol.net)) wrote:
> 
>> VOTE result: 7 +1, no 0, no -1, the VOTE is passed.
>>  
>> Now we need Lead Developers/Owner for each extension on contrib. Being an 
>> Owner means:  
>> - taking care of the extension in general, reviewing commits as much as 
>> possible (even though everyone should help), maintain the jira, etc
>> - be the one to perform releases in general
>>  
>> See below.  
>>  
>> On 21 Jan 2016 at 12:31:06, vinc...@massol.net 
>> (vinc...@massol.net(mailto:vinc...@massol.net)) wrote:
>>  
>>> Hi devs,
>>>
>>> Following the “XWiki Core” VOTE 
>>> (http://markmail.org/message/rqgqzbepzms3p6h2), I’m now proposing to move 
>>> the following extensions out of xwiki-platform and into xwiki-contrib:
>>>
>>> I’ll also start moving some extensions from platform, starting with:
>>> - xwiki-platform-blog  
>>  
>> Who would be ok to be the owner of this one? 
> 
> Nobody is hurrying to become the owner…
> 
> @Sergiu: since you’re the main dev who worked on the Blog, can I put you as 
> the lead in JIRA?

Sure.

> 
> Thanks
> -Vincent
> 
>>> - xwiki-platform-faq  
>>  
>> I can take this one if nobody wants it.  
>>  
>>> - xwiki-platform-jira
>>  
>> I can take this one if nobody wants it.  
>>  
>>> - xwiki-platform-release
>>  
>> I can take this one if nobody wants it.  
>>  
>>> - xwiki-platform-selenium
>>  
>> I can take this one if nobody wants it.  
>>  
>> Thanks  
>> -Vincent
>>  
>>> Please vote.
>>>
>>> Here’s my +1
>>>
>>> Thanks
>>> -Vincent

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] New Anti Spam API in xwiki-platform-spam

[Sergiu Dumitriu]

+1 for contrib.

On 01/29/2016 10:28 AM, vinc...@massol.net wrote:
> Hi,
> 
> On 29 Jan 2016 at 16:14:42, vinc...@massol.net 
> (vinc...@massol.net(mailto:vinc...@massol.net)) wrote:
> 
>>  
>>  
>> On 29 Jan 2016 at 16:13:38, Thomas Mortagne 
>> (thomas.morta...@xwiki.com(mailto:thomas.morta...@xwiki.com)) wrote:
>>  
>>> Why not in contrib ?
>>  
>> It could but I consider it a core service and I’d like to xwiki core dev 
>> team to maintain it. I’m volunteering of course.
> 
> After more thinking I think you’re right and we don’t need to put it in the 
> core.
> 
> So I remove my proposal for platform and I’m going to code this contrib.
> 
> Unless several other devs think it should go in platform...
> 
> Thanks
> -Vincent
> 
>> Thanks
>> -Vincent
>>  
>>> On Fri, Jan 29, 2016 at 4:10 PM, vinc...@massol.net wrote:
>>>> Hi devs,
>>>>
>>>> We’ve suffered some spamming attacks on xwiki.org recently and we’ve put 
>>>> xwiki.org under cloudflare. This should prevent some attacks but it’s not 
>>>> enough and spam is still going through.
>>>>
>>>> I’d like to propose creating a new xwiki-platform-spam module with an API 
>>>> module and a simple implementation using keyword blacklisting.
>>>>
>>>> xwiki-platform-spam
>>>> |_ xwiki-platform-spam-api
>>>> |_ xwiki-platform-spam-simple
>>>>
>>>> We could imagine adding an akismet implementation later on: 
>>>> xwiki-platform-spam-akismet
>>>>
>>>> For the simple implementation, I’d like to be able to configure the 
>>>> keywords in xobjects to make it simple to update and have the community 
>>>> helping.
>>>>
>>>> The API would be simple:
>>>>
>>>> @Role
>>>> public interface SpamChecker
>>>> {
>>>> /**
>>>> * Checks if the passed content is considered spam or not.
>>>> *
>>>> * @param content the content to check
>>>> * @param parameters a map of parameters that depends on the implementation 
>>>> used. For example this can include the
>>>> * IP address of the submitter of the content, its email address, the date 
>>>> of submission, etc
>>>> * @return true if the content is considered spam or false otherwise
>>>> */
>>>> boolean isSpam(Reader content, Map parameters);
>>>> }
>>>>
>>>>
>>>> Then the idea would be to have an EventListener for page save and comment 
>>>> save and go through this API.
>>>>
>>>> WDYT?
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Keep old LTS till next version N.4.1 is released

[Sergiu Dumitriu]

+1 for proposal 2.

On 01/04/2016 03:46 AM, vinc...@massol.net wrote:
> Hi devs,
> 
> I see on http://enterprise.xwiki.org/xwiki/bin/view/Main/Download that the 
> new LTS is 7.4.
> 
> I think that’s a bit dangerous because LTS means that users can put it in 
> production with eyes closed and we’re guaranteeing stability. In practice 
> it’s a bit too early to decide if 7.4 is really that stable.
> 
> In the future I’d suggest that we wait till 7.4.1 (i.e. N.4.1) is released 
> because we remove the previous LTS and swap it with the new one.
> 
> WDYT?
> 
> Thanks
> -Vincent


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Retire XMLRPC

[Sergiu Dumitriu]

+1, REST is king.
On Sep 21, 2015 10:03 AM, "vinc...@massol.net"  wrote:

> Hi devs,
>
> I’d like that we retire the XMLRPC feature of XWiki.
>
> Rationale:
> * We now have a REST API
> * The XMLRPC API is pretty old now, doesn’t support Nested Spaces, see
> http://jira.xwiki.org/browse/XWIKI-1249
>
> The idea would be to:
> * Step 1: Relocate the code in an optional module (in addition to or
> inside one of the existing xmlrpc modules). This means handling some code
> currently in oldcore + update web.xml
> * Step 2: Move the optional xmlrpc modules to the github contrib
> organization
> * Step 3: Update documentation on xwiki.org and add an entry on e.x.o
> (move doc from http://platform.xwiki.org/xwiki/bin/view/Features/XMLRPC in
> it).
>
> Note that this will mean that XOffice will require users to install XMLRPC
> first if they want to try using it. Not a problem IMO. It’s also possible
> that the same will apply to XEclipse (or not) as I don’t remember if we had
> moved the code to use REST or not.
>
> WDYT?
>
> Here’s my +1
>
> Thanks
> -Vincent
>
> PS: FTR, first time this was discussed on the list:
> http://markmail.org/message/gnockgbhnbfroa75
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Page Identifier or Page Name?

[Sergiu Dumitriu]

Agree with Vincent, and I'm actually -1 for changing it to identifier.
Internally, a document already has an identifier, the generated hash.

On 08/25/2015 11:53 AM, vinc...@massol.net wrote:
 You do realize that changing “page name” to “identifier” means introducing a 
 new vocabulary and means
 - changing lots of wiki pages on xwiki.org, 
 - changing APIs that will no longer be consistent, such as pageName in the 
 REST model, getPageName() in create.js, etc
 - changing all places in the UI where we use “page name
 
 That’s a *huge* work...
 
 ATM I’m -0 and very close to -1 to change the vocabulary since we already 
 have a lot to do with NS/ND.
 
 Thanks
 -Vincent
 
 Hi,  
 
 With the latest changes to the create UI [1] we`ve changed (mostly  
 following the agreed-ish proposal [2]) the old Page Name label in the  
 create UI to Identifier because we believed that having both Page Title  
 and Page Name on the same page would confuse users and they would not  
 know which one to use.  
 
 Now, I`d like your quick vote on which one to stick with, since some might  
 consider that Page Name is better.  
 
 One argument for page name (i.e. against identifier) is that an  
 identifier is usually globally unique and in our case this is only true  
 within the same parent. Also, copying a document to a new location and  
 preserving its identifier can feel a bit odd to some, since they would  
 expect the need for a new identifier. Feel free to express your other  
 arguments.  
 
 Another argument for identifier besides the one already mentioned is that  
 it also better reflects its technical nature and should discourage  
 users from working with it and they should be using the document's title  
 instead of their needs (both in the create step and further along).  
 
 Here's my +1 for identifier.  
 
 WDYT?  
 
 Thanks,  
 Eduard  
 
 --  
 [1] http://jira.xwiki.org/browse/XWIKI-12231  
 [2]  
 http://design.xwiki.org/xwiki/bin/download/Proposal/NestedCreate/createTitle1.png
   
 ___  
 devs mailing list  
 devs@xwiki.org  
 http://lists.xwiki.org/mailman/listinfo/devs  
 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs
 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Page Identifier or Page Name?

[Sergiu Dumitriu]

I'm not entirely against changing it to something else, but I can't find
anything less restrictive/technical than identifier but more technical
than name. Does anybody have any suggestions?

Another alternative is to add hints in the form, explaining in more
detail what is a title and what is a name.

On 08/26/2015 06:54 AM, Eduard Moraru wrote:
 We have 2.5 -1s for switching to Identifier so the conclusion is that
 we`ll continue using Page Name.
 
 Thanks for the votes and the arguments!
 
 -Eduard
 
 On Wed, Aug 26, 2015 at 11:47 AM, Thomas Mortagne thomas.morta...@xwiki.com
 wrote:
 
 I indeed forgot about XWikiDocument#getId which move my vote to -1.


 On Wed, Aug 26, 2015 at 10:08 AM, Sergiu Dumitriu ser...@xwiki.com
 wrote:
 Agree with Vincent, and I'm actually -1 for changing it to identifier.
 Internally, a document already has an identifier, the generated hash.

 On 08/25/2015 11:53 AM, vinc...@massol.net wrote:
 You do realize that changing “page name” to “identifier” means
 introducing a new vocabulary and means
 - changing lots of wiki pages on xwiki.org,
 - changing APIs that will no longer be consistent, such as pageName in
 the REST model, getPageName() in create.js, etc
 - changing all places in the UI where we use “page name

 That’s a *huge* work...

 ATM I’m -0 and very close to -1 to change the vocabulary since we
 already have a lot to do with NS/ND.

 Thanks
 -Vincent

 Hi,

 With the latest changes to the create UI [1] we`ve changed (mostly
 following the agreed-ish proposal [2]) the old Page Name label in the
 create UI to Identifier because we believed that having both Page
 Title
 and Page Name on the same page would confuse users and they would not
 know which one to use.

 Now, I`d like your quick vote on which one to stick with, since some
 might
 consider that Page Name is better.

 One argument for page name (i.e. against identifier) is that an
 identifier is usually globally unique and in our case this is only
 true
 within the same parent. Also, copying a document to a new location and
 preserving its identifier can feel a bit odd to some, since they would
 expect the need for a new identifier. Feel free to express your other
 arguments.

 Another argument for identifier besides the one already mentioned is
 that
 it also better reflects its technical nature and should discourage
 users from working with it and they should be using the document's title
 instead of their needs (both in the create step and further along).

 Here's my +1 for identifier.

 WDYT?

 Thanks,
 Eduard

 --
 [1] http://jira.xwiki.org/browse/XWIKI-12231
 [2]

 http://design.xwiki.org/xwiki/bin/download/Proposal/NestedCreate/createTitle1.png
 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs
 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs



 --
 Sergiu Dumitriu
 http://purl.org/net/sergiu
 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs



 --
 Thomas Mortagne
 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs

 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs
 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Move OSCache based cache module to contrib

[Sergiu Dumitriu]

+1, besides the project has been retired in 2011.

On 07/09/2015 12:08 PM, Thomas Mortagne wrote:
 Hi devs,
 
 We never used OSCache based cache module in years and we never upgrade
 OSCache dependency.
 
 It was mostly created for retro compatibility when we moved to JBoss
 Cache and to have more that one implementation of the API to do
 something generic enough but we passed first API design period since a
 long time now...
 
 Here is my +1
 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Do not use dom4j anymore and instead use JDOM2

[Sergiu Dumitriu]

A quick code search on openhub and github:

* library | openhub | github
* org.w3c.dom | 180k [1] | 1.1m [2]
* jdom 1 | 35k [3] | 112k [4]
* stax | 25k [5] | 127k [6]
* jdom 2 | 2k [7] | | 20k [8]

It seems that jdom2 is not that popular, at least not in the projects
tracked by openhub or hosted on github.

[1] http://code.openhub.net/search?s=%22import%20org.w3c.dom%22
[2] https://github.com/search?q=import+org.w3c.domtype=Code
[3] http://code.openhub.net/search?s=%22import%20org.jdom%22
[4] https://github.com/search?q=%22import+org.jdom.%22type=Code
[5] http://code.openhub.net/search?s=%22import%20javax.xml.stream%22
[6] https://github.com/search?q=%22import+javax.xml.stream%22type=Code
[7] http://code.openhub.net/search?s=%22import%20org.jdom2%22
[8] https://github.com/search?q=%22import+org.jdom2%22type=Code

On 06/10/2015 03:53 PM, Paul Libbrecht wrote:
 
 
 On 10/06/15 21:47, Sergiu Dumitriu wrote:
 +1 for removing DOM4J, it's been dead for 10 years.
 But why do we need a non w3c library at all? Why is JDOM better than DOM?
 The main reason is that it is supposedly easier to use for Java
 programmers, but is it that much easier to justify having different
 APIs? The standard DOM is part of the Java language.
 Well... my experience in the ActiveMath group with quite several
 developers is that JDOM is way easier at representing properly the fine
 details of XML in its completeness than DOM. Also, we ran experiment
 with the Xerces DOM implementation around 2005 or so, and basically got
 the following time factors
 - Xerces DOM: 4
 - Xerces SAX with JDOM: 2
 - Saxon SAX with JDOM: 1
 So we kept the latest. Note that Xerces is what's inside Oracle's JVM
 (or used to be).
 Memory was also considerably better using JDOM.
 
 The modern way would be to go for StAX but that is a huge programming
 change.
 
 paul
 
 
 

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Do not use dom4j anymore and instead use JDOM2

[Sergiu Dumitriu]

+1 for removing DOM4J, it's been dead for 10 years.

But why do we need a non w3c library at all? Why is JDOM better than DOM?

The main reason is that it is supposedly easier to use for Java
programmers, but is it that much easier to justify having different
APIs? The standard DOM is part of the Java language.

On 06/10/2015 11:07 AM, vinc...@massol.net wrote:
 Hi devs,
 
 I’d like to propose that we agree about:
 * using JDOM2 when needing to parse/output XML files
 * moving away existing code gradually from DOM4J to JDOM2
 
 Rationale:
 * It would be nice to pick one fwk and have more consistency
 * DOM4J seems not maintained anymore: 
 https://sourceforge.net/projects/dom4j/files/
 * JDOM2 seems maintained: http://jdom.org/news/
 
 WDYT?
 
 Thanks
 -Vincent


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Bug in getusers.vm?

[Sergiu Dumitriu]

  
 Note #1: I've still not found a solution to stopping the velocity
 parser from evaluating below a certain point.  
 
 #stop ?
 
 See 
 http://velocity.apache.org/engine/releases/velocity-1.7/user-guide.html#Stop
 

That stops the rendering as well, and we want to get all the JS code
that comes afterwards.

Maybe #[[ ... ]]# is what we want?

http://velocity.apache.org/engine/devel/vtl-reference-guide.html#Unparsed_Content

It depends on not having ]]# present in the source, but I guess that's
fine since we would explicitly use this when needed.
-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Solr] Word delimiter filter on English text

[Sergiu Dumitriu]

Well, my usecase is not the same, since I'm indexing ontologies and the
end purpose is to find the best matching terms. A few numbers though:

- 4MB ontology with 11k terms ends up as 16M index (including
spellcheck, and most fields are also stored), searches take ~40ms
including the XWiki overhead, ~10ms just in Solr
- 180MB ontology with 24k terms - 100M index, ~15ms Solr search time

For smaller indexes, it does seem to use more disk space than the
source, but Lucene is good at indexing larger data sets, and after a
while the index grows slower than the data.

For me it is worth the extra disk space, since every user is amazed by
how good the search is at finding the relevant terms, overcoming typos,
synonyms, and abbreviations, plus autocomplete while typing.

In XWiki, not all fields should be indexed in all the ways, since it
doesn't make sense to expect an exact match on a large textarea or the
document content.

On 05/07/2015 09:57 AM, Marius Dumitru Florea wrote:
 Hi Sergiu,
 
 Can you tell us the effect on the index size (and speed in the end) if
 each field (e.g. document title, a String or TextArea property) is
 indexed in 5 different ways (5 separate fields in the index)? It is
 worth having this configuration by default?
 
 Thanks,
 Marius
 
 On Tue, May 5, 2015 at 4:57 PM, Sergiu Dumitriu ser...@xwiki.org wrote:
 I agree with Paul.

 The way I usually do searches is:

 - each field gets indexed several times, including:
 -- exact matches ^5n (field == query)
 -- prefix matches ^1.5n (field ^= query)
 -- same spelling ^1.8n (query words in field)
 -- fuzzy matching ^n (aggressive tokenization and stemming)
 -- stub matching ^.5n (query tokens are prefixes of indexed tokens)
 -- and three catch-all fields where every other field gets copied, with
 spelling, fuzzy and stub variants
 - where n is a factor based on the field's importance: page title and
 name have the highest boost, a catch-all field has the lowest boost
 - search with edismax, pf with double the boost (2n) on
 exact,prefix,spelling,fuzzy and qf on spelling,fuzzy,stub

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

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Solr] Word delimiter filter on English text

[Sergiu Dumitriu]

On 05/08/2015 05:22 AM, Marius Dumitru Florea wrote:
 On Fri, May 8, 2015 at 10:39 AM, Sergiu Dumitriu ser...@xwiki.org wrote:
 Well, my usecase is not the same, since I'm indexing ontologies and the
 end purpose is to find the best matching terms. A few numbers though:

 - 4MB ontology with 11k terms ends up as 16M index (including
 spellcheck, and most fields are also stored), searches take ~40ms
 including the XWiki overhead, ~10ms just in Solr
 - 180MB ontology with 24k terms - 100M index, ~15ms Solr search time

 For smaller indexes, it does seem to use more disk space than the
 source, but Lucene is good at indexing larger data sets, and after a
 while the index grows slower than the data.

 
 For me it is worth the extra disk space, since every user is amazed by
 how good the search is at finding the relevant terms, overcoming typos,
 synonyms, and abbreviations, plus autocomplete while typing.
 
 You do this for multiple languages or just for English? In other
 words, do you have text_fr_splitting, text_es_splitting etc.?

At the moment only English.

 Thanks Sergiu, I'll definitely take this into account.
 Marius
 

 In XWiki, not all fields should be indexed in all the ways, since it
 doesn't make sense to expect an exact match on a large textarea or the
 document content.

 On 05/07/2015 09:57 AM, Marius Dumitru Florea wrote:
 Hi Sergiu,

 Can you tell us the effect on the index size (and speed in the end) if
 each field (e.g. document title, a String or TextArea property) is
 indexed in 5 different ways (5 separate fields in the index)? It is
 worth having this configuration by default?

 Thanks,
 Marius

 On Tue, May 5, 2015 at 4:57 PM, Sergiu Dumitriu ser...@xwiki.org wrote:
 I agree with Paul.

 The way I usually do searches is:

 - each field gets indexed several times, including:
 -- exact matches ^5n (field == query)
 -- prefix matches ^1.5n (field ^= query)
 -- same spelling ^1.8n (query words in field)
 -- fuzzy matching ^n (aggressive tokenization and stemming)
 -- stub matching ^.5n (query tokens are prefixes of indexed tokens)
 -- and three catch-all fields where every other field gets copied, with
 spelling, fuzzy and stub variants
 - where n is a factor based on the field's importance: page title and
 name have the highest boost, a catch-all field has the lowest boost
 - search with edismax, pf with double the boost (2n) on
 exact,prefix,spelling,fuzzy and qf on spelling,fuzzy,stub


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Solr] Word delimiter filter on English text

[Sergiu Dumitriu]

I agree with Paul.

The way I usually do searches is:

- each field gets indexed several times, including:
-- exact matches ^5n (field == query)
-- prefix matches ^1.5n (field ^= query)
-- same spelling ^1.8n (query words in field)
-- fuzzy matching ^n (aggressive tokenization and stemming)
-- stub matching ^.5n (query tokens are prefixes of indexed tokens)
-- and three catch-all fields where every other field gets copied, with
spelling, fuzzy and stub variants
- where n is a factor based on the field's importance: page title and
name have the highest boost, a catch-all field has the lowest boost
- search with edismax, pf with double the boost (2n) on
exact,prefix,spelling,fuzzy and qf on spelling,fuzzy,stub

On 05/05/2015 08:28 AM, Paul Libbrecht wrote:
 Eddy,
 We want both or?
 Dies the query not use edismax? 
 If yes, we should make it search the field text_en with higher weight than 
 text_en_splitting by setting the boost parameter to
 ‎ text_en^2 text_eb_splitting^1
 Or?
 Paul
 
 
 -- fat fingered on my z10 --
   Message d'origine  
 De: Eduard Moraru
 Envoyé: Dienstag, 5. Mai 2015 14:13
 À: XWiki Developers
 Répondre à: XWiki Developers
 Objet: Re: [xwiki-devs] [Solr] Word delimiter filter on English text
 
 Hi,
 
 The question is about content fields (document contet, textarea content,
 etc.) and not about the document's space name and document name fields,
 which will still match in both approaches, right?
 
 As far as I`ve understood it, text_en gets less matches than
 text_en_splitting, but text_en has better support for cases where in
 text_en_splitting you would have to use a phrase query to get the match
 (e.g. Blog.News, xwiki.com, etc.).
 
 IMO, text_en_splitting sounds more adapted to real life uses and to the
 fuzziness of user queries. If we want explicit matches for xwiki.com or
 Blog.News within a document's content, phrase queries can still be used,
 right? (i.e. quoting the explicit string).
 
 Thanks,
 Eduard
 
 
 On Tue, May 5, 2015 at 12:55 PM, Marius Dumitru Florea 
 mariusdumitru.flo...@xwiki.com wrote:
 
 Hi guys,

 I just noticed (while updating the screen shots for the Solr Search UI
 documentation [1]) that searching for blog doesn't match Blog.News
 from the category of BlogIntroduction any more as indicated in [2].

 Debug mode view shows me that Blog.News is indexed as blog.new
 which means the text is not split in blog and news as I would have
 expected in this case.

 After checking the Solr schema configuration I understood that this is
 normal considering that we use the Standard Tokenizer [3] for English
 text which has this exception:

 Periods (dots) that are not followed by whitespace are kept as part
 of the token, including Internet domain names.

 Further investigation showed that before 6.0M1 we used the Word
 Delimiter Filter [4] for English text but I changed this with
 XWIKI-8911 when upgrading to Solr 4.7.0.

 I then noticed that the Solr schema has both text_en and
 text_en_splitting types, the later with this comment:

 A text field with defaults appropriate for English, plus aggressive
 word-splitting and autophrase features enabled. This field is just
 like text_en, except it adds WordDelimiterFilter to enable splitting
 and matching of words on case-change, alpha numeric boundaries, and
 non-alphanumeric chars. This means certain compound word cases will
 work, for example query wi fi will match document WiFi or wi-fi.

 So in case someone wants to use this type instead for English text he
 needs to change the type in:

 dynamicField name=*_en type=text_en indexed=true stored=true
 multiValued=true /

 The question is whether we should use this type by default or not. As
 explained in the comment above, there are downsides.

 Thanks,
 Marius

 [1]
 http://extensions.xwiki.org/xwiki/bin/view/Extension/Solr+Search+Application
 [2]
 http://extensions.xwiki.org/xwiki/bin/download/Extension/Solr+Search+Application/searchHighlighting.png
 [3]
 https://cwiki.apache.org/confluence/display/solr/Tokenizers#Tokenizers-StandardTokenizer
 [4]
 https://cwiki.apache.org/confluence/display/solr/Filter+Descriptions#FilterDescriptions-WordDelimiterFilter
 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs

 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs
 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs
 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Remove xwiki-platform-legacy-crypto-script module

[Sergiu Dumitriu]

+1, I like to see legacy code gone.

On 04/23/2015 03:22 AM, vinc...@massol.net wrote:
 Hi devs,
 
 With the upgrade of BouncyCastle to version 1.52 the 
 xwiki-platform-legacy-crypto-script legacy module doesn’t build anymore since 
 BC has removed deprecated code.
 
 We have of course the option to try to fix the legacy code to use newer APIs.
 
 However I think this is overkill and not needed because I don’t believe this 
 legacy code was ever used (Caleb, the author of it, seems to agree with this).
 
 See the comments at http://jira.xwiki.org/browse/XCOMMONS-794 
 
 Thus, according to our rules, I’m sending this VOTE to decide to break this 
 API voluntarily by removing this legacy module.
 
 Here’s my +1
 
 Thanks
 -Vincent
 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [PROPOSAL] Change the webjars URL mapping

[Sergiu Dumitriu]

On 04/04/2015 01:46 AM, Eduard Moraru wrote:
 
 IMO, the ID (if this is what you refer to as resource name) should always
 be between 2 /es. If the resource name contains a / itself, then it
 should be URL escaped by the caller.

Don't forget that escaped / is not allowed in URLs by default by both
HTTPD and Tomcat.

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Google Maps with polygons

[Sergiu Dumitriu]

Maybe this is what you want:
http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial

On 04/18/2015 07:17 PM, Niko B wrote:
 Hello,
 
 I have an Xwiki server setup on Debian 7 using tomcat7 and mysql. I was 
 wondering if there is a way to embed a google map with a polygon (a portion 
 of the map highlighted). I have tried the regular google maps extension and 
 it works great except for the lack of polygons. I was able to generate some 
 javascript code for what I want. Is there a way to display javascript on the 
 page? I have tried the d3js plugin but cant seem to figure out how to insert 
 the code. 
 
 Any help would be much appreciated. 
 
 Thanks!
 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs
 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] build error with xwiki-enterprise

[Sergiu Dumitriu]

 - Debian - Tomcat 8 - MySQL  SKIPPED
 [INFO] XWiki Enterprise - Installer - Debian - Tomcat 8 - Postgres SQL
 SKIPPED
 [INFO]
 
 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 9:40.418s
 [INFO] Finished at: Wed Mar 25 15:10:01 PDT 2015
 [INFO] Final Memory: 123M/983M
 [INFO]
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-antrun-plugin:1.7:run (run-launch4j) on
 project xwiki-enterprise-installer-windows: An Ant BuildException has
 occured: net.sf.launch4j.BuilderException: net.sf.launch4j.ExecException:
 java.io.IOException: Cannot run program
 /home/likewise-open/ANT/nixpeter/Projects/xwiki/xwiki-enterprise/xwiki-enterprise-installers/xwiki-enterprise-installer-windows/target/dependency/bin/windres:
 error=2, No such file or directory
 [ERROR] around Ant part ...launch4j
 configFile=/home/likewise-open/ANT/nixpeter/Projects/xwiki/xwiki-enterprise/xwiki-enterprise-installers/xwiki-enterprise-installer-windows/target/classes/launch4j.xml/...
 @ 6:183 in
 /home/likewise-open/ANT/nixpeter/Projects/xwiki/xwiki-enterprise/xwiki-enterprise-installers/xwiki-enterprise-installer-windows/target/antrun/build-main.xml
 [ERROR] - [Help 1]
 [ERROR]
 [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
 switch.
 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
 [ERROR]
 [ERROR] For more information about the errors and possible solutions,
 please read the following articles:
 [ERROR] [Help 1]
 http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
 [ERROR]
 [ERROR] After correcting the problems, you can resume the build with the
 command
 [ERROR]   mvn goals -rf :xwiki-enterprise-installer-windows
 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs
 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Migration Manager Subsystems

[Sergiu Dumitriu]

There is, take a look at what's happening here:

https://github.com/phenotips/phenotips/blob/master/components/patient-data-sharing/secure-storage/src/main/java/org/phenotips/data/securestorage/internal/SecureStorageRegistrationHandler.java

This registers a class as a supported entity type, where the class uses
annotations to define the mapping. I'd recommend using annotations as
well, unless you prefer XML mapping files, in which case you can change
addAnnotatedClass with addFile(path to mapping file).

I think this only works after the wiki is restarted, since an extension
installed while the wiki is running won't receive the
ApplicationStartedEvent.

On 03/20/2015 11:54 AM, Marc Sladek wrote:
 Hi Vincent
 
 Thanks for your answer. The celements team is indeed interested in
 contributing more to the XWiki project. Therefore we would be willing to
 develop a migration module the way you proposed. This would also enable
 us to upgrade celements to a more recent XWiki version. If you agree, we
 could start with a design document on http://design.xwiki.org.
 
 On an somewhat unrelated note, is there a way to include hibernate
 mappings in XWiki Extensions? I cannot find any mention of it in the
 extension wiki
 (http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Manager+Application).
 
 
 Regards
 
 Marc
 synventis gmbh
 
 On 20.02.2015 14:09, vinc...@massol.net wrote:
 Hi Marc,

 On 18 Feb 2015 at 17:19:01, Marc Sladek
 (marc.sla...@synventis.com(mailto:marc.sla...@synventis.com)) wrote:

  Dear XWiki devs
 
  Within the scope of our XWiki-based project called celements, we are
 using
  several so-called modules, which consist of JARs, web resources
  (VM/CSS/JS files) and hibernate mappings. These modules extend the
  functionality of the base application and can be optionally added if
  required. We need to update and migrate these modules independently
 from
  XWiki. Therefore we require to store individual migration version
 numbers
  in the database for each module.
 
  XWiki's single implementation of
  DataMigrationManager, HibernateDataMigrationManager, isn't intended to
  store multiple version numbers with specific identifiers in the
 database.
  There also doesn't seem to be an evident hook from XWiki to
 seamlessly add
  own implementations of the DataMigrationManager to the application to
  allow migration subsystems.
 
  Considering the similarities of XWiki extensions to our modules, is
 there
  already a way that we have missed to achieve independent migrations
 of our
  modules?

 I recently introduced the xwiki-platform-instance module which creates
 its own DB table to store the XWiki instance id. You can do something
 similar for your “modules”, i.e. one table with each row containing a
 module name + a module version.

 Another option you have is to use the permanent directory and store
 the versions in a file there (in a properties file for example to make
 it easy to read/write).

 About hooks, there’s an Application Started Event or a Database Ready
 Event that you can use to perform your checks/migrations.

  If not, are there any future plans from XWiki's side to add this
  functionality?

 We’ve not seen the need so far, so there’s no future plan ATM.

 Now, if you’re willing to work on this, I guess it could be possible
 to refactor the XWiki Migration Manager into its own module in XWiki
 and in addition, make it more generic so that it can support plugging
 external migrations that would want to benefit from a store and from
 hibernate/liquibase migrations.

 It’s certainly not a priority for the xwiki dev team but if you were
 willing to do the work, maybe it’s possible. Don’t know what others
 think about this.

 We’re always happy to get more contributions in general! It would be
 great if the celements team (http://www.celements.ch/Home?language=en)
 could contribute more stuff on extensions.xwiki.org
 http://extensions.xwiki.org or participate to XWiki’s dev in one way
 or another! :) (having some active committer in the project would also
 allow you to advertise your company/project on xwiki.org
 http://xwiki.org, see
 http://dev.xwiki.org/xwiki/bin/view/Community/Governance).

 Thanks
 -Vincent

  Thanks in advance
 
  Marc Sladek
  synventis gmbh
 
 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Move to Servlet 3.0 now in 7.0

[Sergiu Dumitriu]

+1.

Tomcat 7 is available by default in RHEL7, which has been out for 9
months already, and for RHEL6 as part of the EPEL repository.

Also available for Debian stable.

On 03/13/2015 05:06 AM, vinc...@massol.net wrote:
 Hi devs,
 
 I know this comes slightly late in the 7.0 dev timeframe but now is better 
 than later…
 
 So the vote is about moving to Servlet 3.0 right now for 7.0RC1. The issue 
 has been opened a long time ago at http://jira.xwiki.org/browse/XWIKI-9358 
 and now is a good time.
 
 For full disclosure, my sudden urge comes from the need to use at least 
 Servlet 2.5 to properly and cleanly fix 
 http://jira.xwiki.org/browse/XWIKI-11843, so this would kill 2 birds with one 
 stone.
 
 If someone is -1, then I’d still like to move to Servlet 2.5 at least.
 
 Here’s my +1
 
 Thanks
 -Vincent


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] About using the @Priority annotation when components need priority

[Sergiu Dumitriu]

.

 Thanks
 -Vincent

 Thanks,
 Eduard

 --
 [1] http://docs.oracle.com/javaee/7/api/javax/annotation/Priority.html
 [2] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7151010
 [3]

 http://stackoverflow.com/questions/1554112/multiple-annotations-of-the-same-type-on-one-element

 On Thu, Mar 12, 2015 at 10:41 AM, vinc...@massol.net
 wrote:

 Hi devs,

 As part of http://jira.xwiki.org/browse/XWIKI-11905, Edy has started
 using the Java @Priority annotation.

 This seems very good and I personally didn’t know about this annotation
 before (maybe it’s been introduced not that long ago?). So for me it
 raises
 the question of: do we want to use this annotation more and how does it
 compare with what we’ve done so far.

 I can think of a few places that could have used it:

 * Macros.get/setPriority(). It should be possible to add support for
 @Priority and modify MacroTransformation to use that annotation.
 * Transformations. We have a jira issue opened for adding support for
 Priority in Transformation’s executions (in TransformationManager).
 * @DisposePriority (used by ECM).
 * TranslationBundle.get/setPriority()
 * … and probably some other places…

 However, I think there’s a namespacing problem. For example imagine
 that
 we code a Macro and set @Priority on that Macro component. The ECM
 could
 interpret it as a dispose priority while the MacroTransformation could
 interpret it as an execution priority…

 Globally I think that use an annotation for expressing priority is
 great
 and much better than what we’ve done in the past with get/setPriority()
 methods. It’s better because priority is not a business concept and
 we’re
 polluting the business interface with it.

 Now, in order to fix the namespacing issue, I think that the best
 solution
 is that each module requiring some priority should introduce its own
 annotation and should NOT depend on the @Priority one from the JDK
 (i.e. we
 ban the usage of it).

 WDYT?

 Thanks
 -Vincent


 W

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Plan to remove XWiki Enterprise

[Sergiu Dumitriu]

That is doable, in two ways:

1. Merge xwiki-enterprise into xwiki-platform, move the modules we want
to keep in their new location, delete the modules we don't need anymore.
This requires planning where every module goes in advance, and fixes
everything at once.

2. Extract each module that we want to keep in a separate git
repository, using https://gist.github.com/sdumitriu/1993357 (I need to
update this with a better version), and merge it into xwiki-platform.
This lets us handle each module at a time, but extracting a module takes
a while.

On 03/09/2015 08:56 AM, Ecaterina Moraru (Valica) wrote:
 Just some mentions about these removes/moves:
 - We moved before things from XE to Platform. It's a pain if you want to
 'blame' the source and in the JIRA issue we don't have a link from where
 the page was moved from. Tracking the history for a moved page is difficult
 and a comment stating where the location was is useful.
 - What will happen with the history if we remove the XE repository?
 
 Although the history + the blame use case might not be interesting for
 everyone, myself I'm using it often to understand the initial purpose of
 the feature, to determine if it's a regression, to know which person to
 contact, etc.
 
 Do we have a strategy for keeping the history somehow?

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Using Less4j by default in XWiki

[Sergiu Dumitriu]

+0.

On 03/03/2015 10:59 AM, Marius Dumitru Florea wrote:
 +0
 
 Thanks,
 Marius
 
 On Tue, Mar 3, 2015 at 5:17 PM, Guillaume Louis-Marie Delhumeau
 gdelhum...@xwiki.com wrote:
 Some news.

 Less4j 1.9.0 has been released recently and fixes the blocker points we had
 before.

 At first, I wanted to add an option to be able to chose which version we
 want to use in XWiki: the official lessjs or the java port less4j.

 But I have changed my mind since lessjs have a lot of limitations that
 less4j does not:

 - it only handle files, so when I want to include a template (from a skin
 document for example), I have to create a temporary directory and to put a
 copy of this template there. It is not clean and complicated to maintain
 [1].
 - it has some bugs that less4j does not [2].
 - we are currently blocked to the version 1.7.x because recent versions of
 lessjs does not work with Rhino [3].

 On the other hand, using Less4j is really simple and faster.

 So I update the proposal and I propose now to only use Less4j and get rid
 of the lessjs/rhino solution.

 Here is my +1

 Thanks,
 Guillaume

 [1]:
 https://github.com/xwiki/xwiki-platform/blob/xwiki-platform-6.4.2/xwiki-platform-core/xwiki-platform-lesscss/xwiki-platform-lesscss-default/src/main/java/org/xwiki/lesscss/internal/compiler/CachedIntegratedLESSCompiler.java#L103
 [2]: https://github.com/less/less.js/issues/1968
 [3]: https://github.com/less/less.js/issues/2316

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Fw: [ANNOUNCE] Apache Solr 5.0.0 and Reference Guide for Solr 5.0 released

[Sergiu Dumitriu]

On 02/21/2015 03:38 AM, vinc...@massol.net wrote:
 FYI. Could be interesting for us to upgrade. Don’t know if it’s backward 
 compatible with 4.x or not though.

It is, but not with 3.x. The lucene module has been removed from XE, so
that doesn't matter, but I can't remember if we ever used Solr 3.x?

 
 Thanks
 -Vincent
 On 21 Feb 2015 at 01:05:53, Anshum Gupta (ans...@apache.org) wrote:
 
 20 February 2015, Apache Solr™ 5.0.0 and Reference Guide for Solr 5.0 
 available
 
 The Lucene PMC is pleased to announce the release of Apache Solr 5.0.0
 
 Solr is the popular, blazing fast, open source NoSQL search platform
 from the Apache Lucene project. Its major features include powerful
 full-text search, hit highlighting, faceted search, dynamic
 clustering, database integration, rich document (e.g., Word, PDF)
 handling, and geospatial search.  Solr is highly scalable, providing
 fault tolerant distributed search and indexing, and powers the search
 and navigation features of many of the world's largest internet sites.
 
 Solr 5.0 is available for immediate download at:
   http://lucene.apache.org/solr/mirrors-solr-latest-redir.html
 
 See the CHANGES.txt file included with the release for a full list of
 details.
 
 Solr 5.0 Release Highlights:
 
  * Usability improvements that include improved bin scripts and new and 
 restructured examples.
 
  * Scripts to support installing and running Solr as a service on Linux.
 
  * Distributed IDF is now supported and can be enabled via the config. 
 Currently, there are four supported implementations for the same:
 * LocalStatsCache: Local document stats.
 * ExactStatsCache: One time use aggregation
 * ExactSharedStatsCache: Stats shared across requests
 * LRUStatsCache: Stats shared in an LRU cache across requests
 
  * Solr will no longer ship a war file and instead be a downloadable 
 application.
 
  * SolrJ now has first class support for Collections API.
 
  * Implicit registration of replication,get and admin handlers.
 
  * Config API that supports paramsets for easily configuring solr parameters 
 and configuring fields. This API also supports managing of pre-existing 
 request handlers and editing common solrconfig.xml via overlay.
 
  * API for managing blobs allows uploading request handler jars and 
 registering them via config API.
 
  * BALANCESHARDUNIQUE Collection API that allows for even distribution of 
 custom replica properties.
 
  * There's now an option to not shuffle the nodeSet provided during 
 collection creation.
 
  * Option to configure bandwidth usage by Replication handler to prevent it 
 from using up all the bandwidth.
 
  * Splitting of clusterstate to per-collection enables scalability 
 improvement in SolrCloud. This is also the default format for new Collections 
 that would be created going forward.
 
  * timeAllowed is now used to prematurely terminate requests during query 
 expansion and SolrClient request retry.
 
  * pivot.facet results can now include nested stats.field results constrained 
 by those pivots.
 
  * stats.field can be used to generate stats over the results of arbitrary 
 numeric functions.
 It also allows for requesting for statistics for pivot facets using tags.
 
  * A new DateRangeField has been added for indexing date ranges, especially 
 multi-valued ones.
 
  * Spatial fields that used to require units=degrees now take 
 distanceUnits=degrees/kilometers miles instead.
 
  * MoreLikeThis query parser allows requesting for documents similar to an 
 existing document and also works in SolrCloud mode.
 
  * Logging improvements:
 * Transaction log replay status is now logged
 * Optional logging of slow requests.
 
 Solr 5.0 also includes many other new features as well as numerous
 optimizations and bugfixes of the corresponding Apache Lucene release.
 
 Detailed change log:
 http://lucene.apache.org/solr/5_0_0/changes/Changes.html
 
 Also available is the Solr Reference Guide for Solr 5.0. This 535 page 
 PDF serves as the definitive user's manual for Solr 5.0. It can be downloaded 
 from the Apache mirror network: https://s.apache.org/Solr-Ref-Guide-PDF
 
 Please report any feedback to the mailing lists
 (http://lucene.apache.org/solr/discussion.html)
 
 Note: The Apache Software Foundation uses an extensive mirroring network
 for distributing releases.  It is possible that the mirror you are using
 may not have replicated the release yet.  If that is the case, please
 try another mirror.  This also goes for Maven access.
 
 -- 
 Anshum Gupta
 http://about.me/anshumgupta
 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs
 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] New Translation property naming rules

[Sergiu Dumitriu]

Since we will enter XWiki-related keys most of the time, we should save
keystrokes and go for option 2, i.e. no xwiki. prefix.

On 02/21/2015 03:55 AM, vinc...@massol.net wrote:
 Hi Sergiu,
 
 On 20 Feb 2015 at 21:47:45, Sergiu Dumitriu
 (ser...@xwiki.org(mailto:ser...@xwiki.org)) wrote:
 
 +1, sorry for dropping the ball on that.

 OK for removing the product from the key, I went ahead and edited the
 proposal page.

 Second thoughts: what if we keep the product part for non-XWiki.org
 products bigger than a simple application, for example xclams?
 
 I can think of 3 different answers:
 
 1) Well these rules are only for the XWiki project itself (xwiki github
 org + possibly xwiki contrib org) and we cannot ask other projects to
 follow them, which means they’re free to use whatever rules they want.
 
 2) It’s kind of already taken care of by the star in [module]*”:
 
 “
 Keys should have the following format:
 ##[module]*[.section]*.element[.part]*##, where:
 
 * ##module## is the name of the module or application being translated,
 like ##blog##, ##faq##, ##statistics##… Since a module can have
 submodules, there can be several module names. For example the SOLR
 Search UI is located in
 ##xwiki-platform-search/xwiki-platform-solr/xwiki-platform-solr-ui## and
 would have keys starting with ##search.solr.##.
 “
 
 xclams can be considered a big app with submodules, and could use
 ##xclams.[submodule]…##.
 
 3) We could decide to put back
 ##product.[module]*[.section]*.element[.part]*## and for all modules
 that are meant to compose or are extensions of the XWiki runtime, the
 product is “xwiki”. This means all code in the xwiki organization and
 most code in the xwiki-contrib org would use the “xwiki” product. But
 for those doing another product (i.e a different runtime distribution -
 not some flavor, since flavors are just extensions of the XWiki runtime)
 then they would use their own product name. For example in the past we
 had “xoffice”, “xem”, “xwatch”, “workspaces”. We would do an exception
 for XE since we’re removing it in favor of simply the XWiki runtime
 (we’ll remove the xwiki-enterprise repo at some point when everything is
 moved into xwiki-platform).
 
 So idea 3) would mean that all our keys would start with “xwiki”.
 
 WDYT?
 
 Idea 3) seems the most correct to me (even though it’s a bit of a pain
 to have to prefix all our translation keys with “xwiki” but it’s not
 such a big deal either).
 
 Thanks
 -Vincent
 
 +1 for the deprecation strategy as well.

 On 02/20/2015 10:29 AM, vinc...@massol.net wrote:
  Hi devs,
 
  At the moment the VOTED rule for naming our translation properties
 is the one defined at
 
 http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTranslationPropertyNaming
 
  Back in 2012 Sergiu started drafting an extended L10N Conventions”
 document for best practices around writing translation properties at
  http://dev.xwiki.org/xwiki/bin/view/Drafts/L10N+Conventions
 
  Sergiu sent this a proposal in this mail thread:
  http://markmail.org/message/ofl23yorvxsqhn4x
 
  When Sergiu did this he didn’t realize we already had a VOTED rule
 for naming our translation properties and his proposal was in conflit
 with that. However, in this mail thread, several developers mentioned
 that even though they votes the previous naming rules they didn’t fully
 like it and preferred the one Sergiu was proposing. Several suggestion
 for improvements were also proposed. It was suggested in that thread
 (and Sergiu agreed) that he should resend a VOTE to change those
 established rules. Apparently he didn’t get the time/will to do it since
 I couldn’t find such a mail.
 
  In addition several developers are apparently not following the
 current rules (BAD! :)). For example in the xwiki-platform-icon-ui
 module, the Translations.xml page has the following which is NOT
 following the current rules:
  platform.icon.picker.preview=Preview with:
  platform.icon.picker.loading=Loading
 
  And most translation keys found in contrib apps at
 http://l10n.xwiki.org/xwiki/bin/view/Contrib/WebHome are also not
 following these rules (although we don’t enforce anything for contrib
 projects, when they are coded by devs from the XWiki dev team or by
 known contributors, it would be a good thing to follow the same rule,
 especially as, in the future, we want to provide a path to move from
 contrib sandbox to contrib extensions). For example I see the following
 type of naming: “polls.vote.instructions.single”.
 
  Thus, with this email I’d like to try agreeing on a new naming
 format and conventions.
 
  I propose to VOTE for making
 http://dev.xwiki.org/xwiki/bin/view/Drafts/L10N+Conventions our official
 practice with the following change for the property naming part:
 
  
  Keys should have the following format:
 ##[module]*[.section]*.element[.part]*##, where:
 
  * ##module## is the name of the module or application being
 translated, like ##blog##, ##faq##, ##statistics