IRC Archive for channel #xwiki

00:02 <sdumitriu> has quit
00:04 <Menso> Anyone still up? :-)
00:15 <+sburjan`> Menso, but not for long :)
00:18 <Menso> ah :-)
00:18 <Menso> I wrote some code in 2.5 and put it in a 2.4 wiki of the customer, now running into issue
00:20 <sdumitriu> has joined #xwiki
00:33 <rrodriguez> has quit
00:38 <rrodriguez> has joined #xwiki
00:43 <rrodriguez> has quit
02:38 <florinciu> has quit
03:57 <sdumitriu> has quit
04:12 <abusenius> has quit
04:19 <SvenDowideit_> has joined #xwiki
04:19 <SvenDowideit> has quit
04:23 <Sashi> has joined #xwiki
04:23 <Sashi> what am i doing wrong here? I got xwiki running on tomcat on 8180 port, installed nginx to proxy forward it to port 8180.. all my images are broken now if i forward it to :8180/xwiki/
04:24 <Sashi> works fine if i have nginx do just port 8180 but i woud like to get it to foward it to xwiki
04:49 <SvenDowideit_> has quit
05:01 <SvenDowideit> has joined #xwiki
05:02 <SvenDowideit> has quit
05:38 <SvenDowideit> has joined #xwiki
05:44 <SvenDowideit> has quit
05:44 <SvenDowideit> has joined #xwiki
05:49 <SvenDowideit> has quit
05:49 <SvenDowideit_> has joined #xwiki
06:04 <Denis> has quit
06:09 <Denis> has joined #xwiki
06:13 <+sburjan`> .
06:15 <sburjan`> has quit
06:16 <sburjan`> has joined #xwiki
06:37 <venkatna> has joined #xwiki
06:40 <venkatna> has quit
06:47 <@cjdelisle`> ..
06:50 <rrodriguez> has joined #xwiki
07:35 <mflorea> has joined #xwiki
08:01 <SvenDowideit_> has quit
08:01 <SvenDowideit_> has joined #xwiki
08:01 <SvenDowideit_> is now known as <SvenDowideit>
08:17 <vmassol> has joined #xwiki
08:42 <jstoldt> has joined #xwiki
08:44 <jstoldt> good morning everybody
08:48 <@cjdelisle`> good morning.
08:48 <vmassol> good morning
08:49 <vmassol> cjdelisle`: how are you?
08:49 <@cjdelisle`> Doing pretty well.
08:49 <@cjdelisle`> Sorry for being a bit removed.
08:49 <vmassol> just wanted to check with you about the 3.0 roadmap and whether you'd be ok to finish your work on the attachment storage for 3.0?
08:49 <vmassol> (if you could reply to the roadmap email that would be great)
08:49 <@cjdelisle`> I have attachment storage finished. I'm working on attachment versioning.
08:50 <vmassol> I'm trying to gather what everyone is planning to do for 3.0
08:50 <vmassol> to provide visibility to others
08:50 <@cjdelisle`> If no major obstacles then it will be finished.
08:50 <vmassol> cjdelisle`: great, could you reply to the mail with what you intend to do?
08:51 <@cjdelisle`> Will do. WDYT about my deprecation/removal proposal?
08:51 <vmassol> hehe…. I need to dig it up from the tons of unanswerd mail I have
08:51 <vmassol> can you remind me the title?
08:51 <@cjdelisle`> Just sent this morning so it should be at the top.
08:51 <vmassol> oh
08:51 <@cjdelisle`> [proposal] Deprecate XWikiAttachmentArchive#getArchive() and setArchive() and remove and make private deprecated methods in XHS
08:52 <vmassol> indeed I can see it
08:52 <vmassol> not read that far my emails yet
08:52 <vmassol> :)
08:52 <vmassol> nice trick
08:53 <jstoldt> lol
08:53 <jstoldt> n1
08:53 <@cjdelisle`> That stuff should be no big deal. HibernateStore stuff is very old and unused.
08:53 <@cjdelisle`> AttachmentAtchive stuff is RCS implementation bound.
08:56 <Denis> has quit
08:57 <jvelo> has joined #xwiki
09:01 <vmassol> cjdelisle`: answered
09:01 <@cjdelisle`> thanks.
09:02 <rrodriguez> has quit
09:08 <jvdrean> has joined #xwiki
09:14 <jvelo> has quit
09:16 <tmortagne> has joined #xwiki
09:16 <sabageru> has joined #xwiki
09:20 <vmassol> guys we have the following when going to the main page:
09:20 <vmassol> 2010-12-16 09:19:52,876 [http://localhost:8080/xwiki/bin/view/Main/] ERROR internal.DefaultVelocityEngine  - Left side ($pages.size()) of '>' operation has null value at unknown namespace[line 643, column 21]
09:21 <vmassol> trying to find where it's coming from
09:21 <vmassol> I thought it was informationinline.vm but apparenrtly it's not
09:25 <vmassol> tmortagne: we still have this message (I guess it's in 2.7 too):
09:25 <vmassol> SLF4J: The requested version 1.5.8 by your slf4j binding is not compatible with [1.5.5, 1.5.6]
09:25 <vmassol> SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for further details.
09:26 <vmassol> it's not very nice for users
09:26 <vmassol> could it be coming from the extension manager?
09:26 <+tmortagne> it's not extension manager, it's SLF4J
09:27 <vmassol> ah you're in a joking form today cool
09:27 <sburjan> has joined #xwiki
09:27 <+tmortagne> the message is pretty clear IMO, we don't have proper implementation vs API  of SLF4J for some reason
09:27 <vmassol> :)
09:28 <vmassol> let me try to imitate you… it's not coming from SLF4J, it's coming from a class in the slf4j library
09:28 <vmassol> sigh
09:29 <vmassol> so let me repeat my qeustion
09:29 <vmassol> with more words....
09:29 <vmassol> is this error coming from the fact that the extension manager transitively depends on slf4j somewhere?
09:30 <+tmortagne> it could but again IMO extension manager or any other the fix is probably to use last version of SLF4J implementation
09:30 <vmassol> and it looks like a conflict to me, by different versions of slf4j
09:30 <vmassol> api vs binding
09:30 <+tmortagne> yes different version of API and implem
09:31 <vmassol> not matching
09:31 <vmassol> in any case
09:31 <vmassol> it wasn't there before the extension manager
09:31 <vmassol> and now it's there
09:31 <vmassol> and as a user it's bad
09:31 <vmassol> since as a user you'd wonder what's going wrong in your setup
09:31 <+sburjan> morning
09:31 <vmassol> so it's a pity that our last versiion of 2.x has introduced this
09:31 <+sburjan> you can check the irc logs, sergiu applied my patch to xwiki.org :)
09:32 <vmassol> sburjan: this is not colored for me: http://dev.xwiki.org/xwiki/bin/view/IRC/xwikiArchive20091209
09:33 <+sburjan> no, only the new logs
09:33 <vmassol> do you have a url?
09:33 <vmassol> oh
09:33 <vmassol> wait
09:33 <+sburjan> yes
09:33 <vmassol> he's reverted the livetable
09:33 <vmassol> :(
09:33 <vmassol> I had put the newest on top
09:33 <+sburjan> that is not colored because isn't in irssi syntax
09:34 <vmassol> he's also changed the link
09:34 <vmassol> hmmm
09:34 <vmassol> was better before
09:34 <vmassol> rollbacking page
09:35 <@cjdelisle`> Just got the reply. "+1 but if you deprecate you also need to explain by what it is replaced."  This is tough because there is no way to import/export an attachment archive without being bound to the implementation.
09:35 <+sburjan> all pages are 2.0 syntax .. I hope the one you're reverting remians in 2.0
09:35 <@cjdelisle`> Maybe not the specific implementation but there has to be an import/export format.
09:35 <vmassol> ok better now
09:36 <vmassol> sburjan: no just this page
09:36 <+sburjan> okay.
09:36 <+sburjan> it's good
09:36 <+sburjan> :)
09:36 <+sburjan> do you like it ?
09:36 <vmassol> yep
09:36 <vmassol> cjdelisle`: I think we should deprecate stuff when we offer solutions, don't you think?
09:36 <vmassol> oterhwise as a developer
09:37 <vmassol> I'll be at a pain to modify my code
09:37 <vmassol> since I won't know what to use
09:37 <vmassol> basically when we deprecated we need a @deprecated since XX.XXX use .....
09:37 <vmassol> s/deprecated/deprecate/
09:38 <@cjdelisle`> Continuing to support JRCS means major memory costs unless we donate code to improve it.
09:38 <vmassol> that's not the issue
09:38 <vmassol> I'm fine to replace it by something else
09:38 <vmassol> but we need to define by what
09:39 <@cjdelisle`> If we write something to replace it, then say: use this. It is not generic at all.
09:39 <@cjdelisle`> We are replacing one implementation with another.
09:39 <vmassol> errr?
09:39 <vmassol> are you saying that we shouldn't support archives?
09:40 <vmassol> and thus we shouldn't replac by anything
09:40 <@cjdelisle`> The part which serializes the archive to a byte array will always be implementation bound.
09:40 <vmassol> and?
09:40 <vmassol> how does that rpevent saying
09:40 <@cjdelisle`> I suppose that doesn't much matter unless archives are intended to be generic.
09:41 <vmassol> use an implementation of the XXX interface for perofming bmah blah
09:41 <vmassol> or even without the interface wording if we don't have one
09:42 <@cjdelisle`> So, supposing I write a new serialization mechanism, what happens if the old archive type is sent to the new mechanism? We know what happens if the new archive type is sent to the old mechanism.
09:42 <vmassol> then you say that there's a new serialization mechanism and that from now on it should be used
09:42 <vmassol> I don't understand what you're getting at
09:42 <vmassol> the only thing I don't want
09:43 <vmassol> is to tell users not to use something
09:43 <vmassol> and not explaining what they should do from now on
09:43 <@cjdelisle`> getArchive() is mainly used to store the archive in hibernate which is not applicable for filesystem storage.
09:44 <@cjdelisle`> But if I were to dev a new get/setArchive, I would have to face the problem of the old format being sent to it. It is just a byte array.
09:49 <cjdelisle`> has quit
09:49 <jbrBridge> has quit
09:50 <jvdrean> has quit
10:01 <cjdelisle`> has joined #xwiki
10:01 <jstoldt> brb
10:01 <jstoldt> has quit
10:07 <+sburjan> http://incubator.myxwiki.org/xwiki/bin/view/Test/27snapshots these are the errors I found on 2.7RC1
10:14 <vmassol> sburjan: thanks
10:14 <vmassol> sabageru: the first issue reported by sorin is the one you're working on I think
10:16 <jbrBridge> has joined #xwiki
10:16 <sabageru> vmassol: yes..we have talked about. I finished the part with performances and now i am trying to do an implementation to handle that issue. In my opinion we should add an exists(document, version) in xwiki, but i need to add it and see how it affects performance. I will have an nswer in this afternoon
10:17 <vmassol> ok great
10:18 <jbrBridge> has quit
10:19 <jstoldt> has joined #xwiki
10:19 <jstoldt> re
10:24 <jvdrean> has joined #xwiki
10:25 <cjdelisle`> has quit
10:26 <+sburjan> vmassol: Could you commit the page that you reverted on xwiki.org to the IRCBot app ? Because if any nre patches will be made and applied to xwiki.org, it will be back again (the way you don't like). IMO we should have  this also in the svn, not only custom on xwiki.org. WDYT ?
10:26 <vmassol> sburjan: AFAIK sergiu did ti already
10:27 <+sburjan> vmassol: nop, because it was sergiu's new import that got it reverted last night. So I'm 99% it's not on SVN
10:27 <vmassol> did you read segiu's commits?
10:27 <vmassol> or the jira issues he created?
10:28 <vmassol> can you check please?
10:28 <vmassol> (I don't have time for this)
10:29 <+sburjan> okay. AFAIK he only committed my patch, updated PIrcBot version to 1.5 and crreated new JIRA issues. I didn't see nothing about the changes xwiki.org has custom
10:29 <evalica> has joined #xwiki
10:30 <vmassol> sburjan: what about this http://jira.xwiki.org/jira/browse/XAIRCBOT-10 ?
10:30 <+sburjan> yes, it's fixed
10:30 <vmassol> I think you're wrong
10:30 <+sburjan> yes I am :)
10:30 <vmassol> :)
10:30 <vmassol> that said
10:30 <vmassol> he's linked the channel column to the log
10:31 <vmassol> but removed the link from the file column
10:31 <vmassol> which is bad IMO
10:31 <vmassol> anyway it's a detail
10:31 <+sburjan> yes
10:31 <+sburjan> all I'm saying at the next update, it will be back again :)
10:31 <vmassol> I know that
10:31 <vmassol> of course
10:31 <vmassol> :)
10:34 <jstoldt> you gotta love IBM... seems the entire plant is having trouble with both intranet and internet access...
10:34 <+sburjan> everybody loves IBM :)
10:34 <jstoldt> except everybody, right? ;)
10:35 <+sburjan> nobody messes with IBM. They have patent for so many things, they could ruin everybody that has the balls to sue them
10:35 <jstoldt> well, i think the best thing about IBM is their quantum physics research. because that shit is interesting!
10:35 <+sburjan> I recall the UNIX copyright over the code filled by some company some time ago
10:39 <vmassol> impressive stats for drupal's translations: http://localize.drupal.org/
10:39 <vmassol> (and nice UI)
10:39 <jstoldt> i so wish i could view this -.-
10:42 <silviar> has joined #xwiki
10:43 <vmassol> 3830 active devs…. http://drupal.org/home
10:43 <vmassol> I don't believe this
10:43 <vmassol> :)
10:44 <+sburjan> drupal has a much more larger community than we have
10:44 <+sburjan> don't envy them, we'll get there
10:44 <tmortagne> has quit
10:45 <+sburjan> and IMO most of the devs are contributing with plugins (like in wordpress) not at core level
10:56 <tmortagne> has joined #xwiki
11:07 <jstoldt> brb
11:07 <jstoldt> has quit
11:24 <jstoldt> has joined #xwiki
11:25 <jstoldt> yay, IBM finally restored their "service" :-D
11:30 <Enygma`> has joined #xwiki
11:30 <+sburjan> vmassol: I think I found a bug on xwiki.org. Trying to reproduce locally
11:32 <user___> has joined #xwiki
11:32 <user___> is now known as <cjdelisle`>
11:32 <tmortagne> has quit
11:39 <+sburjan> vmassol: ping. I want to ask you if this is normal intended behavior
11:40 <+sburjan> but we have to wait for xwiki.org ;)
11:41 <mflorea> has quit
11:43 <tmortagne> has joined #xwiki
11:54 <+sburjan> vmassol: can you tell me if this is normal ? go to http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#History . As you see we have a lot of versions. If I click on the second history tab, the page gets refreshed and I have no content anymore. Just the history table. Is this normal ?
12:01 <cjdelisle`> has quit
12:06 <vmassol> sburjan: checking
12:08 <ralucaM> has joined #xwiki
12:09 <vmassol> ralucaM: hi
12:09 <vmassol> I see the images you've added slightly blurred
12:09 <vmassol> while the old ones are sharp
12:09 <ralucaM> vmassol: Hello!
12:09 <ralucaM> the ones I added today?
12:09 <vmassol> does it happen for others too?
12:10 <vmassol> for ex this one is blurred for me: http://platform.xwiki.org/xwiki/bin/download/Features/DocumentLifecycle/AddPage.png?width=650&height=183
12:11 <vmassol> this one too: http://platform.xwiki.org/xwiki/bin/download/Features/DocumentLifecycle/ViewSourceColibri.png?width=650&height=184
12:11 <vmassol> might be my eyes...
12:11 <ralucaM> it it a bit blurred, indeed...I worked from another computer yesterday...let my try again
12:11 <+tmortagne> vmassol: re slf44j: the issue is actually that we have a duplicate now it seems (slf4j-api-1.5.6.jar and slf4j-api-1.5.8.jar), searching what is causing this, we should probably set the version of slf4j in our root pom to avoid things like this like we do for many other standard libs
12:12 <vmassol> sburjan: it's "normal" but I consider it a usability error
12:12 <vmassol> so you should raise a jira IMO
12:13 <florinciu> has joined #xwiki
12:13 <vmassol> tmortagne: yes
12:16 <+sburjan> ok. I will raise it on 2.6. This is also on 2.7. Not sure in which JIRA project to add it.  XE - navigation Application ? or maybe XE - Enterprise Documents
12:16 <vmassol> sburjan: this is done in templates so it's core
12:17 <+sburjan> ok. I'll file it as an improvement
12:18 <cjdelisle> has joined #xwiki
12:19 <ralucaM> vmassol: I tried again but I don't see any difference
12:19 <jbrBridge> has joined #xwiki
12:19 <ralucaM> vmassol: before the import the image looks just fine
12:20 <vmassol> ralucaM: are you resizing it?
12:20 <vmassol> (if so that's the reason)
12:20 <vmassol> (browser resize)
12:20 <+sburjan> yes, resizingg makes them blurry
12:20 <ralucaM> vmassol: no, I keep the actual size
12:20 <vmassol> ralucaM: this is resizing: http://platform.xwiki.org/xwiki/bin/download/Features/DocumentLifecycle/AddPage.png?width=650&height=183
12:21 <abusenius> has joined #xwiki
12:21 <vmassol> this is not resized: http://platform.xwiki.org/xwiki/bin/download/Features/DocumentLifecycle/AddPage.png
12:21 <vmassol> so you are resizinf
12:21 <vmassol> you shouldn't resize
12:22 <sabageru> has quit
12:23 <ralucaM> vmassol: I fixed it
12:25 <Menso> is $!xwiki.jsx.use("AppSpace.AutoSuggest") code that doesn't work in 2.4?
12:28 <sabageru> has joined #xwiki
12:30 <silviar> Hi! I think it would be useful to have a place on xwiki.org where we can put the list of pages that could benefit from updates & the list of features that need documentation. This way anyone who wants to contribute, but doesn't have something specific in mind that needs to be worked on can do so. Wdyt?
12:38 <vmassol> silviar: this can be done from Drafts space on dev.xwiki.org
12:38 <vmassol> you can start it
12:38 <Menso> silviar: good idea, also I think a lot of pages could use benefit from a panel or something that says quickly what version of xwiki is required to run the code and what version xwiki syntax it is in
12:38 <vmassol> silviar: and linked from the contributing page
12:39 <vmassol> Menso: yes we need that. I've been wanting to have it for a years now but didn't get the time to work on it
12:39 <Menso> So should $xwiki.jsx.use("AppSpace.AutoSuggest") work in XWiki 2.4 or does it require 2.5?
12:39 <silviar> vmassol: ok, will link it from the DocGuide as well
12:45 <arkub> has joined #xwiki
12:47 <+tmortagne> vmassol: re slf4j, bad guy was Lucene plugin which transitively depends on 1.5.6 version of slf4j api
12:47 <vmassol> tmortagne: ok
12:56 <silviar> ralucaM: Thanks for updating thr docs! You can also check out this list for some more doc work http://dev.xwiki.org/xwiki/bin/view/Drafts/DocumentationToDo I've assigned the first two to docs to you, since I see you are already on them
12:57 <silviar> sburjan: Please review the extensions pages and list the ones that need to be updated on the above page.
12:58 <ralucaM> silviar: ok, I'll take care of those pages
12:58 <silviar> cool :)
13:11 <florinciu> has quit
13:14 <sdumitriu> has joined #xwiki
13:14 <@sdumitriu> Hi sburjan
13:15 <@sdumitriu> silviar, sburjan: Can you work on the release notes a bit?
13:18 <mihaipaun> has joined #xwiki
13:22 <silviar> sdumitriu: Will work on them until Sorin gets back from lunch and he will finish them.
13:23 <mihaipaun> is there an issue/fix for 2.5.1 when having "Prevent unregistered users from viewing/editing pages, regardless of the page or space rights" options checked, the color theme is not being load unless I refresh+clear cache (after login)
13:23 <mihaipaun> is there an issue/fix for 2.5.1 when having "Prevent unregistered users from viewing/editing pages, regardless of the page or space rights" options checked, the color theme is not being loaded unless I refresh+clear cache (after login)
13:25 <silviar> sdumitriu: any specific things you want us to document?
13:25 <@cjdelisle> sdumitriu, pong
13:26 <jstoldt> mihaipaun: i also ran into that problem
13:26 <jstoldt> the fix is like this
13:27 <jstoldt> don't check those boxes
13:27 <jstoldt> but disallow unregistered users to do anything
13:27 <jstoldt> and then allow them to view your configured ColorTheme
13:28 <@sdumitriu> mihaipaun, jstoldt: Indeed, that is the only fix at the moment
13:28 <@sdumitriu> silviar: There aren't many issues worth documenting, most are bugfixes, or small improvements
13:29 <@sdumitriu> silviar: The fact that color themes can be set for each space
13:29 <+sburjan> sdumitriu: yes. I am the responsable for org documentation from now on
13:31 <mflorea> has joined #xwiki
13:33 <@sdumitriu> cjdelisle: What are you working on?
13:33 <@cjdelisle> attachment versioning.
13:34 <+sburjan> sdumitriu: ok, so you need documented on the release notes page the fact that we can use colorthemes by spaces, not only global
13:37 <evalica> has quit
13:42 <Enygma`> has quit
13:42 <+sburjan> XWIKI-5803
13:42 <Enygma`> has joined #xwiki
13:43 <evalica> has joined #xwiki
13:45 <silviar> sburjan: see above please about the extensions pages (for after you are done with the release notes)
13:45 <+sburjan> silviar: ok
13:45 <silviar> thanks
13:46 <+sburjan> np
13:47 <Menso> has quit
13:48 <mihaipaun> jstoldt, sdumitriu: what's the proper way of globally disallowing unregistered users to do anything?
13:51 <+jvdrean> mihaipaun: I think the best is to explicitly give all the rights to the admin group, view/comment/edit to allgroup, and no rights to unregistered users
13:52 <+jvdrean> + give view rights on the skin and color theme to all group and unregistered users
13:52 <mihaipaun> kinda ugly
13:52 <+jvdrean> this way the login screen will look good (not true when using Prevent unregistered users from viewing pages, regardless of the page or space rights)
13:53 <+jvdrean> mihaipaun: why ?
13:54 <@sdumitriu> sburjan, silviar: So, the build is OK, I can publish it?
13:54 <+sburjan> sdumitriu: well ... :) hard question
13:54 <mihaipaun> I was hoping there's way to check if the user who's visiting the website .isLoggedIn() or something similar
13:54 <+sburjan> there are those bugs on the 27snapshot page. It won't be a production version
13:54 <+sburjan> also mflorea has to fix the jar duplication we found yesterday
13:55 <+sburjan> actually he found :)
13:55 <mihaipaun> jv: I'm going to try what you said, thanks
13:55 <+sburjan> but IMo this will delay the release, do i guess it's your call as committers
13:56 <+mflorea> sburjan: I don't think sdumitriu will re-release XE for that. I'll fix it for RC2
13:56 <sdumitriu1> has joined #xwiki
13:56 <+sburjan> yes.. I have the same opinion
13:56 <sdumitriu1> Known bugs is OK, broken build is not OK
13:58 <sdumitriu> has quit
13:59 <+sburjan> sdumitriu1: also, the Color Theme app should be updated to illustrate the new feature from 2.7 ?
13:59 <sdumitriu1> You mean the documentation?
14:00 <vmassol> mflorea: I don't think we have time for a RC2
14:00 <vmassol> RC2 date is passed since last Monday
14:00 <sdumitriu1> Indeed
14:00 <sdumitriu1> We'll fix critical stuff and release 2.7.0
14:01 <vmassol> yep
14:01 <sdumitriu1> Early next week
14:01 <vmassol> I'm worried though sdumitriu1 by the Activity stream
14:01 <sdumitriu1> It would be best if we fixed everything by tomorrow
14:01 <vmassol> it still has lots of critical issues
14:01 <+mflorea> vmassol: isn't my issue critical?
14:01 <vmassol> mflorea: i don't know
14:01 <vmassol> haven't followed
14:01 <sdumitriu1> mflorea: It is
14:01 <sdumitriu1> Well, not entirely critical
14:02 <vmassol> starting meeting
14:02 <sdumitriu1> Since it doesn't reproduce either for me or for you
14:03 <+sburjan> sdumitriu1: it reproduces for me :)
14:03 <+mflorea> yes, it depends on how JVM loads the classes from the class path
14:03 <sdumitriu1> sburjan: java -version
14:03 <+sburjan> java version "1.6.0_20"
14:03 <+sburjan> OpenJDK Runtime Environment (IcedTea6 1.9.2) (6b20-1.9.2-0ubuntu1~10.04.1)
14:03 <+sburjan> OpenJDK Server VM (build 19.0-b09, mixed mode)
14:04 <sdumitriu1> OK, that might be the problem
14:04 <sdumitriu1> Let me try it as well
14:07 <+mflorea> In my case json-20080701.jar is before org.json-2.0.jar in the class path so it works fine
14:11 <sdumitriu1> sburjan, mflorea: Works well even with OpenJDK
14:11 <sdumitriu1> No warning
14:11 <+sburjan> hmmm
14:11 <sdumitriu1> java -version
14:11 <sdumitriu1> java version "1.6.0_20"
14:11 <sdumitriu1> OpenJDK Runtime Environment (IcedTea6 1.9.1) (Gentoo build 1.6.0_20-b20)
14:11 <sdumitriu1> OpenJDK 64-Bit Server VM (build 19.0-b06, mixed mode)
14:12 <+sburjan> I'm 32
14:12 <+sburjan> and IceTea6 1.9.2
14:12 <+sburjan> IcedTea
14:13 <sdumitriu1> OK, trying 32bit
14:13 <+sburjan> and 1.9.2
14:14 <+sburjan> sdumitriu1: also while compiling the JVM, take a look at the release page and tell me if something needs to be added or  changed
14:14 <sdumitriu1> No warning with:
14:14 <sdumitriu1> java -version
14:14 <sdumitriu1> java version "1.6.0_22"
14:14 <sdumitriu1> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
14:14 <sdumitriu1> Java HotSpot(TM) Server VM (build 17.1-b03, mixed mode)
14:15 <mbryant> has joined #xwiki
14:15 <sdumitriu1> vmassol: The first request login problem doesn't seem to happen on 2.7-rc-1
14:17 <mbryant> has quit
14:18 <mbryant> has joined #xwiki
14:22 <+mflorea> sdumitriu: I just tried the latest version of json lib http://repo2.maven.org/maven2/org/json/json/20090211/ and it doesn't parse document-formats.js throwing the same exception as http://maven.restlet.org/org/json/org.json/2.0/ the reason being the comments that precede the JDON array with the configuration. Removing the comments fixes the problem. I can mark json as provided in xwiki-core-office-importer pom but the problem is that document-
14:22 <+mflorea> (1) Package a version of document-formats.js without the comments in WEB-INF classes
14:22 <+mflorea> (2) Strip the comments before creating the JsonDocumentFormatRegistry (in office importer)
14:24 <sdumitriu1> Where is that file?
14:25 <sdumitriu1> mflorea: Is it bundled in jodconverter jar?
14:25 <+mflorea> yes
14:26 <sdumitriu1> Wait
14:26 <sdumitriu1> Which are the jars causing the conflict?
14:27 <sdumitriu1> I see:
14:27 <sdumitriu1> json-20080701.jar
14:27 <sdumitriu1> json-lib-2.3-jdk15.jar
14:27 <sdumitriu1> org.json-2.0.jar
14:28 <sdumitriu1> json-20080701.jar and org.json-2.0.jar are mostly the same thing
14:28 <+mflorea> json-20080701.jar and org.json-2.0.jar
14:29 <+mflorea> but it seems org.json-2.0.jar (the one loaded by sburjan's JVM) is the one behaving correctly because JSON doesn't allow comments
14:30 <sdumitriu1> So the file is wrong
14:30 <sdumitriu1> Bug report on jodcoverter
14:30 <+mflorea> json-20080701.jar is older than org.json-2.0.jar and maybe they supported comment at first, but then become more strict about it
14:31 <+mflorea> ok, I'll report the issue. Let's see what we can't do about it.
14:32 <+mflorea> (1) bundle a custom document-formats.js without the comments or
14:32 <+mflorea> (2) strip the comments in office importer before creating the JsonDocumentFormatRegistry
14:33 <sdumitriu1> Can we do 2?
14:34 <sdumitriu1> We could also:
14:34 <sdumitriu1> (3) deploy our own jodconverter-core-3.0-beta-3-xwiki.jar
14:34 <+sburjan> so it actually is a bug in jodconverter ?
14:35 <sdumitriu1> sburjan: Yes
14:35 <+sburjan> sdumitriu1: against (3) custom stuff requires more maintenance
14:35 <+mflorea> yes (2) is possible because JsonDocumentFormatRegistry gets an input source or a string. We get construct the input stream
14:35 <+mflorea> and yes, (3) is also possible
14:36 <sdumitriu1> sburjan: (3) isn't that much maintainance
14:36 <sdumitriu1> It's not about forking jodconverter, but just a quick patch until it gets fixed on their side
14:36 <camaritei> has joined #xwiki
14:36 <sdumitriu1> (2) is more dangerous since it means string processing, which is fragile
14:37 <+mflorea> indeed
14:37 <+sburjan> but question : do we need those 3 lines of comments ?
14:38 <sdumitriu1> No
14:38 <+mflorea> well, initially JSON was supposed to be used for data transfer but now it is used also for configuration. Comments are very useful in configuration
14:39 <sdumitriu1> Yes, some people are complaining about this
14:39 <+mflorea> imagine you customize document-format.js and you want to leave a comment in the file
14:39 <+mflorea> explaining your changes
14:39 <sdumitriu1> http://stackoverflow.com/questions/244777/can-i-comment-a-json-file
14:39 <+mflorea> yep
14:40 <sdumitriu1> mflorea: Where did we get the jodconverter jar from? It's not in the central repo
14:40 <+mflorea> let me see
14:43 <+mflorea> good news :) http://maven.xwiki.org/externals/org/artofsolving/jodconverter/jodconverter-core/3.0-beta-3/
14:43 <+sburjan> :D
14:43 <+sburjan> guys, i will be back at 18:00 RO time
14:43 <+sburjan> good luck in fixing the issue
14:44 <+mflorea> so (3) is best option IMO
14:49 <Annatar> has joined #xwiki
14:49 <Annatar> is now known as <StefanO>
14:51 <StefanO> hi
14:51 <mihaipaun> Hello!
14:52 <StefanO> I have a development question
14:53 <StefanO> how can i customize the javascript in the form registration validation?
14:53 <+mflorea> sdumitriu1: I can take http://jodconverter.googlecode.com/svn/tags/3.0-beta-3/ and rebuild with the modified document-format.js . Should I overwrite the exiting jar on maven.xwiki.org or deploy a newer version? Deploying a new version seems cleaner
14:53 <sdumitriu1> Deploy new
14:53 <@cjdelisle> StefanO, What do you want to make it do?
14:54 <StefanO> perform adiitional validation for two more fields that i entered in XWiki/Registration
14:54 <@cjdelisle> What type of validation?
14:54 <StefanO> i wanted them mandatory
14:54 <@cjdelisle> Did you look at the code for XWiki.Registration?
14:55 <StefanO> yes
14:55 <StefanO> i added something like
14:55 <StefanO> #set ( $field =
14:55 <StefanO> {
14:55 <StefanO>   'name' : 'company',
14:55 <StefanO>   'label' : $msg.get('canalplus.userfields.company'),
14:55 <StefanO>   'params' : {'type':'text'},
14:55 <StefanO>   'validate' : {
14:55 <StefanO>     'mandatory' : {'failureMessage' : $msg.get('canalplus.admin.registration.companyMandatory')}
14:56 <StefanO>   }
14:56 <StefanO> })
14:56 <@cjdelisle> $fields.add($field)
14:56 <@cjdelisle> ^that at the end?
14:56 <StefanO> they are added in the form and the server-side validation takes place
14:56 <StefanO> did that too
14:57 <StefanO> but the live validation doesn't occur
14:57 <@cjdelisle> That's odd. The code you see there is all that makes the client side validation work for all other fields.
14:58 <@cjdelisle> Do the other fields still have working livevalidation?
14:58 <Menso> has joined #xwiki
14:58 <StefanO> yes
14:58 <StefanO> the standard ones do
14:58 <@cjdelisle> hah
14:59 <@cjdelisle> try      'mandatory' : {'failureMessage' : "$msg.get('canalplus.admin.registration.companyMandatory')"}
14:59 <@cjdelisle> in ""
15:01 <StefanO> the ones defined by default don't have quotes
15:01 <@cjdelisle> Yea, I just looked and noticed that.
15:02 <@cjdelisle> There must be some syntax mistake. As said, the code which makes the validation script is generic.
15:03 <jvelo> has joined #xwiki
15:03 <jvelo> mflorea: hi
15:04 <+mflorea> jvelo: Hi
15:04 <jvelo> I have a question regarding the WYSIWYG config
15:04 <jvelo> I find xwiki.wysiwyg.toobars in xwiki.cfg but nothing regarding plugins
15:04 <jvelo> (I'm in 2.6)
15:04 <jvelo> where can I find the default list of plugins to override ?
15:04 <@cjdelisle> StefanO, did you try uncommenting the "favorite color" example?
15:04 <StefanO> @cj: dut if i had a syntax error, wouldn't the form items display at all?
15:05 <StefanO> nope
15:05 <@cjdelisle> Try that, I did and it does work. If it works for you, maybe change one thing at a time until it stops working then you know what's wrong.
15:06 <StefanO> i'm on it
15:08 <mihaipaun> has quit
15:10 <+mflorea> jvelo: the new WYSIWYG editor has no configuration parameters in xwiki.cfg. "xwiki.wysiwyg.toobars" is most probably for the old editor. For the new editor there is this page: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/WysiwygEditor . You can find the default (XWiki) values for "plugins", "toolbar" and "menu" in wysiwyg_storeConfig velocity macros in macros.vm. Follow the link to see the all possible values. The easiest way for you to
15:11 <jvelo> mflorea: this mean you can't have a global configuration for all wikis in a XEM ?
15:11 <jvelo> that's bad
15:11 <jvelo> we should be able to override this in xwiki.properties
15:11 <+mflorea> you can, in macros.vm
15:12 <+mflorea> wysiwyg_storeConfig in macros.vm look for XWikiPreferences and falls back on some default values.
15:12 <jvelo> yes but that's not a config file
15:12 <jvelo> that's a code file
15:15 <sdumitriu1> tmortagne: missing jar: org.codehaus.groovy:groovy-all:jar:1.7.6
15:15 <+mflorea> well, I remember I wanted to take the configuration from xwiki.cfg/xwiki.properties but I couldn't do it from within templates like macros.vm . I needed a service or plugin to provide them
15:15 <+tmortagne> sdumitriu1: that's weird since it's release, i confess i did not even checked
15:15 <sdumitriu1> Indeed, missing: http://repo2.maven.org/maven2/org/codehaus/groovy/groovy-all/
15:16 <+tmortagne> released today actually
15:16 <mihaipaun> has joined #xwiki
15:17 <+tmortagne> i guess central repo will be up to date tomorrow or something
15:17 <+tmortagne> i'm reverting it for now
15:17 <+tmortagne> to not block the build
15:19 <+tmortagne> done
15:45 <jstoldt> bye bye
15:45 <jstoldt> has quit
16:05 <sabageru> vmassol: about AS error that sburjan noticed (the one that gave all those exceptions details in log). I tried adding a function exists(Document, version) but as it turns out the performance is highly affected. As a statistic. With the current settings i get a load time of 1.8 - 2.5 s. by adding that function i would get 5-6 s or even more in some cases so it is not a good idea. So the problem is not solved until this moment.
16:09 <jvelo> has quit
16:14 <+sburjan> vmassol: question : do we have to update extensions that aren't made by us ? I mean is our task to maintain screenshots and content of ectionsions which are created by the contributors ?
16:14 <vmassol> sburjan: it's our task to make xwiki.org the best
16:14 <vmassol> now it's question of pririty
16:14 <+sburjan> ok. got it
16:14 <vmassol> priority
16:15 <vmassol> we should make the best extensions be nicely documented
16:16 <+sburjan> another question : what happens with the Extensions that don't have any contributor listed ? (shouldn't we put there XWiki Dev Team) ?
16:16 <vmassol> sburjan: oh no
16:17 <vmassol> certainly not dev team
16:17 <vmassol> :)
16:17 <vmassol> either find who's done them or leave it empty
16:17 <+sburjan> for example : http://extensions.xwiki.org/xwiki/bin/view/Extension/Office+Importer+Application this AFAIK is dev team.
16:18 <+sburjan> and another issue, I really don't like this : Bundled With : enterprise, manager. They should have t least first lettar a capital. Enterprise,Manager
16:18 <+sburjan> even XWiki Enterprise, XWiki Enterprise Manager it is the best
16:18 <vmassol> sburjan: yes I need to fix that
16:19 <vmassol> and yes http://extensions.xwiki.org/xwiki/bin/view/Extension/Office+Importer+Application is dev team
16:19 <+sburjan> doesnt respect the brand :)
16:19 <vmassol> it's not done on purpose sburjan
16:19 <Menso> Ludovic helped me fix a bug in autoSuggest.js for 2.5, can I safely dump that over the autoSuggest.js of a 2.4 as well or will that cause problems? :-)
16:19 <+sburjan> I know. But still should be fixed
16:20 <+sburjan> vmassol: also Webdav Application AFAIk is dev team
16:20 <vmassol> sburjan: yes it  is
16:20 <vmassol> but it's already set
16:21 <+sburjan> yes, but I was refering to the contributors column in the LiveTable
16:21 <vmassol> oh no
16:21 <vmassol> this should never be set
16:21 <+sburjan> should't there appear too Dev Team ?
16:21 <+sburjan> oh, ok
16:21 <vmassol> please remove if you have set the contributor
16:21 <vmassol> to be the xwiki dev team
16:21 <+sburjan> I didn't
16:21 <vmassol> it's wrong
16:21 <vmassol> ok
16:21 <vmassol> pfew
16:21 <vmassol> :)
16:21 <+sburjan> I always ask before
16:21 <vmassol> it's documented
16:21 <+sburjan> before going in execution mode
16:22 <vmassol> it says:
16:22 <vmassol> "Contributors
16:22 <vmassol> (Only specify if not supported by the XWiki Development Team
16:22 <vmassol> Separate different contributors with commas)
16:22 <vmassol> "
16:22 <+sburjan> I guess we are still thinking on the new colmn we want to introduce
16:22 <vmassol> yes jerome need to make it dusplay XWiki Dev Team when it's supported by the xwiki dev team
16:23 <+sburjan> so is it fixable the Bundled with field ? instead of enterprise to put XWiki Enterprise ?
16:23 <vmassol> of course it's fixable
16:23 <vmassol> trying to do it quickly
16:24 <+sburjan> IMO it should be only one place you have to modify
16:24 <+sburjan> but don;t know the backend design
16:24 <sdumitriu1> sabageru: Please remind me why you need that method
16:25 <sdumitriu1> is now known as <sdumitriu>
16:32 <vmassol> sdumitriu: when you have in a static field: key1=value1|key2=value2 how do you get access to value1/value2 in script?
16:33 <vmassol> static list field
16:33 <vmassol> I'm looking at ListProperty and I don't see any method
16:34 <evalica> has quit
16:36 <mflorea> has quit
16:36 <@sdumitriu> vmassol: I think you can't
16:36 <vmassol> oh....
16:37 <vmassol> so i have to hardcode the value to display based on the key?
16:37 <vmassol> yuck…. will do .....
16:38 <Enygma`> has quit
16:39 <vmassol> sburjan: fine
16:39 <vmassol> s/fine/fixed/
16:40 <@sdumitriu> vmassol: There is a trick you can use, but it's a hack
16:41 <@sdumitriu> Do you want me to tell it?
16:41 <sabageru> sdumitriu1: in the AS Macro there are various places where xwiki.getDocument(Document, version) is used. This function catches all exception thrown and logs them with LOG.error(). And when we have a deleted document the AS tries to do that getDocument(Doc, ver) and we get all those big error logs. what i was trying to do is check first if we have the version of the document and after that do the actual get...but it seems if it time consuming because it is
16:41 <vmassol> sdumitriu: it's ok I think
16:43 <@sdumitriu> sabageru: Why is getDocument(doc, version) needed?
16:43 <sabageru> it is need in the macro
16:43 <@sdumitriu> Why?
16:43 <sabageru> there is a function in the macro that checks if a document version is valid
16:43 <sabageru> and besides that
16:44 <sabageru> there is a "changes" link from the AS which you can use in order to get to a page where you can compare two versions of the document
16:44 <@sdumitriu> What I'm trying to say is what data is needed, so that we can remove that call and replace it with something that doesn't go to the database
16:45 <sabageru> well the issue is in this part of code in my opinion
16:45 <sabageru> #set($previousVersion = $xwiki.getDocument($xwiki.getDocument($event.page), $event.version).getPreviousVersion())
16:46 <sabageru> to be more specific #if($event.type == 'update' && $event.version != '1.1')
16:46 <sabageru>             #set($previousVersion = $xwiki.getDocument($xwiki.getDocument($event.page), $event.version).getPreviousVersion())
16:46 <sabageru>             &#183; <a href="$xwiki.getDocument($event.page).getURL('view', "viewer=changes&rev1=${previousVersion}&rev2=${event.version}")">$msg.get('xe.activity.action.seechanges')</a>
16:46 <sabageru>           #end
16:46 <sabageru> and there is also the macro caled isdocumentVersionValid that uses the same function and it will get thos ugly lines in the log ...
16:47 <florinciu> has joined #xwiki
16:47 <@sdumitriu> OK, that one is not performant
16:47 <@sdumitriu> And I think it's not needed
16:47 <+sburjan> vmassol: excelent :) sorry for bugging you.
16:47 <@sdumitriu> If rev1 is missing, and only rev2 is passed, does it work?
16:48 <@sdumitriu> Yes it works
16:48 <@sdumitriu> So just don't compute previousVersion
16:49 <@sdumitriu> And only pass rev2 in the URL
16:49 <@sdumitriu> sabageru: Make a quick patch with this change
16:50 <sabageru> i do not understand what you said
16:50 <sabageru> you say i should pass only rev2 ?
16:54 <@sdumitriu> Yes
16:54 <sabageru> indeed it works as you said.
16:56 <+sburjan> vmassol: another question. I want to delete previous attachments versions of an image. But it seems I don't have any option fomr the UI. Even tested on localhost as admin. Any idea, is this feature not supported ?
16:57 <@sdumitriu> sburjan: Not in the UI
16:57 <@sdumitriu> You can using a script
16:57 <@sdumitriu> With Programming Rights
16:57 <+sburjan> pffff
16:58 <sabageru> sdumitriu: one more question pls. is there a way to work around this macro as well that you can think of ? isDocumentVersionValid(). what it does is the same as above. What this macro does is simplu getDocument(Doc, version) and when the document is deleted it throws an exception. However in this case i do not need the actual document so it would be ok just a check, which i did by the function exists(Document, version) on my local instance. is there any a
16:58 <+sburjan> shouldn't we allow this from UI ? I'd like also to perform a cleanup of the attachments, we have a lot of them which aren't used
16:58 <+sburjan> multiple version to the same attachment
16:58 <@sdumitriu> sburjan: Yes
16:58 <+sburjan> don't know why I remember we had that
16:58 <@sdumitriu> sabageru: And why is that macro needed?
17:00 <sabageru> for example
17:00 <sabageru> in order to display a comment from a previous version. it does the check, gets the document, gets the comments and displays the comment
17:01 <sabageru> $!pageDocRevision.getObject('XWiki.XWikiComments', $util.parseInt($event.param2)).getProperty('comment').value)
17:02 <sabageru> and the same goes for annotation ...
17:04 <mbryant> Hey guys, Quick question.  I am pretty sure that this is the case but I want to make sure.. I can not have "Inherited Classes" right.. I cant create a class of type Vichicle and then one of type Aircraft which would "inherit" all the properties of vechial right
17:04 <mbryant> vechicle
17:07 <@sdumitriu> sabageru: I think there is an alternative, let me check
17:08 <sabageru> ok. waiting :)
17:08 <@sdumitriu> mbryant: No, inheritance is not supported yet
17:08 <@sdumitriu> But it is something we want in the future
17:08 <@sdumitriu> You can "extend" by complement
17:09 <@sdumitriu> Meaning that Aircraft contains only the extra properties not present in Vehicle
17:09 <@sdumitriu> And a document would have objects from both types
17:09 <+florinciu> ralucaM: can you use some smaller images for XWikiReader? not sure all the details in the pictures are needed. it breakes the general aspect of the page.
17:13 <+sburjan> florinciu: that image is big, but it shows an overall aspect of the application. Maybe we could break it in smaller blocks and make from that big picture smaller ones
17:14 <+sburjan> wdyt ?
17:15 <mbryant> sdumitriu: thank you I thought that was the case.. would be nice if it came out sooner rather than later :) that and RDF store. That would cut down my effort in the near future
17:15 <mbryant> but we can all dream :)
17:16 <+florinciu> sburjan: -0 for displaying an image of that size directly on the presentation page. maybe view the entire image after a click.
17:19 <+sburjan> florinciu: I will create a preview of the image, linking to the whole image.... this is the best way IMO
17:20 <+jvdrean> looks like member is a reserved keyword in XWQL, not nice to make queries on groups (example: "where doc.object(XWiki.XWikiGroups).member = 'XWiki.jvdrean'")
17:23 <+jvdrean> "Reserved identifiers are case insensitive. Reserved identifiers must not be used as identification variables."
17:24 <vmassol> jvdrean: fun
17:24 <silviar> has quit
17:24 <+sburjan> guys, I have found and odd issue : ralucaM attached a new image with border. the image is here : http://extensions.xwiki.org/xwiki/bin/downloadrev/Extension/Reader+Application/readerStream.png?rev=1.1 . But when accessing http://extensions.xwiki.org/xwiki/bin/view/Extension/Reader+Application the border isn't there. Whan am I missing .. I'm going crazy :))
17:25 <cjdelisle> has quit
17:25 <+sburjan> and there isn't a newer version which is borderless
17:25 <@sdumitriu> Cache?
17:25 <+sburjan> but there was before a version without borders which was deleted. I hope it's not some crazy storage bug
17:26 <+sburjan> cleared.. tried 2 browsers on 2 computers
17:26 <jbrBridge> has quit
17:27 <@sdumitriu> sabageru: There is another method, but requires PR
17:27 <@sdumitriu> $doc.getDocumentArchive()
17:27 <sabageru> hmm...
17:27 <@sdumitriu> Another metho is to use the criteria service
17:28 <sabageru> is it ok to need PR on AS ?
17:28 <@sdumitriu> No
17:28 <@sdumitriu> Which won't show the exact version, but will return all versions and you'll have to search for it
17:29 <@sdumitriu> Check templates/historyinline.vm
17:29 <@sdumitriu> $doc.getRevisions($criteria)
17:29 <@sdumitriu> That's velocity code, do you want to let someone else handle it?
17:30 <sabageru> it is not that complicated, so i could manage ;)
17:30 <@sdumitriu> K
17:30 <vmassol> sdumitriu: you forgot to remove clirr from xwiki-bridge module. Someone shouldn't have put a clirr exclusion there in the first place
17:33 <+florinciu> sburjan, sdumitriu: included image seems correct. probably pixel loss on image resize.
17:33 <+sburjan> the image is resized. I am only comparing :
17:33 <cjdelisle> has joined #xwiki
17:34 <+sburjan> 1. http://extensions.xwiki.org/xwiki/bin/view/Extension/Reader+Application
17:34 <jbrBridge> has joined #xwiki
17:34 <+sburjan> 2.http://extensions.xwiki.org/xwiki/bin/downloadrev/Extension/Reader+Application/readerStream.png?rev=1.1
17:34 <+sburjan> readerStream.ong from Page, wit the one from thesecond link (border is visible on second link even without zoom)
17:35 <+sburjan> can someone explain this to me so I won't die stupid ?
17:35 <+florinciu> yes. the html contains the correct image, but the resize algorithm is crappy
17:35 <+florinciu> http://extensions.xwiki.org/xwiki/bin/download/Extension/Reader+Application/readerStream.png
17:35 <+florinciu> vs
17:35 <+florinciu> http://extensions.xwiki.org/xwiki/bin/download/Extension/Reader+Application/readerStream.png?width=800
17:35 <@sdumitriu> sburjan: refresh cache
17:36 <@sdumitriu> browser
17:36 <+sburjan> sdumitriu: did that. tried on a browser that has never seen that page. on 3 computers.
17:36 <+florinciu> sburjan: what's not clear in what I said?
17:36 <vmassol> tmortagne: do you remember if we're doing it voluntarily in IncludeMacro not to pass the transformation id when executing the tx?
17:37 <vmassol> (if I remember correctly this id is used as the velocity macro cache id)
17:37 <+tmortagne> vmassol: looking
17:37 <+tmortagne> are you sure it's not only when context=new ?
17:37 <+sburjan> florinciu: you locked the page. Try removing any resizing from code
17:37 <StefanO> has quit
17:38 <vmassol> I've fixed it in my refactoring but wondering if my fix is right...
17:38 <+florinciu> sburjan: unlocked
17:38 <+florinciu> sburjan: a quick solution is to find a size where the border pixels are not lost.
17:39 <+tmortagne> vmassol: context=new is supposed to isolate
17:39 <+tmortagne> so yes it's normal IMO
17:39 <+tmortagne> it shoul no use the same velocity namespace
17:39 <vmassol> I need to re-read the code that uses that id
17:39 <vmassol> right now it deosn't pass any id
17:39 <vmassol> I'm not sure what this means for velocity macro cache
17:40 <vmassol> it means :
17:40 <vmassol>             String key = context.getTransformationContext().getId();
17:40 <vmassol>             if (key == null) {
17:40 <vmassol>                 key = "unknown namespace";
17:40 <vmassol>             }
17:40 <+tmortagne> when there is no id i guess it's regenerated based on current document or something
17:40 <+tmortagne> not nice
17:40 <vmassol> hmmm
17:42 <vmassol> not nice but not criticial either
17:42 <+tmortagne> we probably simply forgot include macro when we introduced this id
17:42 <vmassol> I can fix it though
17:42 <+tmortagne> in any case it should not be the same as the includer document
17:42 <vmassol> the cache is removed after each request if I remember correclty
17:42 <vmassol> after each top level rendering
17:43 <+tmortagne> vmassol: yes i think
17:43 <ralucaM> has quit
17:43 <vmassol> I can use the included doc name as the new id
17:45 <+tmortagne> it should be generated like we do for top id one, need to check but i think that's the document reference yes
17:45 <vmassol> tmortagne: athough we're pusing a new context so we'll be doubly isoltaed
17:45 <+tmortagne> not really
17:45 <+tmortagne> velocity macro are not in the velocity context AFAIK
17:45 <vmassol> hmm yes you're right
17:45 <vmassol> (I think)
17:46 <+tmortagne> <hich is why we use this namespace thing
17:54 <vmassol> tmortagne: we need to move Syntax outside of rendering module IMO
17:54 <+tmortagne> vmassol: why ?
17:55 <vmassol> because it's used in the model
17:55 <+tmortagne> hmm
17:55 <vmassol> and it's not normal that model depends on it
17:55 <vmassol> right now it's in XWikiDocument.getSyntax()
17:55 <vmassol> it's more generic than rendering
17:55 <vmassol> the problem is then to keep the rendering module standalone
17:56 <+tmortagne> depends what we make really part of rendering API, currently there is a lot of things in it that are not APIs
17:56 <vmassol> still
17:56 <vmassol> syntax is not just for rendering
17:57 <vmassol> or is it....
17:57 <vmassol> hmmm
17:57 <+tmortagne> not sure
17:57 <+tmortagne> if you have a syntax it's for parsing/render it
17:57 <vmassol> yes
17:58 <vmassol> ok so maybe it's correct after all
17:58 <vmassol> leaving it there
17:58 <vmassol> I'm adding a dep to rendering-api from xwiki-bridge
17:58 <vmassol> to have a getSyntax() method in DocumentModelBridge
17:58 <vmassol> (and deprecate getSyntaxId())
17:59 <vmassol> I need that to remove a deprecation in IncludeMacro
17:59 <+tmortagne> ok I tough that was already  done
17:59 <+tmortagne> in any case bridge does not have the same constraints than new model
18:21 <camaritei> has left #xwiki
18:22 <sabageru> sdumitriu: I added the modifications you suggested regarding AS and isdocumentVersionValid(). indeed it worked with $pageDoc.getRevisions(). I will makw a xar with both modifications and add attach it to http://jira.xwiki.org/jira/browse/XE-780 and maybe you have time to look on it :)
18:23 <mihaipaun> has quit
18:30 <sburjan> has quit
18:34 <sabageru> sdumitriu: XE-780 was not ok to modify . I created http://jira.xwiki.org/jira/browse/XE-793 and added my patch. It contains both modifications we spoke about today
18:35 <vmassol> tmortagne: the last step of IncludeMacro should only be done if the context is current right?
18:35 <vmassol> (I don't see why we would need to do it if context is new since we're setting the included doc as the current doc in that case)
18:36 <vmassol> hmmm no
18:36 <+tmortagne> "last step" ?
18:36 <vmassol> my bad
18:36 <vmassol> last step of execute()
18:37 <vmassol> checking LinkBlock but we're storing a string AFAIR
18:38 <vmassol> yes
18:38 <vmassol> so it's resolved at render time
18:38 <vmassol> so I'll need to do the same for the context macro
18:38 <vmassol> and add resolving for images too
18:40 <arkub> has quit
18:42 <+tmortagne> vmassol: I'm reading the code but I can't find how this can really do what is written in the comment
18:42 <vmassol> has quit
18:45 <tmortagne1> has joined #xwiki
18:48 <tmortagne> has quit
18:57 <vmassol> has joined #xwiki
18:58 <sabageru> has quit
19:06 <jvdrean> has quit
19:16 <SvenDowideit> has quit
19:16 <SvenDowideit_> has joined #xwiki
19:16 <SvenDowideit_> is now known as <SvenDowideit>
19:58 <florinciu> has quit
20:03 <vmassol> has quit
20:18 <npm> is now known as <np>
20:19 <np> is now known as <Guest76058>
20:21 <vmassol> has joined #xwiki
20:22 <Guest76058> is now known as <npm>
20:27 <mflorea> has joined #xwiki
20:36 <sabageru> has joined #xwiki
20:53 <tmortagne1> has quit
20:58 <SvenDowideit_> has joined #xwiki
20:59 <SvenDowideit> has quit
20:59 <SvenDowideit_> is now known as <SvenDowideit>
21:51 <mbryant> has left #xwiki
22:44 <florinciu> has joined #xwiki
23:08 <xwikibot> has joined #xwiki
23:33 <mflorea> has quit
23:34 <sabageru1> has joined #xwiki
23:34 <sabageru> has quit
23:35 <sabageru1> has quit
23:37 <SvenDowideit> has quit
23:37 <SvenDowideit> has joined #xwiki