IRC Archive for channel #xwiki on 31 August 2015
Last modified by Vincent Massol on 2015/08/31 23:56
<Denis1> has joined #xwiki
01:29 <abusenius_> has quit
01:35 <Denis1> has quit
03:49 <Denis1> has joined #xwiki
03:54 <Denis1> has quit
04:29 <cpe> has quit
04:29 <cpe_> has joined #xwiki
04:29 <cpe_> is now known as <cpe>
06:52 <Ramona1> has joined #xwiki
06:53 <mflorea> has joined #xwiki
07:05 <msmeria> has joined #xwiki
08:01 <sdumitriu> has quit
08:47 <sdumitriu> has joined #xwiki
08:54 <KermitTheFragger> has joined #xwiki
09:06 <vmassol> has joined #xwiki
09:07 <vmassol> has quit
09:07 <vmassol1> has joined #xwiki
09:21 <mflorea> has quit
09:22 <vmassol1> good morning
09:22 <vmassol1> today is release day! let's stabilize our build
09:22 <vmassol1> is now known as <vmassol>
09:41 <mflorea> has joined #xwiki
09:46 <vmassol> mflorea: you're the RM (in case you didn't know :))
09:46 <mflorea> I know :)
09:47 <mflorea> there is one test failing in test-escaping related to AnnotationCode.CreateForm
09:47 <mflorea> someone needs to look at it
09:47 <vmassol> someone caused a clirr error in platform too:
09:47 <vmassol> [ERROR] 6004: com.xpn.xwiki.XWikiConstant: Changed type of field EDIT_MODE_CLASS from org.xwiki.model.reference.EntityReference to org.xwiki.model.reference.LocalDocumentReference
09:47 <mflorea> yes
09:47 <vmassol> in xwiki-platform-legacy-oldcore
09:48 <vmassol> checking history
09:48 <mflorea> Edy should take care of the only selenium 1 test failing in administration because we removed the space switcher
09:49 <vmassol> ok reverting thomas change
09:49 <mflorea> I'm looking at the tests failing due to the changes made on the Create page UI
09:49 <vmassol> (it was thomas for clirr)
09:49 <gdelhumeau> has joined #xwiki
09:51 <evalica> has joined #xwiki
09:51 <vmassol> Edy caused http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-mail-test-tests/1767/testReport/junit/org.xwiki.mail.test.ui/MailTest/testMail/ too
09:52 <vmassol> yes mflorea this one is caused by the removal of the space admin switcher too
09:52 <Enygma`> has joined #xwiki
09:52 <mflorea> ok
09:52 <vmassol> looking for teh jira issue
09:52 <Denis1> has joined #xwiki
09:52 <vmassol> XWIKI-12172
09:53 <vmassol> you have a jenkins link to the other failing tests for the switcher mflorea?
09:53 <mflorea> yes, just a sec
09:53 <vmassol> (so that I can add them in the issue too)
09:53 <mflorea> http://ci.xwiki.org/job/xwiki-enterprise-test-selenium/lastBuild/org.xwiki.enterprise$xwiki-enterprise-test-selenium/testReport/org.xwiki.test.selenium/AdministrationTest/testSettingXWikiPreferences/
09:53 <vmassol> thx
09:55 <vmassol> this is also fro edy I think: http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-flamingo-skin-test-tests/1767/testReport/junit/org.xwiki.flamingo.test.ui/CreatePageAndSpaceTest/createSpaceAndPage/
09:55 <vmassol> (Enygma`)
09:55 <vmassol> and all the failing CreatePageTest
09:57 <vmassol> Enygma`: out of 10 failing tests in platform, 9 are for you to fix :)
09:57 <vmassol> this one is something else I think: http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-wysiwyg-test-tests/1767/testReport/junit/org.xwiki.wysiwyg.test.ui/EditWYSIWYGTest/testUndoRepeatedPaste/
09:58 <Ramona1> has quit
10:02 <Ramona1> has joined #xwiki
10:06 <Slashman> has joined #xwiki
10:21 <ClemensR> has joined #xwiki
10:27 <mflorea> vmassol: yes, EditWYSIWYGTest/testUndoRepeatedPaste/ was failing for M2 too, I investigated it and my conclusion was that it fails on some agents and passes on the others, but I couldn't determine the difference between the agents.
10:28 <vmassol> k….. yuck....
10:29 <mflorea> Enygma`: re the Create Page, I'm currently writing a page object for the document picker (which is used on Copy page also)
10:29 <Pbas> has joined #xwiki
10:30 <Enygma`> getting on it
10:40 <Enygma`> has quit
10:41 <tmortagne> has joined #xwiki
10:41 <Enygma`> has joined #xwiki
10:42 <vmassol> checking the escaping test http://ci.xwiki.org/job/xwiki-enterprise-test-escaping/lastCompletedBuild/org.xwiki.enterprise$xwiki-enterprise-test-escaping/testReport/org.xwiki.test.escaping/ApplicationTest/AnnotationCode_CreateForm_xml__page__selectionContext__language__space__wiki__comment__selectionOffset__selection__reference___testParametersInFlamingo/
11:00 <woshilapin> has joined #xwiki
11:02 <tmortagne> has quit
11:24 <tmortagne> has joined #xwiki
11:32 <tmortagne> has quit
11:38 <vmassol> note: I think thomas introduced some regressions in the annotation module
11:39 <vmassol> going to reopen the issue
11:55 <Enygma`> gdelhumeau, vmassol: we still have no UI to go to the Administration of a space (Nested Document). To fix the failing administration tests, I`ll just build the URL by hand in the page object methods.
11:55 <vmassol> hmm when is this planned?
11:55 <vmassol> (the UI)
11:55 <gdelhumeau> evalica: what do you think?
11:55 <gdelhumeau> the space concept should be hidden in the UI normally
11:55 <vmassol> Enygma`: the alternative is to implement a tree switcher
11:56 <vmassol> (which could be useful)
11:56 <gdelhumeau> and we should create a page admin instead
11:56 <gdelhumeau> when we'll have the page administration the functionnal tests abour space admin wil not be usefull anymore
11:56 <vmassol> I don't see what harm it would do to be able to switch admin page from within the admin
11:57 <vmassol> gdelhumeau: most failing tests are not about that
11:57 <vmassol> hmm maybe they ayre
11:57 <vmassol> *are
11:58 <evalica> since space administration is now 'page administration', the administration should be available in the 'More actions' part of the menu. But switching from global administration could be an alternative.
11:58 <vmassol> for MailTest the tests is about verifying that the admin options are not available in space admins
11:58 <vmassol> s/tests/test
11:59 <vmassol> I guess this test should go directly to the space admin instead of navigating
11:59 <vmassol> since it's not about testing the nav
11:59 <gdelhumeau> that's what Edy did
11:59 <vmassol> he already fixed it?
11:59 <gdelhumeau> for the tests he fixed
12:00 <gdelhumeau> oh sorry
12:00 <gdelhumeau> not did
12:00 <gdelhumeau> but will
12:00 <vmassol> it depends
12:00 <vmassol> that's not what he said
12:00 <vmassol> he said he'd do that everywhere
12:00 <vmassol> this makes sense only for tests that don't need to test the nav
12:00 <vmassol> but I guess we have some tests whoe prupose is to test this nav!
12:01 <vmassol> *whose
12:01 <gdelhumeau> yes
12:05 <Enygma`> vmassol: so you are proposing to change the tests instead of the page object?
12:05 <vmassol> Enygma`: do you want me to fix the MailTest?
12:06 <vmassol> Enygma`: depends
12:06 <vmassol> some tests are wrong
12:06 <vmassol> the MailTests is wrong for ex
12:06 <vmassol> (well not wrong wrong but it does unnecessary testing)
12:06 <vmassol> since it tests space admin swtiching which is not one of the goal of this test
12:07 <vmassol> so for tests like this we could fix them instead
12:07 <vmassol> however there remains the real tests which are testing the admin switching
12:07 <vmassol> and for these we need an alternative
12:07 <vmassol> which is why I was asking when wil we get it?
12:08 <vmassol> so right now we cannot administer a space?
12:09 <vmassol> (without direct url)
12:09 <Enygma`> right
12:09 <vmassol> that seems a blocker
12:09 <vmassol> so at the very minimum RC1
12:09 <vmassol> or possibly delay this release
12:09 <vmassol> by one day to implement it
12:09 <Enygma`> mentioned it on http://jira.xwiki.org/browse/XWIKI-12189?focusedCommentId=87405&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-87405
12:09 <vmassol> because we need a solution for this for 7.2
12:09 <gdelhumeau> vmassol: I can add a temproray link
12:09 <gdelhumeau> to not block the release
12:10 <gdelhumeau> but at the end we should drop the space admin entirely
12:10 <Enygma`> we also need to think it better, since, AFAIK, only admins can access the space administration
12:10 <Enygma`> and now, with ND, that`s just wrong
12:11 <vmassol> Enygma`: we discussed this laready
12:12 <evalica> so the simplest solution now is to add an 'Administer' in the 'More actions' menu that will take to Space Administration
12:13 <Enygma`> (that is displayed only for non-terminal docs)
12:14 <Enygma`> actually, if the parent does not exist, there is an issue
12:14 <vmassol> yes ok for that but I think we need to fix it properly with the page admin in RC1
12:14 <Enygma`> (parent of a non-terminal doc)
12:14 <gdelhumeau> note that in the space admin, there is actually no mention of the term "space"
12:15 <evalica> that's good
12:15 <gdelhumeau> we could actually remove the "edit rights" button of a non-terminal page to have only this administration instead
12:15 <vmassol> gdelhumeau: I don't think sio
12:15 <gdelhumeau> and when it's a terminal doc, then, only the "edit right button", and "administer parent" maybe
12:15 <vmassol> so
12:15 <vmassol> because edit right is not the same as space admin ATM
12:17 <vmassol> one is about edit rigth of the current doc and space admin is about edit rights of all docs of the space
12:17 <vmassol> you cannot set page level rights with space admin
12:19 <gdelhumeau> some ideas there already: http://jira.xwiki.org/browse/XWIKI-12219#
12:20 <vmassol> yes I know
12:21 <vmassol> but the idea has never been to remove page edit rights
12:21 <vmassol> it was to propose both in the same UI
12:21 <vmassol> (in page admin)
12:22 <Enygma`> if we go for an unified page admin that handles both the current page and the space, then page edit rights needs to go
12:22 <vmassol> no
12:22 <vmassol> why?
12:22 <vmassol> see the issue screenshots
12:23 <vmassol> we need page edit rights
12:23 <vmassol> why do you say we don't?
12:23 <vmassol> how do you set page level rights?
12:23 <Enygma`> from this new and unified "page administration": http://jira.xwiki.org/secure/attachment/31242/proposal1.png
12:24 <Enygma`> at least according to this proposal
12:24 <vmassol> Enygma`: ok we're talking cross purpose
12:24 <vmassol> you said "page edit rights" needs to go
12:24 <vmassol> but you probably meant "the page edit rights menu entry" insetad, right?
12:25 <Enygma`> and the /edit/editor=rights template, yes
12:25 <vmassol> so yes, the idea is to have a single page admin
12:25 <vmassol> with all options
12:25 <vmassol> and you see those options depending on your rights
12:25 <vmassol> this is what we discussed in the past
12:26 <vmassol> (if you have admin rights you can change space options, ie affect children)
12:26 <vmassol> (and if you have only edit right you can only affect the current doc)
12:26 <Enygma`> the only concern I have about this is when we want to introduce other page-only related administration/preferences, besides rights... the unified "page administration" UI will get crowded with all sorts of settings first for the page only and then for the page + children... so groups of 2 settings for the same option
12:26 <Enygma`> which might get ugly
12:26 <vmassol> yes we need to present it nicely
12:27 <vmassol> but its logical to have 2 levels:
12:27 <vmassol> - this page only
12:27 <vmassol> - all children pages
12:27 <vmassol> but indeed there are various ways to prsent this
12:28 <Enygma`> yes... I am worried that we will not be able to do this for every option we want to administer...
12:29 <Enygma`> I just don`t see it happening
12:29 <evalica> http://design.xwiki.org/xwiki/bin/download/Improvements/PageAdministration/ContentHistory.png
12:29 <vmassol> well right now we have almost nothing at page level
12:29 <Enygma`> see the link Caty just pasted as a proposal of what we could administer at a page level
12:29 <evalica> but this was a complex idea
12:29 <vmassol> yes but I don't agree with most of them :)
12:29 <vmassol> like history is not an admin thing
12:29 <Enygma`> now imagine that each of those options is duplicated for both the page-only level and the pagel+children level
12:30 <vmassol> Enygma`: that's easy
12:30 <vmassol> that 'sa a checkbox : "Apply to children documents"
12:30 <evalica> in this proposal: history and attachments offered BULK action from administration.
12:30 <vmassol> "Apply to children documents too"
12:31 <vmassol> evalica: yes I don't understand why it would be in admin
12:31 <Enygma`> vmassol: Caty mentioned that to me too, but no... you will end up overriding the other .... you want to see at a given time what are the settings for only for the page and what are the settings for page+children
12:31 <vmassol> but forget the history example
12:31 <vmassol> we may still have lots of options one day if we want to provide ability to set the skin at page level, etc
12:32 <Enygma`> vmassol: and remember that this is now "page admin" and deleting/approving comments... reverting history, deleting attachments are "page administration" actions that are not suited for view mode
12:32 <Enygma`> yes, skin, page elements, etc
12:32 <Enygma`> very useful stuff IMO
12:32 <vmassol> not sure
12:32 <Enygma`> that we lack right now and have to hack with layoutVariables.vm
12:32 <vmassol> they haven't been useful for the past 10 years
12:32 <vmassol> :)
12:32 <vmassol> it's pretty edge cases
12:32 <vmassol> and even more now with nested spaces
12:33 <Enygma`> wdym? we use them alot with #set ($showComments = false) or something like that
12:33 <Enygma`> which is a hack
12:34 <vmassol> anyway I don't see a difference between:
12:34 <vmassol> - 2 entry menus, one for page level admin and another one for children admin level
12:34 <Enygma`> I just hope we`re not painting ourselves in a corner with this unified page admin
12:34 <vmassol> - a singele page admin with 2 sections: one for page level and one for children level
12:34 <vmassol> it's the same
12:35 <vmassol> you can have 2 tabs
12:35 <vmassol> or two left menu links or…
12:35 <evalica> or - a single page admin + switch between page or children mode
12:35 <vmassol> but in the end it's the same as 2 links in the menu
12:35 <vmassol> not more work, not less
12:35 <vmassol> yes or that
12:35 <vmassol> in the end we need to differentiate
12:36 <Enygma`> I like Caty`s idea of using a switch (select above the left menu)
12:36 <vmassol> between page level and children level
12:36 <Enygma`> and it`s very easy to implement
12:36 <vmassol> yes it'es good
12:36 <vmassol> *it's
12:36 <Enygma`> we`re just switching the page we are editing, but the user stays in the same UI
12:38 <Enygma`> commented on the issue about this idea
13:18 <Denis1> has quit
14:10 <Enygma`> vmassol: why were you saying that the mail tests don`t need to perform that step (checking if the mail category appears for space administration)?
14:11 <vmassol> I didn't say that :)
14:11 <vmassol> I said that this test doesn't need to navigate to the space admin
14:11 <vmassol> it could (and should) go to that space admin directly
14:11 <vmassol> said differently
14:11 <vmassol> going to the space admin should be part of the test fixture
14:13 <Enygma`> you mean that instead of starting with wiki administration, it could start with space administration?
14:20 <vmassol> I'm not saying that either
14:20 <vmassol> ok let me be specific
14:20 <vmassol> I'm talking about replacing this line:
14:20 <vmassol> AdministrationPage spaceAdministrationPage = administrationPage.selectSpaceToAdminister("XWiki");
14:21 <vmassol> with some getUtil().gotoPage()
14:21 <vmassol> (or add a static method in AdministrationPage to go directly to an admin section)
14:22 <vmassol> (not admin section but space admin page)
14:23 <vmassol> there's already AdministrationPage.gotoPage(), we could add AdministrationPage.gotoSpaceAdminPage(String spaceReference)
14:23 <Enygma`> yes, that`s what I was shooting for as well
14:23 <vmassol> ok
14:24 <vmassol> cool
14:24 <vmassol> cool thing is that we'll remove the hack at getDriver().waitUntilElementIsVisible(By.id("HAdministration:XWiki"));
14:24 <vmassol> ;)
14:25 <vmassol> and spaceAdministrationPage.waitUntilPageIsLoaded();
14:31 <Enygma`> yes, but this might be temporary, depending on what we will implement in its place in the coming future
14:31 <vmassol> why?
14:31 <vmassol> again it's not the goal of this test to validate that we can switch admin from one space to another
14:31 <vmassol> this test should not navigate
14:32 <vmassol> so direct url is going to be still valid in the future
14:32 <Enygma`> ok, I see what you meant
14:33 <vmassol> said differently, there's no point in having 5 tests that validate space admin swtiching, only one func tests validating this is enough and this test should be in the admin func tests
14:34 <Enygma`> the funny thing is that in reality, we end up having 5 tests indirectly testing a feature by using it in integration tests but without having a single test that directly tests the same feature :)
14:34 <vmassol> yes sometimes we're missing the test in the right place
14:34 <Denis1> has joined #xwiki
14:34 <vmassol> we need to be careful that we do have one validating this in the admin func tests :)
14:35 <Enygma`> :)
14:35 <vmassol> moving annotation test from enterprise to platform now to add some new tests
14:35 <vmassol> (to fix the rgeressions introduced by thomas)
14:35 <Enygma`> now, about the location of this method... looking at TestUtls, I see that we have there even create* methods, instead of having them say in the CreatePage page object
14:35 <Enygma`> so probably TestUtil is a better place for the method
14:36 <vmassol> AdministrationPage seems nice to me
14:36 <vmassol> *nicer
14:36 <Enygma`> and let the pageObjects contain more actual UI testing code
14:36 <vmassol> we started the gotoPage() pattern and for me it's the same pattern
14:36 <vmassol> ws're just contiuing it
14:37 <vmassol> the gotoPag() pattern being that each PageObject should have a way to go to it
14:37 <Enygma`> maybe in this case you are right, since it retuns an AdministrationPage
14:37 <vmassol> (directtly)
14:37 <vmassol> yes
14:37 <Enygma`> yep
14:41 <Enygma`> I guess we need to start using more references in our tests
14:41 <Enygma`> instead of strings
14:41 <vmassol> yes, I started doing this recently and added th required infra for it
14:41 <vmassol> (the resolvers)
14:41 <Enygma`> I was just looking for some resolvers
14:42 <Enygma`> just spotted it in TestUtils
14:42 <vmassol> in TestUtils I added some resolve method
14:43 <tmortagne> has joined #xwiki
14:48 <tmortagne> has quit
14:52 <Enygma`> wondering if the old AdministrationPage.selectSpaceToAdminister(String spaceName) method should redirect to the new static AdministrationPage.gotoSpaceAdministrationPage(String spaceReferenceString)
14:53 <vmassol> you mean very temporarily till RC1?
14:53 <Ramona1> has quit
14:53 <Enygma`> something like that, otherwise it`s useless if it`s not working
14:54 <vmassol> sure ok temporarily, the other option is to add the menu link to space admin
14:54 <Enygma`> I would still modify the currently failing code to use the static method instead of this, so that we avoid still using the UI when we should not
14:54 <vmassol> I'm ok for that
14:54 <vmassol> make sure to add todo and possibily a jira issue to remember putting it back :)
14:55 <vmassol> or add it as comment int he issue for the new page admin ui
14:55 <Enygma`> "putting it back" > you mean to actually implement it when the new UI is up
14:55 <vmassol> yes
14:55 <Enygma`> ok
15:03 <msmeria> has quit
15:08 <Denis1> has quit
15:09 <Denis1> has joined #xwiki
15:16 <vmassol> hmmm some problem in my func test
15:16 <vmassol> 15:15:09.836 [Thread-13] ERROR o.x.t.i.XWikiLogOutputStream - 2015-08-31 15:15:09,836 [http://localhost:8080/xwiki/bin/register/XWiki/Register] ERROR o.h.u.JDBCExceptionReporter - invalid schema name: ${MAINWIKIID}
15:16 <vmassol> debugging...
15:30 <tmortagne> has joined #xwiki
15:35 <tmortagne> has quit
15:37 <vmassol> haha found the culprit I think
15:37 <vmassol> in drawer.vm: #set ($hasHomeWikiAdmin = $xwiki.hasAccessLevel('admin', $xcontext.user, "${mainWikiId}:XWiki.XWikiPreferences"))
15:38 <vmassol> yep and mainwikiid is defined as #set ($mainWikiId = $services.wiki.mainWikiId)
15:38 <vmassol> which means it works only of the wiki module is available
15:38 <vmassol> so basically any func tests that doesn't have a dep on it fails
15:39 <vmassol> this is notnice
15:43 <gdelhumeau> the wiki module is not considered as a basic module of the platform?
15:44 <vmassol> it's never been
15:45 <vmassol> remember that we come from XEM
15:45 <vmassol> subwiki has never been a core notion
15:45 <Enygma`> we faked it into the model :)
15:45 <vmassol> not in the model
15:46 <vmassol> in a separate module
15:46 <gdelhumeau> yes but since 5.4 it's on XE
15:46 <vmassol> there's no reason to have it in the model
15:46 <gdelhumeau> and we can consider it as a basic package
15:46 <vmassol> I don't see why
15:46 <vmassol> I've complained sveeral times
15:46 <vmassol> about the 2 ways to get the main wiki and the current wiki but nodody paid attention it seems
15:47 <vmassol> which created the mess we have now
15:47 <gdelhumeau> to avoid using $xcontext.mainWikiId for example
15:47 <Enygma`> because multiwiki is now part of the model, don`t see why the API to handle should not be
15:47 <vmassol> it's the other way around
15:47 <vmassol> $services.wiki.mainWikiId is the mess
15:47 <vmassol> multiwiki is not part of the model and it never has been
15:47 <Enygma`> at least in the reference API (which is model) we have the notion of multiple wikis
15:47 <vmassol> whether we want it to be in thef turue is naother discussion
15:47 <Enygma`> a reference has a wiki which can be changed
15:48 <vmassol> imagine I want to use xwiki to create a software and I need only a single wiki
15:48 <vmassol> why would I have to have all the multiwiki modules in my software?
15:48 <Enygma`> imagine you want to use XWiki to create a software and you need only a single space
15:48 <vmassol> it's so easy to not have them
15:48 <Enygma`> why would you have to have all the spaces in you software?
15:48 <Enygma`> :)
15:48 <vmassol> it's hard to remove the space notion
15:49 <vmassol> but it's easy for the wiki part
15:49 <Enygma`> this is an implementation detail
15:49 <vmassol> since that's where we come from
15:49 <Enygma`> at the model level you have multiple spaces and multiple wikis
15:49 <Enygma`> IMO it`s a bad practice to keep seeing XWiki as a single wiki
15:49 <Enygma`> this lead to hundreds of bugs
15:49 <Enygma`> a good part of which I know of at least
15:50 <Enygma`> it`s one thing that we come from single wiki, but that was years ago
15:50 <Enygma`> IMO, we just have to stop thinking like that...
15:51 <Enygma`> having a look at the annotations issue
15:52 <vmassol> I'm on it
15:52 <vmassol> (re annotations)
15:52 <vmassol> been on it for a few hours already
15:52 <vmassol> I know exactly what are the problems with it
15:52 <Enygma`> ah, ok then
15:52 <Enygma`> good to know :)
15:53 <vmassol> I said it already on this chat earlier :)
15:53 <vmassol> (that I was handling it)
15:53 <Enygma`> that`s why I mentioned it because I remembered something but was not sure :)
15:53 <vmassol> ok
15:53 <vmassol> so you seem to be all thinking that we should bundle the wiki modules in the core. I know thomas thinks that too
15:54 <vmassol> on my side I want to make the core as small as possible and this in the opposite direction
15:54 <vmassol> but ok I can understand the point
15:54 <vmassol> now we haven't acted till now as if it were part of the core
15:54 <vmassol> so it's a change
15:55 <vmassol> and we need to send a proposal or a vote for this
15:55 <vmassol> there are 2 things that prove it wasn't core
15:55 <vmassol> 1) it's no in the package plugin deps
15:55 <vmassol> 2) in the code we have eveyrwhere things like this:
15:55 <vmassol> #if ("$!services.wiki" != '' && $services.wiki.currentWikiId != $services.wiki.mainWikiId)
15:56 <vmassol> ah maybe the discussion is about the wiki script service then ?
15:56 <vmassol> because that's my real issue
15:57 <gdelhumeau> what do you propose, introduce a core script service?
15:57 <gdelhumeau> to get the name of the main wiki?
15:57 <vmassol> we alreayd have one :)
15:57 <gdelhumeau> $xcontext ?
15:57 <vmassol> and we already have a model ss too
15:58 <vmassol> (ah no forget core script service, was thinking about core config)
15:58 <vmassol> but we have a model ss
15:58 <vmassol> and a model context manager
15:58 <vmassol> ModelContext I mean
15:58 <gdelhumeau> so instead of $services.wiki.mainWikiId, what should we use ?
15:59 <vmassol> also point 3) is that context.getMainXWiki() is not even deprecated nor is context.getWikiId()
16:00 <gdelhumeau> but is *xcontext deprecated?
16:00 <vmassol> getWikiId has even been introduced in 6.1
16:00 <vmassol> 6.1M1
16:00 <vmassol> xcontext is not deprecated
16:01 <vmassol> so we need to decide if wiki script module is core or not
16:01 <vmassol> (ie it has to be in a most minimal wiki we can make)
16:03 <vmassol> if we say that the wiki concept is core then I guess we should also have it in the core so that velocity pages can using wiki apis
16:03 <gdelhumeau> indeed
16:04 <vmassol> velo scripting that is
16:04 <vmassol> api.XWiki is core ATM so I guess it makes sense that wiki SS should be too
16:17 <vmassol> ok mail ready, sending
16:18 <Enygma`> because we come from a single wiki setup *and* because oldcore is... old and should not be extended, the wiki API is bundled in a separate module and accessible to scripting through a script service, but that does not mean that is does not make it core
16:18 <vmassol> it means we didn't have to make it core
16:18 <vmassol> because it was nicely done separately
16:18 <vmassol> w're just loosing this advnatage
16:18 <Enygma`> it was done separately out of necessity
16:18 <vmassol> it's a bet that we won't need it, which is ok, just makes xwiki more heavywieght as it could be
16:19 <Enygma`> but conceptually it should have been there from the start, IMO
16:19 <vmassol> exactly
16:19 <vmassol> and we're loosing that advatnage
16:19 <vmassol> and tomorrow you're going to say that federations of wikis are core too? :)
16:19 <vmassol> (playing the devil's advocate)
16:20 <Enygma`> do you agree that it would suck to have to check in each velocity script that the "spaces" feature is activated before you use it?
16:20 <vmassol> what was done was the hard part ie add multiwiki without changing the core
16:20 <vmassol> we're now going the other way around of removing all the hard work done to separate them
16:20 <vmassol> I'm not saying I don't agree btw,
16:20 <vmassol> especially since it's me proposing it in the mail :)
16:21 <vmassol> (I listened to you guys)
16:21 <vmassol> Enygma`: my view is that 100% of eveyrthing should be optional
16:21 <vmassol> so no I don't agree ith you on this
16:21 <vmassol> what I agree with is that making everythinh optional has a cost
16:22 <vmassol> when you're in a distribution you don't check for active elements
16:22 <vmassol> you know they're ther'e
16:22 <vmassol> *there
16:22 <Enygma`> and I also understand your point, I`m just concerned that there are good practices applied in the not-so-good context :)
16:22 <vmassol> when I write a velo script
16:22 <vmassol> I don't check if the ruby macro is present before using it
16:23 <vmassol> I use it because I'm in a given distribution where I have it installed
16:23 <vmassol> if I were to write xwiki from scratch, I would make sure that the core is just a CLI extension manager
16:23 <vmassol> and that everything else is optional
16:24 <gdelhumeau> an OS actually :)
16:24 <vmassol> features would be contributed by extensions a
16:24 <vmassol> s/a//
16:24 <vmassol> yes, xwiki is an OS
16:24 <vmassol> :)
16:24 <Enygma`> then you will have core XWiki modules depending on the wiki module (so that they don`t depend on it at runtime by checking if it is there) and the result when bundling those core XWiki modules is that you will indirectly make the wiki module core too :)
16:24 <vmassol> if the wiki module is not there I wouldn't present the "create wiki" feature
16:25 <vmassol> and the software will just work with a single schema
16:25 <Enygma`> but for that you have to check at runtime
16:25 <Enygma`> and you said you don`t check at runtime
16:25 <vmassol> which incidentally is interesting if you have a backend that doesn't multiple schemas ;)
16:25 <vmassol> there's a difference between the generic code and the code done by users
16:25 <vmassol> users of the wiki
16:26 <vmassol> and generic code should not check
16:26 <vmassol> it should have extension points
16:26 <vmassol> and it's the extensions that should plug in
16:26 <vmassol> said differently if the annotation module wants to add some specific support for multiwiki, it should be done as a submodule inside the wiki module
16:26 <vmassol> and not as a wiki module inside the annotation module
16:27 <vmassol> :)
16:27 <vmassol> (which requires a check)
16:27 <Enygma`> so you really consider annotations core and multiwiki not core?
16:27 <vmassol> no
16:27 <vmassol> annotations are optional too
16:27 <vmassol> why do you say that?
16:28 <vmassol> I'm talking about a hypothetical annotatio feature for multiwiki here
16:28 <vrachieru> has joined #xwiki
16:29 <vmassol> you don't include the anno module you get neither annos nor that specific multiwiki feature for annos
16:29 <vmassol> s/you don't/if you don't
16:30 <vmassol> in any case these are thought experiements since we're not going to rewrite xwiki from scratch but still this is the philosohpy I'd like to have as much as possible inside xwiki
16:30 <vmassol> ie make the core smaller
16:30 <vmassol> and apply the IOC principle for features
16:31 <Enygma`> so if I want to make an app that makes blue wikis, I can`t use the wiki services in that app to create wiki and then make them blue... I need to have the wikis module support a feature for which my app can write an extension point?
16:31 <vmassol> ie extensions
16:32 <vmassol> yes extensions need to provide extension points for others to use
16:33 <vmassol> ofc you won't think about everytihn so what happens is that users create hacks because you don't offer the proper APIs but then you see teh need and add these new apis as you evolve your apis
16:33 <vmassol> nothing special here, it's basic extension systems
16:33 <vmassol> actually it's just api
16:34 <Enygma`> so we kill script services and replace them with extension points?
16:34 <vmassol> err?
16:34 <Enygma`> why not use the script service if it is available?
16:34 <vmassol> there are several kinds of "apis"
16:34 <vmassol> - java apis
16:34 <vmassol> - UI "apis", ie extension points
16:34 <Enygma`> extension points have their purpose, but it's not to replace script services
16:34 <vmassol> - config naming "apis"
16:34 <vmassol> etc
16:34 <vmassol> why do you want to have a single one?
16:35 <vmassol> SS are java apis
16:35 <Enygma`> "yes extensions need to provide extension points for others to use"
16:35 <vmassol> for ui
16:35 <vmassol> you were talking abtout ui
16:35 <Enygma`> no
16:35 <vmassol> (blue wikis)
16:35 <vmassol> blue is ui for me sorry
16:35 <Enygma`> lol, no, I meant an app that creates wikis for some purpose
16:36 <vmassol> as I said it's just api anyway
16:36 <vmassol> you can't imagine all the possible use of your api
16:36 <vmassol> but then you evolve it
16:36 <vmassol> it doesn't mean you should not provide any api at all
16:37 <vmassol> ok could you plreoy to my mail?
16:37 <vmassol> *reply
16:37 <vmassol> I 'd like to progress and have a few +1 first
16:37 <vmassol> since I'm stuck ATM
16:37 <Enygma`> me too :)
16:38 <vmassol> I mean I could add an epxlicit dep between anno and wiki module
16:38 <vmassol> just because the anno module is using UI and thus is using thr drawer
16:38 <vmassol> but that doesn't seem right
16:38 <vmassol> I'd rather add that dep in the packager mojo
16:38 <vmassol> but we need to agree that wiki modules are core
16:38 <vmassol> hence the mail
16:39 <vmassol> should be easy since you agreed here on irc :)
16:40 <vmassol> btw xwiki-platform-wiki-default is already a dep of the packager plugin, just missing the SS
16:47 <tmortagne> has joined #xwiki
17:02 <Denis1> has quit
17:03 <Denis1> has joined #xwiki
17:21 <vmassol> so where do we stand on the release?
17:21 <vmassol> mflorea: ?
17:21 <vmassol> (you're the RM!)
17:21 <vmassol> :)
17:21 <vmassol> should be done in 30mn on my side
17:22 <vmassol> (for the anno regression)
17:23 <mflorea> vmassol: I'm fixing tests, but CI doesn't look good atm
17:24 <vmassol> I'm more talking about ensuring that everyeone helps and the coordination effort to ensure we can release asap
17:24 <vmassol> right now it seems today is going to be missed
17:25 <vmassol> but what about tomorrow?
17:25 <vmassol> do you think we could succeed tomorrow?
17:25 <vmassol> we need to move the open issues too I think
17:28 <mflorea> vmassol: I can't tell how long it will take to fix the failing tests. I've fixed a few and I'm investigating the others. I know Enygma` is handling the failure related to the create page changes and you are looking at the annotation failures. tmortagne is not available afaiu. gdelhumeau what are you working on?
17:28 <Chuguniy> has joined #xwiki
17:28 <vmassol> do we know how many are remaining overall and do we have a plan for devs to look at them?
17:29 <vmassol> thomas should be here tomorrow btw
17:29 <vmassol> he was just off today
17:29 <vmassol> guys could you please vote on the wiki module thing?
17:29 <vmassol> I'm almost ready to commit
17:30 <vmassol> but I'd like some votes before I do so
17:32 <mflorea> enterprise-test-selenium and enteprise-test-wysiwyg should be fine now. enteprise-test-escaping is related to annotation so I guess it will be fine after you commit. enteprise-test-ui has one failing test related to annotations. Maybe you can take a look at that too? The rest are related to copy (fixed by me) and create (going to be fixed by edy).
17:32 <KermitTheFragger> has quit
17:32 <mflorea> I'm currently looking at the storage tests
17:33 <mflorea> edy is fixing the platform tests related to create page UI
17:33 <vmassol> yes re -ui I'm on it
17:33 <vmassol> I'm moving that test to platform and fixing the issue
17:34 <mflorea> great, thanks
17:37 <mflorea> re storage tests, there seems to be a real issue. Document rollback doesn't work for instance. I'm debugging.
17:38 <vrachieru> has quit
17:40 <vmassol> ok
17:43 <vmassol> hmm
17:43 <vmassol> seems that we need a dep on the refactoring module now for deleting a page from a func tests
17:43 <vmassol> I guess most func test fail to delete right now
17:43 <vmassol> you just don't see it
17:44 <vmassol> I didn"t see it until I stepped with a debugger
17:44 <vmassol> and you get a bit stack trace ending with: Caused by: org.xwiki.component.manager.ComponentLookupException: Can't find descriptor for the component [role = [interface org.xwiki.job.Job] hint = [delete]]
17:44 <vmassol> and that's the refactoring module missing
17:45 <vmassol> so it seems this module is also core now….
17:45 <gdelhumeau> the refactoring module is used by oldcore already
17:45 <vmassol> (which is not logical, so I'm going to create a jira issue for not making it core)
17:45 <vmassol> and for now I'm going to add it to the packager mojo
17:45 <gdelhumeau> every action like rename/delete is done by the refactoring module
17:45 <vmassol> I know gdelhumeau
17:45 <vmassol> it still isn't correct IMO
17:46 <vmassol> we discussed it here
17:46 <vmassol> I don't know if you were here
17:46 <vmassol> but I don't remember our conclusions, mflorea do you remember?
17:46 <gdelhumeau> looking at the irc archive
17:47 <gdelhumeau> I see you have talked about adding a progress bar to the rename action
17:47 <gdelhumeau> I was about asking the question
17:48 <mflorea> vmassol: I don't remember the conclusion, but I don't think we agree on something
17:48 <tmortagne> has quit
17:49 <vmassol> ok sending a mail then instead of jirz
17:51 <mflorea> has quit
17:55 <vmassol> sent
18:05 <vmassol> FYI added refacotring to packagemojo locally
18:05 <vmassol> will commit once the anno tests are passing
18:06 <vmassol> actually I'll commit now
18:08 <vmassol> hmmmm
18:08 <vmassol> mf
18:08 <vmassol> ah marius left
18:09 <vmassol> I think we have a problem with TestUtil.deletePage() now
18:09 <vmassol> since delete uses an async job
18:09 <vmassol> deletePage is now async and that's bad
18:09 <vmassol> while we could use a wait
18:09 <vmassol> I think it would be better to have a query string param to make it synchronous instead
18:11 <vmassol> reopened http://jira.xwiki.org/browse/XWIKI-12388# with a comment
18:33 <woshilapin> has quit
18:33 <vmassol> one more issue....
18:33 <vmassol> geez so many errors
18:33 <vmassol> I'm not progressing
18:34 <vmassol> I know hte problem
18:36 <abusenius_> has joined #xwiki
18:40 <vmassol> hmm I'm a bit stuck actually
18:40 <vmassol> :)
18:40 <vmassol> still trying to move the annotation tests to platform but the issue now is that there's a test using xwiki syntax &.0
18:40 <vmassol> 1.0
18:40 <vmassol> and $xwiki.renderText() has been moved to legacy
18:43 <vmassol> so I need a way to exclude oldcore
18:43 <vmassol> ok I know
18:48 <evalica> has quit
18:50 <Enygma`> has quit
18:50 <Denis1> has quit
19:30 <woshilapin> has joined #xwiki
19:43 <gdelhumeau> has quit
20:06 <ClemensR> has quit
20:54 <MasterPiece> has joined #xwiki
21:00 <MasterPiece> has quit
21:04 <Ramona1> has joined #xwiki
21:07 <Slashman> has quit
21:08 <Ramona1> has quit
21:10 <Chuguniy> has quit
22:21 <woshilapin> has quit
22:22 <woshilapin> has joined #xwiki
22:28 <woshilapin> has quit
22:30 <woshilapin> has joined #xwiki
22:53 <Chuguniy> has joined #xwiki
23:21 <rrodriguez> has joined #xwiki
23:24 <Denis1> has joined #xwiki
23:24 <rrodriguez> has quit
23:25 <rrodriguez> has joined #xwiki
23:45 <vmassol> has quit
23:49 <Chuguniy> has quit
23:56 <woshilapin> has quit
01:29 <abusenius_> has quit
01:35 <Denis1> has quit
03:49 <Denis1> has joined #xwiki
03:54 <Denis1> has quit
04:29 <cpe> has quit
04:29 <cpe_> has joined #xwiki
04:29 <cpe_> is now known as <cpe>
06:52 <Ramona1> has joined #xwiki
06:53 <mflorea> has joined #xwiki
07:05 <msmeria> has joined #xwiki
08:01 <sdumitriu> has quit
08:47 <sdumitriu> has joined #xwiki
08:54 <KermitTheFragger> has joined #xwiki
09:06 <vmassol> has joined #xwiki
09:07 <vmassol> has quit
09:07 <vmassol1> has joined #xwiki
09:21 <mflorea> has quit
09:22 <vmassol1> good morning
09:22 <vmassol1> today is release day! let's stabilize our build
09:22 <vmassol1> is now known as <vmassol>
09:41 <mflorea> has joined #xwiki
09:46 <vmassol> mflorea: you're the RM (in case you didn't know :))
09:46 <mflorea> I know :)
09:47 <mflorea> there is one test failing in test-escaping related to AnnotationCode.CreateForm
09:47 <mflorea> someone needs to look at it
09:47 <vmassol> someone caused a clirr error in platform too:
09:47 <vmassol> [ERROR] 6004: com.xpn.xwiki.XWikiConstant: Changed type of field EDIT_MODE_CLASS from org.xwiki.model.reference.EntityReference to org.xwiki.model.reference.LocalDocumentReference
09:47 <mflorea> yes
09:47 <vmassol> in xwiki-platform-legacy-oldcore
09:48 <vmassol> checking history
09:48 <mflorea> Edy should take care of the only selenium 1 test failing in administration because we removed the space switcher
09:49 <vmassol> ok reverting thomas change
09:49 <mflorea> I'm looking at the tests failing due to the changes made on the Create page UI
09:49 <vmassol> (it was thomas for clirr)
09:49 <gdelhumeau> has joined #xwiki
09:51 <evalica> has joined #xwiki
09:51 <vmassol> Edy caused http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-mail-test-tests/1767/testReport/junit/org.xwiki.mail.test.ui/MailTest/testMail/ too
09:52 <vmassol> yes mflorea this one is caused by the removal of the space admin switcher too
09:52 <Enygma`> has joined #xwiki
09:52 <mflorea> ok
09:52 <vmassol> looking for teh jira issue
09:52 <Denis1> has joined #xwiki
09:52 <vmassol> XWIKI-12172
09:53 <vmassol> you have a jenkins link to the other failing tests for the switcher mflorea?
09:53 <mflorea> yes, just a sec
09:53 <vmassol> (so that I can add them in the issue too)
09:53 <mflorea> http://ci.xwiki.org/job/xwiki-enterprise-test-selenium/lastBuild/org.xwiki.enterprise$xwiki-enterprise-test-selenium/testReport/org.xwiki.test.selenium/AdministrationTest/testSettingXWikiPreferences/
09:53 <vmassol> thx
09:55 <vmassol> this is also fro edy I think: http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-flamingo-skin-test-tests/1767/testReport/junit/org.xwiki.flamingo.test.ui/CreatePageAndSpaceTest/createSpaceAndPage/
09:55 <vmassol> (Enygma`)
09:55 <vmassol> and all the failing CreatePageTest
09:57 <vmassol> Enygma`: out of 10 failing tests in platform, 9 are for you to fix :)
09:57 <vmassol> this one is something else I think: http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-wysiwyg-test-tests/1767/testReport/junit/org.xwiki.wysiwyg.test.ui/EditWYSIWYGTest/testUndoRepeatedPaste/
09:58 <Ramona1> has quit
10:02 <Ramona1> has joined #xwiki
10:06 <Slashman> has joined #xwiki
10:21 <ClemensR> has joined #xwiki
10:27 <mflorea> vmassol: yes, EditWYSIWYGTest/testUndoRepeatedPaste/ was failing for M2 too, I investigated it and my conclusion was that it fails on some agents and passes on the others, but I couldn't determine the difference between the agents.
10:28 <vmassol> k….. yuck....
10:29 <mflorea> Enygma`: re the Create Page, I'm currently writing a page object for the document picker (which is used on Copy page also)
10:29 <Pbas> has joined #xwiki
10:30 <Enygma`> getting on it
10:40 <Enygma`> has quit
10:41 <tmortagne> has joined #xwiki
10:41 <Enygma`> has joined #xwiki
10:42 <vmassol> checking the escaping test http://ci.xwiki.org/job/xwiki-enterprise-test-escaping/lastCompletedBuild/org.xwiki.enterprise$xwiki-enterprise-test-escaping/testReport/org.xwiki.test.escaping/ApplicationTest/AnnotationCode_CreateForm_xml__page__selectionContext__language__space__wiki__comment__selectionOffset__selection__reference___testParametersInFlamingo/
11:00 <woshilapin> has joined #xwiki
11:02 <tmortagne> has quit
11:24 <tmortagne> has joined #xwiki
11:32 <tmortagne> has quit
11:38 <vmassol> note: I think thomas introduced some regressions in the annotation module
11:39 <vmassol> going to reopen the issue
11:55 <Enygma`> gdelhumeau, vmassol: we still have no UI to go to the Administration of a space (Nested Document). To fix the failing administration tests, I`ll just build the URL by hand in the page object methods.
11:55 <vmassol> hmm when is this planned?
11:55 <vmassol> (the UI)
11:55 <gdelhumeau> evalica: what do you think?
11:55 <gdelhumeau> the space concept should be hidden in the UI normally
11:55 <vmassol> Enygma`: the alternative is to implement a tree switcher
11:56 <vmassol> (which could be useful)
11:56 <gdelhumeau> and we should create a page admin instead
11:56 <gdelhumeau> when we'll have the page administration the functionnal tests abour space admin wil not be usefull anymore
11:56 <vmassol> I don't see what harm it would do to be able to switch admin page from within the admin
11:57 <vmassol> gdelhumeau: most failing tests are not about that
11:57 <vmassol> hmm maybe they ayre
11:57 <vmassol> *are
11:58 <evalica> since space administration is now 'page administration', the administration should be available in the 'More actions' part of the menu. But switching from global administration could be an alternative.
11:58 <vmassol> for MailTest the tests is about verifying that the admin options are not available in space admins
11:58 <vmassol> s/tests/test
11:59 <vmassol> I guess this test should go directly to the space admin instead of navigating
11:59 <vmassol> since it's not about testing the nav
11:59 <gdelhumeau> that's what Edy did
11:59 <vmassol> he already fixed it?
11:59 <gdelhumeau> for the tests he fixed
12:00 <gdelhumeau> oh sorry
12:00 <gdelhumeau> not did
12:00 <gdelhumeau> but will
12:00 <vmassol> it depends
12:00 <vmassol> that's not what he said
12:00 <vmassol> he said he'd do that everywhere
12:00 <vmassol> this makes sense only for tests that don't need to test the nav
12:00 <vmassol> but I guess we have some tests whoe prupose is to test this nav!
12:01 <vmassol> *whose
12:01 <gdelhumeau> yes
12:05 <Enygma`> vmassol: so you are proposing to change the tests instead of the page object?
12:05 <vmassol> Enygma`: do you want me to fix the MailTest?
12:06 <vmassol> Enygma`: depends
12:06 <vmassol> some tests are wrong
12:06 <vmassol> the MailTests is wrong for ex
12:06 <vmassol> (well not wrong wrong but it does unnecessary testing)
12:06 <vmassol> since it tests space admin swtiching which is not one of the goal of this test
12:07 <vmassol> so for tests like this we could fix them instead
12:07 <vmassol> however there remains the real tests which are testing the admin switching
12:07 <vmassol> and for these we need an alternative
12:07 <vmassol> which is why I was asking when wil we get it?
12:08 <vmassol> so right now we cannot administer a space?
12:09 <vmassol> (without direct url)
12:09 <Enygma`> right
12:09 <vmassol> that seems a blocker
12:09 <vmassol> so at the very minimum RC1
12:09 <vmassol> or possibly delay this release
12:09 <vmassol> by one day to implement it
12:09 <Enygma`> mentioned it on http://jira.xwiki.org/browse/XWIKI-12189?focusedCommentId=87405&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-87405
12:09 <vmassol> because we need a solution for this for 7.2
12:09 <gdelhumeau> vmassol: I can add a temproray link
12:09 <gdelhumeau> to not block the release
12:10 <gdelhumeau> but at the end we should drop the space admin entirely
12:10 <Enygma`> we also need to think it better, since, AFAIK, only admins can access the space administration
12:10 <Enygma`> and now, with ND, that`s just wrong
12:11 <vmassol> Enygma`: we discussed this laready
12:12 <evalica> so the simplest solution now is to add an 'Administer' in the 'More actions' menu that will take to Space Administration
12:13 <Enygma`> (that is displayed only for non-terminal docs)
12:14 <Enygma`> actually, if the parent does not exist, there is an issue
12:14 <vmassol> yes ok for that but I think we need to fix it properly with the page admin in RC1
12:14 <Enygma`> (parent of a non-terminal doc)
12:14 <gdelhumeau> note that in the space admin, there is actually no mention of the term "space"
12:15 <evalica> that's good
12:15 <gdelhumeau> we could actually remove the "edit rights" button of a non-terminal page to have only this administration instead
12:15 <vmassol> gdelhumeau: I don't think sio
12:15 <gdelhumeau> and when it's a terminal doc, then, only the "edit right button", and "administer parent" maybe
12:15 <vmassol> so
12:15 <vmassol> because edit right is not the same as space admin ATM
12:17 <vmassol> one is about edit rigth of the current doc and space admin is about edit rights of all docs of the space
12:17 <vmassol> you cannot set page level rights with space admin
12:19 <gdelhumeau> some ideas there already: http://jira.xwiki.org/browse/XWIKI-12219#
12:20 <vmassol> yes I know
12:21 <vmassol> but the idea has never been to remove page edit rights
12:21 <vmassol> it was to propose both in the same UI
12:21 <vmassol> (in page admin)
12:22 <Enygma`> if we go for an unified page admin that handles both the current page and the space, then page edit rights needs to go
12:22 <vmassol> no
12:22 <vmassol> why?
12:22 <vmassol> see the issue screenshots
12:23 <vmassol> we need page edit rights
12:23 <vmassol> why do you say we don't?
12:23 <vmassol> how do you set page level rights?
12:23 <Enygma`> from this new and unified "page administration": http://jira.xwiki.org/secure/attachment/31242/proposal1.png
12:24 <Enygma`> at least according to this proposal
12:24 <vmassol> Enygma`: ok we're talking cross purpose
12:24 <vmassol> you said "page edit rights" needs to go
12:24 <vmassol> but you probably meant "the page edit rights menu entry" insetad, right?
12:25 <Enygma`> and the /edit/editor=rights template, yes
12:25 <vmassol> so yes, the idea is to have a single page admin
12:25 <vmassol> with all options
12:25 <vmassol> and you see those options depending on your rights
12:25 <vmassol> this is what we discussed in the past
12:26 <vmassol> (if you have admin rights you can change space options, ie affect children)
12:26 <vmassol> (and if you have only edit right you can only affect the current doc)
12:26 <Enygma`> the only concern I have about this is when we want to introduce other page-only related administration/preferences, besides rights... the unified "page administration" UI will get crowded with all sorts of settings first for the page only and then for the page + children... so groups of 2 settings for the same option
12:26 <Enygma`> which might get ugly
12:26 <vmassol> yes we need to present it nicely
12:27 <vmassol> but its logical to have 2 levels:
12:27 <vmassol> - this page only
12:27 <vmassol> - all children pages
12:27 <vmassol> but indeed there are various ways to prsent this
12:28 <Enygma`> yes... I am worried that we will not be able to do this for every option we want to administer...
12:29 <Enygma`> I just don`t see it happening
12:29 <evalica> http://design.xwiki.org/xwiki/bin/download/Improvements/PageAdministration/ContentHistory.png
12:29 <vmassol> well right now we have almost nothing at page level
12:29 <Enygma`> see the link Caty just pasted as a proposal of what we could administer at a page level
12:29 <evalica> but this was a complex idea
12:29 <vmassol> yes but I don't agree with most of them :)
12:29 <vmassol> like history is not an admin thing
12:29 <Enygma`> now imagine that each of those options is duplicated for both the page-only level and the pagel+children level
12:30 <vmassol> Enygma`: that's easy
12:30 <vmassol> that 'sa a checkbox : "Apply to children documents"
12:30 <evalica> in this proposal: history and attachments offered BULK action from administration.
12:30 <vmassol> "Apply to children documents too"
12:31 <vmassol> evalica: yes I don't understand why it would be in admin
12:31 <Enygma`> vmassol: Caty mentioned that to me too, but no... you will end up overriding the other .... you want to see at a given time what are the settings for only for the page and what are the settings for page+children
12:31 <vmassol> but forget the history example
12:31 <vmassol> we may still have lots of options one day if we want to provide ability to set the skin at page level, etc
12:32 <Enygma`> vmassol: and remember that this is now "page admin" and deleting/approving comments... reverting history, deleting attachments are "page administration" actions that are not suited for view mode
12:32 <Enygma`> yes, skin, page elements, etc
12:32 <Enygma`> very useful stuff IMO
12:32 <vmassol> not sure
12:32 <Enygma`> that we lack right now and have to hack with layoutVariables.vm
12:32 <vmassol> they haven't been useful for the past 10 years
12:32 <vmassol> :)
12:32 <vmassol> it's pretty edge cases
12:32 <vmassol> and even more now with nested spaces
12:33 <Enygma`> wdym? we use them alot with #set ($showComments = false) or something like that
12:33 <Enygma`> which is a hack
12:34 <vmassol> anyway I don't see a difference between:
12:34 <vmassol> - 2 entry menus, one for page level admin and another one for children admin level
12:34 <Enygma`> I just hope we`re not painting ourselves in a corner with this unified page admin
12:34 <vmassol> - a singele page admin with 2 sections: one for page level and one for children level
12:34 <vmassol> it's the same
12:35 <vmassol> you can have 2 tabs
12:35 <vmassol> or two left menu links or…
12:35 <evalica> or - a single page admin + switch between page or children mode
12:35 <vmassol> but in the end it's the same as 2 links in the menu
12:35 <vmassol> not more work, not less
12:35 <vmassol> yes or that
12:35 <vmassol> in the end we need to differentiate
12:36 <Enygma`> I like Caty`s idea of using a switch (select above the left menu)
12:36 <vmassol> between page level and children level
12:36 <Enygma`> and it`s very easy to implement
12:36 <vmassol> yes it'es good
12:36 <vmassol> *it's
12:36 <Enygma`> we`re just switching the page we are editing, but the user stays in the same UI
12:38 <Enygma`> commented on the issue about this idea
13:18 <Denis1> has quit
14:10 <Enygma`> vmassol: why were you saying that the mail tests don`t need to perform that step (checking if the mail category appears for space administration)?
14:11 <vmassol> I didn't say that :)
14:11 <vmassol> I said that this test doesn't need to navigate to the space admin
14:11 <vmassol> it could (and should) go to that space admin directly
14:11 <vmassol> said differently
14:11 <vmassol> going to the space admin should be part of the test fixture
14:13 <Enygma`> you mean that instead of starting with wiki administration, it could start with space administration?
14:20 <vmassol> I'm not saying that either
14:20 <vmassol> ok let me be specific
14:20 <vmassol> I'm talking about replacing this line:
14:20 <vmassol> AdministrationPage spaceAdministrationPage = administrationPage.selectSpaceToAdminister("XWiki");
14:21 <vmassol> with some getUtil().gotoPage()
14:21 <vmassol> (or add a static method in AdministrationPage to go directly to an admin section)
14:22 <vmassol> (not admin section but space admin page)
14:23 <vmassol> there's already AdministrationPage.gotoPage(), we could add AdministrationPage.gotoSpaceAdminPage(String spaceReference)
14:23 <Enygma`> yes, that`s what I was shooting for as well
14:23 <vmassol> ok
14:24 <vmassol> cool
14:24 <vmassol> cool thing is that we'll remove the hack at getDriver().waitUntilElementIsVisible(By.id("HAdministration:XWiki"));
14:24 <vmassol> ;)
14:25 <vmassol> and spaceAdministrationPage.waitUntilPageIsLoaded();
14:31 <Enygma`> yes, but this might be temporary, depending on what we will implement in its place in the coming future
14:31 <vmassol> why?
14:31 <vmassol> again it's not the goal of this test to validate that we can switch admin from one space to another
14:31 <vmassol> this test should not navigate
14:32 <vmassol> so direct url is going to be still valid in the future
14:32 <Enygma`> ok, I see what you meant
14:33 <vmassol> said differently, there's no point in having 5 tests that validate space admin swtiching, only one func tests validating this is enough and this test should be in the admin func tests
14:34 <Enygma`> the funny thing is that in reality, we end up having 5 tests indirectly testing a feature by using it in integration tests but without having a single test that directly tests the same feature :)
14:34 <vmassol> yes sometimes we're missing the test in the right place
14:34 <Denis1> has joined #xwiki
14:34 <vmassol> we need to be careful that we do have one validating this in the admin func tests :)
14:35 <Enygma`> :)
14:35 <vmassol> moving annotation test from enterprise to platform now to add some new tests
14:35 <vmassol> (to fix the rgeressions introduced by thomas)
14:35 <Enygma`> now, about the location of this method... looking at TestUtls, I see that we have there even create* methods, instead of having them say in the CreatePage page object
14:35 <Enygma`> so probably TestUtil is a better place for the method
14:36 <vmassol> AdministrationPage seems nice to me
14:36 <vmassol> *nicer
14:36 <Enygma`> and let the pageObjects contain more actual UI testing code
14:36 <vmassol> we started the gotoPage() pattern and for me it's the same pattern
14:36 <vmassol> ws're just contiuing it
14:37 <vmassol> the gotoPag() pattern being that each PageObject should have a way to go to it
14:37 <Enygma`> maybe in this case you are right, since it retuns an AdministrationPage
14:37 <vmassol> (directtly)
14:37 <vmassol> yes
14:37 <Enygma`> yep
14:41 <Enygma`> I guess we need to start using more references in our tests
14:41 <Enygma`> instead of strings
14:41 <vmassol> yes, I started doing this recently and added th required infra for it
14:41 <vmassol> (the resolvers)
14:41 <Enygma`> I was just looking for some resolvers
14:42 <Enygma`> just spotted it in TestUtils
14:42 <vmassol> in TestUtils I added some resolve method
14:43 <tmortagne> has joined #xwiki
14:48 <tmortagne> has quit
14:52 <Enygma`> wondering if the old AdministrationPage.selectSpaceToAdminister(String spaceName) method should redirect to the new static AdministrationPage.gotoSpaceAdministrationPage(String spaceReferenceString)
14:53 <vmassol> you mean very temporarily till RC1?
14:53 <Ramona1> has quit
14:53 <Enygma`> something like that, otherwise it`s useless if it`s not working
14:54 <vmassol> sure ok temporarily, the other option is to add the menu link to space admin
14:54 <Enygma`> I would still modify the currently failing code to use the static method instead of this, so that we avoid still using the UI when we should not
14:54 <vmassol> I'm ok for that
14:54 <vmassol> make sure to add todo and possibily a jira issue to remember putting it back :)
14:55 <vmassol> or add it as comment int he issue for the new page admin ui
14:55 <Enygma`> "putting it back" > you mean to actually implement it when the new UI is up
14:55 <vmassol> yes
14:55 <Enygma`> ok
15:03 <msmeria> has quit
15:08 <Denis1> has quit
15:09 <Denis1> has joined #xwiki
15:16 <vmassol> hmmm some problem in my func test
15:16 <vmassol> 15:15:09.836 [Thread-13] ERROR o.x.t.i.XWikiLogOutputStream - 2015-08-31 15:15:09,836 [http://localhost:8080/xwiki/bin/register/XWiki/Register] ERROR o.h.u.JDBCExceptionReporter - invalid schema name: ${MAINWIKIID}
15:16 <vmassol> debugging...
15:30 <tmortagne> has joined #xwiki
15:35 <tmortagne> has quit
15:37 <vmassol> haha found the culprit I think
15:37 <vmassol> in drawer.vm: #set ($hasHomeWikiAdmin = $xwiki.hasAccessLevel('admin', $xcontext.user, "${mainWikiId}:XWiki.XWikiPreferences"))
15:38 <vmassol> yep and mainwikiid is defined as #set ($mainWikiId = $services.wiki.mainWikiId)
15:38 <vmassol> which means it works only of the wiki module is available
15:38 <vmassol> so basically any func tests that doesn't have a dep on it fails
15:39 <vmassol> this is notnice
15:43 <gdelhumeau> the wiki module is not considered as a basic module of the platform?
15:44 <vmassol> it's never been
15:45 <vmassol> remember that we come from XEM
15:45 <vmassol> subwiki has never been a core notion
15:45 <Enygma`> we faked it into the model :)
15:45 <vmassol> not in the model
15:46 <vmassol> in a separate module
15:46 <gdelhumeau> yes but since 5.4 it's on XE
15:46 <vmassol> there's no reason to have it in the model
15:46 <gdelhumeau> and we can consider it as a basic package
15:46 <vmassol> I don't see why
15:46 <vmassol> I've complained sveeral times
15:46 <vmassol> about the 2 ways to get the main wiki and the current wiki but nodody paid attention it seems
15:47 <vmassol> which created the mess we have now
15:47 <gdelhumeau> to avoid using $xcontext.mainWikiId for example
15:47 <Enygma`> because multiwiki is now part of the model, don`t see why the API to handle should not be
15:47 <vmassol> it's the other way around
15:47 <vmassol> $services.wiki.mainWikiId is the mess
15:47 <vmassol> multiwiki is not part of the model and it never has been
15:47 <Enygma`> at least in the reference API (which is model) we have the notion of multiple wikis
15:47 <vmassol> whether we want it to be in thef turue is naother discussion
15:47 <Enygma`> a reference has a wiki which can be changed
15:48 <vmassol> imagine I want to use xwiki to create a software and I need only a single wiki
15:48 <vmassol> why would I have to have all the multiwiki modules in my software?
15:48 <Enygma`> imagine you want to use XWiki to create a software and you need only a single space
15:48 <vmassol> it's so easy to not have them
15:48 <Enygma`> why would you have to have all the spaces in you software?
15:48 <Enygma`> :)
15:48 <vmassol> it's hard to remove the space notion
15:49 <vmassol> but it's easy for the wiki part
15:49 <Enygma`> this is an implementation detail
15:49 <vmassol> since that's where we come from
15:49 <Enygma`> at the model level you have multiple spaces and multiple wikis
15:49 <Enygma`> IMO it`s a bad practice to keep seeing XWiki as a single wiki
15:49 <Enygma`> this lead to hundreds of bugs
15:49 <Enygma`> a good part of which I know of at least
15:50 <Enygma`> it`s one thing that we come from single wiki, but that was years ago
15:50 <Enygma`> IMO, we just have to stop thinking like that...
15:51 <Enygma`> having a look at the annotations issue
15:52 <vmassol> I'm on it
15:52 <vmassol> (re annotations)
15:52 <vmassol> been on it for a few hours already
15:52 <vmassol> I know exactly what are the problems with it
15:52 <Enygma`> ah, ok then
15:52 <Enygma`> good to know :)
15:53 <vmassol> I said it already on this chat earlier :)
15:53 <vmassol> (that I was handling it)
15:53 <Enygma`> that`s why I mentioned it because I remembered something but was not sure :)
15:53 <vmassol> ok
15:53 <vmassol> so you seem to be all thinking that we should bundle the wiki modules in the core. I know thomas thinks that too
15:54 <vmassol> on my side I want to make the core as small as possible and this in the opposite direction
15:54 <vmassol> but ok I can understand the point
15:54 <vmassol> now we haven't acted till now as if it were part of the core
15:54 <vmassol> so it's a change
15:55 <vmassol> and we need to send a proposal or a vote for this
15:55 <vmassol> there are 2 things that prove it wasn't core
15:55 <vmassol> 1) it's no in the package plugin deps
15:55 <vmassol> 2) in the code we have eveyrwhere things like this:
15:55 <vmassol> #if ("$!services.wiki" != '' && $services.wiki.currentWikiId != $services.wiki.mainWikiId)
15:56 <vmassol> ah maybe the discussion is about the wiki script service then ?
15:56 <vmassol> because that's my real issue
15:57 <gdelhumeau> what do you propose, introduce a core script service?
15:57 <gdelhumeau> to get the name of the main wiki?
15:57 <vmassol> we alreayd have one :)
15:57 <gdelhumeau> $xcontext ?
15:57 <vmassol> and we already have a model ss too
15:58 <vmassol> (ah no forget core script service, was thinking about core config)
15:58 <vmassol> but we have a model ss
15:58 <vmassol> and a model context manager
15:58 <vmassol> ModelContext I mean
15:58 <gdelhumeau> so instead of $services.wiki.mainWikiId, what should we use ?
15:59 <vmassol> also point 3) is that context.getMainXWiki() is not even deprecated nor is context.getWikiId()
16:00 <gdelhumeau> but is *xcontext deprecated?
16:00 <vmassol> getWikiId has even been introduced in 6.1
16:00 <vmassol> 6.1M1
16:00 <vmassol> xcontext is not deprecated
16:01 <vmassol> so we need to decide if wiki script module is core or not
16:01 <vmassol> (ie it has to be in a most minimal wiki we can make)
16:03 <vmassol> if we say that the wiki concept is core then I guess we should also have it in the core so that velocity pages can using wiki apis
16:03 <gdelhumeau> indeed
16:04 <vmassol> velo scripting that is
16:04 <vmassol> api.XWiki is core ATM so I guess it makes sense that wiki SS should be too
16:17 <vmassol> ok mail ready, sending
16:18 <Enygma`> because we come from a single wiki setup *and* because oldcore is... old and should not be extended, the wiki API is bundled in a separate module and accessible to scripting through a script service, but that does not mean that is does not make it core
16:18 <vmassol> it means we didn't have to make it core
16:18 <vmassol> because it was nicely done separately
16:18 <vmassol> w're just loosing this advnatage
16:18 <Enygma`> it was done separately out of necessity
16:18 <vmassol> it's a bet that we won't need it, which is ok, just makes xwiki more heavywieght as it could be
16:19 <Enygma`> but conceptually it should have been there from the start, IMO
16:19 <vmassol> exactly
16:19 <vmassol> and we're loosing that advatnage
16:19 <vmassol> and tomorrow you're going to say that federations of wikis are core too? :)
16:19 <vmassol> (playing the devil's advocate)
16:20 <Enygma`> do you agree that it would suck to have to check in each velocity script that the "spaces" feature is activated before you use it?
16:20 <vmassol> what was done was the hard part ie add multiwiki without changing the core
16:20 <vmassol> we're now going the other way around of removing all the hard work done to separate them
16:20 <vmassol> I'm not saying I don't agree btw,
16:20 <vmassol> especially since it's me proposing it in the mail :)
16:21 <vmassol> (I listened to you guys)
16:21 <vmassol> Enygma`: my view is that 100% of eveyrthing should be optional
16:21 <vmassol> so no I don't agree ith you on this
16:21 <vmassol> what I agree with is that making everythinh optional has a cost
16:22 <vmassol> when you're in a distribution you don't check for active elements
16:22 <vmassol> you know they're ther'e
16:22 <vmassol> *there
16:22 <Enygma`> and I also understand your point, I`m just concerned that there are good practices applied in the not-so-good context :)
16:22 <vmassol> when I write a velo script
16:22 <vmassol> I don't check if the ruby macro is present before using it
16:23 <vmassol> I use it because I'm in a given distribution where I have it installed
16:23 <vmassol> if I were to write xwiki from scratch, I would make sure that the core is just a CLI extension manager
16:23 <vmassol> and that everything else is optional
16:24 <gdelhumeau> an OS actually :)
16:24 <vmassol> features would be contributed by extensions a
16:24 <vmassol> s/a//
16:24 <vmassol> yes, xwiki is an OS
16:24 <vmassol> :)
16:24 <Enygma`> then you will have core XWiki modules depending on the wiki module (so that they don`t depend on it at runtime by checking if it is there) and the result when bundling those core XWiki modules is that you will indirectly make the wiki module core too :)
16:24 <vmassol> if the wiki module is not there I wouldn't present the "create wiki" feature
16:25 <vmassol> and the software will just work with a single schema
16:25 <Enygma`> but for that you have to check at runtime
16:25 <Enygma`> and you said you don`t check at runtime
16:25 <vmassol> which incidentally is interesting if you have a backend that doesn't multiple schemas ;)
16:25 <vmassol> there's a difference between the generic code and the code done by users
16:25 <vmassol> users of the wiki
16:26 <vmassol> and generic code should not check
16:26 <vmassol> it should have extension points
16:26 <vmassol> and it's the extensions that should plug in
16:26 <vmassol> said differently if the annotation module wants to add some specific support for multiwiki, it should be done as a submodule inside the wiki module
16:26 <vmassol> and not as a wiki module inside the annotation module
16:27 <vmassol> :)
16:27 <vmassol> (which requires a check)
16:27 <Enygma`> so you really consider annotations core and multiwiki not core?
16:27 <vmassol> no
16:27 <vmassol> annotations are optional too
16:27 <vmassol> why do you say that?
16:28 <vmassol> I'm talking about a hypothetical annotatio feature for multiwiki here
16:28 <vrachieru> has joined #xwiki
16:29 <vmassol> you don't include the anno module you get neither annos nor that specific multiwiki feature for annos
16:29 <vmassol> s/you don't/if you don't
16:30 <vmassol> in any case these are thought experiements since we're not going to rewrite xwiki from scratch but still this is the philosohpy I'd like to have as much as possible inside xwiki
16:30 <vmassol> ie make the core smaller
16:30 <vmassol> and apply the IOC principle for features
16:31 <Enygma`> so if I want to make an app that makes blue wikis, I can`t use the wiki services in that app to create wiki and then make them blue... I need to have the wikis module support a feature for which my app can write an extension point?
16:31 <vmassol> ie extensions
16:32 <vmassol> yes extensions need to provide extension points for others to use
16:33 <vmassol> ofc you won't think about everytihn so what happens is that users create hacks because you don't offer the proper APIs but then you see teh need and add these new apis as you evolve your apis
16:33 <vmassol> nothing special here, it's basic extension systems
16:33 <vmassol> actually it's just api
16:34 <Enygma`> so we kill script services and replace them with extension points?
16:34 <vmassol> err?
16:34 <Enygma`> why not use the script service if it is available?
16:34 <vmassol> there are several kinds of "apis"
16:34 <vmassol> - java apis
16:34 <vmassol> - UI "apis", ie extension points
16:34 <Enygma`> extension points have their purpose, but it's not to replace script services
16:34 <vmassol> - config naming "apis"
16:34 <vmassol> etc
16:34 <vmassol> why do you want to have a single one?
16:35 <vmassol> SS are java apis
16:35 <Enygma`> "yes extensions need to provide extension points for others to use"
16:35 <vmassol> for ui
16:35 <vmassol> you were talking abtout ui
16:35 <Enygma`> no
16:35 <vmassol> (blue wikis)
16:35 <vmassol> blue is ui for me sorry
16:35 <Enygma`> lol, no, I meant an app that creates wikis for some purpose
16:36 <vmassol> as I said it's just api anyway
16:36 <vmassol> you can't imagine all the possible use of your api
16:36 <vmassol> but then you evolve it
16:36 <vmassol> it doesn't mean you should not provide any api at all
16:37 <vmassol> ok could you plreoy to my mail?
16:37 <vmassol> *reply
16:37 <vmassol> I 'd like to progress and have a few +1 first
16:37 <vmassol> since I'm stuck ATM
16:37 <Enygma`> me too :)
16:38 <vmassol> I mean I could add an epxlicit dep between anno and wiki module
16:38 <vmassol> just because the anno module is using UI and thus is using thr drawer
16:38 <vmassol> but that doesn't seem right
16:38 <vmassol> I'd rather add that dep in the packager mojo
16:38 <vmassol> but we need to agree that wiki modules are core
16:38 <vmassol> hence the mail
16:39 <vmassol> should be easy since you agreed here on irc :)
16:40 <vmassol> btw xwiki-platform-wiki-default is already a dep of the packager plugin, just missing the SS
16:47 <tmortagne> has joined #xwiki
17:02 <Denis1> has quit
17:03 <Denis1> has joined #xwiki
17:21 <vmassol> so where do we stand on the release?
17:21 <vmassol> mflorea: ?
17:21 <vmassol> (you're the RM!)
17:21 <vmassol> :)
17:21 <vmassol> should be done in 30mn on my side
17:22 <vmassol> (for the anno regression)
17:23 <mflorea> vmassol: I'm fixing tests, but CI doesn't look good atm
17:24 <vmassol> I'm more talking about ensuring that everyeone helps and the coordination effort to ensure we can release asap
17:24 <vmassol> right now it seems today is going to be missed
17:25 <vmassol> but what about tomorrow?
17:25 <vmassol> do you think we could succeed tomorrow?
17:25 <vmassol> we need to move the open issues too I think
17:28 <mflorea> vmassol: I can't tell how long it will take to fix the failing tests. I've fixed a few and I'm investigating the others. I know Enygma` is handling the failure related to the create page changes and you are looking at the annotation failures. tmortagne is not available afaiu. gdelhumeau what are you working on?
17:28 <Chuguniy> has joined #xwiki
17:28 <vmassol> do we know how many are remaining overall and do we have a plan for devs to look at them?
17:29 <vmassol> thomas should be here tomorrow btw
17:29 <vmassol> he was just off today
17:29 <vmassol> guys could you please vote on the wiki module thing?
17:29 <vmassol> I'm almost ready to commit
17:30 <vmassol> but I'd like some votes before I do so
17:32 <mflorea> enterprise-test-selenium and enteprise-test-wysiwyg should be fine now. enteprise-test-escaping is related to annotation so I guess it will be fine after you commit. enteprise-test-ui has one failing test related to annotations. Maybe you can take a look at that too? The rest are related to copy (fixed by me) and create (going to be fixed by edy).
17:32 <KermitTheFragger> has quit
17:32 <mflorea> I'm currently looking at the storage tests
17:33 <mflorea> edy is fixing the platform tests related to create page UI
17:33 <vmassol> yes re -ui I'm on it
17:33 <vmassol> I'm moving that test to platform and fixing the issue
17:34 <mflorea> great, thanks
17:37 <mflorea> re storage tests, there seems to be a real issue. Document rollback doesn't work for instance. I'm debugging.
17:38 <vrachieru> has quit
17:40 <vmassol> ok
17:43 <vmassol> hmm
17:43 <vmassol> seems that we need a dep on the refactoring module now for deleting a page from a func tests
17:43 <vmassol> I guess most func test fail to delete right now
17:43 <vmassol> you just don't see it
17:44 <vmassol> I didn"t see it until I stepped with a debugger
17:44 <vmassol> and you get a bit stack trace ending with: Caused by: org.xwiki.component.manager.ComponentLookupException: Can't find descriptor for the component [role = [interface org.xwiki.job.Job] hint = [delete]]
17:44 <vmassol> and that's the refactoring module missing
17:45 <vmassol> so it seems this module is also core now….
17:45 <gdelhumeau> the refactoring module is used by oldcore already
17:45 <vmassol> (which is not logical, so I'm going to create a jira issue for not making it core)
17:45 <vmassol> and for now I'm going to add it to the packager mojo
17:45 <gdelhumeau> every action like rename/delete is done by the refactoring module
17:45 <vmassol> I know gdelhumeau
17:45 <vmassol> it still isn't correct IMO
17:46 <vmassol> we discussed it here
17:46 <vmassol> I don't know if you were here
17:46 <vmassol> but I don't remember our conclusions, mflorea do you remember?
17:46 <gdelhumeau> looking at the irc archive
17:47 <gdelhumeau> I see you have talked about adding a progress bar to the rename action
17:47 <gdelhumeau> I was about asking the question
17:48 <mflorea> vmassol: I don't remember the conclusion, but I don't think we agree on something
17:48 <tmortagne> has quit
17:49 <vmassol> ok sending a mail then instead of jirz
17:51 <mflorea> has quit
17:55 <vmassol> sent
18:05 <vmassol> FYI added refacotring to packagemojo locally
18:05 <vmassol> will commit once the anno tests are passing
18:06 <vmassol> actually I'll commit now
18:08 <vmassol> hmmmm
18:08 <vmassol> mf
18:08 <vmassol> ah marius left
18:09 <vmassol> I think we have a problem with TestUtil.deletePage() now
18:09 <vmassol> since delete uses an async job
18:09 <vmassol> deletePage is now async and that's bad
18:09 <vmassol> while we could use a wait
18:09 <vmassol> I think it would be better to have a query string param to make it synchronous instead
18:11 <vmassol> reopened http://jira.xwiki.org/browse/XWIKI-12388# with a comment
18:33 <woshilapin> has quit
18:33 <vmassol> one more issue....
18:33 <vmassol> geez so many errors
18:33 <vmassol> I'm not progressing
18:34 <vmassol> I know hte problem
18:36 <abusenius_> has joined #xwiki
18:40 <vmassol> hmm I'm a bit stuck actually
18:40 <vmassol> :)
18:40 <vmassol> still trying to move the annotation tests to platform but the issue now is that there's a test using xwiki syntax &.0
18:40 <vmassol> 1.0
18:40 <vmassol> and $xwiki.renderText() has been moved to legacy
18:43 <vmassol> so I need a way to exclude oldcore
18:43 <vmassol> ok I know
18:48 <evalica> has quit
18:50 <Enygma`> has quit
18:50 <Denis1> has quit
19:30 <woshilapin> has joined #xwiki
19:43 <gdelhumeau> has quit
20:06 <ClemensR> has quit
20:54 <MasterPiece> has joined #xwiki
21:00 <MasterPiece> has quit
21:04 <Ramona1> has joined #xwiki
21:07 <Slashman> has quit
21:08 <Ramona1> has quit
21:10 <Chuguniy> has quit
22:21 <woshilapin> has quit
22:22 <woshilapin> has joined #xwiki
22:28 <woshilapin> has quit
22:30 <woshilapin> has joined #xwiki
22:53 <Chuguniy> has joined #xwiki
23:21 <rrodriguez> has joined #xwiki
23:24 <Denis1> has joined #xwiki
23:24 <rrodriguez> has quit
23:25 <rrodriguez> has joined #xwiki
23:45 <vmassol> has quit
23:49 <Chuguniy> has quit
23:56 <woshilapin> has quit
