IRC Archive for channel #xwiki on 16 November 2011
Last modified by Vincent Massol on 2012/10/18 19:22
01:02 <CIA-102> Sergiu Dumitriu master * r2a7601f / xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-api/src/main/java/org/xwiki/extension/AbstractExtension.java : XWIKI-7150: The name, licenses and summary of a local extension isn't copied over from the remote descriptor ...
06:01 <Denis1> has joined #xwiki
06:04 <Denis> has quit
06:56 <Enygma`> has joined #xwiki
07:14 <tekzilla> has quit
07:15 <tekzilla> has joined #xwiki
07:30 <DrLou> has quit
08:12 <vmassol> has joined #xwiki
08:17 <CIA-102> Eduard Moraru master * r5541789 / (17 files in 9 dirs): XWIKI-7152: Use script service everywhere for accessing the wiki manager and application manager plugins - http://git.io/qy-ZGw
08:18 <CIA-102> Eduard Moraru master * r695e140 / (8 files in 2 dirs): XEM-201 : Use of the wiki manager plugin as a script service - http://git.io/bb4-_w
08:21 <Enygma`> has quit
08:24 <vmassol> has quit
08:31 <sburjan`> has quit
08:36 <sburjan`> has joined #xwiki
08:59 <mflorea> has joined #xwiki
09:04 <CIA-102> Sergiu Dumitriu feature-applicationWithinMinutes * ra3b2226 / xwiki-platform-core/xwiki-platform-web/src/main/webapp/templates/macros.vm : Merge pull request #26 from sorzu/master ...
09:04 <CIA-102> Sergiu Dumitriu feature-applicationWithinMinutes * r2a7601f / xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-api/src/main/java/org/xwiki/extension/AbstractExtension.java : XWIKI-7150: The name, licenses and summary of a local extension isn't copied over from the remote descriptor ...
09:04 <CIA-102> Eduard Moraru feature-applicationWithinMinutes * r5541789 / (17 files in 9 dirs): XWIKI-7152: Use script service everywhere for accessing the wiki manager and application manager plugins - http://git.io/qy-ZGw
09:19 <tmortagne> has joined #xwiki
09:27 <Denis1> is now known as <Denis>
09:30 <CIA-102> Sergiu Dumitriu master * r7725791 / xwiki-platform-core/xwiki-platform-web/src/main/webapp/templates/saverights.vm : XWIKI-7149: Forbidding delete right transforms undelete right in "un" right ...
09:30 <CIA-102> Sergiu Dumitriu master * r4c2da47 / xwiki-platform-core/xwiki-platform-web/src/main/webapp/resources/js/xwiki/usersandgroups/usersandgroups.js : XWIKI-7148: Delete right shown in the UI when delete right is not present but undelete right is present ...
09:32 <sburjan> has joined #xwiki
09:34 <CIA-102> Sergiu Dumitriu master * rf2cd5e8 / pom.xml : XCOMMONS-59: Upgrade to commons-lang 3.1 ...
09:47 <vmassol> has joined #xwiki
10:47 <vmassol> sdumitriu: how can I change the filter used by http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10590 to use the new filter I've shared: http://jira.xwiki.org/secure/IssueNavigator.jspa?mode=hide&requestId=11192 ?
11:13 <lucaa> has joined #xwiki
11:22 <lucaa> has quit
11:22 <+mflorea> sdumitriu: you there?
11:23 <vmassol> Denis: I'm in a meeting right now but we need to talk about your collision id work. We need to know how safe this and Ludovic would like us to have a flag so that this is turned off by default
11:23 <vmassol> basicallt it's a very risk feature
11:24 <vmassol> and we need to guarantee that users are not going to have problems
11:24 <vmassol> since it could leave the whole DB unusable
11:24 <+Denis> this is why the migration work has to be in before
11:24 <vmassol> it should have been in M1
11:24 <vmassol> we have 2 options IMO
11:25 <+Denis> I have started in 3.2
11:25 <vmassol> either we commit it in 3.4M1 (which is in 2 weeks from now)
11:25 <vmassol> or we have fag off by default
11:25 <vmassol> flag
11:25 <vmassol> so that people can try it and report how it works
11:25 <vmassol> (the problem is not when it was started Denis but when it's first made available)
11:26 <lucaa> has joined #xwiki
11:28 <@cjdelisle> What are the failure modes to think about?
11:29 <@cjdelisle> I guess we don't really have to worry about it forgetting a table and leaving deleted attachments all broken or anything since that would have been clear early on.
11:29 <@cjdelisle> Which leaves upgrading, finding the upgrade has problems, downgrading, being broken.
11:29 <vmassol> yes
11:30 <vmassol> that's the use case to take into account
11:30 <+Denis> but before upgrading, you have to backup your DB
11:31 <@cjdelisle> s/have to/should/ but indeed yes.
11:31 <+Denis> yes you must
11:31 <@cjdelisle> I think the way most users work is they do db backups daily and they assume that's enough.
11:32 <@cjdelisle> they have a backup routine and they have an upgrade routine and they don't think about backups when they upgrade.
11:32 <vmassol> Denis: Ludovic doesn't agree with this because he says users will upgrade without doing backups and then we'll have to fix their mess....
11:32 <+Denis> this should be a hot warning on the release that will contains my migration
11:33 <vmassol> not enough
11:33 <@cjdelisle> Can we turn it on optimistically? thus if it gets migrated (magicly) then it reads the db version and starts using the new ids?
11:33 <+Denis> since MySQL ISAM has not rollback, there is no way to go back cleanly
11:33 <lucaa> has quit
11:33 <vmassol> Denis: yes which is why Ludovic is suggesting the flag
11:34 <vmassol> cjdelisle's idea sounds good too
11:34 <vmassol> (which is the same but with an "internal" flag: the dB version)
11:34 <lucaa> has joined #xwiki
11:34 <vmassol> personally
11:34 <vmassol> I prefer to defer this to 3.4M1
11:34 <vmassol> so that we get ample time for testing
11:35 <+Denis> this is not enought, Id migration is not transactional on MySQL
11:35 <@cjdelisle> The benefit of optimistic is that a few more versions down the road, we force it on them and if the wiki doesn't work right for whatever reason, they downgrade 1 version and it still works with the modified id numbers.
11:35 <@cjdelisle> I suspect >90% of the upgrade/downgrade problems will quietly vanish with that.
11:36 <+Denis> but half upgraded DB will be broken
11:37 <@cjdelisle> you're concerned that it will upgrade half way and croak?
11:37 <+Denis> my migration code can start again from a half upgraded DB
11:37 <+Denis> but it cannot roll back them
11:38 <+Denis> since ids are hashes, it could be possible to create collision, but it very unlikely
11:38 <vmassol> which is why either we're 100% sure it works or we have a flag turned off by default for some time to let people experiment with this
11:38 <+Denis> on the other hand, there could be network or db issue, or what else
11:38 <+Denis> we will never be 100% sure it works
11:39 <vmassol> again since this is coming very late for 3.3 I don't think we have any other option than the flag
11:39 <vmassol> sure
11:39 <vmassol> 99.999%
11:39 <vmassol> :)
11:39 <@cjdelisle> The main concern for me is that people will upgrade and it will work perfect and all that, then they will find some unrelated UI thing is broken and they downgrade while they work on figuring it out, then everything fails.
11:39 <vmassol> yep
11:39 <vmassol> that too
11:40 <+Denis> so you are saying that we need a rollback procedure ?
11:40 <vmassol> no
11:40 <vmassol> I'm saying that people who want to try it out can and they should backup
11:40 <+Denis> that we should introduce the rollback procedure in 3.3, and upgrade in 3.4
11:40 <vmassol> but till we get enough feedback that it's working we shouldn't have it on by default
11:40 <CIA-102> tmortagne master * r9d06f96 / (10 files in 5 dirs): XWIKI-7151: Installed extension licenses are lost after server restart - http://git.io/BmAzlw
11:41 <vmassol> and again my opinion is that we commit this in 3.4M1
11:41 <vmassol> so that people will try 3.4M1
11:41 <@cjdelisle> I don't like the rollback idea that much, I would rather it detect the modified db and be able to work with it. then a couple versions down the road, force the migration, then my concern is solved.
11:42 <+Denis> ok, lets way 3.4 to commit it on master, but I really need an agreement on the target ids and the fact it will be applied before
11:42 <+Denis> s/way/wait/
11:42 <+Denis> I means, I should be able to apply this on my side with assurance that I will be 3.4 compatible later
11:43 <vmassol> I understand
11:43 <@cjdelisle> IMO the quicker you can get optimistic stuff in place the better, then the longer you are willing to wait before forcing the change with the migrator, the better, it all means there's a wider buffer.
11:44 <+Denis> cjdelisle: with the migration procedure updated (separate patch), I have the garantee that a given wiki version will not use an incompatible database with its core version
11:45 <@cjdelisle> I don't follow? can you elaborate?
11:45 <+Denis> I have never envision a situation where a core support 2 different database version
11:45 <@cjdelisle> ahh I see
11:45 <+Denis> Currently, if a migration fails, the wiki starts
11:46 <+Denis> and with this Ids stuff, it really corrupt your data
11:46 <+Denis> creating missing classes for example because their id has not been migrated
11:46 <@cjdelisle> indeed
11:47 <+Denis> So I have improved the migration stuff, and I prevent any access to a database that has not the correct version number for a given core
11:48 <@cjdelisle> Ahh is that already in place?
11:48 <+Denis> If migration are activated, I upgrade the database as before, and this is transparent, else I just tell that the database needs migration
11:48 <@cjdelisle> I suppose it has to be..
11:48 <+Denis> it is a separate patch, not master right now
11:49 <+Denis> maybe this could be in for 3.3
11:49 <@cjdelisle> I don't think we are likely to end up with a db which is half migraded and all broken.
11:50 <@cjdelisle> But ending up with a core<->db mismatch, that is very likely.
11:51 <+Denis> the migration stuff improve many things, like not upgrading schema at many places on the fly, and note that shema upgrade was containing some row upgrades that has nothing to do there
11:51 <+Denis> do not apply migration on an empty database
11:51 <+Denis> do not apply migration on newly created wikis
11:52 <@cjdelisle> /nod
11:52 <@cjdelisle> is it in a branch?
11:52 <+Denis> http://jira.xwiki.org/browse/XWIKI-7006
11:52 <jvdrean> has joined #xwiki
11:55 <+Denis> it is in my own fork: https://github.com/dgervalle/xwiki-platform/compare/04ca2c9937b7f1f22d5cff8858acd75edff6fbfd...f1fa1b1357d17c1ee4ed65eb2cc7f2867ddb3762
11:57 <@cjdelisle> +@Named("hibernate") <-- Why Thankyou :)
11:58 <+Denis> because the migration systems see stores as a whole and is compatible with only on kind of store
11:58 <+Denis> this should be improved, but it is not so easy
11:58 <+Denis> having hibernate unqualified, means you do not know the kind of store you get
11:59 <+Denis> this has been a initial mistake IMO
12:00 <+Denis> so I have hinted hibernate stores and use "hibernate" as a default hint
12:00 <@cjdelisle> checkHibernate gets called a lot
12:00 <+Denis> this is unchanged
12:00 <+Denis> before it also trigger schema updates !
12:00 <@cjdelisle> https://github.com/dgervalle/xwiki-platform/compare/04ca2c9937b7f1f22d5cff8858acd75edff6fbfd...f1fa1b1357d17c1ee4ed65eb2cc7f2867ddb3762#L4L567
12:02 <+Denis> yes, what is your question ?
12:03 <+Denis> I means, checkHibernate has always been called often
12:04 <@cjdelisle> I think the reason for that dirty double lock is because checkHibernate gets called a lot and it was trying to avoid overhead.. now initHibernate will be called every time.
12:04 <+Denis> only when getSessionFactory() is null
12:05 <+Denis> which is not so often
12:06 <@cjdelisle> look in XHS
12:06 <@cjdelisle> it's called everywhere
12:07 <+Denis> yes
12:07 <+Denis> but the goal of initHibernate is to set the factory
12:07 <+Denis> so it will be called on once
12:08 <+Denis> only once
12:09 <@cjdelisle> ok I see
12:09 <@cjdelisle> the double checking danger is still there although less obvious
12:10 <+Denis> I do not think this matter a lot therefore, and double check is bad
12:10 <@cjdelisle> but I think sun and most of the other major jvm implementations realized a while back that they basicly had to support it.
12:17 <+Denis> if you really prefer, I can leave it there
12:17 <@cjdelisle> There seem to be a number of different concerns being addressed there, it looks to me like a patch set.
12:18 <@cjdelisle> The naming to "hibernate" is one concern
12:18 <@cjdelisle> then the beefing up the migrator
12:19 <@cjdelisle> The changes to XHBS is the part which I'm least comfortable with.
12:21 <+Denis> all this was require to better integrate the migration stuff
12:21 <+Denis> I do not plan it upfront
12:21 <@cjdelisle> yea
12:24 <+Denis> but compare to before, the risk of corrupting your database has been lowered by many
12:25 <+Denis> before, you have some component accessing subwiki databases before migration occurs
12:25 <+Denis> and absolutely no guard against the database version before access
12:40 <@cjdelisle> I see your fork still seems to use hashCode() for getting a document id.
12:42 <lucaa> has quit
12:47 <lucaa> has joined #xwiki
12:49 <+Denis> cjdelisle: yes changing that will be really harder, I am reducing the likelyhood not suppressing it fully, but with MD5 hash, it is really better
12:49 <CIA-102> tmortagne master * r6152024 / xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-api/src/main/java/org/xwiki/extension/AbstractExtension.java : XWIKI-7151: Installed extension licenses are lost after server restart ...
13:02 <lucaa> has quit
13:17 <lucaa> has joined #xwiki
13:20 <Denis1> has joined #xwiki
13:21 <Denis> has quit
13:28 <mflorea> has quit
13:30 <Denis1> is now known as <Denis>
13:33 <evalica> has joined #xwiki
13:40 <Enygma`> has joined #xwiki
13:50 <DrLou> has joined #xwiki
14:22 <mflorea> has joined #xwiki
14:32 <evalica> has quit
14:32 <evalica> has joined #xwiki
14:36 <evalica> has quit
14:42 <JuanDaugherty> has left #xwiki
14:43 <lucaa> has quit
14:43 <tmortagne> has quit
14:43 <sburjan`> has quit
14:47 <vmassol> guys please add your stuff to http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise33M2
14:47 <vmassol> sdumitriu: when do we release?
14:48 <lucaa> has joined #xwiki
14:48 <tmortagne> has joined #xwiki
14:48 <sburjan`> has joined #xwiki
14:48 <vmassol> sburjan: let me prepare the Dashboard application extension for you
15:00 <vmassol> tmortagne: how do I say that the extension is developed by the xwiki dev team, http://extensions.xwiki.org/xwiki/bin/inline/Extension/Dashboard+Application?
15:00 <vmassol> I don't see the field anymore
15:01 <tmortagne> vmassol: you put it as author
15:01 <vmassol> ah yes
15:02 <vmassol> hmm so for the license there's no way to say: "the license of the xwiki project"?
15:02 <tmortagne> no but that's the default license
15:02 <vmassol> (before when you said it was done by the xwiki dev team the right license was used)
15:02 <tmortagne> if you do nothing you will have LGPL 2.1
15:02 <vmassol> yes but it means someone can make a mistake
15:03 <vmassol> if I choose ASL for ex
15:03 <vmassol> and developed by the xiwki dev team
15:03 <vmassol> what happens?
15:03 <tmortagne> well if he change the license he should know what he is doing I would say
15:03 <vmassol> (btw this would come useful if one day we decide to have several licneses for several parts of xwiki ;))
15:04 <vmassol> tmortagne: also
15:04 <vmassol> imagine we change from LGPL 2.1 to LGPL 3
15:04 <vmassol> we have to change all extensions
15:04 <vmassol> (xwiki dev team extensions)
15:04 <tmortagne> yes
15:04 <tmortagne> but when you change a license it changed to new versions the old license stay true for the old versions
15:05 <tmortagne> also mean that the licnse probably need to be at version level
15:05 <vmassol> btw is the license now attached to a version?
15:06 <vmassol> yep
15:07 <tmortagne> technically everything could be associated to the version as we discussed last time but it's a matter of how much information you need to duplicate and what really need to be separated
15:07 <vmassol> sburjan: the page is ready for you to document: http://extensions.xwiki.org/xwiki/bin/view/Extension/Dashboard+Application :)
15:08 <vmassol> tmortagne: I don't remember what you said about the instructions listed for bundled apps, for ex: http://extensions.xwiki.org/xwiki/bin/view/Extension/Dashboard+Application
15:08 <vmassol> it always seems strange to me to have instructions if nothing can be downloade
15:08 <vmassol> cannot you only display instructions if there 's a download?
15:09 <vmassol> s/cannot/couldn't/
15:10 <tmortagne> the fact that an extension of type xar does not have anything to download sounds like temporary or a mistake to me
15:10 <vmassol> yes but users see it now
15:10 <vmassol> so it seems a good rule
15:11 <vmassol> to not have install instructions if there's no download
15:11 <vmassol> what's wrong with that?
15:11 <vmassol> tmortagne: btw just noticed a bug on http://enterprise.xwiki.org/xwiki/bin/view/Main/Features
15:11 <vmassol> it also lists other things than apps now
15:12 <vmassol> like macros
15:12 <tmortagne> http://extensions.xwiki.org/xwiki/bin/view/Extension/Tag+Cloud+Macro
15:12 <tmortagne> as far as i can see it's an application, a xar
15:12 <vmassol> ah wiki macros
15:12 <vmassol> hmmm
15:13 <vmassol> we have a problem
15:13 <vmassol> because there's no reason we list wiki macros and not other macros
15:13 <vmassol> and if we want to list all bundled macros we would need to list them in a separate section
15:13 <vmassol> (not in the Bundled Applications section)
15:14 <tmortagne> probably since it's a lot of things
15:22 <Enygma`> has quit
15:22 <vmassol> tmortagne: hmm macros are now components
15:22 <vmassol> (java macros)
15:22 <vmassol> so basically we currently have no way of identifying macros
15:22 <tmortagne> they are jar
15:22 <vmassol> (whether they are wiki macros or java macros)
15:23 <vmassol> what can we do?
15:23 <vmassol> tags?
15:23 <vmassol> anything better than tags?
15:23 <vmassol> what if users want to see all macros?
15:23 <vmassol> (in the extension LT)
15:23 <+sburjan> vmassol: ok, I think I'll have time only next week got it
15:23 <+sburjan> *for it
15:23 <+sburjan> but thanks !
15:23 <sburjan_> has joined #xwiki
15:33 <lucaa> has quit
15:33 <tmortagne> has quit
15:33 <sburjan`> has quit
15:33 <sburjan_> is now known as <sburjan`>
15:36 <vmassol> thanks ™
15:37 <vmassol> :)
15:41 <tmortagne> has joined #xwiki
15:41 <lucaa> has joined #xwiki
16:07 <+lucaa> guys, when I include page A in page B and page A uses some protected API, who has to have the rights, included page or including page (A or B)
16:07 <+lucaa> ?
16:07 <+lucaa> "the rights" == be saved with programming rights
16:35 <+tmortagne> lucaa: depends what include you use
16:35 <+tmortagne> what context parameter I mean
16:36 <+tmortagne> by default all include do is to insert included content as it was part of your document already (except for the reference resolution)
17:02 <vmassol> tmortagne: there's a problem with the breadcrumb
17:02 <vmassol> for ex: http://extensions.xwiki.org/xwiki/bin/view/Extension/Dashboard+Application
17:03 <vmassol> Extensions is listed twice
17:03 <+tmortagne> vmassol: not exactly
17:03 <vmassol> yes I know
17:03 <vmassol> but still it's not correct
17:04 <+tmortagne> all I can see to fix it is a redirect
17:04 <vmassol> why not change the extensions?
17:04 <vmassol> isn't this what we had before
17:05 <vmassol> parent being set a Main.Webhome
17:05 <vmassol> s/a/as/
17:05 <vmassol> ?
17:05 <vmassol> and when a new extension is created set its parent as Main.WebHome
17:05 <Enygma`> has joined #xwiki
17:05 <vmassol> what redirect do you have in mind?
17:05 <+tmortagne> I try to have code commons to XR and extensions.xwiki.org annd XR home page is Extension.WebHome since it's an extension itseelf
17:06 <vmassol> or
17:06 <vmassol> we change the home page name
17:06 <+tmortagne> yes we can do that
17:07 <vmassol> but since both pages are the same...
17:07 <+tmortagne> nor exactly actually
17:07 <+tmortagne> "Extensions are ways to extend XWiki Enterprise. Select the Extension you wish to install from the list below and then follow the instructions on the extension page to install it in your wiki."
17:08 <+tmortagne> because of "XWiki Enterprise mostly"
17:08 <vmassol> I don't undertand wym
17:08 <+tmortagne> and there could be much more difference that that
17:08 <+tmortagne> things specific to extensions.xwiki.org home page, I don't know
17:09 <+tmortagne> like links to xwiki.org etc
17:09 <+tmortagne> or explaining that you can find extension and documentation for example which does not mak much sense for XR
17:09 <vmassol> well right now they're the same and I don't plan to change it
17:09 <+lucaa> tmortagne: re includes: so context=existing uses the rights of including document, context=new uses the rights of included
17:10 <vmassol> even if you add a few links it'sn ot going to make a big visual difference
17:11 <+tmortagne> lucaa: context=current behave exactly has if the content you ionclude was part of your document (except for the links) and context=new behave has if you where viewing the included content from its own page
17:11 <+lucaa> tmortagne: ok, merci
17:14 <vmassol> tmortagne: how do you plan to handle categories for the EM UI?
17:14 <vmassol> (we have the same need for the feature page of XE for ex)
17:14 <vmassol> (and macros could be handled like this)
17:15 <+tmortagne> vmassol: not much plan since it's not in the model yet but I was thinking of reusing tags as I suggested when we talked about features page
17:15 <vmassol> but tags are not in maven
17:16 <vmassol> so we would also need some custom props for maven right?
17:16 <+tmortagne> there is no concept of category in maven anyway
17:16 <+tmortagne> custom props is easy yes
17:16 <+tmortagne> I'm already using them for some EM things not supported by maven
17:17 <+tmortagne> and plan to add more
17:19 <+tmortagne> (I understood "XR UI" instead of "EM UI" at first)
17:19 <+tmortagne> I don't remember if evalica did a proposal about category in her design already
17:20 <+tmortagne> but from EM point it's only informationnal so it's just a lits of string to display somewhere
17:22 <vmassol> I don't think she's taken that into account… http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ExtensionManagerProposalI3
17:22 <vmassol> however she has different categories in the left menu
17:22 <vmassol> like macros, skins, etc
17:22 <+tmortagne> I see "tags" in her proposal
17:22 <+tmortagne> sounds like the same thing to me
17:23 <+tmortagne> under "ratings"
17:23 <+tmortagne> on the left of the extension description
17:23 <vmassol> yes I see them
17:23 <vmassol> they could finer-grained cateogires indeed
17:24 <vmassol> s/could/could be/
17:24 <vmassol> we probably still need top level categories such as macros, skins, themes, etc
17:25 <+tmortagne> not sure
17:25 <+tmortagne> it make sense to have multiple catagories
17:25 <+tmortagne> a xar extension is often several things, we don't have much wiki macro alone
17:26 <vmassol> in any case the only category she's taken into account so far in her UI are the ones in the left menu
17:27 <vmassol> there's no UI mockup for filtering extensions on other things that I can see
17:27 <+tmortagne> yes the the one on the left are kind of random, they were supposed to be types and she just took what she found on extensions.xwiki.org
17:27 <vmassol> they're not random!
17:27 <vmassol> they 're the ones we had defined
17:27 <vmassol> in any case we need to ask her to work on this I think
17:28 <vmassol> and on our side we need to take it into accoutn too
17:28 <+tmortagne> also mostly depends on what sdumitriu did already
17:30 <vmassol> who knows…. we'll discover that a few days after the release ;)
17:31 <vmassol> (unless sergiu wants to share what he's working on with us before ofc...)
17:33 <vmassol> tmortagne: old extensions have correct breadcrumbs: http://extensions.xwiki.org/xwiki/bin/view/Extension/Sheet+Module Maybe customizing the Extension Template is ok?
17:34 <vmassol> since template is a bit usage-specific
17:34 <+tmortagne> vmassol: I did not modified old extensions parents
17:34 <vmassol> (yes I guessed so)
17:34 <+tmortagne> problem is that template or not it's a page in XR xar so something you have to skip when importing a new version
17:35 <+tmortagne> unless I don't provide any template in XR
17:35 <vmassol> or you provide a default one
17:35 <vmassol> but the XR config has a field to list the template to use
17:36 <vmassol> if not defined the default one is used
17:36 <+tmortagne> hmm
17:36 <vmassol> is that overkill? :)
17:36 <+tmortagne> would need mflorea input on that probably since XR is using old template/sheet system which is not good anyway
17:37 <vmassol> I agree that if we can find a simpler solution it's better
17:37 <+tmortagne> never use the new system yet
17:37 <+tmortagne> with the debate about naming convention etc I'm not sure what is it's current best practice
17:38 <+tmortagne> but as far as I understood either way there is no page based template anymore
17:38 <+mflorea> tmortagne: I haven't followed the discussion. What is the relation between the template you are talking about and the new sheet system?
17:38 <+tmortagne> vmassol: having a configuration is ok, I already created a configuration system for XR so it's just a field to add
17:39 <vmassol> tmortagne: yes but if we can have a XR that fits exactly our need for xwiki.org it's even better
17:39 <+tmortagne> mflorea: mostly the fact that XR should not use template page anyway if it fowwon the new syste, right ?
17:40 <+tmortagne> in fact I don't really know what's the current best practice around tmeplate/sheet when creating a new application
17:41 <+mflorea> no, the new sheet system doesn't eliminate the usage of template, on the contrary, it uses templates. For instance, when you create a new page of a specific type (Blog.BlogPostClass) you need a template specified in the URL in order for the edit action to work properly (i.e. the Inline form to be triggered)
17:41 <+tmortagne> and the issue here is that the defautl extension parent for XR and extensions.xwiki.org are not the same
17:42 <+tmortagne> mflorea: don't you mean sheet ?
17:42 <+mflorea> no, I mean template
17:42 <+mflorea> let me explain
17:43 <+mflorea> the sheet is automatically applied only if there is an object of type T added to the page. But when you create a new page you don't have this object. By specifying the template in the URL, the edit action copies the object from the template to the new page and thus the sheet is applied
17:43 <+tmortagne> ok so it's the same as before
17:44 <+mflorea> wrt templates yes
17:44 <+mflorea> i.e. they serve the same role
17:44 <+tmortagne> ok so sorry for the noise :)
17:44 <+mflorea> np :)
17:45 <+tmortagne> vmassol: issue is that it's not right IMO to have a Main.WebHome page in the XR xar
17:46 <vmassol> yep I agree
17:46 <+tmortagne> i'm ok with the configuration id, it's not very hard to do
17:47 <vmassol> another option is to have a config option for the parent of extensions, defaulting to Extension.WebHome
17:47 <+tmortagne> and there probably a lot more things I could make configurable
17:47 <+tmortagne> vmassol: that's harder
17:47 <vmassol> that allows to reuse the template
17:47 <+tmortagne> because th parent field is not a velocity field
17:47 <+tmortagne> so you can't have a dynamic parent in the template
17:47 <vmassol> the parent is passed in the URL
17:47 <vmassol> when you create a new extension
17:48 <+tmortagne> or this mean you override the template after the creation
17:48 <vmassol> AFAIR
17:48 <+tmortagne> I don't think so, you can maybe override the parent but you put the template in the URL and it's copied as it is AFAIK
17:48 <vmassol> yep
17:48 <vmassol> http://extensions.xwiki.org/xwiki/bin/inline/Extension/sss?parent=Extension.WebHome&template=ExtensionCode.ExtensionTemplate&createExtension=true&name=sss
17:49 <vmassol> (for ex)
17:49 <+tmortagne> but it's not hard to override what's in the template anyway
17:49 <vmassol> so easy to do
17:50 <+tmortagne> yes should be
17:51 <+tmortagne> if it's really taken into account :)
17:51 <vmassol> it is I'm pretty sure
17:51 <@sdumitriu> Hey guys, what's the status for the release? Still waiting for code to stabilize?
17:52 <@sdumitriu> I see lots of problems on ci.xwiki.org
17:52 <+tmortagne> don't think so, I'm working on a bugfix but i can go after the release
17:52 <vmassol> Denis: you're the BM right? :)
17:52 <vmassol> I asked devs here about their status this morning
17:52 <vmassol> but didn't got much answers
17:52 <+Denis> right
17:53 <+Denis> I try to be
17:53 <vmassol> Denis: can we release?
17:53 <vmassol> mflorea: I think you're ok right?
17:53 <+tmortagne> vmassol: did you fixed the test about dashboard refactoring
17:53 <vmassol> hmm what tests tmortagne?
17:53 <+tmortagne> reported by Enygma`IIRW
17:53 <+tmortagne> some page moved or has been renamed and some test count on it
17:53 <vmassol> maybe I missed that because it doesn't ring a bell
17:53 <+tmortagne> or maybe it was mflorea
17:54 <+Denis> not yet, I has to commit my own stuff, and there is some failling tests
17:54 <+Denis> (not mine)
17:54 <+Denis> but I do not know if this is major or not
17:55 <vmassol> hmm btw console output here isn't good re logback :http://ci.xwiki.org/job/xwiki-enterprise-test-ui/org.xwiki.enterprise$xwiki-enterprise-test-ui/595/testReport/org.xwiki.test.ui/AttachmentTest/testUploadDownloadTwoAttachments/
17:55 <+mflorea> vmassol: on the AppWithinMinutes yes. I have some bugs on my list (unrelated to AppWithinMinutes) that I'd like to fix, but they shouldn't postpone the release (i.e. they can make it to 3.3RC1)
17:56 <+mflorea> tmortagne: I can take care of the WYSIWYG tests
17:57 <+tmortagne> mflorea: ok
18:07 <abusenius> has joined #xwiki
18:10 <tmortagne> has quit
18:20 <vmassol> has quit
18:23 <CIA-102> Denis Gervalle feature-immutable-refs * r459c2c3 / xwiki-platform-core/xwiki-platform-model/src/main/java/org/xwiki/model/reference/EntityReference.java : XWIKI-7097 Make EntityReference immutables, adding parameters to EntityReference and allowing Locale and Version in DocumentReference ...
18:23 <CIA-102> Denis Gervalle master * r459c2c3 / xwiki-platform-core/xwiki-platform-model/src/main/java/org/xwiki/model/reference/EntityReference.java : XWIKI-7097 Make EntityReference immutables, adding parameters to EntityReference and allowing Locale and Version in DocumentReference ...
18:23 <CIA-102> Denis Gervalle master * r0edbb5d / (45 files in 19 dirs): XWIKI-7097 Make EntityReference immutables, and add Locale in DocumentReference ...
18:32 <CIA-102> Denis Gervalle master * r1751411 / xwiki-platform-core/xwiki-platform-model/src/main/java/org/xwiki/model/reference/EntityReference.java : XWIKI-7097 Make EntityReference immutables, and add Locale in DocumentReference ...
18:38 <sburjan> has quit
18:44 <mflorea> has quit
18:50 <CIA-102> Eduard Moraru master * rd8c64da / (4 files in 2 dirs): XWIKI-7153 : Don`t use translation keys from dependencies - http://git.io/rSoneQ
19:44 <@sdumitriu> Broken attachment: http://extensions.xwiki.org/xwiki/bin/view/Extension/XSLT+Macro#Attachments
19:45 <@sdumitriu> I wonder what happened
20:14 <lucaa> has quit
20:16 <vmassol> has joined #xwiki
20:29 <vmassol> guys I've analyzed all failing UI tests
20:29 <vmassol> one I've just fixed and the others are caused by thomas' changes
20:29 <vmassol> I've reported them to thomas on skype
20:29 <vmassol> (but he's offline right now, he'll see them tomorrow)
20:30 <CIA-102> Vincent Massol master * r0f66061 / (2 files): Fix test (was having an extra new line) - http://git.io/C1fJQg
20:33 <vmassol> webstandards issues are caused by marius, sending him on skype
20:33 <+Denis> vmassol: hey, you are doing my job, I had plane to do that this evening...
20:33 <+Denis> thanks :)
20:33 <vmassol> ok all reviewed :)
20:34 <vmassol> ah no
20:34 <vmassol> still need to reviex escaping
20:34 <+Denis> I think marius is aware
20:34 <vmassol> same issue it's for marius
20:34 <vmassol> bbl
20:51 <jvdrean> has quit
21:47 <rrodriguez> has joined #xwiki
21:56 <jvdrean> has joined #xwiki
22:16 <vmassol> has quit
22:29 <abusenius> has quit
23:19 <Enygma`> has quit
06:01 <Denis1> has joined #xwiki
06:04 <Denis> has quit
06:56 <Enygma`> has joined #xwiki
07:14 <tekzilla> has quit
07:15 <tekzilla> has joined #xwiki
07:30 <DrLou> has quit
08:12 <vmassol> has joined #xwiki
08:17 <CIA-102> Eduard Moraru master * r5541789 / (17 files in 9 dirs): XWIKI-7152: Use script service everywhere for accessing the wiki manager and application manager plugins - http://git.io/qy-ZGw
08:18 <CIA-102> Eduard Moraru master * r695e140 / (8 files in 2 dirs): XEM-201 : Use of the wiki manager plugin as a script service - http://git.io/bb4-_w
08:21 <Enygma`> has quit
08:24 <vmassol> has quit
08:31 <sburjan`> has quit
08:36 <sburjan`> has joined #xwiki
08:59 <mflorea> has joined #xwiki
09:04 <CIA-102> Sergiu Dumitriu feature-applicationWithinMinutes * ra3b2226 / xwiki-platform-core/xwiki-platform-web/src/main/webapp/templates/macros.vm : Merge pull request #26 from sorzu/master ...
09:04 <CIA-102> Sergiu Dumitriu feature-applicationWithinMinutes * r2a7601f / xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-api/src/main/java/org/xwiki/extension/AbstractExtension.java : XWIKI-7150: The name, licenses and summary of a local extension isn't copied over from the remote descriptor ...
09:04 <CIA-102> Eduard Moraru feature-applicationWithinMinutes * r5541789 / (17 files in 9 dirs): XWIKI-7152: Use script service everywhere for accessing the wiki manager and application manager plugins - http://git.io/qy-ZGw
09:19 <tmortagne> has joined #xwiki
09:27 <Denis1> is now known as <Denis>
09:30 <CIA-102> Sergiu Dumitriu master * r7725791 / xwiki-platform-core/xwiki-platform-web/src/main/webapp/templates/saverights.vm : XWIKI-7149: Forbidding delete right transforms undelete right in "un" right ...
09:30 <CIA-102> Sergiu Dumitriu master * r4c2da47 / xwiki-platform-core/xwiki-platform-web/src/main/webapp/resources/js/xwiki/usersandgroups/usersandgroups.js : XWIKI-7148: Delete right shown in the UI when delete right is not present but undelete right is present ...
09:32 <sburjan> has joined #xwiki
09:34 <CIA-102> Sergiu Dumitriu master * rf2cd5e8 / pom.xml : XCOMMONS-59: Upgrade to commons-lang 3.1 ...
09:47 <vmassol> has joined #xwiki
10:47 <vmassol> sdumitriu: how can I change the filter used by http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10590 to use the new filter I've shared: http://jira.xwiki.org/secure/IssueNavigator.jspa?mode=hide&requestId=11192 ?
11:13 <lucaa> has joined #xwiki
11:22 <lucaa> has quit
11:22 <+mflorea> sdumitriu: you there?
11:23 <vmassol> Denis: I'm in a meeting right now but we need to talk about your collision id work. We need to know how safe this and Ludovic would like us to have a flag so that this is turned off by default
11:23 <vmassol> basicallt it's a very risk feature
11:24 <vmassol> and we need to guarantee that users are not going to have problems
11:24 <vmassol> since it could leave the whole DB unusable
11:24 <+Denis> this is why the migration work has to be in before
11:24 <vmassol> it should have been in M1
11:24 <vmassol> we have 2 options IMO
11:25 <+Denis> I have started in 3.2
11:25 <vmassol> either we commit it in 3.4M1 (which is in 2 weeks from now)
11:25 <vmassol> or we have fag off by default
11:25 <vmassol> flag
11:25 <vmassol> so that people can try it and report how it works
11:25 <vmassol> (the problem is not when it was started Denis but when it's first made available)
11:26 <lucaa> has joined #xwiki
11:28 <@cjdelisle> What are the failure modes to think about?
11:29 <@cjdelisle> I guess we don't really have to worry about it forgetting a table and leaving deleted attachments all broken or anything since that would have been clear early on.
11:29 <@cjdelisle> Which leaves upgrading, finding the upgrade has problems, downgrading, being broken.
11:29 <vmassol> yes
11:30 <vmassol> that's the use case to take into account
11:30 <+Denis> but before upgrading, you have to backup your DB
11:31 <@cjdelisle> s/have to/should/ but indeed yes.
11:31 <+Denis> yes you must
11:31 <@cjdelisle> I think the way most users work is they do db backups daily and they assume that's enough.
11:32 <@cjdelisle> they have a backup routine and they have an upgrade routine and they don't think about backups when they upgrade.
11:32 <vmassol> Denis: Ludovic doesn't agree with this because he says users will upgrade without doing backups and then we'll have to fix their mess....
11:32 <+Denis> this should be a hot warning on the release that will contains my migration
11:33 <vmassol> not enough
11:33 <@cjdelisle> Can we turn it on optimistically? thus if it gets migrated (magicly) then it reads the db version and starts using the new ids?
11:33 <+Denis> since MySQL ISAM has not rollback, there is no way to go back cleanly
11:33 <lucaa> has quit
11:33 <vmassol> Denis: yes which is why Ludovic is suggesting the flag
11:34 <vmassol> cjdelisle's idea sounds good too
11:34 <vmassol> (which is the same but with an "internal" flag: the dB version)
11:34 <lucaa> has joined #xwiki
11:34 <vmassol> personally
11:34 <vmassol> I prefer to defer this to 3.4M1
11:34 <vmassol> so that we get ample time for testing
11:35 <+Denis> this is not enought, Id migration is not transactional on MySQL
11:35 <@cjdelisle> The benefit of optimistic is that a few more versions down the road, we force it on them and if the wiki doesn't work right for whatever reason, they downgrade 1 version and it still works with the modified id numbers.
11:35 <@cjdelisle> I suspect >90% of the upgrade/downgrade problems will quietly vanish with that.
11:36 <+Denis> but half upgraded DB will be broken
11:37 <@cjdelisle> you're concerned that it will upgrade half way and croak?
11:37 <+Denis> my migration code can start again from a half upgraded DB
11:37 <+Denis> but it cannot roll back them
11:38 <+Denis> since ids are hashes, it could be possible to create collision, but it very unlikely
11:38 <vmassol> which is why either we're 100% sure it works or we have a flag turned off by default for some time to let people experiment with this
11:38 <+Denis> on the other hand, there could be network or db issue, or what else
11:38 <+Denis> we will never be 100% sure it works
11:39 <vmassol> again since this is coming very late for 3.3 I don't think we have any other option than the flag
11:39 <vmassol> sure
11:39 <vmassol> 99.999%
11:39 <vmassol> :)
11:39 <@cjdelisle> The main concern for me is that people will upgrade and it will work perfect and all that, then they will find some unrelated UI thing is broken and they downgrade while they work on figuring it out, then everything fails.
11:39 <vmassol> yep
11:39 <vmassol> that too
11:40 <+Denis> so you are saying that we need a rollback procedure ?
11:40 <vmassol> no
11:40 <vmassol> I'm saying that people who want to try it out can and they should backup
11:40 <+Denis> that we should introduce the rollback procedure in 3.3, and upgrade in 3.4
11:40 <vmassol> but till we get enough feedback that it's working we shouldn't have it on by default
11:40 <CIA-102> tmortagne master * r9d06f96 / (10 files in 5 dirs): XWIKI-7151: Installed extension licenses are lost after server restart - http://git.io/BmAzlw
11:41 <vmassol> and again my opinion is that we commit this in 3.4M1
11:41 <vmassol> so that people will try 3.4M1
11:41 <@cjdelisle> I don't like the rollback idea that much, I would rather it detect the modified db and be able to work with it. then a couple versions down the road, force the migration, then my concern is solved.
11:42 <+Denis> ok, lets way 3.4 to commit it on master, but I really need an agreement on the target ids and the fact it will be applied before
11:42 <+Denis> s/way/wait/
11:42 <+Denis> I means, I should be able to apply this on my side with assurance that I will be 3.4 compatible later
11:43 <vmassol> I understand
11:43 <@cjdelisle> IMO the quicker you can get optimistic stuff in place the better, then the longer you are willing to wait before forcing the change with the migrator, the better, it all means there's a wider buffer.
11:44 <+Denis> cjdelisle: with the migration procedure updated (separate patch), I have the garantee that a given wiki version will not use an incompatible database with its core version
11:45 <@cjdelisle> I don't follow? can you elaborate?
11:45 <+Denis> I have never envision a situation where a core support 2 different database version
11:45 <@cjdelisle> ahh I see
11:45 <+Denis> Currently, if a migration fails, the wiki starts
11:46 <+Denis> and with this Ids stuff, it really corrupt your data
11:46 <+Denis> creating missing classes for example because their id has not been migrated
11:46 <@cjdelisle> indeed
11:47 <+Denis> So I have improved the migration stuff, and I prevent any access to a database that has not the correct version number for a given core
11:48 <@cjdelisle> Ahh is that already in place?
11:48 <+Denis> If migration are activated, I upgrade the database as before, and this is transparent, else I just tell that the database needs migration
11:48 <@cjdelisle> I suppose it has to be..
11:48 <+Denis> it is a separate patch, not master right now
11:49 <+Denis> maybe this could be in for 3.3
11:49 <@cjdelisle> I don't think we are likely to end up with a db which is half migraded and all broken.
11:50 <@cjdelisle> But ending up with a core<->db mismatch, that is very likely.
11:51 <+Denis> the migration stuff improve many things, like not upgrading schema at many places on the fly, and note that shema upgrade was containing some row upgrades that has nothing to do there
11:51 <+Denis> do not apply migration on an empty database
11:51 <+Denis> do not apply migration on newly created wikis
11:52 <@cjdelisle> /nod
11:52 <@cjdelisle> is it in a branch?
11:52 <+Denis> http://jira.xwiki.org/browse/XWIKI-7006
11:52 <jvdrean> has joined #xwiki
11:55 <+Denis> it is in my own fork: https://github.com/dgervalle/xwiki-platform/compare/04ca2c9937b7f1f22d5cff8858acd75edff6fbfd...f1fa1b1357d17c1ee4ed65eb2cc7f2867ddb3762
11:57 <@cjdelisle> +@Named("hibernate") <-- Why Thankyou :)
11:58 <+Denis> because the migration systems see stores as a whole and is compatible with only on kind of store
11:58 <+Denis> this should be improved, but it is not so easy
11:58 <+Denis> having hibernate unqualified, means you do not know the kind of store you get
11:59 <+Denis> this has been a initial mistake IMO
12:00 <+Denis> so I have hinted hibernate stores and use "hibernate" as a default hint
12:00 <@cjdelisle> checkHibernate gets called a lot
12:00 <+Denis> this is unchanged
12:00 <+Denis> before it also trigger schema updates !
12:00 <@cjdelisle> https://github.com/dgervalle/xwiki-platform/compare/04ca2c9937b7f1f22d5cff8858acd75edff6fbfd...f1fa1b1357d17c1ee4ed65eb2cc7f2867ddb3762#L4L567
12:02 <+Denis> yes, what is your question ?
12:03 <+Denis> I means, checkHibernate has always been called often
12:04 <@cjdelisle> I think the reason for that dirty double lock is because checkHibernate gets called a lot and it was trying to avoid overhead.. now initHibernate will be called every time.
12:04 <+Denis> only when getSessionFactory() is null
12:05 <+Denis> which is not so often
12:06 <@cjdelisle> look in XHS
12:06 <@cjdelisle> it's called everywhere
12:07 <+Denis> yes
12:07 <+Denis> but the goal of initHibernate is to set the factory
12:07 <+Denis> so it will be called on once
12:08 <+Denis> only once
12:09 <@cjdelisle> ok I see
12:09 <@cjdelisle> the double checking danger is still there although less obvious
12:10 <+Denis> I do not think this matter a lot therefore, and double check is bad
12:10 <@cjdelisle> but I think sun and most of the other major jvm implementations realized a while back that they basicly had to support it.
12:17 <+Denis> if you really prefer, I can leave it there
12:17 <@cjdelisle> There seem to be a number of different concerns being addressed there, it looks to me like a patch set.
12:18 <@cjdelisle> The naming to "hibernate" is one concern
12:18 <@cjdelisle> then the beefing up the migrator
12:19 <@cjdelisle> The changes to XHBS is the part which I'm least comfortable with.
12:21 <+Denis> all this was require to better integrate the migration stuff
12:21 <+Denis> I do not plan it upfront
12:21 <@cjdelisle> yea
12:24 <+Denis> but compare to before, the risk of corrupting your database has been lowered by many
12:25 <+Denis> before, you have some component accessing subwiki databases before migration occurs
12:25 <+Denis> and absolutely no guard against the database version before access
12:40 <@cjdelisle> I see your fork still seems to use hashCode() for getting a document id.
12:42 <lucaa> has quit
12:47 <lucaa> has joined #xwiki
12:49 <+Denis> cjdelisle: yes changing that will be really harder, I am reducing the likelyhood not suppressing it fully, but with MD5 hash, it is really better
12:49 <CIA-102> tmortagne master * r6152024 / xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-api/src/main/java/org/xwiki/extension/AbstractExtension.java : XWIKI-7151: Installed extension licenses are lost after server restart ...
13:02 <lucaa> has quit
13:17 <lucaa> has joined #xwiki
13:20 <Denis1> has joined #xwiki
13:21 <Denis> has quit
13:28 <mflorea> has quit
13:30 <Denis1> is now known as <Denis>
13:33 <evalica> has joined #xwiki
13:40 <Enygma`> has joined #xwiki
13:50 <DrLou> has joined #xwiki
14:22 <mflorea> has joined #xwiki
14:32 <evalica> has quit
14:32 <evalica> has joined #xwiki
14:36 <evalica> has quit
14:42 <JuanDaugherty> has left #xwiki
14:43 <lucaa> has quit
14:43 <tmortagne> has quit
14:43 <sburjan`> has quit
14:47 <vmassol> guys please add your stuff to http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise33M2
14:47 <vmassol> sdumitriu: when do we release?
14:48 <lucaa> has joined #xwiki
14:48 <tmortagne> has joined #xwiki
14:48 <sburjan`> has joined #xwiki
14:48 <vmassol> sburjan: let me prepare the Dashboard application extension for you
15:00 <vmassol> tmortagne: how do I say that the extension is developed by the xwiki dev team, http://extensions.xwiki.org/xwiki/bin/inline/Extension/Dashboard+Application?
15:00 <vmassol> I don't see the field anymore
15:01 <tmortagne> vmassol: you put it as author
15:01 <vmassol> ah yes
15:02 <vmassol> hmm so for the license there's no way to say: "the license of the xwiki project"?
15:02 <tmortagne> no but that's the default license
15:02 <vmassol> (before when you said it was done by the xwiki dev team the right license was used)
15:02 <tmortagne> if you do nothing you will have LGPL 2.1
15:02 <vmassol> yes but it means someone can make a mistake
15:03 <vmassol> if I choose ASL for ex
15:03 <vmassol> and developed by the xiwki dev team
15:03 <vmassol> what happens?
15:03 <tmortagne> well if he change the license he should know what he is doing I would say
15:03 <vmassol> (btw this would come useful if one day we decide to have several licneses for several parts of xwiki ;))
15:04 <vmassol> tmortagne: also
15:04 <vmassol> imagine we change from LGPL 2.1 to LGPL 3
15:04 <vmassol> we have to change all extensions
15:04 <vmassol> (xwiki dev team extensions)
15:04 <tmortagne> yes
15:04 <tmortagne> but when you change a license it changed to new versions the old license stay true for the old versions
15:05 <tmortagne> also mean that the licnse probably need to be at version level
15:05 <vmassol> btw is the license now attached to a version?
15:06 <vmassol> yep
15:07 <tmortagne> technically everything could be associated to the version as we discussed last time but it's a matter of how much information you need to duplicate and what really need to be separated
15:07 <vmassol> sburjan: the page is ready for you to document: http://extensions.xwiki.org/xwiki/bin/view/Extension/Dashboard+Application :)
15:08 <vmassol> tmortagne: I don't remember what you said about the instructions listed for bundled apps, for ex: http://extensions.xwiki.org/xwiki/bin/view/Extension/Dashboard+Application
15:08 <vmassol> it always seems strange to me to have instructions if nothing can be downloade
15:08 <vmassol> cannot you only display instructions if there 's a download?
15:09 <vmassol> s/cannot/couldn't/
15:10 <tmortagne> the fact that an extension of type xar does not have anything to download sounds like temporary or a mistake to me
15:10 <vmassol> yes but users see it now
15:10 <vmassol> so it seems a good rule
15:11 <vmassol> to not have install instructions if there's no download
15:11 <vmassol> what's wrong with that?
15:11 <vmassol> tmortagne: btw just noticed a bug on http://enterprise.xwiki.org/xwiki/bin/view/Main/Features
15:11 <vmassol> it also lists other things than apps now
15:12 <vmassol> like macros
15:12 <tmortagne> http://extensions.xwiki.org/xwiki/bin/view/Extension/Tag+Cloud+Macro
15:12 <tmortagne> as far as i can see it's an application, a xar
15:12 <vmassol> ah wiki macros
15:12 <vmassol> hmmm
15:13 <vmassol> we have a problem
15:13 <vmassol> because there's no reason we list wiki macros and not other macros
15:13 <vmassol> and if we want to list all bundled macros we would need to list them in a separate section
15:13 <vmassol> (not in the Bundled Applications section)
15:14 <tmortagne> probably since it's a lot of things
15:22 <Enygma`> has quit
15:22 <vmassol> tmortagne: hmm macros are now components
15:22 <vmassol> (java macros)
15:22 <vmassol> so basically we currently have no way of identifying macros
15:22 <tmortagne> they are jar
15:22 <vmassol> (whether they are wiki macros or java macros)
15:23 <vmassol> what can we do?
15:23 <vmassol> tags?
15:23 <vmassol> anything better than tags?
15:23 <vmassol> what if users want to see all macros?
15:23 <vmassol> (in the extension LT)
15:23 <+sburjan> vmassol: ok, I think I'll have time only next week got it
15:23 <+sburjan> *for it
15:23 <+sburjan> but thanks !
15:23 <sburjan_> has joined #xwiki
15:33 <lucaa> has quit
15:33 <tmortagne> has quit
15:33 <sburjan`> has quit
15:33 <sburjan_> is now known as <sburjan`>
15:36 <vmassol> thanks ™
15:37 <vmassol> :)
15:41 <tmortagne> has joined #xwiki
15:41 <lucaa> has joined #xwiki
16:07 <+lucaa> guys, when I include page A in page B and page A uses some protected API, who has to have the rights, included page or including page (A or B)
16:07 <+lucaa> ?
16:07 <+lucaa> "the rights" == be saved with programming rights
16:35 <+tmortagne> lucaa: depends what include you use
16:35 <+tmortagne> what context parameter I mean
16:36 <+tmortagne> by default all include do is to insert included content as it was part of your document already (except for the reference resolution)
17:02 <vmassol> tmortagne: there's a problem with the breadcrumb
17:02 <vmassol> for ex: http://extensions.xwiki.org/xwiki/bin/view/Extension/Dashboard+Application
17:03 <vmassol> Extensions is listed twice
17:03 <+tmortagne> vmassol: not exactly
17:03 <vmassol> yes I know
17:03 <vmassol> but still it's not correct
17:04 <+tmortagne> all I can see to fix it is a redirect
17:04 <vmassol> why not change the extensions?
17:04 <vmassol> isn't this what we had before
17:05 <vmassol> parent being set a Main.Webhome
17:05 <vmassol> s/a/as/
17:05 <vmassol> ?
17:05 <vmassol> and when a new extension is created set its parent as Main.WebHome
17:05 <Enygma`> has joined #xwiki
17:05 <vmassol> what redirect do you have in mind?
17:05 <+tmortagne> I try to have code commons to XR and extensions.xwiki.org annd XR home page is Extension.WebHome since it's an extension itseelf
17:06 <vmassol> or
17:06 <vmassol> we change the home page name
17:06 <+tmortagne> yes we can do that
17:07 <vmassol> but since both pages are the same...
17:07 <+tmortagne> nor exactly actually
17:07 <+tmortagne> "Extensions are ways to extend XWiki Enterprise. Select the Extension you wish to install from the list below and then follow the instructions on the extension page to install it in your wiki."
17:08 <+tmortagne> because of "XWiki Enterprise mostly"
17:08 <vmassol> I don't undertand wym
17:08 <+tmortagne> and there could be much more difference that that
17:08 <+tmortagne> things specific to extensions.xwiki.org home page, I don't know
17:09 <+tmortagne> like links to xwiki.org etc
17:09 <+tmortagne> or explaining that you can find extension and documentation for example which does not mak much sense for XR
17:09 <vmassol> well right now they're the same and I don't plan to change it
17:09 <+lucaa> tmortagne: re includes: so context=existing uses the rights of including document, context=new uses the rights of included
17:10 <vmassol> even if you add a few links it'sn ot going to make a big visual difference
17:11 <+tmortagne> lucaa: context=current behave exactly has if the content you ionclude was part of your document (except for the links) and context=new behave has if you where viewing the included content from its own page
17:11 <+lucaa> tmortagne: ok, merci
17:14 <vmassol> tmortagne: how do you plan to handle categories for the EM UI?
17:14 <vmassol> (we have the same need for the feature page of XE for ex)
17:14 <vmassol> (and macros could be handled like this)
17:15 <+tmortagne> vmassol: not much plan since it's not in the model yet but I was thinking of reusing tags as I suggested when we talked about features page
17:15 <vmassol> but tags are not in maven
17:16 <vmassol> so we would also need some custom props for maven right?
17:16 <+tmortagne> there is no concept of category in maven anyway
17:16 <+tmortagne> custom props is easy yes
17:16 <+tmortagne> I'm already using them for some EM things not supported by maven
17:17 <+tmortagne> and plan to add more
17:19 <+tmortagne> (I understood "XR UI" instead of "EM UI" at first)
17:19 <+tmortagne> I don't remember if evalica did a proposal about category in her design already
17:20 <+tmortagne> but from EM point it's only informationnal so it's just a lits of string to display somewhere
17:22 <vmassol> I don't think she's taken that into account… http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ExtensionManagerProposalI3
17:22 <vmassol> however she has different categories in the left menu
17:22 <vmassol> like macros, skins, etc
17:22 <+tmortagne> I see "tags" in her proposal
17:22 <+tmortagne> sounds like the same thing to me
17:23 <+tmortagne> under "ratings"
17:23 <+tmortagne> on the left of the extension description
17:23 <vmassol> yes I see them
17:23 <vmassol> they could finer-grained cateogires indeed
17:24 <vmassol> s/could/could be/
17:24 <vmassol> we probably still need top level categories such as macros, skins, themes, etc
17:25 <+tmortagne> not sure
17:25 <+tmortagne> it make sense to have multiple catagories
17:25 <+tmortagne> a xar extension is often several things, we don't have much wiki macro alone
17:26 <vmassol> in any case the only category she's taken into account so far in her UI are the ones in the left menu
17:27 <vmassol> there's no UI mockup for filtering extensions on other things that I can see
17:27 <+tmortagne> yes the the one on the left are kind of random, they were supposed to be types and she just took what she found on extensions.xwiki.org
17:27 <vmassol> they're not random!
17:27 <vmassol> they 're the ones we had defined
17:27 <vmassol> in any case we need to ask her to work on this I think
17:28 <vmassol> and on our side we need to take it into accoutn too
17:28 <+tmortagne> also mostly depends on what sdumitriu did already
17:30 <vmassol> who knows…. we'll discover that a few days after the release ;)
17:31 <vmassol> (unless sergiu wants to share what he's working on with us before ofc...)
17:33 <vmassol> tmortagne: old extensions have correct breadcrumbs: http://extensions.xwiki.org/xwiki/bin/view/Extension/Sheet+Module Maybe customizing the Extension Template is ok?
17:34 <vmassol> since template is a bit usage-specific
17:34 <+tmortagne> vmassol: I did not modified old extensions parents
17:34 <vmassol> (yes I guessed so)
17:34 <+tmortagne> problem is that template or not it's a page in XR xar so something you have to skip when importing a new version
17:35 <+tmortagne> unless I don't provide any template in XR
17:35 <vmassol> or you provide a default one
17:35 <vmassol> but the XR config has a field to list the template to use
17:36 <vmassol> if not defined the default one is used
17:36 <+tmortagne> hmm
17:36 <vmassol> is that overkill? :)
17:36 <+tmortagne> would need mflorea input on that probably since XR is using old template/sheet system which is not good anyway
17:37 <vmassol> I agree that if we can find a simpler solution it's better
17:37 <+tmortagne> never use the new system yet
17:37 <+tmortagne> with the debate about naming convention etc I'm not sure what is it's current best practice
17:38 <+tmortagne> but as far as I understood either way there is no page based template anymore
17:38 <+mflorea> tmortagne: I haven't followed the discussion. What is the relation between the template you are talking about and the new sheet system?
17:38 <+tmortagne> vmassol: having a configuration is ok, I already created a configuration system for XR so it's just a field to add
17:39 <vmassol> tmortagne: yes but if we can have a XR that fits exactly our need for xwiki.org it's even better
17:39 <+tmortagne> mflorea: mostly the fact that XR should not use template page anyway if it fowwon the new syste, right ?
17:40 <+tmortagne> in fact I don't really know what's the current best practice around tmeplate/sheet when creating a new application
17:41 <+mflorea> no, the new sheet system doesn't eliminate the usage of template, on the contrary, it uses templates. For instance, when you create a new page of a specific type (Blog.BlogPostClass) you need a template specified in the URL in order for the edit action to work properly (i.e. the Inline form to be triggered)
17:41 <+tmortagne> and the issue here is that the defautl extension parent for XR and extensions.xwiki.org are not the same
17:42 <+tmortagne> mflorea: don't you mean sheet ?
17:42 <+mflorea> no, I mean template
17:42 <+mflorea> let me explain
17:43 <+mflorea> the sheet is automatically applied only if there is an object of type T added to the page. But when you create a new page you don't have this object. By specifying the template in the URL, the edit action copies the object from the template to the new page and thus the sheet is applied
17:43 <+tmortagne> ok so it's the same as before
17:44 <+mflorea> wrt templates yes
17:44 <+mflorea> i.e. they serve the same role
17:44 <+tmortagne> ok so sorry for the noise :)
17:44 <+mflorea> np :)
17:45 <+tmortagne> vmassol: issue is that it's not right IMO to have a Main.WebHome page in the XR xar
17:46 <vmassol> yep I agree
17:46 <+tmortagne> i'm ok with the configuration id, it's not very hard to do
17:47 <vmassol> another option is to have a config option for the parent of extensions, defaulting to Extension.WebHome
17:47 <+tmortagne> and there probably a lot more things I could make configurable
17:47 <+tmortagne> vmassol: that's harder
17:47 <vmassol> that allows to reuse the template
17:47 <+tmortagne> because th parent field is not a velocity field
17:47 <+tmortagne> so you can't have a dynamic parent in the template
17:47 <vmassol> the parent is passed in the URL
17:47 <vmassol> when you create a new extension
17:48 <+tmortagne> or this mean you override the template after the creation
17:48 <vmassol> AFAIR
17:48 <+tmortagne> I don't think so, you can maybe override the parent but you put the template in the URL and it's copied as it is AFAIK
17:48 <vmassol> yep
17:48 <vmassol> http://extensions.xwiki.org/xwiki/bin/inline/Extension/sss?parent=Extension.WebHome&template=ExtensionCode.ExtensionTemplate&createExtension=true&name=sss
17:49 <vmassol> (for ex)
17:49 <+tmortagne> but it's not hard to override what's in the template anyway
17:49 <vmassol> so easy to do
17:50 <+tmortagne> yes should be
17:51 <+tmortagne> if it's really taken into account :)
17:51 <vmassol> it is I'm pretty sure
17:51 <@sdumitriu> Hey guys, what's the status for the release? Still waiting for code to stabilize?
17:52 <@sdumitriu> I see lots of problems on ci.xwiki.org
17:52 <+tmortagne> don't think so, I'm working on a bugfix but i can go after the release
17:52 <vmassol> Denis: you're the BM right? :)
17:52 <vmassol> I asked devs here about their status this morning
17:52 <vmassol> but didn't got much answers
17:52 <+Denis> right
17:53 <+Denis> I try to be
17:53 <vmassol> Denis: can we release?
17:53 <vmassol> mflorea: I think you're ok right?
17:53 <+tmortagne> vmassol: did you fixed the test about dashboard refactoring
17:53 <vmassol> hmm what tests tmortagne?
17:53 <+tmortagne> reported by Enygma`IIRW
17:53 <+tmortagne> some page moved or has been renamed and some test count on it
17:53 <vmassol> maybe I missed that because it doesn't ring a bell
17:53 <+tmortagne> or maybe it was mflorea
17:54 <+Denis> not yet, I has to commit my own stuff, and there is some failling tests
17:54 <+Denis> (not mine)
17:54 <+Denis> but I do not know if this is major or not
17:55 <vmassol> hmm btw console output here isn't good re logback :http://ci.xwiki.org/job/xwiki-enterprise-test-ui/org.xwiki.enterprise$xwiki-enterprise-test-ui/595/testReport/org.xwiki.test.ui/AttachmentTest/testUploadDownloadTwoAttachments/
17:55 <+mflorea> vmassol: on the AppWithinMinutes yes. I have some bugs on my list (unrelated to AppWithinMinutes) that I'd like to fix, but they shouldn't postpone the release (i.e. they can make it to 3.3RC1)
17:56 <+mflorea> tmortagne: I can take care of the WYSIWYG tests
17:57 <+tmortagne> mflorea: ok
18:07 <abusenius> has joined #xwiki
18:10 <tmortagne> has quit
18:20 <vmassol> has quit
18:23 <CIA-102> Denis Gervalle feature-immutable-refs * r459c2c3 / xwiki-platform-core/xwiki-platform-model/src/main/java/org/xwiki/model/reference/EntityReference.java : XWIKI-7097 Make EntityReference immutables, adding parameters to EntityReference and allowing Locale and Version in DocumentReference ...
18:23 <CIA-102> Denis Gervalle master * r459c2c3 / xwiki-platform-core/xwiki-platform-model/src/main/java/org/xwiki/model/reference/EntityReference.java : XWIKI-7097 Make EntityReference immutables, adding parameters to EntityReference and allowing Locale and Version in DocumentReference ...
18:23 <CIA-102> Denis Gervalle master * r0edbb5d / (45 files in 19 dirs): XWIKI-7097 Make EntityReference immutables, and add Locale in DocumentReference ...
18:32 <CIA-102> Denis Gervalle master * r1751411 / xwiki-platform-core/xwiki-platform-model/src/main/java/org/xwiki/model/reference/EntityReference.java : XWIKI-7097 Make EntityReference immutables, and add Locale in DocumentReference ...
18:38 <sburjan> has quit
18:44 <mflorea> has quit
18:50 <CIA-102> Eduard Moraru master * rd8c64da / (4 files in 2 dirs): XWIKI-7153 : Don`t use translation keys from dependencies - http://git.io/rSoneQ
19:44 <@sdumitriu> Broken attachment: http://extensions.xwiki.org/xwiki/bin/view/Extension/XSLT+Macro#Attachments
19:45 <@sdumitriu> I wonder what happened
20:14 <lucaa> has quit
20:16 <vmassol> has joined #xwiki
20:29 <vmassol> guys I've analyzed all failing UI tests
20:29 <vmassol> one I've just fixed and the others are caused by thomas' changes
20:29 <vmassol> I've reported them to thomas on skype
20:29 <vmassol> (but he's offline right now, he'll see them tomorrow)
20:30 <CIA-102> Vincent Massol master * r0f66061 / (2 files): Fix test (was having an extra new line) - http://git.io/C1fJQg
20:33 <vmassol> webstandards issues are caused by marius, sending him on skype
20:33 <+Denis> vmassol: hey, you are doing my job, I had plane to do that this evening...
20:33 <+Denis> thanks :)
20:33 <vmassol> ok all reviewed :)
20:34 <vmassol> ah no
20:34 <vmassol> still need to reviex escaping
20:34 <+Denis> I think marius is aware
20:34 <vmassol> same issue it's for marius
20:34 <vmassol> bbl
20:51 <jvdrean> has quit
21:47 <rrodriguez> has joined #xwiki
21:56 <jvdrean> has joined #xwiki
22:16 <vmassol> has quit
22:29 <abusenius> has quit
23:19 <Enygma`> has quit
