Search: concept

{{/version}} = Examples = == Full Examples == * {{scm path="xwiki-platform-core/xwiki-platform-menu/xwiki-platform-menu-test/xwiki-platform-menu-test-docker/src/test/it/org/xwiki/menu/test/ui/MenuIT.java"}}MenuIT{{/scm}} * {{scm path="xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-test/xwiki-platform-mail-test-docker/src/test/it/org/xwiki/mail/test/ui/MailIT.java"}}MailIT{{/scm}} == Example 1: Basic test == {{code language="java"}} @UITest public class SeleniumTest { @Test public void test(XWikiWebDriver driver, TestUtils setup) { driver.get("http://xwiki.org"); assertThat(driver.getTitle(), containsString("XWiki - The Advanced Open Source Enterprise and Application Wiki")); driver.findElement(By.linkText("XWiki's concept")).click(); } } {{/code}} == Example 2: Choosing Container + DB + Browser and versions == {{code language="java"}} @UITest(database = Database.MYSQL, databaseTag = "5", servletEngine = ServletEngine.TOMCAT, servletEngineTag = "8", browser = Browser.CHROME) public class MenuIT ...

09:54 <Denis> for the same reason 09:55 <vmassol> it's your impl that is not going to work 09:55 <vmassol> not the concept 09:55 <vmassol> it just means the impl is not correct 09:55 <Denis> its is for speed and memory 09:55 <vmassol> yes but I doubt that it's a problem 09:55 <Denis> the implementation from Andreas were even worse 09:56 <vmassol> we defiintley need to be able to add and rmoeve rights 09:56 <vmassol> so if the impl cannot do we shouldn't even consider it 09:56 <vmassol> since it's not fulfulling the main reason for the new impl 09:56 <Denis> we could remove rights, but a singe run will keep them 09:56 <vmassol> I'm dispapointed 09:56 <Denis> untill restart 09:57 <vmassol> couldn't you at least keep holes?

09:54 <Denis> for the same reason 09:55 <vmassol> it's your impl that is not going to work 09:55 <vmassol> not the concept 09:55 <vmassol> it just means the impl is not correct 09:55 <Denis> its is for speed and memory 09:55 <vmassol> yes but I doubt that it's a problem 09:55 <Denis> the implementation from Andreas were even worse 09:56 <vmassol> we defiintley need to be able to add and rmoeve rights 09:56 <vmassol> so if the impl cannot do we shouldn't even consider it 09:56 <vmassol> since it's not fulfulling the main reason for the new impl 09:56 <Denis> we could remove rights, but a singe run will keep them 09:56 <vmassol> I'm dispapointed 09:56 <Denis> untill restart 09:57 <vmassol> couldn't you at least keep holes?

14:25 <tmortagne> all you have to do with do the Solr request with a locales which is part of the supported locales 14:26 <tmortagne> locales=en will matches only documents you would see if you have en as current locale 14:27 <tmortagne> the "locales" field contains all the supported locales for which the document is the one to show in the UI 14:28 <tmortagne> the fallback is "calculated" during index basically 14:30 <tmortagne> I initially did this so that the main Solr search would look in all the documents you would see with the current locale instead on only the documents explicitly for the current locale 14:30 <tmortagne> so this field is pretty old 14:31 <mflorea> I know it'old 14:34 <mflorea> I though there could be multiple translations of a doc matched by locales=en, but it's not the case 14:35 <tmortagne> "so this field is pretty old" = might have been broken since it is not used anymore in the main UI but it's what it's supposed to do 14:36 <mflorea> it shouldn't be broken, I don't remember touching it, but indeed the search UI doesn't use it 14:37 <tmortagne> anyway import thing is that the concept already exist and just need to check if it still work and fix it otherwise since that would be a regression 14:37 <mflorea> now, another thing that worries me about Solr is sort and pagination performance.

14:25 <tmortagne> all you have to do with do the Solr request with a locales which is part of the supported locales 14:26 <tmortagne> locales=en will matches only documents you would see if you have en as current locale 14:27 <tmortagne> the "locales" field contains all the supported locales for which the document is the one to show in the UI 14:28 <tmortagne> the fallback is "calculated" during index basically 14:30 <tmortagne> I initially did this so that the main Solr search would look in all the documents you would see with the current locale instead on only the documents explicitly for the current locale 14:30 <tmortagne> so this field is pretty old 14:31 <mflorea> I know it'old 14:34 <mflorea> I though there could be multiple translations of a doc matched by locales=en, but it's not the case 14:35 <tmortagne> "so this field is pretty old" = might have been broken since it is not used anymore in the main UI but it's what it's supposed to do 14:36 <mflorea> it shouldn't be broken, I don't remember touching it, but indeed the search UI doesn't use it 14:37 <tmortagne> anyway import thing is that the concept already exist and just need to check if it still work and fix it otherwise since that would be a regression 14:37 <mflorea> now, another thing that worries me about Solr is sort and pagination performance.

I fear not many people will understand either though 19:00 <vmassol> (this concept of repair and what it means) 19:00 <vmassol> they'll just click on repair when they see it :) 19:00 <tmortagne> that's the plan :) 19:00 <vmassol> hopefully that's good enough and they don't need to understand anything more 19:01 <tmortagne> they have a read message and a button talking about repairing it, I guess it's enough for most user 19:01 <vmassol> ok re revapi we know the problem 19:01 <vmassol> https://github.com/revapi/revapi/issues/36#issuecomment-205890553 19:02 <vmassol> lkrejci: :) 19:02 <vmassol> (thanks for checking this out so quickly btw!

I fear not many people will understand either though 19:00 <vmassol> (this concept of repair and what it means) 19:00 <vmassol> they'll just click on repair when they see it :) 19:00 <tmortagne> that's the plan :) 19:00 <vmassol> hopefully that's good enough and they don't need to understand anything more 19:01 <tmortagne> they have a read message and a button talking about repairing it, I guess it's enough for most user 19:01 <vmassol> ok re revapi we know the problem 19:01 <vmassol> https://github.com/revapi/revapi/issues/36#issuecomment-205890553 19:02 <vmassol> lkrejci: :) 19:02 <vmassol> (thanks for checking this out so quickly btw!

10:41 <vmassol> *injected 10:41 <tmortagne> the role is RenderingContext 10:41 <vmassol> yes with a different role then 10:41 <tmortagne> would be a different context 10:41 <vmassol> AFAICS all the RenderingContext stuff is 6.0 so still unstable 10:41 <tmortagne> different role means different instance 10:41 <Denis1> the mutable aspect of it is not public API 10:42 <vmassol> I know Denis1 but the impl is ugly 10:42 <tmortagne> vmassol: you can propose something else 10:42 <vmassol> yes sure like I have the time to redo eveything Denis did :) 10:43 <vmassol> I don't think the answer is to ask someone finding a problem to redo everything others did :) 10:43 <vmassol> I'm just questioning the need for the cast which IMO is a design smell 10:43 <Denis1> this is the best I could do at the time it has been done, and if you consider that we should get rid of the mutable aspect, I do not see where you have a problem 10:44 <vmassol> what I know is that if I have to design something from scratch I 'll never force c ast 10:44 <vmassol> *cast 10:44 <Denis1> is now known as <Denis> 10:44 <Denis> I do not want to keep a MutableContext in the end 10:44 <vmassol> now I don't know enough about what was done to suggest something ATM 10:44 <Denis> so if you have the time to refactor what need be to get rid of it, go on :) 10:45 <tmortagne> vmassol: the answer is not to just say "that's crap" without any counter proposal, Denis tough a lot about it and did what he could 10:45 <Denis> as you said, I am inheriting of someone else work, and we can always redo what as been done 10:45 <vmassol> what I meant 10:46 <Denis> s/can/can't 10:46 <vmassol> is that this new concept of Rendering Context is new 10:46 <vmassol> still new 10:46 <vmassol> but not for a long time more 10:46 <Denis> the RenderingContext as non-mutable is clean 10:46 <vmassol> (it's going to be out of unstable) 10:46 <Denis> the mutable stuff is internal 10:46 <vmassol> and if we wait too long 10:46 <vmassol> we'll have no options 10:46 <tmortagne> MutableRenderingContext is internal, we can change it anytime we want 10:46 <Denis> we should not be afraid 10:46 <vmassol> you don't understand tmortagne 10:46 <Denis> the dirty aspect has been kept internal 10:46 <vmassol> I'm talking design 10:47 <vmassol> and you're talking impl 10:47 <tmortagne> again what is public is only the read only part and there is no issue there 10:47 <tmortagne> nobody need to cast anything to get the current rendering context properties 10:48 <tmortagne> anything else IS impl so you are talking about impl 10:48 <Denis> the designed aspect is clean Vincent, there is no issue there.

10:41 <vmassol> *injected 10:41 <tmortagne> the role is RenderingContext 10:41 <vmassol> yes with a different role then 10:41 <tmortagne> would be a different context 10:41 <vmassol> AFAICS all the RenderingContext stuff is 6.0 so still unstable 10:41 <tmortagne> different role means different instance 10:41 <Denis1> the mutable aspect of it is not public API 10:42 <vmassol> I know Denis1 but the impl is ugly 10:42 <tmortagne> vmassol: you can propose something else 10:42 <vmassol> yes sure like I have the time to redo eveything Denis did :) 10:43 <vmassol> I don't think the answer is to ask someone finding a problem to redo everything others did :) 10:43 <vmassol> I'm just questioning the need for the cast which IMO is a design smell 10:43 <Denis1> this is the best I could do at the time it has been done, and if you consider that we should get rid of the mutable aspect, I do not see where you have a problem 10:44 <vmassol> what I know is that if I have to design something from scratch I 'll never force c ast 10:44 <vmassol> *cast 10:44 <Denis1> is now known as <Denis> 10:44 <Denis> I do not want to keep a MutableContext in the end 10:44 <vmassol> now I don't know enough about what was done to suggest something ATM 10:44 <Denis> so if you have the time to refactor what need be to get rid of it, go on :) 10:45 <tmortagne> vmassol: the answer is not to just say "that's crap" without any counter proposal, Denis tough a lot about it and did what he could 10:45 <Denis> as you said, I am inheriting of someone else work, and we can always redo what as been done 10:45 <vmassol> what I meant 10:46 <Denis> s/can/can't 10:46 <vmassol> is that this new concept of Rendering Context is new 10:46 <vmassol> still new 10:46 <vmassol> but not for a long time more 10:46 <Denis> the RenderingContext as non-mutable is clean 10:46 <vmassol> (it's going to be out of unstable) 10:46 <Denis> the mutable stuff is internal 10:46 <vmassol> and if we wait too long 10:46 <vmassol> we'll have no options 10:46 <tmortagne> MutableRenderingContext is internal, we can change it anytime we want 10:46 <Denis> we should not be afraid 10:46 <vmassol> you don't understand tmortagne 10:46 <Denis> the dirty aspect has been kept internal 10:46 <vmassol> I'm talking design 10:47 <vmassol> and you're talking impl 10:47 <tmortagne> again what is public is only the read only part and there is no issue there 10:47 <tmortagne> nobody need to cast anything to get the current rendering context properties 10:48 <tmortagne> anything else IS impl so you are talking about impl 10:48 <Denis> the designed aspect is clean Vincent, there is no issue there.

11:47 <vmassol> they're the same, filter will need to call something :) 11:47 <vmassol> (and this something is a servlet) 11:48 <cjd> filter gets called for any connection that comes in, servlet gets called based on web.xml mapping 11:48 <vmassol> nope 11:48 <vmassol> you have a filter mapping 11:48 <cjd> ahh ok 11:48 <vmassol> they're the same 11:48 <vmassol> the only difference is that filters can be chained 11:49 <vmassol> while servlet are the end of the chain if you prefer 11:49 <cjd> One approach to getting rid of the struts/oldcore stuff would be to work our way down from the top 11:49 <cjd> fake the servlet, then fake struts, then fake oldcore 11:50 <cjd> err fake the servlet container 11:50 <vmassol> the approach I'm taking is create parallel paths 11:50 <vmassol> same as I did for Rendering 11:50 <vmassol> ie support several schemes 11:50 <vmassol> - the current url scheme (currently called "standard") 11:50 <vmassol> - any new scheme 11:50 <vmassol> then provide a nicer new scheme 11:50 <vmassol> at some point make it the default 11:51 <cjd> hm 11:51 <vmassol> and move the "standard" one to legacy/retire it 11:51 <cjd> the hard part is creating the correct context/xwikiservletrequest/etc for oldcore to be happy 11:52 <vmassol> sure 11:52 <vmassol> my goal here 11:52 <vmassol> is not to replace oldcore 11:52 <cjd> +1 11:52 <vmassol> it's to replace the front end part of oldcore (ie struts and XWikiACtion) 11:52 <cjd> IMO you pretty much have to live with XWikiAction 11:52 <cjd> but for what we use struts for, we can probably "mock" it 11:53 <vmassol> I don't understand why we'd need to mock struts, I'm going around it, not needing it 11:53 <cjd> because most of /web/ relies on some little stuff that struts does 11:54 <cjd> not really complex stuff to do otherwise, just little annoying stuff that's just enough to break when you remove it 11:54 <cjd> and IMO replacing oldcore/web/ is a lofty ambition 11:55 <cjd> anyway happy to see this old project coming back again 11:56 <vmassol> the only thing that struts provide IMO is the Form classe, i.e. gather url parameters into a java object 11:56 <cjd> /nod 11:56 <vmassol> not very hard to populate them without struts 11:57 <cjd> yeap, that's basically what I'm getting at re "mocking struts" 11:57 <vmassol> ok 12:04 <webczat> I have concept problems with ldap thing. It will have event listeners that modify directory on modification of user documents.

11:47 <vmassol> they're the same, filter will need to call something :) 11:47 <vmassol> (and this something is a servlet) 11:48 <cjd> filter gets called for any connection that comes in, servlet gets called based on web.xml mapping 11:48 <vmassol> nope 11:48 <vmassol> you have a filter mapping 11:48 <cjd> ahh ok 11:48 <vmassol> they're the same 11:48 <vmassol> the only difference is that filters can be chained 11:49 <vmassol> while servlet are the end of the chain if you prefer 11:49 <cjd> One approach to getting rid of the struts/oldcore stuff would be to work our way down from the top 11:49 <cjd> fake the servlet, then fake struts, then fake oldcore 11:50 <cjd> err fake the servlet container 11:50 <vmassol> the approach I'm taking is create parallel paths 11:50 <vmassol> same as I did for Rendering 11:50 <vmassol> ie support several schemes 11:50 <vmassol> - the current url scheme (currently called "standard") 11:50 <vmassol> - any new scheme 11:50 <vmassol> then provide a nicer new scheme 11:50 <vmassol> at some point make it the default 11:51 <cjd> hm 11:51 <vmassol> and move the "standard" one to legacy/retire it 11:51 <cjd> the hard part is creating the correct context/xwikiservletrequest/etc for oldcore to be happy 11:52 <vmassol> sure 11:52 <vmassol> my goal here 11:52 <vmassol> is not to replace oldcore 11:52 <cjd> +1 11:52 <vmassol> it's to replace the front end part of oldcore (ie struts and XWikiACtion) 11:52 <cjd> IMO you pretty much have to live with XWikiAction 11:52 <cjd> but for what we use struts for, we can probably "mock" it 11:53 <vmassol> I don't understand why we'd need to mock struts, I'm going around it, not needing it 11:53 <cjd> because most of /web/ relies on some little stuff that struts does 11:54 <cjd> not really complex stuff to do otherwise, just little annoying stuff that's just enough to break when you remove it 11:54 <cjd> and IMO replacing oldcore/web/ is a lofty ambition 11:55 <cjd> anyway happy to see this old project coming back again 11:56 <vmassol> the only thing that struts provide IMO is the Form classe, i.e. gather url parameters into a java object 11:56 <cjd> /nod 11:56 <vmassol> not very hard to populate them without struts 11:57 <cjd> yeap, that's basically what I'm getting at re "mocking struts" 11:57 <vmassol> ok 12:04 <webczat> I have concept problems with ldap thing. It will have event listeners that modify directory on modification of user documents.

17:07 <vmassol> yes, 99% of api work is about bikeshedding 17:07 <cjd> http://bikeshed.com/ 17:07 <cjd> it's worth a read 17:08 <vmassol> will do but I get the concept 17:08 <cjd> because these kinds of api discussions did a horrific job on the freebsd community 17:08 <vmassol> the problem is when you don't do anything instead of acting 17:08 <cjd> IMO pick something, stick with it enough that a casual user can't spot inconsistancy and ship ship ship :) 17:08 <vmassol> but thinking a bit is not counterproductive IMO 17:09 <vmassol> it must not last too long 17:09 <cjd> in 10 minutes it will have lasted as long as it took to write the patch 17:10 <vmassol> that's not much compared to the cost we will hav eto pay to change the name 17:10 <cjd> a config variable == you don't change it 17:10 <cjd> but if all fsattach is fsattach, store.rdbms is not *obviously* inconsistant 17:12 <vmassol> it wouldn' tbe rdbms, it would be store.rdbmsattach :) 17:12 <cjd> not if we don't do it that way 17:12 <cjd> my point is the users will not notice if we have store.rdbms.someValue 17:12 <cjd> and then on the other side we have store.fsattach.someConfig 17:13 <cjd> nobody is going to notice a thing 17:13 <vmassol> especially since the store module will probably have to go away or be heavily refactored 17:13 <vmassol> since it wasn't coded with the goal of being a replacement to the existing store 17:14 <vmassol> so when we rewrite the existing store, the api will probably be different to take into account all store options 17:14 <vmassol> ok so 17:15 <vmassol> if nobody disagrees with fsattach, we'll keep it and I'll go with the flow, hoping that you'll still be around if we need to change it ;) 17:15 <vmassol> btw this reminds me of a comment from ludovic 17:16 <vmassol> that he would like us to join xwiki.properties and xwiki.cfg 17:16 <cjd> I'd be favorable to that 17:16 <vmassol> because it's too complex for users to have to look at 2 config files 17:16 <cjd> +1 17:16 <vmassol> and now the store config is split in 2 places 17:17 <cjd> Something I've noticed about windows kernel is it's incredibly stupendously well engineered 17:17 <vmassol> so far we tried to have domains defined in either of the 2 files but not in both 17:17 <cjd> designed by people smarter than me, the entire kernel is asynchronous which makes it like the only kernel in the world like that 17:17 <cjd> but writing code to interact with it is impossible 17:18 <cjd> whereas linux is basically a mountain of hacks but they're very fast hacks and writing code for it is really easy because the things you're most likely to do are streamlined 17:18 <cjd> same story with solaris, brilliant beautiful design 17:18 <cjd> takes 200 LoC to open a tun device which can be done in linux with 30 17:19 <cjd> anyway I guess my point is embrase the ugly and make stuff which is really easy to use 17:19 <cjd> :) 17:21 <vmassol> yes sure it really boils down to why you code 17:22 <vmassol> personally I consider it an art and I'm trying to achieve perfection as much as possible 17:22 <cjd> I recognize your position 17:23 <vmassol> of course it's not possible in a not perfect world... 17:23 <vmassol> :) 17:23 <cjd> Do you think I can convince you to read another piece of text when you get a chance?

17:07 <vmassol> yes, 99% of api work is about bikeshedding 17:07 <cjd> http://bikeshed.com/ 17:07 <cjd> it's worth a read 17:08 <vmassol> will do but I get the concept 17:08 <cjd> because these kinds of api discussions did a horrific job on the freebsd community 17:08 <vmassol> the problem is when you don't do anything instead of acting 17:08 <cjd> IMO pick something, stick with it enough that a casual user can't spot inconsistancy and ship ship ship :) 17:08 <vmassol> but thinking a bit is not counterproductive IMO 17:09 <vmassol> it must not last too long 17:09 <cjd> in 10 minutes it will have lasted as long as it took to write the patch 17:10 <vmassol> that's not much compared to the cost we will hav eto pay to change the name 17:10 <cjd> a config variable == you don't change it 17:10 <cjd> but if all fsattach is fsattach, store.rdbms is not *obviously* inconsistant 17:12 <vmassol> it wouldn' tbe rdbms, it would be store.rdbmsattach :) 17:12 <cjd> not if we don't do it that way 17:12 <cjd> my point is the users will not notice if we have store.rdbms.someValue 17:12 <cjd> and then on the other side we have store.fsattach.someConfig 17:13 <cjd> nobody is going to notice a thing 17:13 <vmassol> especially since the store module will probably have to go away or be heavily refactored 17:13 <vmassol> since it wasn't coded with the goal of being a replacement to the existing store 17:14 <vmassol> so when we rewrite the existing store, the api will probably be different to take into account all store options 17:14 <vmassol> ok so 17:15 <vmassol> if nobody disagrees with fsattach, we'll keep it and I'll go with the flow, hoping that you'll still be around if we need to change it ;) 17:15 <vmassol> btw this reminds me of a comment from ludovic 17:16 <vmassol> that he would like us to join xwiki.properties and xwiki.cfg 17:16 <cjd> I'd be favorable to that 17:16 <vmassol> because it's too complex for users to have to look at 2 config files 17:16 <cjd> +1 17:16 <vmassol> and now the store config is split in 2 places 17:17 <cjd> Something I've noticed about windows kernel is it's incredibly stupendously well engineered 17:17 <vmassol> so far we tried to have domains defined in either of the 2 files but not in both 17:17 <cjd> designed by people smarter than me, the entire kernel is asynchronous which makes it like the only kernel in the world like that 17:17 <cjd> but writing code to interact with it is impossible 17:18 <cjd> whereas linux is basically a mountain of hacks but they're very fast hacks and writing code for it is really easy because the things you're most likely to do are streamlined 17:18 <cjd> same story with solaris, brilliant beautiful design 17:18 <cjd> takes 200 LoC to open a tun device which can be done in linux with 30 17:19 <cjd> anyway I guess my point is embrase the ugly and make stuff which is really easy to use 17:19 <cjd> :) 17:21 <vmassol> yes sure it really boils down to why you code 17:22 <vmassol> personally I consider it an art and I'm trying to achieve perfection as much as possible 17:22 <cjd> I recognize your position 17:23 <vmassol> of course it's not possible in a not perfect world... 17:23 <vmassol> :) 17:23 <cjd> Do you think I can convince you to read another piece of text when you get a chance?

19:01 <vmassol> or that comments = xobjects 19:01 <vmassol> etc 19:01 <vmassol> sure, we're talking about NS here not ND 19:02 <vmassol> (create space will not exist by default anymore in ND) 19:03 <OSIMasson> has quit 19:04 <vmassol> "Note that even though we'll remove the Add > Space menu entry in Flamingo, we should still probably continue supporting the create space template action for extension that might call it or simply for other skins which might want to create spaces since the Space concept still exist at the model level." 19:04 <vmassol> so in the default UI we won't see create space 19:07 <vmassol> so to summarize, the fact that a space is implemented as a page should remain an implementation details for me and not exposed in the UI as much as possible. 19:09 <vmassol> (Enygma`) 19:09 <Enygma`> so basically you are proposing that we use a parallel set of labels to apply in this case to the create UI 19:09 <vmassol> yes 19:09 <vmassol> and a different ui 19:10 <vmassol> there are commo parts but they're different uis 19:10 <Enygma`> why?

19:01 <vmassol> or that comments = xobjects 19:01 <vmassol> etc 19:01 <vmassol> sure, we're talking about NS here not ND 19:02 <vmassol> (create space will not exist by default anymore in ND) 19:03 <OSIMasson> has quit 19:04 <vmassol> "Note that even though we'll remove the Add > Space menu entry in Flamingo, we should still probably continue supporting the create space template action for extension that might call it or simply for other skins which might want to create spaces since the Space concept still exist at the model level." 19:04 <vmassol> so in the default UI we won't see create space 19:07 <vmassol> so to summarize, the fact that a space is implemented as a page should remain an implementation details for me and not exposed in the UI as much as possible. 19:09 <vmassol> (Enygma`) 19:09 <Enygma`> so basically you are proposing that we use a parallel set of labels to apply in this case to the create UI 19:09 <vmassol> yes 19:09 <vmassol> and a different ui 19:10 <vmassol> there are commo parts but they're different uis 19:10 <Enygma`> why?

13:58 <msmeria> for ex. "0 Document(s) installed" 13:58 <tmortagne> you get that message because the UI is looking at old packager for imported document and can't find any 13:58 <tmortagne> the refactoring is not complete yet 13:58 <tmortagne> that's what it's not by default 13:58 <msmeria> I see 13:59 <tmortagne> see jira.xwiki.org/browse/XWIKI-9720 for the list of known limitations 13:59 <tmortagne> in this case it's "the report is directly gathered from PackageAPI" 14:00 <msmeria> yep. got it. thanks for the clarification 14:00 <tmortagne> since it was in blue I did not even seen its was written as an error 14:01 <tmortagne> evalica: the concept of bundled extension does not really exist in XWiki Repository, it's a xwiki.org customization 14:02 <tmortagne> it does not really make sense at generic repository application level 14:02 <evalica> the repository Application equals 'Repository' component?

13:58 <msmeria> for ex. "0 Document(s) installed" 13:58 <tmortagne> you get that message because the UI is looking at old packager for imported document and can't find any 13:58 <tmortagne> the refactoring is not complete yet 13:58 <tmortagne> that's what it's not by default 13:58 <msmeria> I see 13:59 <tmortagne> see jira.xwiki.org/browse/XWIKI-9720 for the list of known limitations 13:59 <tmortagne> in this case it's "the report is directly gathered from PackageAPI" 14:00 <msmeria> yep. got it. thanks for the clarification 14:00 <tmortagne> since it was in blue I did not even seen its was written as an error 14:01 <tmortagne> evalica: the concept of bundled extension does not really exist in XWiki Repository, it's a xwiki.org customization 14:02 <tmortagne> it does not really make sense at generic repository application level 14:02 <evalica> the repository Application equals 'Repository' component?

08:12 <vmassol> no 08:12 <mflorea> :( 08:12 <vmassol> there's no text format with the locale 08:12 <vmassol> doesn't exist 08:12 <vmassol> the concept of locale currently only exists at the Java Object level 08:12 <vmassol> (ie DocumentReference) 08:12 <mflorea> so if I want to target a specific locale with a request I have to send to parameters, the document reference and the locale 08:13 <vmassol> yes 08:13 <vmassol> or 08:13 <vmassol> you create the DocumentReferene 08:13 <vmassol> and add the locale 08:13 <vmassol> that's hte best actually 08:13 <vmassol> and is what we do in other places 08:13 <mflorea> and?

08:12 <vmassol> no 08:12 <mflorea> :( 08:12 <vmassol> there's no text format with the locale 08:12 <vmassol> doesn't exist 08:12 <vmassol> the concept of locale currently only exists at the Java Object level 08:12 <vmassol> (ie DocumentReference) 08:12 <mflorea> so if I want to target a specific locale with a request I have to send to parameters, the document reference and the locale 08:13 <vmassol> yes 08:13 <vmassol> or 08:13 <vmassol> you create the DocumentReferene 08:13 <vmassol> and add the locale 08:13 <vmassol> that's hte best actually 08:13 <vmassol> and is what we do in other places 08:13 <mflorea> and?