IRC Archive for channel #xwiki on 05 April 2016
Last modified by Vincent Massol on 2016/04/05 23:58
<cjd> has joined #xwiki
09:19 <Pbas> For the right access I think we can not edit/view page with an account from http://www.xwiki.org/xwiki/
09:21 <Pbas> You are rude with captcha ;-)
09:24 <vmassol> hi
09:24 <Pbas> ok 3 capcha later ...
09:24 <Pbas> hi :-)
09:25 <vmassol> Pbas: you're logged with an account from xwiki.org or from playground?
09:25 <Pbas> ok it is fine with a new xwiki account created on http://playground.xwiki.org/xwiki/bin/view/XWiki/xxx
09:25 <vmassol> rights seem ok
09:26 <Pbas> With xwiki.org we can not view playground
09:26 <vmassol> I can improve a bit to make it work better for users with accounts on xwiki.org though
09:26 <vmassol> yes fixing that
09:26 <Pbas> * xwiki.org account
09:26 <vmassol> which is strange since I remember doing something about it
09:27 <Pbas> With playground account, I have some errors on http://playground.xwiki.org/xwiki/bin/view/Invitation/ page
09:27 <Pbas> Failed to execute the [include] macro. Click on this message for details.#loadInvitationConfig($config)
09:27 <Pbas> #loadInvitationMail($config, $emailContainer, $mail)
09:28 <vmassol> Pbas: just viewing the page?
09:28 <vmassol> displays fine with admin user
09:28 <Pbas> Myabe you can hide this space
09:28 <Pbas> yes in view mode with http://playground.xwiki.org/xwiki/bin/view/XWiki/TestTest account
09:29 <vmassol> indeed
09:29 <vmassol> I can reproduce
09:29 <vmassol> wow lots of errors
09:29 <vmassol> the issue is:
09:29 <Pbas> but maybe it is not a goog idea to allow anyone sending mail?
09:29 <vmassol> Current user [playground:XWiki.vma] doesn't have view rights on document [playground:Invitation.InvitationCommon]
09:30 <vmassol> checking permissions and checking xwiki 8.0
09:30 <vmassol> yes you're not supposed to be see the invitation app I think, I'll check
09:30 <vmassol> first, can I reset the playgound wiki ?
09:30 <vmassol> (for rights)
09:30 <vmassol> (you'll loose your user there)
09:31 <Pbas> heu are you talking to me? Sure you can
09:33 <vmassol> doing it
09:33 <Pbas> :)
09:34 <vmassol> hmm http://www.xwiki.org/xwiki/bin/view/WikiManager/#|t=wikis&p=1&l=10&s=wikiprettyname&d=asc&wikiprettyname=p is not working any more either
09:34 <vmassol> filter doesn't work
09:34 <Pbas> ho boy! I did the mess again
09:34 <vmassol> issue is:
09:35 <vmassol> Caused by: org.hibernate.hql.ast.QuerySyntaxException: Invalid path: 'wikiprettyname.value' [select distinct doc.fullName, wikiprettyname.value from com.xpn.xwiki.doc.XWikiDocument doc , com.xpn.xwiki.objects.BaseObject as obj , com.xpn.xwiki.objects.StringProperty as prop_wikiprettyname where (doc.language is null or doc.language = '' or doc.language = 'en') and (obj.name=doc.fullName and obj.className = ? and doc.fullName <> ? and
09:36 <tmortagne> ok so that's why I had issue yesterday probably, I tough I was putting the wrong pretty name
09:36 <vmassol> http://www.xwiki.org/xwiki/bin/get/WikiManager/WikisLiveTableResults?outputSyntax=plain&transprefix=platform.wiki.browse.&classname=XWiki.XWikiServerClass&collist=wikiprettyname%2Cdescription%2Cowner%2Cdoc.creationDate%2CmembershipType&queryFilters=currentlanguage%2Chidden&offset=1&limit=10&reqNo=11&wikiprettyname=play&sort=wikiprettyname&dir=asc
09:36 <vmassol> going on with the playground re-creation FTM
09:38 <tmortagne> vmassol: broken on standard jetty/hsqldb too, create a jira issue
09:39 <vmassol> hmm
09:39 <vmassol> wiki creation seems stuck or very very slow
09:39 <vmassol> not stuck
09:39 <vmassol> just very slow
09:40 <vmassol> takes 5 seconds to copy one doc
09:40 <vmassol> 2-5s
09:40 <tmortagne> you sure ? maybe you are fooled by the refresh of the log not being instant ?
09:40 <vmassol> progress bar is not moving
09:40 <vmassol> so I'm sure
09:41 <acotiuga> has quit
09:42 <vmassol> I've never seen is so slow…
09:42 <tmortagne> so new blocker for 8.1M1: http://jira.xwiki.org/browse/XWIKI-13288
09:44 <vmassol> I thnk xwiki.org is just very slow
09:44 <acotiuga> has joined #xwiki
09:46 <vmassol> Pbas: could you retest playground with your user from xwiki.org?
09:46 <Pbas> sure
09:47 <Pbas> It seem ok now
09:47 <vmassol> ok cool
09:47 <vmassol> now moving to invitation
09:48 <Pbas> txs :)
09:48 <Pbas> thxs
09:49 <Pbas> users created on playground are wiped every day?
09:49 <vmassol> yes
09:50 <Pbas> ok good to know
09:50 <vmassol> hmmm
09:50 <vmassol> I'll update the welcome message to make that explicit
09:51 <Pbas> last thing: blue message box is not translated
09:51 <vmassol> yes that's normal
09:51 <mflorea> has joined #xwiki
09:52 <vmassol> we can improve this when we create the demo flavor in contrib
09:52 <vmassol> I still have it on my plate...
09:52 <vmassol> https://github.com/xwiki-contrib/flavor-demo
09:53 <Pbas> yes but it is not already full ... your plate?
09:53 <vmassol> already 2 months that I started it and didn't finish it ;)
09:53 <vmassol> an extensible plate indeed
09:53 <Pbas> same for me :-D
10:05 <vmassol> Pbas: I'll need to recreate playground again later once i've fixed the invitation app issue…
10:06 <Pbas> May I a suggetion? give write access at guest on Sandbox space.
10:06 <vmassol> Pbas: the issue is that this may bring the farm down
10:07 <vmassol> you can't imagine all the spam that bots and people put when it's open
10:07 <vmassol> but we could try
10:07 <Pbas> ha yes I understand
10:07 <vmassol> especially now that we have some antispam tool
10:07 <Pbas> if bot send big file probably
10:07 <vmassol> checking if I've put delayed indexing
10:08 <Pbas> write access on on page then
10:08 <Pbas> and reinit it every hours
10:08 <Pbas> houre just to test editor without registering
10:10 <Pbas> (because "basic" users like test wysiwig editor I think)
10:10 <vmassol> wdym by "write access on on page then"?
10:10 <vmassol> one page you mean?
10:10 <mflorea> has joined #xwiki
10:11 <lkrejci> has joined #xwiki
10:11 <Pbas> Give write access on http://playground.xwiki.org/xwiki/bin/view/Sandbox/WebHome at guests
10:11 <vmassol> we could do:
10:11 <evalica> has joined #xwiki
10:12 <vmassol> hmm no
10:12 <vmassol> yes we could open Sandbox to everyone as a test
10:12 <Pbas> all space instead an unique page?
10:13 <vmassol> tmortagne, mflorea, all: wdyt about giving guests write access to Sandbox space on playground as a test?
10:13 <vmassol> (I'd modify the welcome message to explain that)
10:13 <Pbas> You can wipe it every houres to secure it
10:14 <vmassol> that's a bit more complex
10:14 <Pbas> maybe
10:14 <Pbas> You can use my extension for that ;-))
10:15 <vmassol> link?
10:15 <Pbas> Ouch!
10:15 <Pbas> http://extensions.xwiki.org/xwiki/bin/view/Extension/Reinit_Sandbox
10:15 <Enygma`> has joined #xwiki
10:16 <Pbas> you are mean ;-)
10:16 <mflorea> vmassol is playground excluded from indexing? (in robots.txt)
10:16 <vmassol> not sure, I've implemented delayed indexing though
10:16 <vmassol> so only pages that are older than 5 days are indexed
10:17 <vmassol> however need to check if it's based on creation date, don't remember
10:17 <mflorea> IMO it shouldn't be indexed at all
10:17 <vmassol> sure I can do that
10:17 <mflorea> maybe expect for the home page, which should e readonly
10:18 <mflorea> s/expect/except
10:18 <vmassol> actuallt it's already done :)
10:18 <mflorea> great
10:18 <mflorea> then I guess we can allow edit for guests on Sandbox space
10:18 <vmassol> through
10:18 <vmassol> <meta name=“robots” content=“noindex,nofollow” />
10:19 <mflorea> good
10:19 <vmassol> ok let's try it and we'll see how it goes
10:19 <vmassol> let me prepare this
10:19 <vmassol> fixing invitation issue first
10:19 <Pbas> Why homepage readonly?
10:20 <Pbas> sandbox homepage
10:20 <mflorea> Main.WebHome readonly, not Sandbox.WebHome
10:20 <Pbas> to show editor
10:21 <Pbas> ha ok sorry
10:21 <mflorea> Main.WebHome has some messages explaining the goal of the playground wiki
10:21 <Pbas> sure
10:21 <mflorea> we don't want those deleted
10:21 <vmassol> hmm there are strange things on playgroundtemplate
10:22 <Pbas> but you will give guest access right to sandbox space only, isn't it?
10:22 <vmassol> yes
10:22 <vmassol> write access
10:22 <Pbas> right is not write yes sorry :-D
10:23 <Pbas> the worst is ... my wife is english
10:27 <KermitTheFragger> has joined #xwiki
10:36 <Slashman> has joined #xwiki
10:39 <Pbas> FYI your bot seem to be down (the bot who send extensions updates to this IRC)
10:48 <cjd> !news
10:48 <cjd> indeed, it's connected but not responding
10:50 <vmassol> been broken for weeks now
10:51 <cjd> ok then I won't bother trying to find the page and cycle it
11:10 <lkrejci> has quit
11:11 <lkrejci> has joined #xwiki
11:26 <Enygma`> vmassol: http://jira.xwiki.org/browse/XWIKI-12912 has a commit on it, but it`s an added test. I guess it can safely be moved to 8.1M2
11:27 <vmassol> Enygma`: yes
11:27 <vmassol> thanks
11:27 <vmassol> test is @ignore
11:29 <tmortagne> Enygma`: I don't think we can release with http://jira.xwiki.org/browse/XWIKI-12912
11:29 <tmortagne> http://jira.xwiki.org/browse/XWIKI-13288 sorry
11:30 <vmassol> cjd: question for your on the invitation app
11:31 <Enygma`> mflorea: any plans for http://jira.xwiki.org/browse/XWIKI-11095? Should we split it?
11:31 <vmassol> did you test installing it in a subwiki and verify it works for guest, for a user logged in locally and for a user logged in on the main wiki?
11:31 <vmassol> (that's for cjd)
11:33 <vmassol> cjd: for example for Invitation.InvitationCommon I see it allows view for guests and XWiki.XWikiAllGroup in a XWiki.XWikiRights xobject. What about a user logged in on the main wiki?
11:34 <cjd> I don't recall, likely no because at the time when the automated tests were written there was no ability to automatically test subwikis
11:35 <Enygma`> we currently have 2 blockers:
11:35 <Enygma`> http://jira.xwiki.org/browse/XWIKI-13179
11:35 <vmassol> tmortagne: I see a XWiki.XWikiGlobalRights xobject on a page with an allow for groups: "xwiki:XWiki.XWikiAllGroup,XWiki.XWikiAllGroup,". Does that work? Doesn't it needs a XWiki.XWikiRights xobject instead for local XWiki.XWikiAllGroup?
11:36 <vmassol> cjd: so I can assume that right now the invitation app should only be installed on the main wiki to work properly?
11:36 <tmortagne> XWikiRights is for the page, nothing do with the group
11:36 <cjd> vmassol: yes, that's a fair assumption because the testing has not been performed
11:36 <cjd> AFAIK it's not part of the QA test program
11:37 <vmassol> cjd: ok then, I'll add a namespace restriction to it and remove it from the subwiki list of apps
11:37 <Enygma`> tmortagne: would you be available to handle http://jira.xwiki.org/browse/XWIKI-13288 ?
11:37 <cjd> ooo we have main-wiki-only restriction now ?
11:38 <vmassol> yup
11:38 <cjd> I want to apply that to WebSocket because that is an endless difficulty
11:38 <tmortagne> Enygma`: this afternoon yes
11:38 <cjd> How do I set that ?
11:38 <vmassol> wait
11:38 <acotiuga> I would like to write some JUnit tests in xwiki-platform-ratings module but I'm not sure if their place should be in a xwiki-platform-ratings-test submodule (doesn't exist) or in xwiki-platform-ratings/src/test/java/org/xwiki/ratings/
11:39 <vmassol> cjd: example: https://github.com/xwiki/xwiki-platform/blob/182857c98f68924afcb99d1b3c39278dee698385/xwiki-platform-core/xwiki-platform-vfs/xwiki-platform-vfs-api/pom.xml#L44-L44
11:39 <cjd> ok, that's easy enough :)
11:39 <cjd> thanks
11:39 <Enygma`> acotiuga: unit tests go with the code, so same module
11:39 <Enygma`> only functional tests need a separate module
11:40 <Enygma`> (selenium)
11:40 <acotiuga> thanks
11:40 <vmassol> cjd: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki80#HNamespaceconstraint and http://extensions.xwiki.org/xwiki/bin/view/Extension/XWiki+Commons+-+Extension+-+Repository+-+Maven#HCustomproperties
11:40 <tmortagne> acotiuga: depend if you need a real XWiki instance or if you are fine with a mocked database which is just a map with documents in it and no search support
11:40 <cjd> thanks also
11:40 <lkrejci> has quit
11:40 <vmassol> cjd: last link has the most info
11:40 <tmortagne> s/no search support/no query support/
11:41 <lkrejci> has joined #xwiki
11:41 <tmortagne> also if the goal is to test the UI you usually need a real instance of XWiki right now
11:45 <acotiuga> Maybe I didn't understand well the idea of unit tests and functional tests, but I thought unit test has nothing to do with the UI...
11:46 <acotiuga> Now, there are no tests on ratings module and I would like to start with unit tests and then to add some functional tests
11:46 <tmortagne> you said "JUnits tests", not unit tests, everything is run with Junit :)
11:47 <acotiuga> ahh
11:47 <tmortagne> so I'm indicating you all possibilities for Junit test ;)
13:31 <vmassol> Enygma`: can I push to platform on master?
13:32 <vmassol> since I see a commit message about rendering above I guess you're currently building platform and thus the answer is probably no
13:32 <vmassol> I can wait
13:39 <acotiuga> I can see that javax.servlet:servlet-api:jar is used as dependency in some contrib applications and even in xwiki-platform, but it hasn't a <version>
13:39 <acotiuga> Using it in the same way I got org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs: [ERROR] 'dependencies.dependency.version' for javax.servlet:servlet-api:jar is missing. @ line 71, column 17
13:40 <lkrejci> has quit
13:40 <lkrejci> has joined #xwiki
13:41 <acotiuga> Should I look somewhere for that version or is there any way to skip this check ?
13:41 <vmassol> deleting playground again
13:42 <vmassol> acotiuga: the version is inherited from the parent pom
13:42 <vmassol> this check should not be skipped, it's very important :)
13:43 <vmassol> you should also not have a scope for it
13:43 <vmassol> since it should inherit from parent and be provided
13:43 <vmassol> that's also very important
13:43 <acotiuga> I have the test scope
13:43 <vmassol> it's not correct
13:43 <vmassol> it's not too bad but not the best
13:44 <vmassol> if it's needed during testing it means it's required when executing
13:44 <vmassol> (probably)
13:44 <acotiuga> https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-watchlist/xwiki-platform-watchlist-api/pom.xml#L77
13:44 <vmassol> so there should be a runtime scope, but since this jar is provided by the servlet container ti should be provided
13:44 <vmassol> which is what is done in parent poms
13:44 <vmassol> yes it depends why you need it
13:45 <vmassol> I can't guess this so you need to see why it's needed
13:45 <vmassol> or paste the reason why you have a problem when running
13:45 <vmassol> reason = stack trace
13:48 <acotiuga> since I'm trying to follow the example from the above url, I guess I need it for the same reason: running unit test and maybe to mock something (XWikiContext, XWikiDocument)
13:49 <vmassol> you need to know for sure
13:49 <acotiuga> http://pastebin.com/PPvcpDR9 stacktrace
13:55 <xwikibot> has joined #xwiki
13:57 <vmassol> evalica: cool, didn't realize that the top level menu on playground was only visible to admins or to users logged on the main wiki
13:57 <vmassol> hmm actually it's a bug
13:57 <vmassol> it's also visible to guests
13:57 <vmassol> so it's not visible to local users only!
13:58 <vmassol> Pbas: ok invitation app should not be visible anymore on playground for non admins
13:58 <vmassol> (I'm talking about the entry in the applications panel)
14:00 <vmassol> acotiuga: so the main issue is that this dep in a provided and thus is not inheritable, see https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
14:01 <vmassol> so we cannot just set it in the modules that need it for compilation
14:01 <vmassol> we also need it in the modules that uses the modules that need it for compilation
14:02 <vmassol> I guess we could cheat tmortagne
14:02 <vmassol> maybe by setting a compile scope and then removing that artifact when we create the WAR
14:02 <Pbas> vmassol: yes invitation is not visible anymore.
14:03 <vmassol> the EM would see it as a compile time dep when installing extensions but since the artifact will always be present locally it might be ok… could be an issue if it has a different version though…hmmm that would be a problem
14:03 <vmassol> I don't see any solution to improve the situation...
14:03 <vmassol> Pbas: ok cool
14:03 <vmassol> moving to documenting my issues for 8.1M1 RN now
14:06 <tmortagne> vmassol: we could say the same from any <scope>provide</scope> dependency since this use case is the perfect illustration of what provided scope was designed for bu indeed this scope is not very nice for tests of backward dependencies
14:06 <tmortagne> *<scope>provided</scope>
14:07 <vmassol> yes it's true for all but servlet-api is really one we have to put back everywhere
14:07 <vmassol> another option
14:07 <vmassol> is to add it as a dep for all modules by default
14:07 <vmassol> not sure it's that nice though
14:08 <vmassol> (by default = in top level pom)
14:14 <tmortagne> not very nice no
14:14 <tmortagne> and it's not everywhere, far from it
14:14 <tmortagne> it's usally in module that deal with request
14:15 <vmassol> well in module that uses some other modules that deal with requests
14:15 <vmassol> and when you have some module in the way that depends on oldcore then you need it...
14:16 <tmortagne> not really, you need to deal with request during the test
14:16 <tmortagne> it's not because you depend on oldcore that your test will use servlet API
14:16 <vmassol> not really
14:16 <vmassol> java fails to load any class that has an import that uses the servlet api
14:16 <vmassol> you don't need to use requests
14:16 <tmortagne> I did not say use request in your test, I said during the test
14:17 <vmassol> yes thats what I said
14:17 <tmortagne> many module depend on oldcore but use things that don't touch request
14:17 <vmassol> you don't need to use requests during your test
14:17 <tmortagne> Java will not load all the classes of oldcore during the test
14:17 <vmassol> you just need to use a class/component that has some methods using servlet api but this class/component can also have some other methods not related at all to sevlet api
14:17 <tmortagne> only what is actually used
14:17 <vmassol> (that you're using)
14:18 <vmassol> it happened to me plenty of times
14:22 <tmortagne> here is an idea
14:23 <tmortagne> * extract reusable test stuff from oldcore (mostly MockitoOldcoreRule and stuff around it)
14:23 <tmortagne> * make this new test module declare a runtime dependency on servlet API
14:24 <tmortagne> most module that need oldcore during test need MockitoOldcoreRule (or should move to) and other oldcore oriented test stuff
14:25 <tmortagne> that way you automatically get servlet API when you use oldcore test tool but only as test dependency because you declare oldcore-test as test dependency
14:27 <vmassol> so the trick is in using "runtime" (which is inheritable) rather than "provided" for tests
14:27 <vmassol> seems interesting
14:29 <tmortagne> only in a module that is alwyas used as test dependency
14:29 <tmortagne> the issue with that is test of oldcore module itself
14:30 <tmortagne> since they will need to be move in another module that can depend on oldcore-test which is not nice from test coverage point of view
14:30 <tmortagne> but it's nicer for all modules that use those test tools
14:31 <tmortagne> hmm what can work for everyone is to depend on oldcore test jar in oldcore-test and also add the servlet api dependency
14:32 <tmortagne> that way other modules use oldcore-test instead of oldcore and oldcore can still directly use MockitoOldcore and stiff like this
14:32 <tmortagne> s/stiff/stuff/
14:32 <tmortagne> doing it quickly in a branch, will be easier to understand :)
14:33 <vmassol> :)
14:36 <vmassol> mflorea: Found a regression in search on xwiki.org
14:37 <mflorea> vmassol: what's the problem?
14:37 <vmassol> I searched for something and opened the Location facet, then selected one location; it refreshed and then I cannot choose another location
14:37 <vmassol> (and the location facet was closed again btw but that's a minor usability issue)
14:37 <mflorea> you have links in the location facet right?
14:38 <vmassol> you can try it here: http://www.xwiki.org/xwiki/bin/view/Main/Search?text=clirr&f_type=DOCUMENT&f_locale=en&f_locale=&r=1&l_space_facet=10
14:38 <mflorea> it shows a breadcrumb
14:38 <vmassol> ah wait
14:38 <mflorea> yes
14:38 <mflorea> it's a breadcrumb
14:38 <vmassol> I'm using it wrongly
14:38 <vmassol> :)
14:38 <vmassol> hmm no
14:39 <vmassol> how do I say:
14:39 <vmassol> all spaces except those
14:39 <vmassol> ?
14:39 <vmassol> for some reason I thought there were all selected and I could uncheck them, which is what would seem logical but I don't see that anymore
14:39 <mflorea> you need to use query syntax, this can't be done from the facet
14:40 <vmassol> it's strange because the other facets use another behaior
14:40 <vmassol> behavior
14:40 <vmassol> they select all items and you can unselect
14:40 <vmassol> not all, some
14:40 <mflorea> that's not the case for the datafacet
14:40 <lkrejci> has joined #xwiki
14:40 <vmassol> actually very few
14:41 <mflorea> each face can have its own behaviour
14:41 <vmassol> only result type and language
14:41 <vmassol> hmm still not easy way to see the syntax, we need to fix that
14:41 <mflorea> selecting all the values makes sense _only_ when the list of values is very limited
14:42 <mflorea> otherwise selecting all the values will generate a huge query
14:42 <vmassol> can you remind me how to exclude some locations?
14:42 <vmassol> I see
14:42 <vmassol> -space:ReleasePlans doesn't work so that's not the right syntax
14:42 <mflorea> -space_exact:A.B
14:43 <mflorea> you need to exclude subspaces also?
14:43 <vmassol> not on xwiki.org
14:43 <vmassol> since we don't use them atm
14:43 <vmassol> so yes space_exact is far from obvious without a help
14:43 <vmassol> thanks
14:44 <vmassol> ah one issue
14:44 <vmassol> how do you unselect a location? :)
14:45 <vmassol> don't tell me to hit the browser back button! :)
14:45 <vmassol> (kidding)
14:45 <mflorea> as I said above, when you select a location you get a breadcrumb
14:45 <mflorea> which you can use to navigate to any parent
14:45 <vmassol> I don't want to nav
14:45 <mflorea> including the root (home0
14:45 <vmassol> I'm searching
14:45 <mflorea> I'm referring to the Location facet
14:45 <vmassol> oh clickong on the home seems to work
14:46 <mflorea> it shows you a breadcrumb
14:46 <vmassol> that's nice but really not intuitive
14:46 <mflorea> it's a breadcrumb
14:46 <vmassol> would be better to have checkbox as the othr facets
14:46 <mflorea> we show it everywhre
14:46 <vmassol> yes but it means bavigating
14:46 <vmassol> *navigating
14:46 <vmassol> I'm not navigating here
14:46 <vmassol> I would never have dreamed being able to click on it
14:46 <vmassol> and stay on the search pagre
14:46 <vmassol> *page
14:47 <vmassol> I didn't even try because i didn't want to move away from the search
14:48 <vmassol> anyworks works for me FTM but I don't feel it's very intuitive
14:48 <vmassol> thanks
14:50 <tmortagne> vmassol: https://github.com/xwiki/xwiki-platform/compare/feature-test-oldcore?expand=1
14:52 <tmortagne> by the way the forced dependency to test-component in xwiki-platform-core should be removed IMO, it force doing hack in the test module like this one
14:52 <tmortagne> if a module need test-component module it's not such a pain to put it in dependencies
14:52 <tmortagne> which is what many modules do anyway already
14:53 <tmortagne> (it's also wrong to make all module that don't need that depend on it, like XAR modules)
14:55 <vmassol> mflorea: any idea why http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/ReleasePlanHelp#HGenerateBackwardCompatibilityReport doesn't appear in http://www.xwiki.org/xwiki/bin/view/Main/Search?sort=score&sortOrder=desc&highlight=true&facet=true&r=1&f_type=DOCUMENT&f_locale=en&f_locale=&l_space_facet=10&text=clirr+-space_exact%3AReleasePlans+-space_exact%3AIRC ?
15:01 <vmassol> @all: should we remove http://dev.xwiki.org/xwiki/bin/view/Community/ReleaseProcess now?
15:01 <vmassol> (I think so)
15:05 <vmassol> Enygma`: let me know when I can commit in platform on master
15:05 <vmassol> tmortagne: ok re "the forced dependency to test-component in xwiki-platform-core should be removed IMO"
15:06 <vmassol> ah I see it's in your branch
15:07 <vmassol> tmortagne: not sure why you removed <artifactId>xwiki-commons-tool-test-component</artifactId> from xwiki-platform-test-page/pom.xml
15:07 <tmortagne> vmassol: it provided by test-oldcore
15:07 <vmassol> it seems good to have it to me, isn't it a direct dep
15:07 <tmortagne> *it's
15:07 <vmassol> yes I know
15:07 <vmassol> but still
15:08 <vmassol> when oldcore goes away, it's still required
15:08 <vmassol> that's what I mean by a direct dep
15:08 <vmassol> ok for the rest
15:08 <vmassol> now we need to see what effect this has on the rest ;)
15:09 <mflorea> vmassol: you exclude ReleasePlans space and ReleasePlanHelp is in that space
15:09 <vmassol> mflorea: ah… stupid me....
15:09 <vmassol> brain not working fully today it seems…
15:09 <vmassol> sorry
15:09 <mflorea> :)
15:09 <mflorea> np
15:10 <vmassol> this shows that I still don't trust our search 100% yet
15:10 <vmassol> I need to shake that belief!
15:10 <vmassol> *shake off
15:10 <lkrejci> has quit
15:10 <vmassol> (inherited from the past I guess and from indexing issue we had)
15:10 <lkrejci> has joined #xwiki
15:11 <tmortagne> vmassol: "now we need to see what effect this has on the rest" for now the effect is less dependencies to declare for other modules
15:12 <vmassol> we don't need to add the test dep removed from xwiki-platform-core in lots of places?
15:12 <vmassol> (not saying it's a bad thing!)
15:12 <Enygma`> vmassol: done building the release
15:13 <vmassol> thanks
15:15 <tmortagne> vmassol: according to Eclipse all is ok with the current state of the branch so it seems that all project that needed test-component where the same that were using oldcore stuff (or they explicitely declare test-component)
15:16 <vmassol> hehe we were all stacking commits ;)
15:22 <Aranjedeath> has quit
15:22 <M-yflory> has quit
15:22 <lynxt> has quit
15:24 <lynxt> has joined #xwiki
15:25 <vmassol> Enygma`: haven't you implemented this https://jira.xwiki.org/browse/XWIKI-13290 already?
15:25 <vmassol> hmm maybe it's different, not sure I understand fully, I'll comment
15:26 <M-jsimard> has quit
15:26 <vmassol> ah yes it's different, I get it now
15:26 <M-jsimard> has joined #xwiki
15:27 <Aranjedeath> has joined #xwiki
15:29 <Enygma`> vmassol: yes, it`s about making the selected spaces of a template provider apply to their children as well
15:29 <vmassol> so right now when you click in the tree
15:30 <vmassol> it only selects the current node but not the children, right?
15:30 <Enygma`> yes, current space actually, so it inherits to terminal docs inside that space, including WebHome
15:30 <Enygma`> but not to Nested Spaces, children of the selected space
15:30 <vmassol> ok got it, thx
15:31 <Enygma`> applied the same thing to the Annotations Administration section
15:31 <Enygma`> it`s highly problematic to inherit
15:31 <Enygma`> since you can not say that from this point on, don`t inherit anymore
15:31 <vmassol> you can unselect
15:31 <vmassol> in the tree
15:31 <Enygma`> and also, from this other point on, start inheriting again
15:32 <Enygma`> it`s also a problem of what do you store in the preference?
15:32 <vmassol> ah yes
15:32 <vmassol> ok it's easy in the tree but harder to persist the information
15:32 <Enygma`> the top node and inherit programatically or do you store *all* child nodes (including the top node)
15:32 <Enygma`> I`ve looked at it from various angles and this was the only "sane" thing to do at the moment
15:34 <Enygma`> we will also probably encounter this problem in other forms in the future as well
15:34 <Enygma`> since I`ve encountered it twice so far (Annotations + Template providers)
15:34 <Enygma`> so maybe we`ll come up with a better approach in the end
15:40 <tmortagne> looks like XEclipse follow test dependencies like it was compile dependencies when the project is open
15:50 <Enygma`> has quit
15:50 <Enygma`> has joined #xwiki
15:56 <sdumitriu> has quit
16:00 <sdumitriu> has joined #xwiki
16:04 <acotiuga> has quit
16:27 <Enygma`1> has joined #xwiki
16:29 <sdumitriu> has quit
16:30 <Enygma`> has quit
16:35 <sdumitriu> has joined #xwiki
16:39 <Pbas> has quit
16:48 <tmortagne> has quit
17:35 <tmortagne> has joined #xwiki
18:10 <lkrejci> has quit
18:10 <lkrejci> has joined #xwiki
18:12 <cjd> has quit
18:27 <vmassol> tmortagne: I see you added some ignores in commons for revapi
18:28 <vmassol> for non-young apis
18:28 <vmassol> is that normal? do we need to to discuss that to make sure we don't break users?
18:28 <vmassol> (users = extensions)
18:28 <tmortagne> those change are binary compatible
18:29 <vmassol> why are they ignored then?
18:29 <vmassol> I have checked revapi issue tracker and didn't see an issue for them
18:29 <tmortagne> because they are incompatible from build point of view and revapi take that seriously it seems
18:29 <vmassol> but we need to report it if it's wrong!
18:30 <KermitTheFragger> has quit
18:30 <tmortagne> basically if you upgrade you dependency on commons you will need to update you code if it call those methods to build properly
18:31 <vmassol> just asked here: https://github.com/revapi/revapi/issues/36#issuecomment-205885076
18:31 <tmortagne> its not wrong
18:31 <vmassol> you said "those change are binary compatible"
18:32 <vmassol> are they or are they not? :)
18:32 <vmassol> ah yes
18:32 <tmortagne> yes but they are not compatible for the build
18:32 <vmassol> ok so they are binary
18:32 <vmassol> but not source
18:32 <tmortagne> yep
18:32 <vmassol> is that it?
18:32 <vmassol> so revapi is correct
18:32 <vmassol> it's reporting backward compat issues
18:32 <tmortagne> yep but I think CLIRR used to not check source compatibility
18:32 <vmassol> ie binary + source
18:32 <vmassol> no
18:32 <tmortagne> by the way did we updated the release plan for revapi ?
18:33 <vmassol> clirr was checking source too
18:33 <tmortagne> ok did not noticed
18:33 <vmassol> re release plan no, we need to figure out how to do it, I'm still working on it
18:33 <vmassol> I talked to Edy today about it during the release and on skype (see chat)
18:33 <tmortagne> I guess it's pretty much the same as CLIRR: remove the ignores and build
18:34 <vmassol> not quite
18:34 <tmortagne> it's just that we don't have tools to make it easier now
18:34 <vmassol> it's harder ATM
18:34 <vmassol> I am discusing here: https://github.com/revapi/revapi/issues/29
18:35 <vmassol> clirr could output violations to a file
18:35 <tmortagne> anyway for 8.1M1 I can add those 3 myself CLIRR style for now, not a big deal
18:35 <vmassol> ATM I have an issue
18:35 <vmassol> I cannot make revapi fail
18:35 <vmassol> see https://github.com/revapi/revapi/issues/36
18:36 <tmortagne> hmm it was definitely failind when I added the ignore since I copy pasted the JSON :)
18:37 <tmortagne> s/failind/failing/
18:37 <vmassol> could you try it?
18:37 <vmassol> remove ignore and build
18:37 <tmortagne> did we ungraded revapi in the meantime ?
18:37 <tmortagne> trying
18:37 <vmassol> I wondered abtout that but I rolled back locally to previous version of revapi and it didn't fail either
18:38 <lkrejci> has quit
18:40 <tmortagne> vmassol: does not fail for me either when I remove the ignores
18:40 <tmortagne> maybe revapi have some kind of cache
18:40 <vmassol> ok
18:40 <tmortagne> but I used clean
18:40 <vmassol> lukas has reproduced and I guess he's debugging now
18:42 <tmortagne> ok
18:42 <tmortagne> poor lukas, ending up being used by XWiki
18:42 <vmassol> :)
18:42 <vmassol> yes xwiki is not a relaxing user… ;)
18:44 <vmassol> tmortagne: "Known flavors are not tested anymore in the Distribution Wizard"
18:44 <vmassol> you mean s/not/now?
18:44 <vmassol> (in RN of 8.1M1)
18:45 <vmassol> ah no
18:45 <vmassol> forget that
18:45 <tmortagne> nop its the right word :)
18:45 <vmassol> you mean flavors are now listed?
18:45 <tmortagne> you need to remember what was introduce in 8.0 actually for it to be more clear
18:46 <tmortagne> in 8.0 we started validating flavors in the background, known flavors and directly added without any validation
18:46 <tmortagne> will rewrite it a bit
18:46 <vmassol> ok thanks
18:46 <tmortagne> finishing with API stuff
18:46 <vmassol> what's a known flavor?
18:47 <vmassol> maybe you could also explain what it means to "repair" an extension in the RN?
18:47 <vmassol> (it's not clear to me)
18:48 <vmassol> reminder to self: fix the line "The XAR plugin now also verifies that Translations.xml pages are using the plain/1.0 syntax.
18:48 <vmassol> "
18:51 <tmortagne> done
18:51 <lkrejci> has joined #xwiki
18:52 <vmassol> thx
18:52 <tmortagne> I tough "repair" was clear in the context of an invalid extension, it tries to find a way to repair it whatever is the issue
18:52 <vmassol> how can an extension be broken?
18:53 <tmortagne> usually because of an upgrade of the WAR where something changed
18:53 <vmassol> for me broken means it doesn't work, like there's a bug in it
18:53 <vmassol> so repair would fix that, seems hard to do
18:53 <tmortagne> core extension removed or new core extension conflicting with an installed extension for example
18:53 <tmortagne> it's invalid from Extension Manager point of view
18:54 <tmortagne> EM have no idea if you extension works or not
18:54 <vmassol> I know
18:55 <vmassol> hmm
18:55 <vmassol> "The Extension Manager now tries to repair automatically any invalid dependency and provides a "Repair" button to repair specific invalid extension."
18:56 <lkrejci> has quit
18:56 <vmassol> if it does it automatically why is there a repair button?
18:56 <tmortagne> dependency
18:56 <vmassol> ok
18:56 <tmortagne> if you install a perfectly valid extension which depends on an already installed but invalid one it used to fail
18:57 <lkrejci> has joined #xwiki
18:57 <vmassol> so right now if you an extension that is invalid and has invalid deps
18:57 <vmassol> those deps will be fixed
18:57 <vmassol> but not the extension
18:57 <vmassol> and you need to click repair for that
18:57 <vmassol> ?
18:57 <vmassol> s/you an/you have an
18:57 <tmortagne> no
18:57 <vmassol> ok I don't understad the snetence then :)
18:57 <tmortagne> Extension Manager does not fix anything at startup
18:58 <tmortagne> its automatic as automatically done during install or another extension
18:59 <tmortagne> s/or/of/
19:00 <vmassol> ok don't worry, I don't understand but it doesn't matter ATM. I fear not many people will understand either though
19:00 <vmassol> (this concept of repair and what it means)
19:00 <vmassol> they'll just click on repair when they see it :)
19:00 <tmortagne> that's the plan :)
19:00 <vmassol> hopefully that's good enough and they don't need to understand anything more
19:01 <tmortagne> they have a read message and a button talking about repairing it, I guess it's enough for most user
19:01 <vmassol> ok re revapi we know the problem
19:01 <vmassol> https://github.com/revapi/revapi/issues/36#issuecomment-205890553
19:02 <vmassol> lkrejci: :)
19:02 <vmassol> (thanks for checking this out so quickly btw! that's great :))
19:10 <evalica> has quit
19:11 <mflorea> has quit
19:14 <Enygma`1> has quit
19:31 <lkrejci> vmassol: so the ball hopefully is back on your side ;)
19:34 <cjd> has joined #xwiki
19:56 <vmassol> bb in 1 hour
19:56 <vmassol> actually 2
20:01 <sorinello> has joined #xwiki
20:26 <tmortagne> has quit
20:33 <Slashman> has quit
20:35 <abusenius> has joined #xwiki
20:47 <abusenius> has quit
21:09 <mflorea> has joined #xwiki
21:14 <mflorea> has quit
21:47 <Daemoen> lo folks
22:39 <lkrejci> has quit
22:40 <lkrejci> has joined #xwiki
23:45 <Denis1> has quit
23:45 <Denis> has joined #xwiki
23:52 <vmassol> has quit
23:58 <Daemoen> how do you extend the ability of macro to support additional modules (in the case of python; i want to dynamically generate pages based on inventory information, thus i need to import mysql, etc)
09:19 <Pbas> For the right access I think we can not edit/view page with an account from http://www.xwiki.org/xwiki/
09:21 <Pbas> You are rude with captcha ;-)
09:24 <vmassol> hi
09:24 <Pbas> ok 3 capcha later ...
09:24 <Pbas> hi :-)
09:25 <vmassol> Pbas: you're logged with an account from xwiki.org or from playground?
09:25 <Pbas> ok it is fine with a new xwiki account created on http://playground.xwiki.org/xwiki/bin/view/XWiki/xxx
09:25 <vmassol> rights seem ok
09:26 <Pbas> With xwiki.org we can not view playground
09:26 <vmassol> I can improve a bit to make it work better for users with accounts on xwiki.org though
09:26 <vmassol> yes fixing that
09:26 <Pbas> * xwiki.org account
09:26 <vmassol> which is strange since I remember doing something about it
09:27 <Pbas> With playground account, I have some errors on http://playground.xwiki.org/xwiki/bin/view/Invitation/ page
09:27 <Pbas> Failed to execute the [include] macro. Click on this message for details.#loadInvitationConfig($config)
09:27 <Pbas> #loadInvitationMail($config, $emailContainer, $mail)
09:28 <vmassol> Pbas: just viewing the page?
09:28 <vmassol> displays fine with admin user
09:28 <Pbas> Myabe you can hide this space
09:28 <Pbas> yes in view mode with http://playground.xwiki.org/xwiki/bin/view/XWiki/TestTest account
09:29 <vmassol> indeed
09:29 <vmassol> I can reproduce
09:29 <vmassol> wow lots of errors
09:29 <vmassol> the issue is:
09:29 <Pbas> but maybe it is not a goog idea to allow anyone sending mail?
09:29 <vmassol> Current user [playground:XWiki.vma] doesn't have view rights on document [playground:Invitation.InvitationCommon]
09:30 <vmassol> checking permissions and checking xwiki 8.0
09:30 <vmassol> yes you're not supposed to be see the invitation app I think, I'll check
09:30 <vmassol> first, can I reset the playgound wiki ?
09:30 <vmassol> (for rights)
09:30 <vmassol> (you'll loose your user there)
09:31 <Pbas> heu are you talking to me? Sure you can
09:33 <vmassol> doing it
09:33 <Pbas> :)
09:34 <vmassol> hmm http://www.xwiki.org/xwiki/bin/view/WikiManager/#|t=wikis&p=1&l=10&s=wikiprettyname&d=asc&wikiprettyname=p is not working any more either
09:34 <vmassol> filter doesn't work
09:34 <Pbas> ho boy! I did the mess again
09:34 <vmassol> issue is:
09:35 <vmassol> Caused by: org.hibernate.hql.ast.QuerySyntaxException: Invalid path: 'wikiprettyname.value' [select distinct doc.fullName, wikiprettyname.value from com.xpn.xwiki.doc.XWikiDocument doc , com.xpn.xwiki.objects.BaseObject as obj , com.xpn.xwiki.objects.StringProperty as prop_wikiprettyname where (doc.language is null or doc.language = '' or doc.language = 'en') and (obj.name=doc.fullName and obj.className = ? and doc.fullName <> ? and
09:36 <tmortagne> ok so that's why I had issue yesterday probably, I tough I was putting the wrong pretty name
09:36 <vmassol> http://www.xwiki.org/xwiki/bin/get/WikiManager/WikisLiveTableResults?outputSyntax=plain&transprefix=platform.wiki.browse.&classname=XWiki.XWikiServerClass&collist=wikiprettyname%2Cdescription%2Cowner%2Cdoc.creationDate%2CmembershipType&queryFilters=currentlanguage%2Chidden&offset=1&limit=10&reqNo=11&wikiprettyname=play&sort=wikiprettyname&dir=asc
09:36 <vmassol> going on with the playground re-creation FTM
09:38 <tmortagne> vmassol: broken on standard jetty/hsqldb too, create a jira issue
09:39 <vmassol> hmm
09:39 <vmassol> wiki creation seems stuck or very very slow
09:39 <vmassol> not stuck
09:39 <vmassol> just very slow
09:40 <vmassol> takes 5 seconds to copy one doc
09:40 <vmassol> 2-5s
09:40 <tmortagne> you sure ? maybe you are fooled by the refresh of the log not being instant ?
09:40 <vmassol> progress bar is not moving
09:40 <vmassol> so I'm sure
09:41 <acotiuga> has quit
09:42 <vmassol> I've never seen is so slow…
09:42 <tmortagne> so new blocker for 8.1M1: http://jira.xwiki.org/browse/XWIKI-13288
09:44 <vmassol> I thnk xwiki.org is just very slow
09:44 <acotiuga> has joined #xwiki
09:46 <vmassol> Pbas: could you retest playground with your user from xwiki.org?
09:46 <Pbas> sure
09:47 <Pbas> It seem ok now
09:47 <vmassol> ok cool
09:47 <vmassol> now moving to invitation
09:48 <Pbas> txs :)
09:48 <Pbas> thxs
09:49 <Pbas> users created on playground are wiped every day?
09:49 <vmassol> yes
09:50 <Pbas> ok good to know
09:50 <vmassol> hmmm
09:50 <vmassol> I'll update the welcome message to make that explicit
09:51 <Pbas> last thing: blue message box is not translated
09:51 <vmassol> yes that's normal
09:51 <mflorea> has joined #xwiki
09:52 <vmassol> we can improve this when we create the demo flavor in contrib
09:52 <vmassol> I still have it on my plate...
09:52 <vmassol> https://github.com/xwiki-contrib/flavor-demo
09:53 <Pbas> yes but it is not already full ... your plate?
09:53 <vmassol> already 2 months that I started it and didn't finish it ;)
09:53 <vmassol> an extensible plate indeed
09:53 <Pbas> same for me :-D
10:05 <vmassol> Pbas: I'll need to recreate playground again later once i've fixed the invitation app issue…
10:06 <Pbas> May I a suggetion? give write access at guest on Sandbox space.
10:06 <vmassol> Pbas: the issue is that this may bring the farm down
10:07 <vmassol> you can't imagine all the spam that bots and people put when it's open
10:07 <vmassol> but we could try
10:07 <Pbas> ha yes I understand
10:07 <vmassol> especially now that we have some antispam tool
10:07 <Pbas> if bot send big file probably
10:07 <vmassol> checking if I've put delayed indexing
10:08 <Pbas> write access on on page then
10:08 <Pbas> and reinit it every hours
10:08 <Pbas> houre just to test editor without registering
10:10 <Pbas> (because "basic" users like test wysiwig editor I think)
10:10 <vmassol> wdym by "write access on on page then"?
10:10 <vmassol> one page you mean?
10:10 <mflorea> has joined #xwiki
10:11 <lkrejci> has joined #xwiki
10:11 <Pbas> Give write access on http://playground.xwiki.org/xwiki/bin/view/Sandbox/WebHome at guests
10:11 <vmassol> we could do:
10:11 <evalica> has joined #xwiki
10:12 <vmassol> hmm no
10:12 <vmassol> yes we could open Sandbox to everyone as a test
10:12 <Pbas> all space instead an unique page?
10:13 <vmassol> tmortagne, mflorea, all: wdyt about giving guests write access to Sandbox space on playground as a test?
10:13 <vmassol> (I'd modify the welcome message to explain that)
10:13 <Pbas> You can wipe it every houres to secure it
10:14 <vmassol> that's a bit more complex
10:14 <Pbas> maybe
10:14 <Pbas> You can use my extension for that ;-))
10:15 <vmassol> link?
10:15 <Pbas> Ouch!
10:15 <Pbas> http://extensions.xwiki.org/xwiki/bin/view/Extension/Reinit_Sandbox
10:15 <Enygma`> has joined #xwiki
10:16 <Pbas> you are mean ;-)
10:16 <mflorea> vmassol is playground excluded from indexing? (in robots.txt)
10:16 <vmassol> not sure, I've implemented delayed indexing though
10:16 <vmassol> so only pages that are older than 5 days are indexed
10:17 <vmassol> however need to check if it's based on creation date, don't remember
10:17 <mflorea> IMO it shouldn't be indexed at all
10:17 <vmassol> sure I can do that
10:17 <mflorea> maybe expect for the home page, which should e readonly
10:18 <mflorea> s/expect/except
10:18 <vmassol> actuallt it's already done :)
10:18 <mflorea> great
10:18 <mflorea> then I guess we can allow edit for guests on Sandbox space
10:18 <vmassol> through
10:18 <vmassol> <meta name=“robots” content=“noindex,nofollow” />
10:19 <mflorea> good
10:19 <vmassol> ok let's try it and we'll see how it goes
10:19 <vmassol> let me prepare this
10:19 <vmassol> fixing invitation issue first
10:19 <Pbas> Why homepage readonly?
10:20 <Pbas> sandbox homepage
10:20 <mflorea> Main.WebHome readonly, not Sandbox.WebHome
10:20 <Pbas> to show editor
10:21 <Pbas> ha ok sorry
10:21 <mflorea> Main.WebHome has some messages explaining the goal of the playground wiki
10:21 <Pbas> sure
10:21 <mflorea> we don't want those deleted
10:21 <vmassol> hmm there are strange things on playgroundtemplate
10:22 <Pbas> but you will give guest access right to sandbox space only, isn't it?
10:22 <vmassol> yes
10:22 <vmassol> write access
10:22 <Pbas> right is not write yes sorry :-D
10:23 <Pbas> the worst is ... my wife is english
10:27 <KermitTheFragger> has joined #xwiki
10:36 <Slashman> has joined #xwiki
10:39 <Pbas> FYI your bot seem to be down (the bot who send extensions updates to this IRC)
10:48 <cjd> !news
10:48 <cjd> indeed, it's connected but not responding
10:50 <vmassol> been broken for weeks now
10:51 <cjd> ok then I won't bother trying to find the page and cycle it
11:10 <lkrejci> has quit
11:11 <lkrejci> has joined #xwiki
11:26 <Enygma`> vmassol: http://jira.xwiki.org/browse/XWIKI-12912 has a commit on it, but it`s an added test. I guess it can safely be moved to 8.1M2
11:27 <vmassol> Enygma`: yes
11:27 <vmassol> thanks
11:27 <vmassol> test is @ignore
11:29 <tmortagne> Enygma`: I don't think we can release with http://jira.xwiki.org/browse/XWIKI-12912
11:29 <tmortagne> http://jira.xwiki.org/browse/XWIKI-13288 sorry
11:30 <vmassol> cjd: question for your on the invitation app
11:31 <Enygma`> mflorea: any plans for http://jira.xwiki.org/browse/XWIKI-11095? Should we split it?
11:31 <vmassol> did you test installing it in a subwiki and verify it works for guest, for a user logged in locally and for a user logged in on the main wiki?
11:31 <vmassol> (that's for cjd)
11:33 <vmassol> cjd: for example for Invitation.InvitationCommon I see it allows view for guests and XWiki.XWikiAllGroup in a XWiki.XWikiRights xobject. What about a user logged in on the main wiki?
11:34 <cjd> I don't recall, likely no because at the time when the automated tests were written there was no ability to automatically test subwikis
11:35 <Enygma`> we currently have 2 blockers:
11:35 <Enygma`> http://jira.xwiki.org/browse/XWIKI-13179
11:35 <vmassol> tmortagne: I see a XWiki.XWikiGlobalRights xobject on a page with an allow for groups: "xwiki:XWiki.XWikiAllGroup,XWiki.XWikiAllGroup,". Does that work? Doesn't it needs a XWiki.XWikiRights xobject instead for local XWiki.XWikiAllGroup?
11:36 <vmassol> cjd: so I can assume that right now the invitation app should only be installed on the main wiki to work properly?
11:36 <tmortagne> XWikiRights is for the page, nothing do with the group
11:36 <cjd> vmassol: yes, that's a fair assumption because the testing has not been performed
11:36 <cjd> AFAIK it's not part of the QA test program
11:37 <vmassol> cjd: ok then, I'll add a namespace restriction to it and remove it from the subwiki list of apps
11:37 <Enygma`> tmortagne: would you be available to handle http://jira.xwiki.org/browse/XWIKI-13288 ?
11:37 <cjd> ooo we have main-wiki-only restriction now ?
11:38 <vmassol> yup
11:38 <cjd> I want to apply that to WebSocket because that is an endless difficulty
11:38 <tmortagne> Enygma`: this afternoon yes
11:38 <cjd> How do I set that ?
11:38 <vmassol> wait
11:38 <acotiuga> I would like to write some JUnit tests in xwiki-platform-ratings module but I'm not sure if their place should be in a xwiki-platform-ratings-test submodule (doesn't exist) or in xwiki-platform-ratings/src/test/java/org/xwiki/ratings/
11:39 <vmassol> cjd: example: https://github.com/xwiki/xwiki-platform/blob/182857c98f68924afcb99d1b3c39278dee698385/xwiki-platform-core/xwiki-platform-vfs/xwiki-platform-vfs-api/pom.xml#L44-L44
11:39 <cjd> ok, that's easy enough :)
11:39 <cjd> thanks
11:39 <Enygma`> acotiuga: unit tests go with the code, so same module
11:39 <Enygma`> only functional tests need a separate module
11:40 <Enygma`> (selenium)
11:40 <acotiuga> thanks
11:40 <vmassol> cjd: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki80#HNamespaceconstraint and http://extensions.xwiki.org/xwiki/bin/view/Extension/XWiki+Commons+-+Extension+-+Repository+-+Maven#HCustomproperties
11:40 <tmortagne> acotiuga: depend if you need a real XWiki instance or if you are fine with a mocked database which is just a map with documents in it and no search support
11:40 <cjd> thanks also
11:40 <lkrejci> has quit
11:40 <vmassol> cjd: last link has the most info
11:40 <tmortagne> s/no search support/no query support/
11:41 <lkrejci> has joined #xwiki
11:41 <tmortagne> also if the goal is to test the UI you usually need a real instance of XWiki right now
11:45 <acotiuga> Maybe I didn't understand well the idea of unit tests and functional tests, but I thought unit test has nothing to do with the UI...
11:46 <acotiuga> Now, there are no tests on ratings module and I would like to start with unit tests and then to add some functional tests
11:46 <tmortagne> you said "JUnits tests", not unit tests, everything is run with Junit :)
11:47 <acotiuga> ahh
11:47 <tmortagne> so I'm indicating you all possibilities for Junit test ;)
13:31 <vmassol> Enygma`: can I push to platform on master?
13:32 <vmassol> since I see a commit message about rendering above I guess you're currently building platform and thus the answer is probably no
13:32 <vmassol> I can wait
13:39 <acotiuga> I can see that javax.servlet:servlet-api:jar is used as dependency in some contrib applications and even in xwiki-platform, but it hasn't a <version>
13:39 <acotiuga> Using it in the same way I got org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs: [ERROR] 'dependencies.dependency.version' for javax.servlet:servlet-api:jar is missing. @ line 71, column 17
13:40 <lkrejci> has quit
13:40 <lkrejci> has joined #xwiki
13:41 <acotiuga> Should I look somewhere for that version or is there any way to skip this check ?
13:41 <vmassol> deleting playground again
13:42 <vmassol> acotiuga: the version is inherited from the parent pom
13:42 <vmassol> this check should not be skipped, it's very important :)
13:43 <vmassol> you should also not have a scope for it
13:43 <vmassol> since it should inherit from parent and be provided
13:43 <vmassol> that's also very important
13:43 <acotiuga> I have the test scope
13:43 <vmassol> it's not correct
13:43 <vmassol> it's not too bad but not the best
13:44 <vmassol> if it's needed during testing it means it's required when executing
13:44 <vmassol> (probably)
13:44 <acotiuga> https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-watchlist/xwiki-platform-watchlist-api/pom.xml#L77
13:44 <vmassol> so there should be a runtime scope, but since this jar is provided by the servlet container ti should be provided
13:44 <vmassol> which is what is done in parent poms
13:44 <vmassol> yes it depends why you need it
13:45 <vmassol> I can't guess this so you need to see why it's needed
13:45 <vmassol> or paste the reason why you have a problem when running
13:45 <vmassol> reason = stack trace
13:48 <acotiuga> since I'm trying to follow the example from the above url, I guess I need it for the same reason: running unit test and maybe to mock something (XWikiContext, XWikiDocument)
13:49 <vmassol> you need to know for sure
13:49 <acotiuga> http://pastebin.com/PPvcpDR9 stacktrace
13:55 <xwikibot> has joined #xwiki
13:57 <vmassol> evalica: cool, didn't realize that the top level menu on playground was only visible to admins or to users logged on the main wiki
13:57 <vmassol> hmm actually it's a bug
13:57 <vmassol> it's also visible to guests
13:57 <vmassol> so it's not visible to local users only!
13:58 <vmassol> Pbas: ok invitation app should not be visible anymore on playground for non admins
13:58 <vmassol> (I'm talking about the entry in the applications panel)
14:00 <vmassol> acotiuga: so the main issue is that this dep in a provided and thus is not inheritable, see https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
14:01 <vmassol> so we cannot just set it in the modules that need it for compilation
14:01 <vmassol> we also need it in the modules that uses the modules that need it for compilation
14:02 <vmassol> I guess we could cheat tmortagne
14:02 <vmassol> maybe by setting a compile scope and then removing that artifact when we create the WAR
14:02 <Pbas> vmassol: yes invitation is not visible anymore.
14:03 <vmassol> the EM would see it as a compile time dep when installing extensions but since the artifact will always be present locally it might be ok… could be an issue if it has a different version though…hmmm that would be a problem
14:03 <vmassol> I don't see any solution to improve the situation...
14:03 <vmassol> Pbas: ok cool
14:03 <vmassol> moving to documenting my issues for 8.1M1 RN now
14:06 <tmortagne> vmassol: we could say the same from any <scope>provide</scope> dependency since this use case is the perfect illustration of what provided scope was designed for bu indeed this scope is not very nice for tests of backward dependencies
14:06 <tmortagne> *<scope>provided</scope>
14:07 <vmassol> yes it's true for all but servlet-api is really one we have to put back everywhere
14:07 <vmassol> another option
14:07 <vmassol> is to add it as a dep for all modules by default
14:07 <vmassol> not sure it's that nice though
14:08 <vmassol> (by default = in top level pom)
14:14 <tmortagne> not very nice no
14:14 <tmortagne> and it's not everywhere, far from it
14:14 <tmortagne> it's usally in module that deal with request
14:15 <vmassol> well in module that uses some other modules that deal with requests
14:15 <vmassol> and when you have some module in the way that depends on oldcore then you need it...
14:16 <tmortagne> not really, you need to deal with request during the test
14:16 <tmortagne> it's not because you depend on oldcore that your test will use servlet API
14:16 <vmassol> not really
14:16 <vmassol> java fails to load any class that has an import that uses the servlet api
14:16 <vmassol> you don't need to use requests
14:16 <tmortagne> I did not say use request in your test, I said during the test
14:17 <vmassol> yes thats what I said
14:17 <tmortagne> many module depend on oldcore but use things that don't touch request
14:17 <vmassol> you don't need to use requests during your test
14:17 <tmortagne> Java will not load all the classes of oldcore during the test
14:17 <vmassol> you just need to use a class/component that has some methods using servlet api but this class/component can also have some other methods not related at all to sevlet api
14:17 <tmortagne> only what is actually used
14:17 <vmassol> (that you're using)
14:18 <vmassol> it happened to me plenty of times
14:22 <tmortagne> here is an idea
14:23 <tmortagne> * extract reusable test stuff from oldcore (mostly MockitoOldcoreRule and stuff around it)
14:23 <tmortagne> * make this new test module declare a runtime dependency on servlet API
14:24 <tmortagne> most module that need oldcore during test need MockitoOldcoreRule (or should move to) and other oldcore oriented test stuff
14:25 <tmortagne> that way you automatically get servlet API when you use oldcore test tool but only as test dependency because you declare oldcore-test as test dependency
14:27 <vmassol> so the trick is in using "runtime" (which is inheritable) rather than "provided" for tests
14:27 <vmassol> seems interesting
14:29 <tmortagne> only in a module that is alwyas used as test dependency
14:29 <tmortagne> the issue with that is test of oldcore module itself
14:30 <tmortagne> since they will need to be move in another module that can depend on oldcore-test which is not nice from test coverage point of view
14:30 <tmortagne> but it's nicer for all modules that use those test tools
14:31 <tmortagne> hmm what can work for everyone is to depend on oldcore test jar in oldcore-test and also add the servlet api dependency
14:32 <tmortagne> that way other modules use oldcore-test instead of oldcore and oldcore can still directly use MockitoOldcore and stiff like this
14:32 <tmortagne> s/stiff/stuff/
14:32 <tmortagne> doing it quickly in a branch, will be easier to understand :)
14:33 <vmassol> :)
14:36 <vmassol> mflorea: Found a regression in search on xwiki.org
14:37 <mflorea> vmassol: what's the problem?
14:37 <vmassol> I searched for something and opened the Location facet, then selected one location; it refreshed and then I cannot choose another location
14:37 <vmassol> (and the location facet was closed again btw but that's a minor usability issue)
14:37 <mflorea> you have links in the location facet right?
14:38 <vmassol> you can try it here: http://www.xwiki.org/xwiki/bin/view/Main/Search?text=clirr&f_type=DOCUMENT&f_locale=en&f_locale=&r=1&l_space_facet=10
14:38 <mflorea> it shows a breadcrumb
14:38 <vmassol> ah wait
14:38 <mflorea> yes
14:38 <mflorea> it's a breadcrumb
14:38 <vmassol> I'm using it wrongly
14:38 <vmassol> :)
14:38 <vmassol> hmm no
14:39 <vmassol> how do I say:
14:39 <vmassol> all spaces except those
14:39 <vmassol> ?
14:39 <vmassol> for some reason I thought there were all selected and I could uncheck them, which is what would seem logical but I don't see that anymore
14:39 <mflorea> you need to use query syntax, this can't be done from the facet
14:40 <vmassol> it's strange because the other facets use another behaior
14:40 <vmassol> behavior
14:40 <vmassol> they select all items and you can unselect
14:40 <vmassol> not all, some
14:40 <mflorea> that's not the case for the datafacet
14:40 <lkrejci> has joined #xwiki
14:40 <vmassol> actually very few
14:41 <mflorea> each face can have its own behaviour
14:41 <vmassol> only result type and language
14:41 <vmassol> hmm still not easy way to see the syntax, we need to fix that
14:41 <mflorea> selecting all the values makes sense _only_ when the list of values is very limited
14:42 <mflorea> otherwise selecting all the values will generate a huge query
14:42 <vmassol> can you remind me how to exclude some locations?
14:42 <vmassol> I see
14:42 <vmassol> -space:ReleasePlans doesn't work so that's not the right syntax
14:42 <mflorea> -space_exact:A.B
14:43 <mflorea> you need to exclude subspaces also?
14:43 <vmassol> not on xwiki.org
14:43 <vmassol> since we don't use them atm
14:43 <vmassol> so yes space_exact is far from obvious without a help
14:43 <vmassol> thanks
14:44 <vmassol> ah one issue
14:44 <vmassol> how do you unselect a location? :)
14:45 <vmassol> don't tell me to hit the browser back button! :)
14:45 <vmassol> (kidding)
14:45 <mflorea> as I said above, when you select a location you get a breadcrumb
14:45 <mflorea> which you can use to navigate to any parent
14:45 <vmassol> I don't want to nav
14:45 <mflorea> including the root (home0
14:45 <vmassol> I'm searching
14:45 <mflorea> I'm referring to the Location facet
14:45 <vmassol> oh clickong on the home seems to work
14:46 <mflorea> it shows you a breadcrumb
14:46 <vmassol> that's nice but really not intuitive
14:46 <mflorea> it's a breadcrumb
14:46 <vmassol> would be better to have checkbox as the othr facets
14:46 <mflorea> we show it everywhre
14:46 <vmassol> yes but it means bavigating
14:46 <vmassol> *navigating
14:46 <vmassol> I'm not navigating here
14:46 <vmassol> I would never have dreamed being able to click on it
14:46 <vmassol> and stay on the search pagre
14:46 <vmassol> *page
14:47 <vmassol> I didn't even try because i didn't want to move away from the search
14:48 <vmassol> anyworks works for me FTM but I don't feel it's very intuitive
14:48 <vmassol> thanks
14:50 <tmortagne> vmassol: https://github.com/xwiki/xwiki-platform/compare/feature-test-oldcore?expand=1
14:52 <tmortagne> by the way the forced dependency to test-component in xwiki-platform-core should be removed IMO, it force doing hack in the test module like this one
14:52 <tmortagne> if a module need test-component module it's not such a pain to put it in dependencies
14:52 <tmortagne> which is what many modules do anyway already
14:53 <tmortagne> (it's also wrong to make all module that don't need that depend on it, like XAR modules)
14:55 <vmassol> mflorea: any idea why http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/ReleasePlanHelp#HGenerateBackwardCompatibilityReport doesn't appear in http://www.xwiki.org/xwiki/bin/view/Main/Search?sort=score&sortOrder=desc&highlight=true&facet=true&r=1&f_type=DOCUMENT&f_locale=en&f_locale=&l_space_facet=10&text=clirr+-space_exact%3AReleasePlans+-space_exact%3AIRC ?
15:01 <vmassol> @all: should we remove http://dev.xwiki.org/xwiki/bin/view/Community/ReleaseProcess now?
15:01 <vmassol> (I think so)
15:05 <vmassol> Enygma`: let me know when I can commit in platform on master
15:05 <vmassol> tmortagne: ok re "the forced dependency to test-component in xwiki-platform-core should be removed IMO"
15:06 <vmassol> ah I see it's in your branch
15:07 <vmassol> tmortagne: not sure why you removed <artifactId>xwiki-commons-tool-test-component</artifactId> from xwiki-platform-test-page/pom.xml
15:07 <tmortagne> vmassol: it provided by test-oldcore
15:07 <vmassol> it seems good to have it to me, isn't it a direct dep
15:07 <tmortagne> *it's
15:07 <vmassol> yes I know
15:07 <vmassol> but still
15:08 <vmassol> when oldcore goes away, it's still required
15:08 <vmassol> that's what I mean by a direct dep
15:08 <vmassol> ok for the rest
15:08 <vmassol> now we need to see what effect this has on the rest ;)
15:09 <mflorea> vmassol: you exclude ReleasePlans space and ReleasePlanHelp is in that space
15:09 <vmassol> mflorea: ah… stupid me....
15:09 <vmassol> brain not working fully today it seems…
15:09 <vmassol> sorry
15:09 <mflorea> :)
15:09 <mflorea> np
15:10 <vmassol> this shows that I still don't trust our search 100% yet
15:10 <vmassol> I need to shake that belief!
15:10 <vmassol> *shake off
15:10 <lkrejci> has quit
15:10 <vmassol> (inherited from the past I guess and from indexing issue we had)
15:10 <lkrejci> has joined #xwiki
15:11 <tmortagne> vmassol: "now we need to see what effect this has on the rest" for now the effect is less dependencies to declare for other modules
15:12 <vmassol> we don't need to add the test dep removed from xwiki-platform-core in lots of places?
15:12 <vmassol> (not saying it's a bad thing!)
15:12 <Enygma`> vmassol: done building the release
15:13 <vmassol> thanks
15:15 <tmortagne> vmassol: according to Eclipse all is ok with the current state of the branch so it seems that all project that needed test-component where the same that were using oldcore stuff (or they explicitely declare test-component)
15:16 <vmassol> hehe we were all stacking commits ;)
15:22 <Aranjedeath> has quit
15:22 <M-yflory> has quit
15:22 <lynxt> has quit
15:24 <lynxt> has joined #xwiki
15:25 <vmassol> Enygma`: haven't you implemented this https://jira.xwiki.org/browse/XWIKI-13290 already?
15:25 <vmassol> hmm maybe it's different, not sure I understand fully, I'll comment
15:26 <M-jsimard> has quit
15:26 <vmassol> ah yes it's different, I get it now
15:26 <M-jsimard> has joined #xwiki
15:27 <Aranjedeath> has joined #xwiki
15:29 <Enygma`> vmassol: yes, it`s about making the selected spaces of a template provider apply to their children as well
15:29 <vmassol> so right now when you click in the tree
15:30 <vmassol> it only selects the current node but not the children, right?
15:30 <Enygma`> yes, current space actually, so it inherits to terminal docs inside that space, including WebHome
15:30 <Enygma`> but not to Nested Spaces, children of the selected space
15:30 <vmassol> ok got it, thx
15:31 <Enygma`> applied the same thing to the Annotations Administration section
15:31 <Enygma`> it`s highly problematic to inherit
15:31 <Enygma`> since you can not say that from this point on, don`t inherit anymore
15:31 <vmassol> you can unselect
15:31 <vmassol> in the tree
15:31 <Enygma`> and also, from this other point on, start inheriting again
15:32 <Enygma`> it`s also a problem of what do you store in the preference?
15:32 <vmassol> ah yes
15:32 <vmassol> ok it's easy in the tree but harder to persist the information
15:32 <Enygma`> the top node and inherit programatically or do you store *all* child nodes (including the top node)
15:32 <Enygma`> I`ve looked at it from various angles and this was the only "sane" thing to do at the moment
15:34 <Enygma`> we will also probably encounter this problem in other forms in the future as well
15:34 <Enygma`> since I`ve encountered it twice so far (Annotations + Template providers)
15:34 <Enygma`> so maybe we`ll come up with a better approach in the end
15:40 <tmortagne> looks like XEclipse follow test dependencies like it was compile dependencies when the project is open
15:50 <Enygma`> has quit
15:50 <Enygma`> has joined #xwiki
15:56 <sdumitriu> has quit
16:00 <sdumitriu> has joined #xwiki
16:04 <acotiuga> has quit
16:27 <Enygma`1> has joined #xwiki
16:29 <sdumitriu> has quit
16:30 <Enygma`> has quit
16:35 <sdumitriu> has joined #xwiki
16:39 <Pbas> has quit
16:48 <tmortagne> has quit
17:35 <tmortagne> has joined #xwiki
18:10 <lkrejci> has quit
18:10 <lkrejci> has joined #xwiki
18:12 <cjd> has quit
18:27 <vmassol> tmortagne: I see you added some ignores in commons for revapi
18:28 <vmassol> for non-young apis
18:28 <vmassol> is that normal? do we need to to discuss that to make sure we don't break users?
18:28 <vmassol> (users = extensions)
18:28 <tmortagne> those change are binary compatible
18:29 <vmassol> why are they ignored then?
18:29 <vmassol> I have checked revapi issue tracker and didn't see an issue for them
18:29 <tmortagne> because they are incompatible from build point of view and revapi take that seriously it seems
18:29 <vmassol> but we need to report it if it's wrong!
18:30 <KermitTheFragger> has quit
18:30 <tmortagne> basically if you upgrade you dependency on commons you will need to update you code if it call those methods to build properly
18:31 <vmassol> just asked here: https://github.com/revapi/revapi/issues/36#issuecomment-205885076
18:31 <tmortagne> its not wrong
18:31 <vmassol> you said "those change are binary compatible"
18:32 <vmassol> are they or are they not? :)
18:32 <vmassol> ah yes
18:32 <tmortagne> yes but they are not compatible for the build
18:32 <vmassol> ok so they are binary
18:32 <vmassol> but not source
18:32 <tmortagne> yep
18:32 <vmassol> is that it?
18:32 <vmassol> so revapi is correct
18:32 <vmassol> it's reporting backward compat issues
18:32 <tmortagne> yep but I think CLIRR used to not check source compatibility
18:32 <vmassol> ie binary + source
18:32 <vmassol> no
18:32 <tmortagne> by the way did we updated the release plan for revapi ?
18:33 <vmassol> clirr was checking source too
18:33 <tmortagne> ok did not noticed
18:33 <vmassol> re release plan no, we need to figure out how to do it, I'm still working on it
18:33 <vmassol> I talked to Edy today about it during the release and on skype (see chat)
18:33 <tmortagne> I guess it's pretty much the same as CLIRR: remove the ignores and build
18:34 <vmassol> not quite
18:34 <tmortagne> it's just that we don't have tools to make it easier now
18:34 <vmassol> it's harder ATM
18:34 <vmassol> I am discusing here: https://github.com/revapi/revapi/issues/29
18:35 <vmassol> clirr could output violations to a file
18:35 <tmortagne> anyway for 8.1M1 I can add those 3 myself CLIRR style for now, not a big deal
18:35 <vmassol> ATM I have an issue
18:35 <vmassol> I cannot make revapi fail
18:35 <vmassol> see https://github.com/revapi/revapi/issues/36
18:36 <tmortagne> hmm it was definitely failind when I added the ignore since I copy pasted the JSON :)
18:37 <tmortagne> s/failind/failing/
18:37 <vmassol> could you try it?
18:37 <vmassol> remove ignore and build
18:37 <tmortagne> did we ungraded revapi in the meantime ?
18:37 <tmortagne> trying
18:37 <vmassol> I wondered abtout that but I rolled back locally to previous version of revapi and it didn't fail either
18:38 <lkrejci> has quit
18:40 <tmortagne> vmassol: does not fail for me either when I remove the ignores
18:40 <tmortagne> maybe revapi have some kind of cache
18:40 <vmassol> ok
18:40 <tmortagne> but I used clean
18:40 <vmassol> lukas has reproduced and I guess he's debugging now
18:42 <tmortagne> ok
18:42 <tmortagne> poor lukas, ending up being used by XWiki
18:42 <vmassol> :)
18:42 <vmassol> yes xwiki is not a relaxing user… ;)
18:44 <vmassol> tmortagne: "Known flavors are not tested anymore in the Distribution Wizard"
18:44 <vmassol> you mean s/not/now?
18:44 <vmassol> (in RN of 8.1M1)
18:45 <vmassol> ah no
18:45 <vmassol> forget that
18:45 <tmortagne> nop its the right word :)
18:45 <vmassol> you mean flavors are now listed?
18:45 <tmortagne> you need to remember what was introduce in 8.0 actually for it to be more clear
18:46 <tmortagne> in 8.0 we started validating flavors in the background, known flavors and directly added without any validation
18:46 <tmortagne> will rewrite it a bit
18:46 <vmassol> ok thanks
18:46 <tmortagne> finishing with API stuff
18:46 <vmassol> what's a known flavor?
18:47 <vmassol> maybe you could also explain what it means to "repair" an extension in the RN?
18:47 <vmassol> (it's not clear to me)
18:48 <vmassol> reminder to self: fix the line "The XAR plugin now also verifies that Translations.xml pages are using the plain/1.0 syntax.
18:48 <vmassol> "
18:51 <tmortagne> done
18:51 <lkrejci> has joined #xwiki
18:52 <vmassol> thx
18:52 <tmortagne> I tough "repair" was clear in the context of an invalid extension, it tries to find a way to repair it whatever is the issue
18:52 <vmassol> how can an extension be broken?
18:53 <tmortagne> usually because of an upgrade of the WAR where something changed
18:53 <vmassol> for me broken means it doesn't work, like there's a bug in it
18:53 <vmassol> so repair would fix that, seems hard to do
18:53 <tmortagne> core extension removed or new core extension conflicting with an installed extension for example
18:53 <tmortagne> it's invalid from Extension Manager point of view
18:54 <tmortagne> EM have no idea if you extension works or not
18:54 <vmassol> I know
18:55 <vmassol> hmm
18:55 <vmassol> "The Extension Manager now tries to repair automatically any invalid dependency and provides a "Repair" button to repair specific invalid extension."
18:56 <lkrejci> has quit
18:56 <vmassol> if it does it automatically why is there a repair button?
18:56 <tmortagne> dependency
18:56 <vmassol> ok
18:56 <tmortagne> if you install a perfectly valid extension which depends on an already installed but invalid one it used to fail
18:57 <lkrejci> has joined #xwiki
18:57 <vmassol> so right now if you an extension that is invalid and has invalid deps
18:57 <vmassol> those deps will be fixed
18:57 <vmassol> but not the extension
18:57 <vmassol> and you need to click repair for that
18:57 <vmassol> ?
18:57 <vmassol> s/you an/you have an
18:57 <tmortagne> no
18:57 <vmassol> ok I don't understad the snetence then :)
18:57 <tmortagne> Extension Manager does not fix anything at startup
18:58 <tmortagne> its automatic as automatically done during install or another extension
18:59 <tmortagne> s/or/of/
19:00 <vmassol> ok don't worry, I don't understand but it doesn't matter ATM. I fear not many people will understand either though
19:00 <vmassol> (this concept of repair and what it means)
19:00 <vmassol> they'll just click on repair when they see it :)
19:00 <tmortagne> that's the plan :)
19:00 <vmassol> hopefully that's good enough and they don't need to understand anything more
19:01 <tmortagne> they have a read message and a button talking about repairing it, I guess it's enough for most user
19:01 <vmassol> ok re revapi we know the problem
19:01 <vmassol> https://github.com/revapi/revapi/issues/36#issuecomment-205890553
19:02 <vmassol> lkrejci: :)
19:02 <vmassol> (thanks for checking this out so quickly btw! that's great :))
19:10 <evalica> has quit
19:11 <mflorea> has quit
19:14 <Enygma`1> has quit
19:31 <lkrejci> vmassol: so the ball hopefully is back on your side ;)
19:34 <cjd> has joined #xwiki
19:56 <vmassol> bb in 1 hour
19:56 <vmassol> actually 2
20:01 <sorinello> has joined #xwiki
20:26 <tmortagne> has quit
20:33 <Slashman> has quit
20:35 <abusenius> has joined #xwiki
20:47 <abusenius> has quit
21:09 <mflorea> has joined #xwiki
21:14 <mflorea> has quit
21:47 <Daemoen> lo folks
22:39 <lkrejci> has quit
22:40 <lkrejci> has joined #xwiki
23:45 <Denis1> has quit
23:45 <Denis> has joined #xwiki
23:52 <vmassol> has quit
23:58 <Daemoen> how do you extend the ability of macro to support additional modules (in the case of python; i want to dynamically generate pages based on inventory information, thus i need to import mysql, etc)
