IRC Archive for channel #xwiki on 31 January 2012

00:14 <rrodriguez> has quit
00:15 <helge> @sdumitriu: Hi Dumitriu, any news from the debugging side? Thanks, Helge
00:15 <@sdumitriu> Not yet
00:18 <helge> All right. Just in case: If I would set up a new install of XE 3.4 wit Posgres, would you recomend to apply the patch you told me previously or should it just work fine without i it was not a migration?
00:18 <@sdumitriu> It should work fine without it
00:19 <helge> should read "if it was not"
00:23 <helge> Ok, good to know. I would probably just make a new install then, if no one else is facing this problem. I do not have too many pages yet and can transfer them copy-paste wise.
00:23 <@sdumitriu> It should work with a XAR export+import, if you run a 3.1 version on the old database
00:24 <helge> But I shall do it without history, right?
00:25 <@sdumitriu> Depends, with history it will require more resources (RAM), so it depends how much you want to keep it
00:27 <helge> Well, I would like to keep it, if possible. So you think migrating the database would break it but xar import-export would not?
00:34 <@sdumitriu> Exactly
00:34 <@sdumitriu> Or, you could try to manually migrate the database
00:34 <@sdumitriu> You'd have to set up a 3.4 instance on a new database, and see what's the table structure that gets generated
00:34 <@sdumitriu> And then compare it to the existing one
00:35 <@sdumitriu> And see if there are any differences
00:40 <helge> ok, I guess I'll try the xar-way first and find out if I have enough RAM. Thank you again for helping, I do highliy appreciate that.
00:42 <helge> And I like you porject. Congratulations to what you achieved so far!
00:42 <@sdumitriu> Thanks!
00:44 <@sdumitriu> Sorry for the mess, we did a rewrite of the database mapping files to have them more up to date with the current Hibernate standards, and this required some backwards incompatible changes
00:51 <helge> All right, I guess you can't get away from that 100%. I will set it up again and probably not touch it for long time, then.
00:51 <SvenDowideit> has quit
00:51 <SvenDowideit> has joined #xwiki
00:53 <helge> It's late where I am, so I am out. Cheers, Helge.
00:53 <@sdumitriu> Bye Helge
00:53 <@sdumitriu> Thanks for your patience
00:54 <helge> has quit
01:03 <tekzilla> has quit
01:05 <tekzilla> has joined #xwiki
01:08 <Enygma`> has quit
01:22 <sburjan_> has joined #xwiki
01:26 <sburjan`> has quit
01:26 <sburjan_> is now known as <sburjan`>
03:24 <sdumitriu> has quit
03:24 <xipe_> has quit
03:24 <CIA-32> has quit
03:25 <xipe_> has joined #xwiki
03:26 <sdumitriu> has joined #xwiki
03:26 <CIA-85> has joined #xwiki
03:27 <rrodriguez> has joined #xwiki
03:39 <rrodriguez> has quit
06:00 <Denis1> has joined #xwiki
06:02 <Denis> has quit
06:09 <sdumitriu> has quit
06:45 <sburjan`> has quit
06:45 <sburjan`> has joined #xwiki
06:48 <DrLou_> has quit
07:49 <vmassol> has joined #xwiki
08:47 <Enygma`> has joined #xwiki
09:14 <tmortagne> has joined #xwiki
09:15 <gdelhumeau> has joined #xwiki
09:56 <rrodriguez> has joined #xwiki
10:01 <rrodriguez> has quit
10:13 <jvdrean> has joined #xwiki
10:15 <evalica> has joined #xwiki
10:30 <sburjan> has joined #xwiki
10:44 <vmassol> tmortagne: we might to change again the text when the plugin will be able to be downloaded
10:44 <vmassol> *might need
10:45 <+tmortagne> yep but we should probably improve the plugin text to get the class and id somewhere to put the proper text from the start instead of having to indicate what to replace in the custom instructions
10:45 <vmassol> yes not sure how to do that though
10:46 <+tmortagne> some plugin related object I would say
10:46 <vmassol> unless we add a new xclass for plugins
10:48 <vmassol> or unless we invent a system where the standard instuctions can contain variables and for each variable used we display a form in the UI for the user to set its value and we store that value in some generic xobjects…. that seems a bit complex ;)
10:49 <vmassol> the plugin xobject should be good enough since it's a deprecated technology
10:49 <+tmortagne> yep
10:58 <CIA-85> Vincent Massol master * r7abe753 / xwiki-enterprise-test/xwiki-enterprise-test-ui/src/test/it/org/xwiki/test/ui/xe/AllDocsTest.java : XWIKI-7421: Add new Index Module ...
10:58 <CIA-85> Vincent Massol master * rcf06373 / xwiki-enterprise-ui/src/main/resources/XWiki/AttachmentSelector.xml : XE-1104: XWiki.AttachmentSelector page has a wrong title - http://git.io/45gWFw
11:21 <CIA-85> tmortagne master * r2150f69 / (3 files in 2 dirs): XWIKI-7164: ConfigurationSource#getProperty(propertyName, defaultValue) ...
11:24 <CIA-85> tmortagne master * r2e0c7e2 / xwiki-platform-core/xwiki-platform-configuration/xwiki-platform-configuration-default/src/test/java/org/xwiki/configuration/internal/CommonsConfigurationSourceTest.java : XWIKI-7164: ConfigurationSource#getProperty(propertyName, defaultValue) ...
11:32 <+jvdrean> Hi, I'm still upgrading an app based on XE from 3.1.1 to 3.3.1, I get 2 jars
11:32 <+jvdrean> xwiki-platform-legacy-oldcore-3.3.1.jar
11:32 <+jvdrean> xwiki-platform-oldcore-3.3.1-cloud.jar
11:33 <+jvdrean> what's the difference between them ?
11:33 <vmassol> the legacy one adds legacy apis
11:33 <vmassol> (ie deprecated apis)
11:33 <vmassol> it's a superset of oldcore
11:34 <+jvdrean> ok, so we get a lot of duplicates, right ?
11:34 <vmassol> thus you only need the legacy one if you want to have the deprecated apis
11:34 <vmassol> it's fully duplicated
11:34 <vmassol> you should never have both
11:34 <vmassol> it's one or the other
11:34 <+jvdrean> XE war has both
11:34 <+jvdrean> xwiki-platform-legacy-oldcore-3.5-20120130.114114-45.jar
11:34 <+jvdrean> xwiki-platform-oldcore-3.5-20120130.112558-52.jar
11:34 <+tmortagne> jvdrean: you sure ?
11:34 <+jvdrean> fresh trunk build
11:34 <+tmortagne> it's not supposed to
11:35 <+tmortagne> you seen then in the war package ?
11:35 <+tmortagne> or it's because you get it in yours ?
11:36 <+jvdrean> [jv:~/Dev/xwiki.org/xwiki-enterprise/xwiki-enterprise-web/target/xwiki-enterprise-web-3.5-SNAPSHOT/WEB-INF/lib]$ ls | grep oldcore
11:36 <+jvdrean> xwiki-platform-legacy-oldcore-3.5-20120130.114114-45.jar
11:36 <+jvdrean> xwiki-platform-oldcore-3.5-20120130.112558-52.jar
11:36 <+tmortagne> that's a bug then and a pretty recent one since there used to be only one for sure
11:36 <+jvdrean> since CLI is worth a thousand words :)
11:36 <+tmortagne> or maybe it's a snapshot thing
11:36 <+jvdrean> I'm downloading xe's war from our repo to see what's inside
11:37 <+jvdrean> (3.1.1 release)
11:37 <+tmortagne> looking at 3.4
11:37 <+jvdrean> 3.3.1
11:39 <+tmortagne> http://maven.xwiki.org/snapshots/org/xwiki/enterprise/xwiki-enterprise-web/3.5-SNAPSHOT/xwiki-enterprise-web-3.5-20120131.100048-36.war
11:39 <+tmortagne> can't find oldcore in there
11:39 <+jvdrean> [jv:~/Dev/tmp]$ unzip -l xwiki-enterprise-web-3.3.1.war | grep oldcore
11:39 <+jvdrean>   2644758  01-17-12 09:17   WEB-INF/lib/xwiki-platform-legacy-oldcore-3.3.1.jar
11:39 <+jvdrean> indeed the released war is fine, something is wrong in my build
11:39 <+tmortagne> so looks like it's not in a war built by jenkins
11:47 <+tmortagne> looks like xwiki-enterprise-test-ui get stuck pretty often if not all the time
11:47 <+tmortagne> vmassol: din't we used the have the issue in the past ?
11:47 <vmassol> not sure, we had some many in the past that i don't recall
11:48 <vmassol> for sure it used to get stuck
11:48 <vmassol> I fixed those issues though
11:48 <vmassol> (they were in webdriver when calling findElements() under some conditions)
11:50 <+tmortagne> will need to find exactly what is stuck
11:50 <+tmortagne> I have to go, back in 2h, will check that after
12:29 <CIA-85> Vincent Massol master * r76828ab / (9 files in 7 dirs): XWIKI-7473: Add new Zip Explorer Module - http://git.io/rRoQzg
12:29 <CIA-85> Vincent Massol master * r5a73ecb / xwiki-enterprise-web/pom.xml : XWIKI-7473: Add new Zip Explorer Module - http://git.io/O6RwzQ
14:02 <vmassol> cjd: hi. Would yuo say "Specifies whether the script output contains wiki markup" or "Specifies if the script output contains wiki markup". For me if we use "whether" then we need to end with "or not". Wdyt?
14:03 <@cjd> Specifies whether the script output contains wiki markup <-- is better
14:03 <@cjd> Specifies or not whether the script output contains wiki markup <-- is even better
14:03 <@cjd> err
14:03 <@cjd> Specifies whether or not the script output contains wiki markup   :)
14:03 <vmassol> if thought that using "if" would allow to drop the "or not"
14:04 <@cjd> Specifies if  the script output contains wiki markup <-- sounds wrong
14:04 <vmassol> ok I'll use "whether" with "or not", thanks
14:09 <CIA-85> Vincent Massol master * re7f3798 / xwiki-platform-core/xwiki-platform-rendering/xwiki-platform-rendering-macros/xwiki-platform-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/ScriptMacroParameters.java : [Misc] Try to improve description for the "wiki" parameter ...
14:09 <CIA-85> Vincent Massol master * r940ad82 / (2 files in 2 dirs): [Misc] Try to improve description for the "wiki" parameter ...
14:22 <sburjan> has quit
14:23 <sburjan> has joined #xwiki
14:23 <CIA-85> Denis Gervalle feature-security-authorization * r848d7ec / xwiki-platform-core/xwiki-platform-security/xwiki-platform-security-api/src/main/java/org/xwiki/security/authorization/DefaultAuthorizationManager.java : Fix an NPE during logging of deny access for a null right. - http://git.io/feLbsw
14:23 <CIA-85> Denis Gervalle feature-security-authorization * r1dece7d / (20 files in 7 dirs): Use Set in place of List in RightDescription to allow proper equality. ...
14:34 <DrLou_> has joined #xwiki
14:40 <+Enygma`> Hi. I`m curious about something: When you have a component (or worse, a plugin that you want to convert to components) that has methods like getSomething(String documentName, param1, XWikiContext context), can you refactor it to get rid of the context parameter by using an @Inject Execution instead and getting the XWikiContext from the Execution whenever you need it?
14:41 <+Enygma`> is the XWikiContext retrieved from the Execution the one corresponding to the current call context or is it a cached one that was assigned at component initialization time?
14:42 <+tmortagne> Enygma`: it's supposed to be the same
14:42 <+tmortagne> unless some code create a special context to give it in parameter of course
14:42 <+tmortagne> so in theory yes you can refactor it all using ExecutionContext which is how most of the components are working
14:43 <+Enygma`> the main issue is: how will documentName be resolved if you`r in a multiwiki environment and documentName is a relative?
14:43 <+Enygma`> does it deppend from the context where the call is made?
14:44 <+tmortagne> Enygma`: you can use DocumentReferenceResolver with hint "current" for this kind of use case
14:45 <+Enygma`> well, I want to catch both cases: when the documentName si both relative and absolute
14:46 <+Enygma`> so, in any case, the idea is that doing what I described is safe and recommended, right?
14:57 <+sburjan> guys, I can't see any link to download XEM/Workspaces on our download page. is this intended ? http://enterprise.xwiki.org/xwiki/bin/view/Main/Download I also see that this redirects to enterprise. I'm not sure this is ok
14:59 <vmassol> sburjan: the link you gave is for XE
15:00 <vmassol> (it also contains links to other projects below)
15:00 <vmassol> (in the other downloads section)
15:00 <vmassol> personally i don't like too much this download page (I don't find it easy to read - evalica)
15:01 <+tmortagne> Enygma`: DocumentReferenceResolver will work with both relative and absolute reference, that's its job
15:02 <+tmortagne> it's here so that you don't have to worry and always get an absolute reference
15:02 <+sburjan> I guess XE is our flag product, so that is advertized in the first place. We have a hierarchical structure. As we advertise, XE is flag product, other are seconday
15:02 <+Enygma`> tmortagne: ok, thanks
15:04 <+tmortagne> and about ExecutionContext, yes you can safely use it that's the way all our API is going so if there is an issue your not going to be alone ;)
15:12 <sdumitriu> has joined #xwiki
15:18 <+tmortagne> did not planned to import that much actually
15:18 <+tmortagne> had to import twice
15:21 <vmassol> tmortagne: I don't think non admins should see the "import extension" part
15:21 <+tmortagne> vmassol: did not tough much about it actually
15:22 <+tmortagne> but not sure about that, some contrib extensions author could need to import their extension
15:27 <vmassol> tmortagne: I'm 100% sure non admins shouldn't see it for e.x.o
15:27 <vmassol> (it's too technical)
15:28 <+tmortagne> but how would contrib developer would import a extension ?
15:28 <+tmortagne> ask an admin ?
15:28 <vmassol> they do it like they do now
15:28 <vmassol> create a wiki page
15:28 <+tmortagne> I mean someone who have a contrib extension on the maven repository
15:28 <+tmortagne> same as us
15:29 <vmassol> what we could do is have a link in the "add extension" screen
15:29 <vmassol> what I don't like is that big box on the e.x.o home page
15:30 <+tmortagne> sure we can improve the design I just added what was needed for the feature here
15:30 <vmassol> FTM I'd rather keep this on a separate page and direct people who as to that page
15:30 <vmassol> s/who as/who ask/
15:31 <vmassol> 99% of contributors will use the standard way and contrib users can ask on the list or irc/mails
15:32 <+tmortagne> sure, finishing upgrade first
15:33 <sburjan> has quit
15:41 <+tmortagne> restarting xwiki.org (to install XR jar)
15:43 <xwikibot> has joined #xwiki
15:46 <xwikibot> has joined #xwiki
15:51 <+tmortagne> looks like we have a general issue with REST on xwiki.org, http://www.xwiki.org/xwiki/rest/ does not work
15:51 <vmassol> indeed
15:52 <@sdumitriu> Weird, jumptopage works
15:52 <@sdumitriu> So at least some part of rest works
15:52 <+tmortagne> looks like only the rest service returning custom object don't work
15:52 <+tmortagne> service returning string or standard response are working as far as I can see
15:53 <+tmortagne> so we have some issue with jaxb objects
15:53 <@sdumitriu> At least it's not 404 anymore, but 500
15:54 <+tmortagne> yep it's an error
15:54 <+tmortagne> WARNING: No message body writer found for class class org.xwiki.rest.model.jaxb.Xwiki, genericType class org.xwiki.rest.model.jaxb.Xwiki; response media type should be: text/html; accepted media types are: [[text/html, application/xhtml+xml], [application/xml], [*/*]]
15:54 <+tmortagne> this one
15:54 <@sdumitriu> It might work with application/json
15:54 <+tmortagne> looks like restlet try to return html by default and can't find converter for html mime type
15:55 <+tmortagne> yep it should work if the client specify explicitely the mime type
15:55 <+tmortagne> like application/json or application/xml
15:55 <+tmortagne> so should be ok for most use case except for the browser
15:55 <vmassol> looks like a regression
15:56 <vmassol> works in 3.2 for sure: http://myxwiki.org/xwiki/rest
15:56 <+tmortagne> but not very handy
15:56 <+tmortagne> probably caused by the upgrade
15:56 <+tmortagne> to restlet 2
15:56 <@sdumitriu> Works with Accept: */*
15:56 <vmassol> tested on 3.3 and it works too
15:56 <vmassol> so must be a regression introduced in 3.4
15:56 <+tmortagne> restlet has been upgraded in 3.4
15:57 <vmassol> yes that's bad
15:57 <vmassol> introduced in 3.4 RC1
15:57 <vmassol> at the last moment
15:57 <vmassol> http://jira.xwiki.org/jira/browse/XWIKI-7407
15:57 <+tmortagne> we did not seen it because all our test set the mime type
15:57 <+tmortagne> so we would need some simple browser test to check that
15:58 <vmassol> there's another issue for the upgrade: http://jira.xwiki.org/jira/browse/XWIKI-6632
15:58 <+tmortagne>  XWIKI-7407 is just a minor upgrade
16:07 <mflorea> has joined #xwiki
16:29 <+tmortagne> vmassol: http://extensions.xwiki.org/xwiki/bin/view/ExtensionCode/ImportExtension
16:29 <vmassol> cool
16:29 <+tmortagne> just updated http://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki+Manager+Application, looks like there is a bug with the last version
16:29 <+tmortagne> looking at it
16:29 <+tmortagne> but appart from this all is there
16:29 <vmassol> we'll need to decide how we want to display the import feature in the XR app
16:30 <vmassol> tmortagne: k I'll let you import one extension frist before trying it :)
16:30 <+tmortagne> vmassol: (04:30:22 PM) tmortagne: just updated http://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki+Manager+Application, looks like there is a bug with the last version
16:30 <+tmortagne> already did :)
16:31 <vmassol> a bug with what?
16:31 <+tmortagne> the latest version is not imported it seems
16:31 <+tmortagne> so we don't have 3.4 in the result
16:31 <+tmortagne> checking why
16:31 <vmassol> ok
16:31 <vmassol> hmm
16:31 <vmassol> why was the page title modified?
16:31 <vmassol> I think we shouldn't modify it if it exists
16:32 <+tmortagne> the name changed actually, it's the reference extension name
16:32 <+tmortagne> the description does not change, same for the summary but I though the reference extension name should be seen as the right one in theory
16:33 <vmassol> well we need to find a solution for this
16:33 <vmassol> because right now the name is less good than what we had I think
16:33 <+tmortagne> if the name is not right we should probably change it in maven
16:33 <vmassol> it's not necessarily the same rule
16:33 <vmassol> but yes we can discuss this
16:33 <vmassol> we have a new "Dependencies" section, cool
16:34 <+tmortagne> it's not new :)
16:34 <vmassol> does it link to the extension page too?
16:34 <+tmortagne> it's just that the dependency was never provided
16:34 <+tmortagne> yes it does (and did)
16:34 <vmassol> (if the page exists)
16:34 <vmassol> hmm I don't understand the website information
16:35 <+tmortagne> it's the one XR found in the Extension object
16:35 <+tmortagne> it's the one generated by maven in that case
16:35 <vmassol> we probably shouldn't display it on e.x.o
16:35 <vmassol> since the website is supposed to be the page itself
16:37 <vmassol> tmortagne: can we restrict how many versions we import?
16:37 <vmassol> btw you need to remove the first version object ;)
16:37 <+tmortagne> it's not un the script service API but it would be easy to add
16:38 <+tmortagne> vmassol: I think this object is part of the bug with the last version, it's supposed to be removed
16:38 <vmassol> ok
16:38 <vmassol> according to our rule we should only keep the last 2 releases for the version I think
16:38 <+tmortagne> not 2 release actually
16:38 <+tmortagne> 2 branches
16:39 <+tmortagne> but we can decide to import only stable versions
16:39 <vmassol> actually why do we need to keep anything more than the last version?
16:39 <+tmortagne> right now there is not much filtering
16:40 <vmassol> the other versions are in maven repos
16:40 <vmassol> it's just for the EM search right?
16:40 <vmassol> (till we support maven indexing)
16:40 <+tmortagne> well you don't always are on the lastest XE version and sometime you can't install the last version
16:40 <vmassol> sure but they're avail in maven repos
16:40 <vmassol> they don't have to be on e.x.o
16:41 <+tmortagne> then you have to know the id and the version you want to install it from maven repository right now
16:41 <vmassol> actually in theory we don't need any version on e.x.o … :)
16:41 <vmassol> yes because we cannot search in maven repos yet
16:41 <+tmortagne> it depends how you see e.x.o
16:41 <+tmortagne> if it's just here as a documentation we don't really need to import anything...
16:41 <vmassol> if the search was working across XR repos we would get dups
17:14 <CIA-85> tmortagne master * rd4fee38 / xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-repositories/xwiki-platform-extension-repository-aether/src/main/java/org/xwiki/extension/repository/aether/internal/AetherExtensionRepository.java : XWIKI-7474: Aether based implementation of resolveVersions does not ...
17:14 <CIA-85> tmortagne master * r6c3d150 / xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-repositories/xwiki-platform-extension-repository-xwiki/xwiki-platform-extension-repository-xwiki-server-api/src/main/java/org/xwiki/extension/repository/xwiki/internal/DefaultRepositoryManager.java : XWIKI-7475: Extension import resolve several times the last version - http://git.io/Pr4wIQ
18:05 <gdelhumeau> has quit
18:11 <jvdrean> has quit
18:18 <npm_> has joined #xwiki
18:20 <tekzilla_> has joined #xwiki
18:24 <tekzilla> has quit
18:24 <npm> has quit
18:30 <npm_> is now known as <npm>
19:28 <+tmortagne> restarting xwiki.org
19:30 <xwikibot> has joined #xwiki
19:46 <abusenius> has joined #xwiki
20:20 <tmortagne> has quit
21:55 <CIA-85> Marius Dumitru Florea master * r4c6dbda / (3 files in 3 dirs): XWIKI-7476: Sheets need to be able to display the title of the document they are applied to ...
21:57 <CIA-85> Marius Dumitru Florea master * r118a756 / (2 files): XE-1105: Default class sheet does't display correctly the class title ...
22:33 <rrodriguez> has joined #xwiki
22:54 <evalica> has quit
23:09 <npm> has quit
23:16 <npm> has joined #xwiki
23:38 <vmassol> has quit
23:56 <xwikibot> has joined #xwiki