IRC Archive for channel #xwiki on 21 May 2012

00:00 <@cjd> try cd xwiki-commons && git pull && mvn clean install
00:00 <@cjd> then cd ../xwiki-rendering && git pull && mvn clean install
00:00 <@cjd> then back to platform
00:00 <@cjd> looks like your version of xwiki-rendering is old
00:01 <jssol> ok let me try that
00:01 <qwebirc84308> whats the link for the enterprise web app?
00:02 <mflorea> has quit
00:02 <@cjd> http://enterprise.xwiki.org/xwiki/bin/view/Main/Download
00:02 <@cjd> .war is for a tomcat server
00:02 <@cjd> .exe and .zip are for a standalone
00:03 <slugz> has quit
00:04 <@cjd> when you use a big server like tomcat or glassfish, you have to worry about their bugs too...
00:04 <qwebirc84308> Is it this one  - A Debian repository containing a set a Debian packages to install XWiki on any Debian based distribution.?
00:04 <jssol> to confirm, the xwiki-platform, common, and rendering folders should all be at the same level?
00:04 <jssol> or should common and rendering be inside the platform folder
00:05 <@cjd> qwebirc84308: sorry i don't know anything about the debian packages, I've not used them
00:05 <@cjd> no, commons, rendering, platform are all in the same dir
00:05 <@cjd> https://github.com/xwiki/xwiki-trunks
00:06 <qwebirc84308> Which enterprise web app have you used?
00:06 <@cjd> we use that for keeping track of them
00:06 <@cjd> qwebirc84308: I've used the war, and zip versions extensively, I recommand the zip version if you don't already have a tomcat application server
00:07 <qwebirc84308> okay, cool :-)
00:09 <qwebirc84308> Btw: I have a Godaddy Shared Host, but im guessing ill need something with more power?
00:09 <@cjd> yes, shared hosting will not work unless it's shared java hosting
00:09 <@cjd> shared php hosting is not enough.
00:10 <qwebirc84308> so standalone is also included as a web app?
00:11 <qwebirc84308> standalone = web app OR both?
00:13 <@cjd> yes, the standalone .zip file is also a webapp.
00:13 <qwebirc84308> aWesome :-)
00:13 <@cjd> The different is that the .war distribution is meant to run under a server like tomcat.
00:13 <qwebirc84308> any host you guys recommend?
00:14 <@cjd> My recommendation is to use a VPS rather than shared tomcat hosting.
00:14 <@cjd> As far as good vps provders... Not entirely sure.
00:14 <qwebirc84308> Java VPS?
00:15 <qwebirc84308> Cool, Ill have a look around.
00:15 <@cjd> just a normal vps is enough as long as you're sutably experienced with the linux command line to install java yourself
00:15 <qwebirc84308> Ah okay, i see.
00:17 <qwebirc84308> Sweet thanks guys. See ya :-)
00:17 <qwebirc84308> has quit
00:22 <abusenius> has quit
00:25 <jssol> hi @cjd, so i was able to build commons succesfully but not rendering
00:25 <jssol> here is the error: https://ezcrypt.it/Wa5n#h9LQMIBu7or6pt7ZcUYX8Pis
00:25 <jssol> i think i'm missing a dependency d4j?
00:25 <jssol> *dom4j
00:25 <@cjd> hmm no that looks like a bug on out end
00:26 <@cjd> *our
00:29 <@cjd> everything looks right
00:32 <jssol> hmm, i tried again pulling straight from xwiki's github and still get the same error. here it is with -e https://ezcrypt.it/Xa5n#EksvQZcMoRYSkghLyRdTkHRP
00:32 <@cjd> the background on your error is that the <version> for dom4j is unspecified
00:32 <@cjd> but it's specified in xwiki-commons
00:32 <@cjd> and rendering inherits from commons
00:32 <@cjd> so it should work
00:33 <@cjd> try:  mvn --version
00:33 <jssol> https://ezcrypt.it/Ya5n#tdf6vtv8UiR6uLB2I0ZkQ9yR
00:34 <@cjd> that should be fine
00:34 <@cjd> try this:
00:35 <@cjd> rm ~/.m2/repository/* -r
00:35 <@cjd> cd ../xwiki-commons
00:35 <@cjd> mvn clean install
00:35 <@cjd> cd ../xwiki-renderinf
00:35 <@cjd> mvn clean install
00:35 <@cjd> *rendering
00:35 <@cjd> let me know what happens
00:35 <@cjd> I'll try the same here.
00:36 <jssol> this is a typo right? cd ../xwiki-renderinf
00:36 <jssol> oh it is
00:36 <jssol> sorry!
00:41 <@cjd> for dir in `ls`; do [ -d $dir ] && cd $dir && git reset --hard && git clean -dxf && git checkout master && git reset --hard && git clean -dxf && git pull && cd ..; done
00:42 <@cjd> ^^ nice way to update all of your sub-repos at once
00:42 <@cjd> hrm no that script has a bug
00:45 <@cjd> for dir in `ls`; do [ -d $dir ] && ( cd $dir && git reset --hard && git clean -dxf && git checkout master && git reset --hard && git clean -dxf && git pull && echo "$dir Success" ); done
00:45 <@cjd> that one seems to work :)
00:46 <qwebirc46003> has joined #xwiki
00:55 <qwebirc46003> hello, one more question. it was mentioned earlier that xwiki requires at least 1 gig, is this referring to storage space or the actual server ram?
00:56 <qwebirc46003> pricing starts to get quite costly when upsizing ram...
00:59 <@cjd> that's ram, you can probably get away with less but it starts to get tight
01:00 <@cjd> 256M is just not going to happen
01:00 <qwebirc46003> okay, so 1 gig of ram, but more if you can affort.
01:00 <qwebirc46003> afford ***
01:00 <@cjd> 512M is possible but extremely tight and you'll probably end up with OOM issues
01:01 <@cjd> yes, 1G is possible, it will likely run into issues when it scales to a large wiki but it will get you off the ground comfortably
01:01 <@cjd> oh
01:01 <@cjd> make sure not to use a 64 bit system
01:01 <@cjd> more specifically, don't use 64 bit java
01:02 <@cjd> because one thing Sun fails at is using ram efficiently (obviously) and in 64 bit java, all of their mistakes are amplified twice as much.
01:03 <qwebirc46003> great, thanks for the advice! noted.
01:07 <qwebirc46003> has quit
01:08 <cjd> has quit
01:09 <jssol> hi cjd, i'm still getting the same error
01:09 <jssol> common builds correctly, and rendering has issue with dom4j
01:10 <cjd> has joined #xwiki
01:10 <jssol> hi cjd, i'm still getting the same error
01:10 <jssol> common builds correctly, and rendering has issue with dom4j
01:10 <cjd> is now known as <Guest84285>
01:11 <Guest84285> trying it myself
01:12 <Guest84285> has quit
01:12 <cjd_> has joined #xwiki
01:28 <@cjd_> I'm getting a build success
01:31 <jssol> hmmm, my folder directory looks like: xwik/xwiki-commons; xwik/xwiki-platform; xwik/xwiki-rendering
01:31 <jssol> and do you need to install anything besides maven ( a plugin or sth?), i just did apt-get install maven
01:33 <@cjd_> I'm going to try an older version of java, I wouldn't be surprised if this is a java version thing
01:34 <jssol> ok
01:34 <@cjd_> I'm using 2.6_30
01:36 <jssol> that's probably it then since it seems i'm quite far behind
01:36 <jssol> java version "1.6.0_24" OpenJDK Runtime Environment (IcedTea6 1.11.1) (6b24-1.11.1-4ubuntu2) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
01:45 <@cjd_> hmm commons doesn't compile 1.6_21
01:46 <@cjd_> anyway, try using the newest version and see if that solves your problem, I'm running almost the same version of maven so it should all "just work" the same.
01:47 <jssol> alright, doing that right now. thanks!
02:28 <sburjan`> has quit
02:54 <npm> I'm still seeing something like http://jira.xwiki.org/browse/XWIKI-6180 in XE 3.5 -- my macro becomes unregistered after restart. have to resave as Admin to get it working again
02:57 <jssol> i'm still having issues. i'm using what seems to be the latest version avaiable
02:57 <jssol> java version "1.7.0_04" Java(TM) SE Runtime Environment (build 1.7.0_04-b20) Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
02:57 <jssol> i'm not sure how you got 2.6_30?
03:10 <@cjd_> ahh, I downloaded it back when it was the newest
03:10 <@cjd_> that was kind of a long shot anyway
03:10 <@cjd_> I've seen odd version dependent issues EG: commons doesn't compile with 1.6.0_21
03:15 <jssol> woudn't 2.6 be newer than 1.7?
03:15 <jssol> in any regards, any other ideas?
03:15 <@cjd_> sorry, 1.6.0_30
03:15 <@cjd_> typo
03:52 <@cjd_> jssol: I assume your ~/.m2/settings.xml is exactly what is here: http://dev.xwiki.org/xwiki/bin/view/Community/Building
03:53 <@cjd_> I just built with that and it build commons and rendering ok
04:19 <jssol> yes, i did c&p
04:20 <@cjd_> that's weird
04:20 <jssol> it is interesting that i can build commons without a hitch
04:20 <@cjd_> vmassol might know more since he's an ex-maven developer
04:21 <cjd_> is now known as <cjd>
04:21 <jssol> what would be the best way to contact him? should i ask on the mailing list?
04:22 <@cjd> he'll be here in about 6 or 7 hours from now
04:24 <jssol> also, another question if i did a fix for jira, since it was just deleting text from translation
04:24 <jssol> do i need to mark it, or will the person managing the pull request manage it
04:26 <@cjd> you mean there's an issue on jira and you fixed it, you're wondering if you need to make note that you fixed it?
04:26 <@cjd> or you're wondering if you need to create an issue to get your PR pulled?
04:26 <jssol> the first
04:27 <@cjd> I think you should somehow communicate that it fixes the other issue so that the issue is closed as it should be.
04:28 <jssol> i wrote the link in the pull request (the issue: http://jira.xwiki.org/browse/XWIKI-7678)
04:31 <@cjd> you know a lot of languages ;)
04:32 <@cjd> in my experience, these kinds of things require the most discussion and can be the most difficult types of issues to get consensus on.
04:32 <@cjd> it's something the user will see...
04:32 <@cjd> http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality
04:33 <@cjd> So the thing to do (IMO) is ask on the devs list if that change makes sense.
04:33 <jssol> aha, i assumed it was where the period was. my newness is showing
04:34 <jssol> ok, i will go ahead and do that. thanks for all your help cjd!
04:35 <@cjd> sure thing
04:57 <ssavi> has joined #xwiki
05:27 <qwebirc26754> has joined #xwiki
05:28 <qwebirc26754> Hey, where abouts is the database stored in xwiki enterprise? Is it in the folder named database? There are several files in there...
05:30 <@cjd> yes, that's the storage for the HyperSQL database.
05:31 <qwebirc26754> Are those the files I need to backup?
05:33 <@cjd> yes
05:33 <qwebirc26754> Cool.
05:34 <@cjd> backing up the whole directory is nice if you have incremental backup so it doesn't take up too much space
05:34 <qwebirc26754> Could I copy the database and paste it into another instance of xwiki?
05:34 <@cjd> It should be possible but I've not done it, you might want to try just to make sure.
05:35 <qwebirc26754> Okay will do
05:35 <qwebirc26754> Have u heard of a host named arvixie?
05:36 <@cjd> nope
05:37 <qwebirc26754> $4 per month to host xwiki...
05:37 <qwebirc26754> Sounds pretty good
05:38 <@cjd> nice
05:41 <qwebirc26754> I'm wondering what the downside is...
05:42 <@cjd> with a lot of those, the downside is they oversell so when they get more customers, you find you don't have as much ram as they promised
05:42 <@cjd> or processes randomly get terminated because they're out of ram
05:42 <@cjd> but if they're not full then they can oversell all they want...
05:44 <qwebirc26754> Ah I see, yah it is shared VIPs...
05:44 <qwebirc26754> Vos
05:44 <qwebirc26754> VIPs
05:44 <qwebirc26754> Sorry, iPad correcting my text
05:44 <qwebirc26754> Cool
05:45 <@cjd> heh yeap
05:45 <qwebirc26754> Okay and how do you back up attachments?
05:46 <@cjd> by default, attachments are stored in the database
05:46 <@cjd> so I recommend you either switch to FS attachments (there are instructions on xwiki.org) or switch to mysql since it's better about large data sets.
05:47 <rrodriguez> has joined #xwiki
05:52 <qwebirc26754> Okay understand :)
06:05 <qwebirc26754> has quit
06:54 <rrodriguez> has quit
07:03 <Denis1> has joined #xwiki
07:03 <Denis> has quit
07:06 <jssol> has quit
07:28 <ssavi> has quit
07:29 <ssavi> has joined #xwiki
07:42 <rrodriguez> has joined #xwiki
07:45 <mflorea> has joined #xwiki
07:46 <sburjan`> has joined #xwiki
07:56 <rrodriguez> has quit
08:07 <polx> has joined #xwiki
08:11 <vmassol> has joined #xwiki
08:27 <tmortagne> has joined #xwiki
08:28 <polx> has quit
08:54 <mflorea> has quit
09:33 <mflorea> has joined #xwiki
09:34 <tmortagne1> has joined #xwiki
09:35 <tmortagne> has quit
09:56 <polx> has joined #xwiki
09:58 <lucaa> has joined #xwiki
10:05 <polx> has quit
10:12 <sburjan> has joined #xwiki
10:18 <tmortagne1> has quit
10:29 <tmortagne> has joined #xwiki
10:32 <CIA-74> Vincent Massol master * r6865666 https://github.com/xwiki/xwiki-rendering/commit/6865666b161678345d8c17382ad50ffed0306d6c / (6 files in 3 dirs): XRENDERING-205: Add support for Metadata Syntax different than the Syntax being tested in the CTS - http://git.io/lT4ZrA
10:32 <vmassol> tmortagne: do you know if the following was supported in XWiki Syntax 1.0: "This is * bold *"
10:32 <vmassol> right now it's failing
10:33 <vmassol> going to try it
10:34 <jvdrean> has joined #xwiki
10:34 <vmassol> answer: it wasn't supported
10:35 <vmassol> cool I'll make the test not applicable
10:36 <CIA-74> Vincent Massol master * rff88625 https://github.com/xwiki/xwiki-rendering/commit/ff88625b68653052a92ae7d3fa3b7a9d947cf1a4 / xwiki-rendering-syntaxes/xwiki-rendering-syntax-xwiki10/src/test/resources/xwiki10/config.properties : [CTS] Whitespaces inside bold are not supported in XWiki Syntax 1.0 - http://git.io/gJnmWg
10:41 <jvdrean> has quit
10:41 <jvdrean> has joined #xwiki
11:11 <CIA-74> Marius Dumitru Florea master * rc17768a https://github.com/xwiki/xwiki-enterprise/commit/c17768a817fc269da533db4c3d8d00f31525c62e / (6 files in 4 dirs): Drop support for Firefox 3.x - http://git.io/nRhsVA
11:16 <ssavi> has left #xwiki
11:28 <tmortagne> has quit
11:48 <polx> has joined #xwiki
12:14 <polx> has quit
12:16 <polx> has joined #xwiki
12:25 <Enygma`> has joined #xwiki
12:26 <evalica> has joined #xwiki
12:43 <sburjan> has quit
12:47 <sburjan> has joined #xwiki
13:00 <CIA-74> Vincent Massol master * rced76d1 https://github.com/xwiki/xwiki-rendering/commit/ced76d134afac4db091e841710423c144e4ba53a / (6 files in 4 dirs): [CTS] Added table1 tests for more syntaxes - http://git.io/CCpNyQ
13:09 <polx> has quit
13:11 <+sburjan> Hello. I was able to start a job for testing our ui-tests on IE8, but it seems we still have 3 tests that fail on Jenkins that should be excluded.  Should I create a separate issue, re-open the one we have, or do nothing on jira ? the issue I am talking about is http://jira.xwiki.org/browse/XE-1147
13:11 <vmassol> any issue closed it closed
13:11 <vmassol> if the release has been made
13:12 <vmassol> so you should create a new one if the version correpsponding to the fixfor has been released
13:12 <vmassol> (since obviously we cannot un-release ;))
13:12 <+sburjan> it was fixedFor 4.0 M1 .. so it has been released
13:12 <+sburjan> 4.0M2, sorry
13:12 <+sburjan> okay, creating a new one
13:12 <+sburjan> thanks. I'll create a pull request today
13:13 <vmassol> @sburjan: if you reopne it it means the code committers against it will not have existed
13:13 <vmassol> which isn't true
13:13 <vmassol> because the issue won't be listed int eh list of issues done for that release
13:13 <vmassol> you see the rationale?
13:13 <vmassol> s/committers/cmmitted/
13:14 <+sburjan> vmassol: yes, I guess only way to re-open it would be if the issue was a regression, but it's not a regression
13:14 <vmassol> why?
13:14 <vmassol> why would you reopne for a regression?
13:15 <vmassol> you mean something that is meant to be fixed but is not fixed?
13:15 <+sburjan> basically something changed, or the environment is diferent on the Jenkins agent, this is why the 3 tests are failing
13:15 <+sburjan> no, I wouldn, it's _not_ a regression
13:15 <+sburjan> I wqas agreeing with your point :)
13:15 <vmassol> yes I agree that we could/should reopen for something marked to be fixed but not fixed
13:16 <vmassol> except if some part has been fixed...
13:16 <vmassol> which is usually the case
13:16 <vmassol> so we never reopen
13:16 <+sburjan> yepp
13:16 <+sburjan> I agree
13:19 <vmassol> Guys, we need to fix the platform build failure due to CLIRR
13:19 <vmassol> if someone knows why it's failing please let me know
13:19 <vmassol> mflorea: you have some idea?
13:20 <+mflorea> vmassol: no, but I will take a look
13:20 <vmassol> I started to look at it yesterday but haven't finished
13:20 <vmassol> going to decompile 4.0 and 4.1 and compare
13:21 <vmassol> btw we had a talk about it with cjd yesterday, see IRC histo
13:21 <vmassol> hmm would be nice to have an irc bot command to get the url of a irc archive
13:21 <vmassol> http://dev.xwiki.org/xwiki/bin/view/IRC/xwikiArchive20120520
13:23 <+mflorea> vmassol: could this be related to http://jira.xwiki.org/browse/XWIKI-7833 Sergiu suspected it has to do with the order in which maven plugins goals are executed
13:24 <vmassol> I'll need to read that issue, I haven't followed it, I'll check it too
13:26 <mflorea> has quit
13:28 <vmassol> so in the aspect we have: private XWikiNotificationManager XWiki.notificationManager;
13:28 <vmassol> this translates to:  public XWikiNotificationManager ajc$interField$com_xpn_xwiki_XWikiCompatibilityAspect$notificationManager;
13:29 <vmassol> that's in 4.0
13:29 <vmassol> now checking why it would have been removed in 4.1snap
13:31 <vmassol> indeed, in 4.1snap I have:  private XWikiNotificationManager notificationManager;
13:32 <vmassol> now the question is: why? :)
13:37 <vmassol> one idea is that maybe we've changed the aspectj version, checking
13:38 <vmassol> indeed we've done that: http://jira.xwiki.org/jira/browse/XCOMMONS-156
13:38 <vmassol> checking more
13:49 <vmassol> ok that's it
13:49 <vmassol> at least we know why now :)
13:50 <vmassol> note that there are still 2 real issues not caused by this:
13:50 <vmassol> [ERROR] com.xpn.xwiki.doc.merge.MergeUtils: Class com.xpn.xwiki.doc.merge.MergeUtils removed
13:50 <vmassol> [ERROR] com.xpn.xwiki.objects.ObjectInterface: Method 'public com.xpn.xwiki.objects.classes.BaseClass getXClass(com.xpn.xwiki.XWikiContext)' has been added to an interface
13:56 <gdelhumeau> has joined #xwiki
13:59 <vmassol> ok so ATM the only good solution I can think of is:
14:00 <Enygma`> has quit
14:00 <vmassol> Step 1: add exclusions for ajc$ stuff
14:00 <vmassol> Step 2: RM must absolutely remove them and test with aspectj 1.3 before the release to ensure we don't add breakages
14:01 <vmassol> it'll be autofixed once 4.1 final is released
14:01 <vmassol> I'll comment in the pom
14:01 <Enygma`> has joined #xwiki
14:06 <@cjd> These magic ajc$ functions are (undocumented) API?
14:07 <vmassol> don't know
14:07 <vmassol> haven't checked that far
14:07 <vmassol> now what worries me is that someone of us has added the clirr excludes without discussing it or commenting abou tit!
14:07 <vmassol> that's really bad
14:08 <vmassol> let's see who did this :)
14:08 <@cjd> IMO those functions are injected by aspectj so that it can handle it's internal doings and we should never expect them to last even a minute, let alone a release.
14:09 <@cjd> So anyone who uses an ajc$ function deserves to be broken.
14:09 <vmassol> ok it's segiu in 6bb610b2347324cb3c9d9bc50874e8939e76740e
14:09 <vmassol> sergiu
14:09 <vmassol> nobody will ever use that
14:09 <vmassol> that's not the issue
14:10 <vmassol> cjd: here's the comment I'm adding:
14:10 <vmassol>             <!-- The following excludes are needed because we've upgraded from AspectJ 1.6.7 to AspectJ 1.6.11
14:10 <vmassol>                  in 4.0-milestone-1 and it seems that AspectJ has changed the way they weave stuff in class files thus
14:10 <vmassol>                  leading to false CLIRR errors.
14:10 <vmassol>                  Thus we have to add those excludes. However those excludes could hide real breakages and thus before
14:10 <vmassol>                  the release is done the Release Manager must absolutely remove those excludes below and try running
14:10 <vmassol>                  CLIRR with AspectJ 1.6.7 to verify that no breakages have been added. To do so simply edit the
14:10 <vmassol>                  Legacy OldCore pom.xml and add <version>1.6.7</version> for aspectjrt and <version>1.3</version> for
14:10 <vmassol>                  the AspectJ Maven plugin version.
14:10 <vmassol>             -->
14:10 <Enygma`> has quit
14:10 <Enygma`1> has joined #xwiki
14:10 <vmassol> cjd: is that understandable?
14:11 <@cjd> However those excludes could hide real breakages <-- not true
14:11 <vmassol> errr?
14:11 <@cjd> java bans the use of the $ in function names so no "real" function can ever have a $ in it.
14:11 <vmassol> no no
14:11 <evalica1> has joined #xwiki
14:11 <vmassol> you don't undestand
14:11 <vmassol> let me explain
14:12 <vmassol> we're excluding com/xpn/xwiki/XWiki for ex
14:12 <evalica> has quit
14:12 <@cjd> oh
14:12 <vmassol> imagine someone adds a new public method to it or removes one or change a signature
14:12 <@cjd> indeed, that should be excluded for oldcore only
14:12 <vmassol> since we're excluding it
14:12 <vmassol> it won't be noticed
14:12 <@cjd> not for legacy-oldcore
14:12 <vmassol> yes there's nothing to exlude from legacy modules
14:12 <vmassol> by definition
14:13 <vmassol> of legacy modules
14:13 <vmassol> :)
14:13 <vmassol> (except for exceptional cases that we vote obviously)
14:13 <vmassol> (but we've not done that yet)
14:13 <@cjd> so the exclude is necessary to make oldcore build, but it should not be applied to -legacy-oldcore
14:13 <vmassol> no
14:13 <vmassol> the way we do it is:
14:13 <vmassol> we don't run clirr on oldcore at all
14:14 <vmassol> so oldcore always build
14:14 <vmassol> the clirr check is only done in legacy modules
14:14 <vmassol> because
14:14 <vmassol> we need to run it *after* apsects have been weaved
14:14 <vmassol> got it? :)
14:14 <@cjd> hmm, then I am indeed confused since those excludes should not be necessary as far as I can see.
14:14 <vmassol> well read my comment
14:15 <vmassol> if it's not clear I need to improve it
14:15 <vmassol> aspectj has changed
14:15 <Enygma`1> has quit
14:15 <@cjd> ok, I'd like to try it out on my desktop too and see if I notice anything
14:16 <vmassol> sure no pb
14:16 <vmassol> ask le if you have any question because it's quite clear for me now
14:16 <vmassol> s/le/me/
14:16 <@cjd> excluding $ajc* makes perfect sense since aj might add or remove "internal" functions at it's own whim.
14:16 <vmassol> we cannot do that
14:16 <vmassol> it's not possible
14:17 <@cjd> ahh, that is a pain :(
14:17 <vmassol> I wanted to check the clirr sources to see how hard it would be to add this
14:17 <vmassol> btw I talked with the clirr creator back in 2000s about it
14:18 <vmassol> but he didn't get the time to do it and then the project hasn't been touched by anyone else
14:18 <vmassol> (btw fyi I had the idea of clirr and the guy implemented it based on my idea, that was cool ;))
14:18 <@cjd> heh nice
14:19 <Enygma`> has joined #xwiki
14:19 <@cjd> I'd like to stage 4.1M2 as soon as possible so we can have some time to test it and actually meet the release date (!)
14:19 <@cjd> what are your thoughts on a date
14:20 <@cjd> (how soon is ok from your end)
14:21 <vmassol> well we need to ask mflorea and tmortagne
14:21 <vmassol> since they're the one having the mos timportant stuff for it
14:21 <mflorea> has joined #xwiki
14:21 <vmassol> and sdumitriu too for the page generation module
14:21 <vmassol> what's the date btw?
14:21 <vmassol> cheking`...
14:21 <vmassol> 28th
14:21 <Enygma`> has quit
14:21 <Enygma`1> has joined #xwiki
14:22 <vmassol> so IMO we should start asking devs about their status
14:22 <vmassol> this week
14:22 <vmassol> so that we're ready by end of week
14:22 <vmassol> ready = ready to stage
14:22 <lucaa> has quit
14:22 <vmassol> s/stage/start staging/
14:23 <@cjd> If we want to release monday then we would need to be in staging for friday.
14:23 <@cjd> at the least
14:24 <vmassol> mflorea: this week is the last week before 4.1M2
14:24 <vmassol> (on next Monday)
14:25 <vmassol> hope you can have the merge UI ready by end of week :)
14:25 <+mflorea> I know, I hope too, I'm writing documentation now.. :)
14:25 <+mflorea> (to be able to close my issues)
14:26 <@cjd> end of the week == postpone the release, because that would only have us into staging by monday and then we'd need 2 or 3 more days for a decent release
14:26 <vmassol> cjd: not really
14:26 <vmassol> this is a milestone
14:26 <vmassol> there's no staging
14:26 <vmassol> that's the point of milestone
14:26 <vmassol> :)
14:26 <vmassol> otehrwise we don't need milestone
14:26 <+mflorea> cjd did staging for M1 afaik
14:26 <vmassol> it's either staging or milestones/rcs
14:27 <vmassol> yes but that's not our strategy
14:27 <vmassol> they're about achieving the same result
14:27 <@cjd> Do we do any testing of milestones before releasing?
14:28 <vmassol> well 2 things:
14:28 <vmassol> - devs must test their stuff
14:28 <vmassol> it's a must not a should
14:28 <vmassol> :)
14:28 <vmassol> - sburjan tries to test as much as possible but it's a best effort
14:28 <vmassol> his only strong commitment is a full func test before RC
14:29 <@cjd> ok and this is post-release testing when it's for a milestone?
14:29 <vmassol> (before or after rc is released, not sure anymore the exact proces)
14:29 <vmassol> the idea of milestones is basically to put it in the wid
14:29 <vmassol> to let our community a chance to test it for rea
14:29 <vmassol> real
14:30 <vmassol> s/wid/wild
14:30 <@cjd> I think whatever the process we use for finals and RCs we should also use for milestones
14:30 <@cjd> because then everything is a rehersal
14:30 <@cjd> perhaps the process should be abridged
14:31 <vmassol> sure , make a proposal
14:31 <vmassol> explain the issue and make a proposal
14:31 <vmassol> but
14:31 <vmassol> what wouldn't be good
14:31 <vmassol> is if you make the whole process longer
14:31 <vmassol> in your propsoal
14:32 <vmassol> the other bad thing would be if it requires more energy
14:32 <vmassol> from xwiki devs
14:32 <vmassol> the idea here is to spread energy
14:32 <vmassol> between devs and users so that users who get something free can contribute a bit too and help out
14:32 <vmassol> personally
14:33 <vmassol> I'm all for removing milestones/rcs compeltely
14:33 <vmassol> I've even propsoed that a few times ont he list
14:33 <vmassol> but that requires some conditions  and we were not ready so far
14:33 <@cjd> How do you see it working, I'm interested in hearing this..
14:33 <@cjd> ?
14:33 <vmassol> btw this is what I've been doing on several others projets before xwiki
14:34 <vmassol> it's simple but it requires good understanding from all devs
14:34 <vmassol> in short:
14:34 <vmassol> - you need good test coverage (about 70%)
14:34 <vmassol> - short releases
14:34 <vmassol> (around every 2 weeks)
14:35 <@cjd> Do we have major-ish releases every month and minor releases every 2 weeks?
14:36 <vmassol> you mean right now or in the scheme I'm dsicussing?
14:36 <@cjd> your proposal
14:36 <@cjd> or all releases are the same?
14:36 <vmassol> release are teh same
14:36 <vmassol> you just break big stuff
14:36 <vmassol> into smaller chunks
14:36 <@cjd> hmm
14:36 <@cjd> this is interesting
14:36 <vmassol> max is 2 weeks chunks
14:36 <@cjd> what kind of time span for staging?
14:36 <vmassol> ah another thing
14:37 <vmassol> anothe condition for success with this strategy
14:37 <vmassol> - you need to be able to easily upgrade an xwiki instance
14:37 <@cjd> upgrade button :D
14:37 <vmassol> the idea is that if someone get broken, you can be sure it'll be fixed within 2 weeks
14:37 <vmassol> (if it slips though)
14:37 <vmassol> but you need to be able to easily upgrade
14:37 <vmassol> so all users are almost always on the latest versions
14:38 <vmassol> you can have LTE though
14:38 <vmassol> LTS
14:38 <@cjd> so I think we need an autoupgrade feature if this is going to work
14:38 <vmassol> btw this can easily be implemented
14:39 <vmassol> using git feature branches
14:39 <vmassol> cjd: this is what we're currently developing :)
14:39 <vmassol> (autoupgrade)
14:39 <@cjd> how will it work?
14:39 <vmassol> this is why I was saying that till now we've not ready to do this kind of process
14:39 <@cjd> I see
14:39 <vmassol> re TPC we're about 40-50% overall I think
14:40 <vmassol> I need to recomput eit
14:40 <@cjd> including functional tests?
14:40 <vmassol> yes
14:40 <vmassol> let me check the latest figure I have put online
14:40 <@cjd> that means there is dead code IMO
14:40 <vmassol> http://dev.xwiki.org/xwiki/bin/view/Community/Testing#HTestCoverage
14:40 <vmassol> http://maven.xwiki.org/site/clover/20101017/
14:40 <vmassol> 53% at the time
14:40 <vmassol> not bad
14:41 <vmassol> so once we have autouprgade + 70% we're good to go! :)
14:41 <vmassol> we're getting closer
14:41 <vmassol> ;)
14:42 <vmassol> back to CLIRR, I'm checking why we have: "[ERROR] com.xpn.xwiki.doc.merge.MergeUtils: Class com.xpn.xwiki.doc.merge.MergeUtils removed"
14:43 <@cjd> How about the not shipping legacy? I didn't see any real decision on the list about not shipping it.
14:43 <vmassol> we're ok with the principle
14:43 <vmassol> now someone needs to propose how to do it in practice
14:43 <vmassol> we're ok with the principle = it's been voted
14:44 <@cjd> My concern is that not removing code is not a sustainable development method.
14:44 <vmassol> that' s different
14:44 <vmassol> that's the vote we did
14:44 <vmassol> and you voted +1
14:44 <@cjd> ok so now I have to propose breaking everyone and making them swap jar files around :D
14:44 <vmassol> if you have new doubt syou could start a new thread….
14:45 <vmassol> personally I don't see a problem
14:45 <vmassol> it takes a bit of time to move stuff to aspects sure but I don't think the time it takes is so huge that we shouldn't do it
14:45 <@cjd> ...which I happen to think is the proper level of difficulty given they are askign us to support old and potentially broken APIs which need to go away for the good of the code.
14:47 <@cjd> also moving more code out into legacy will help our non-legacy test coverage if we isolate and move out dead code, helping us in the other direction as well.
14:48 <vmassol> sure
14:48 <vmassol> this is our objective
14:48 <vmassol> re Mergeutils I've found the culprit: it's tmortagne in 550d59b77caf5d44e40d422d2d3ab740e8d8d943
14:49 <vmassol> strange commit message: "XWIKI-7761: The string merging is not very good during XAR merge"
14:49 <vmassol> he's changed from package com.xpn.xwiki.doc.merge; to package com.xpn.xwiki.internal.merge;
14:50 <vmassol> I see in the issue: "Making MergeUtils internal and moving to JDiff which provide a real 3-ways merge
14:50 <vmassol> API for now until we create a clean diff/merge tool (probably in commons)."
14:51 <evalica1> is now known as <evalica>
14:51 <vmassol> thomas is giving a training right now, waiting for him to finish
14:52 <vmassol> last issue is [ERROR] com.xpn.xwiki.objects.ObjectInterface: Method 'public com.xpn.xwiki.objects.classes.BaseClass getXClass(com.xpn.xwiki.XWikiContext)' has been added to an interface
14:52 <vmassol> checking it
14:53 <jvdrean1> has joined #xwiki
14:54 <vmassol> that's more of a problem
14:54 <jvdrean> has quit
14:56 <vmassol> I don't have a good solution for this one except not adding the new method to this interface and instead adding a new interface
14:56 <vmassol> or deciding to break some users ofc...
14:58 <@cjd> my feeling is that it's reasonable to expect that we have the only implementation of that interface. We might be wrong there but it's certainly not going to be like taking away searchDocuments or something.
14:58 <vmassol> well anyone having a custom displayer will be impacted
14:59 <@cjd> ahh
14:59 <@cjd> I glossed over it since there are so many interfaces which only exist to provide interchangability between our own internal implementations.
14:59 <vmassol> but my point is more general
14:59 <vmassol> how do we do to not break anything
15:00 <vmassol> I could only find 2 solutions:
15:00 <vmassol> 1) introduce a new interface and do some instanceof when using new methods
15:00 <vmassol> 2) add aspectj-like feature to the xwiki runtime (ie execute aspects at runtime)
15:01 <vmassol> for 2) it means introducing a default implementation of new methods when they're not provided
15:01 <vmassol> (with sensible default behaviors)
15:02 <vmassol> what thomas did cjd is just to add a new method to ObjectInterface
15:02 <vmassol> he added:
15:02 <vmassol> public BaseClass getXClass(XWikiContext context) throws XWikiException;
15:03 <vmassol> and he removed public BaseClass getxWikiClass(XWikiContext context) throws XWikiException; which he added back in an aspect
15:04 <vmassol> so the default impl of getXClass is simple here :)
15:04 <vmassol> just call getxWikiClass
15:04 <vmassol> (or rather do the same thing)
15:04 <vmassol> anyway 2) is some serious work
15:04 <@cjd> What would a custom displayer be?
15:05 <vmassol> well any class implementing ObjectInterface is impacted
15:05 <vmassol> and if you check our code you'll see
15:05 <vmassol> BaseClass, BooleanClass, ListClass, ....
15:06 <vmassol> so if you have your own MyTypeClass you're impacted
15:06 <vmassol> ie you need to recompile your code and add implementation for the new method
15:07 <vmassol> in this case I'm not sure why thomas did this since we want to rewrite displayers in the future anyway
15:08 <@cjd> ahh ok
15:09 <@cjd> indeed that is real, whereas a lot of interfaces would have almost no risk of impacting anyone
15:11 <@cjd> reminds me of the interface in hamcrest which has a function
15:11 <vmassol> btw that's till JDK 7 :)
15:11 <@cjd> _do_not_implement_this_interface_instead_extend_that_class()
15:12 <@cjd> oh yeah, that reminds me that we need to decide how we define "support java 6" because commons does not compile with 1.6.0_21 anymore
15:12 <@cjd> I gether they change the compiler a lot more than they do the vm
15:16 <vmassol> cjd: http://www.baptiste-wicht.com/2010/05/java-7-add-public-defender-methods-to-java-interfaces/
15:24 <@cjd> haha multiple inheritence
15:24 <@cjd> the circle of life has completed, and we're back at C++
15:24 <vmassol> I don't see it as multiple inheritance
15:25 <@cjd> I suppose it's ok as long as people don't start using it that way
15:26 <CIA-74> Vincent Massol master * r747fb06 https://github.com/xwiki/xwiki-platform/commit/747fb0685a30bf50310c0019c86c21fa36109135 / xwiki-platform-core/pom.xml : Add some CLIRR excludes and explain why - The Release Manager for 4.1 needs to read this carefullly... - http://git.io/dEderw
15:26 <vmassol> cjd: since you're the one who's going to release 4.1M2 and later you should check this last commit and tell me if you're ok with it
15:27 <vmassol> note: I still need to exclude MergeUtils+ObjectInterface but I want to add a discussion with thomas first
15:27 <vmassol> (and it's not exactly the same topic)
15:28 <@cjd> indeed
15:28 <@cjd> perhaps we can script this into maven?
15:28 <@cjd> profile based?
15:28 <vmassol> this is just one shot
15:28 <vmassol> you can do pass the versions on the command line if you want
15:28 <vmassol> s/do//
15:29 <@cjd> I'm quite sure that aj still uses these magic functions, I tested for them in M1 the other day
15:29 <vmassol> functions yes
15:29 <vmassol> but this is not about functions
15:29 <vmassol> it's about fields
15:30 <vmassol> the functions are located in a class named after the aspect
15:30 <vmassol> whereas the fields were injected in the weaved class in 1.6.7
15:30 <vmassol> they're still injected in 1.6.11 but as private and without special ajc$ stuff
15:31 <@cjd> ahh
15:31 <vmassol> ideally we should be able to find that in the relzase notes of http://www.eclipse.org/aspectj/
15:33 <vmassol> found it I think
15:33 <@cjd> public static com.xpn.xwiki.XWiki com.xpn.xwiki.api.XWiki.ajc$get$xwiki(com.xpn.xwiki.api.XWiki)
15:33 <vmassol> ep
15:33 <vmassol> :)
15:34 <vmassol> here: http://www.eclipse.org/aspectj/doc/released/README-169.html
15:34 <vmassol> search for "Intertype fields preserve visibility and name
15:34 <vmassol> "
15:34 <@cjd> public com.xpn.xwiki.XWikiContext com.xpn.xwiki.api.XWiki.ajc$superDispatch$com_xpn_xwiki_api_XWiki$getXWikiContext()
15:34 <@cjd> ^^this is 4.1M1
15:34 <@cjd> I just listed declared methods
15:34 <@cjd> and there are indeed public "magic methods"
15:34 <@cjd> which we must assume will come and go as they please.
15:35 <@cjd> And I gather this is with the new version of aj
15:37 <CIA-74> Vincent Massol master * r8225050 https://github.com/xwiki/xwiki-platform/commit/822505056407d574a3ecb870dcac2e867a56f4b2 / xwiki-platform-core/pom.xml : Add more information - http://git.io/4Q6aWA
15:37 <@cjd> So I think we must assume that aj is going to cause clirr errors basicly every time we modify anything todo with aj.
15:37 <vmassol> probably
15:39 <vmassol> clirr sources are here: http://clirr.cvs.sourceforge.net/viewvc/clirr/clirr/
15:39 <@cjd> so this means it adds to the workload of the RM in every release, not just one-off
15:39 <vmassol> not really
15:40 <vmassol> only if we change aspectj maven plugin
15:40 <vmassol> and that's not often
15:41 <@cjd> if we move a function to an aspect and it then needs to access private fields, it seems to me that it will inject another one of these secret accessor methods
15:43 <vmassol> it should be pretty easy to modify clirr to support excluding at method or field level IMO
15:44 <vmassol> the info is already there, see http://clirr.cvs.sourceforge.net/viewvc/clirr/clirr/core/src/java/net/sf/clirr/core/ApiDifference.java?revision=1.8&view=markup
15:45 <vmassol> I think we just need to change implementation of DiffListener: http://clirr.cvs.sourceforge.net/viewvc/clirr/clirr/core/src/java/net/sf/clirr/core/DiffListener.java?revision=1.3&view=markup
15:46 <vmassol> the info is  even already there in the xml diff listener: http://clirr.cvs.sourceforge.net/viewvc/clirr/clirr/core/src/java/net/sf/clirr/core/XmlDiffListener.java?revision=1.4&view=markup
15:47 <vmassol> IMO we don't even need to make a single line change in clirr itself
15:47 <vmassol> checking the mavne clirr plugin now
15:52 <jvelo> has joined #xwiki
15:53 <@cjd> Hi jvelo, what did you want to know about DataNucleusStore?
15:56 <polx> has joined #xwiki
15:56 <vmassol> cjd: ok I've checked the sources, it's easy to improve :)
15:57 <@cjd> awesome, I spent all that time trying to get cvs working...
15:57 <vmassol> you're looking at the wrog project :)
15:57 <@cjd> so glad we use git, everything else feels like a toy in comparison
15:57 <vmassol> as I said the clirr sources are ok they already provide the information
15:57 <vmassol> ie class, method, field
15:57 <vmassol> the only thing we need to improve is the clirr maven plugin
15:57 <vmassol> and that's easy to do
15:58 <@cjd> ahh so it's just the clirr maven plugin then
15:58 <vmassol> right now
15:58 <vmassol> the excludes is just used to filter what sources to add to the check
15:58 <vmassol> what we need is another set of exludes
15:58 <vmassol> to ignore violations
15:58 <vmassol> for whateever field or method we specify
16:03 <jvelo> Hi cjd . I've been looking at the code of "xwiki-platform-store-datanucleus-base" and I'm trying to unweave your vision about it :) I understand that the persistable class issued to store XClass definitions (defined as groovy JDO classes is that right ?) and that the persistable object is here of storing object instances. Now I'm trying to figure out how - and if - all that should fit with the notion of wiki documents (but not tal
16:03 <vmassol> I think I can modify the clirr plugin in 1 ?2 hours to add support for this… but not right now… ;)
16:03 <jvelo> about xwiki-platform-store-datanucleus-documents which is legacy for the "old core")
16:04 <jvelo> cjd: I see there is a JavaClassNameDocumentReferenceSerializer.java in base
16:04 <@cjd> f wiki documents (but not tal|<-- cut off
16:05 <jvelo> cjd: "the notion of wiki documents (but not talking about xwiki-platform-store-datanucleus-documents which is legacy for the "old core")"
16:05 <jvelo> sorry for the long post :)
16:05 <@cjd> -base is meant to be generic so it will work looking forward
16:06 <@cjd> the idea is that a user can define classes in the editor in the browser, they will be saved and instances can be persisted
16:06 <jvelo> OK. so it could actually be used outside XWiki
16:06 <@cjd> so a large amount of the server can actually exist inside of the database and take advantage of the versioning
16:07 <@cjd> yes, it's not xwiki(1.0) specific
16:07 <jvelo> cjd: yep I've figured that out, the browser IDE part
16:07 <@cjd> i wanted to prototype a possible way forward into xwiki2.0 model
16:07 <@cjd> basicly users write first class java (groovy) classes and persist them
16:07 <jvelo> cjd: I actually think this base should not even know the notion of wiki documents
16:08 <vmassol> cjd: FTR I've reported http://jira.codehaus.org/browse/MCLIRR-48 for now and I'll implement it when I get 2 hours of free time
16:08 <@cjd> The reason for the document element is because storage wants there to be a single reasonably small element like document
16:09 <jvelo> you mean like a container ?
16:09 <@cjd> storage systems like cassandra and mongodb want to have a single document like thing which is not too big and they can scan a table of them
16:10 <jvelo> I see
16:10 <@cjd> everything inside of the document is colocated together so it's fast to load, outside of the document it's an indexed table so it's fast to find a single one
16:10 <jvelo> and then objects reference that document is ?
16:10 <jvelo> ok
16:10 <@cjd> the way it's currently setup, every PersistableObject is in the table along with the document
16:11 <@cjd> there is a bug which I intend on fixing, DataNucleus puts the class name before the object name which breaks my db organization
16:11 <@cjd> I want to have the document be followed by each of it's objects to they are all adjacent to one another in the table
16:12 <@cjd> hence the careful creation of ID strings
16:14 <@cjd> the solution is to reorder the ID string so the class name follows the traditional ID rather than preceeding it, then Cassandra will place all objects of a document next to the document in storage and also allow for the loading of them all in a single range query.
16:14 <jvelo> but ultimately such documents doesn't have to be XWiki documents, right ? I mean this system could live outside XWiki ; and document IDs not be xwiki model representation
16:14 <@cjd> correct
16:14 <vmassol> mflorea: have you seen http://ci.xwiki.org/job/xwiki-platform/org.xwiki.platform$xwiki-platform-index-test-tests/2012/testReport/junit/org.xwiki.index.test.ui/AllDocsTest/org_xwiki_index_test_ui_AllDocsTest/ ? Have you changed FF on this agent?
16:15 <+mflorea> which agent?
16:15 <vmassol> agent1
16:15 <@cjd> of course it is documents with objects and classes, it "walks like a duck and quacks" so it's arguable that it is xwiki even if it's entirely a cleanroom implementation.
16:15 <+mflorea> yep, FF11
16:15 <vmassol> it's failing
16:15 <+mflorea> will ping infra
16:15 <vmassol> ok
16:16 <jvelo> cjd: sure, but in terms of nomenclature you don't necessarily have to call it a duck ;) you could call it a "node" for instance
16:16 <jvelo> and it would make sense
16:16 <@cjd> yes, it's designed to be generic
16:17 <jvelo> All this is very interesting. I want to experiment with the web IDE part
16:17 <@cjd> one nice fact about the "code as data" design is you can update a swarm of "cloud" nodes without having to login to each one.
16:18 <jvelo> yep. one drawback I see is that you lose the powerful features of the SCM
16:18 <jvelo> your data history is not going to be as powerful as what Git can bring for instance
16:18 <@cjd> git integration is a possibility once I get versioning to work.
16:19 <@cjd> I might not be up to implementing branching and merging
16:19 <jvelo> one thing that can be very nice is linking dynamically a DNS subdomain to a version of the code
16:20 <@cjd> hmm indeed
16:20 <@cjd> or any kind of url match
16:20 <jvelo> yep
16:20 <jvelo> subdomain is good, because it doesn't interfere with your app URL api
16:21 <@cjd> either have to bake it directly in to the code or have some aweful magic with the latest version checking out an older version
16:22 <@cjd> and potentially not something you want people being able to do
16:29 <jvelo> cjd: also, I gave a try to your wiki-nodes.sh
16:29 <jvelo> this runs with an embedded cassandra ?
16:29 <@cjd> yes, cassandra is in-vm with all of that stuff
16:30 <@cjd> I'd like to eventually look at optimizing around thrift so it's a single thread from HTTP to disk and back.
16:30 <jvelo> ok, it's kind of the hsqldb of nosql
16:30 <@cjd> IMO it's the best way.
16:30 <jvelo> cjd: but not in production ?
16:30 <@cjd> Saves a huge amount of ram since java is *cough* pig *cough* not optimized that well
16:31 <@cjd> I don't see why it should not be used in production.
16:31 <jvelo> ok
16:32 <jvelo> well then it has only advantages I guess:) caus' it also simplifies deployment
16:32 <@cjd> If there are solid reasons then I'm glad to hear them but I feel like people put together highly fragile and bug prone stacks just because they use lots of big brand name applications and that is just silly
16:35 <jvelo> cjd: but the in-vm setup is different than installing cassandra on the machine right ?
16:35 <jvelo> I mean, is this something they recommend ?
16:35 <@cjd> no, they don't recommend it at all
16:36 <@cjd> they don't say it's bad, they don't seem to consider the possiblity at all
16:36 <sdumitriu> has joined #xwiki
16:36 <@cjd> I want control over the stack so I can handle bugs
16:37 <jvelo> I see
16:37 <jvelo> there's no performance penalty ?
16:37 <@cjd> no because there are always too many threads for whatever you're doing
16:37 <jvelo> how does it work, like an in-memory store ?
16:38 <@cjd> nah, it memory maps big files
16:38 <@cjd> which is why it's slow on 32 bit machines
16:38 <@cjd> on 32 bit it has to use NIO which is slower than mmap()ing the whole file
16:49 <jvelo> cjd: how do you see thrift fit in this picture ?
16:50 <@cjd> the only place where thrift plays a part is as the annoying thing which sits between me and cassandra
16:50 <jvelo> isn't thrift an IDL ?
16:50 <@cjd> IDL?
16:50 <jvelo> iterface definition language
16:50 <jvelo> like CORBA
16:50 <@cjd> ahh yes it's serialization and RPC
16:50 <@cjd> but the cassandra devs don't seem to like it too much
16:51 <@cjd> new features need to be implemented inside of cassandra then added to the thrift client
16:51 <@cjd> so it's likely to be deprecated over time
16:52 <@cjd> What I'm interested in is getting the internal listening code in cassandra and figuring out how to hook it so I can have the same performance as HSQL
17:02 <tmortagne> has joined #xwiki
17:22 <gdelhumeau> has quit
17:27 <vmassol> fixing remainig 2 clirr excludes
17:35 <polx> has quit
17:37 <polx> has joined #xwiki
17:40 <polx> has quit
17:50 <tmortagne> has quit
17:54 <+sburjan> http://jira.xwiki.org/browse/XE-1175?focusedCommentId=70604#comment-70604
17:55 <sburjan> has quit
18:02 <npm> I'm seeing something like http://jira.xwiki.org/browse/XWIKI-7549 happen for my macros (not extensions) after restart. Saving as user w/ programming rights seems to make them stop giving "unknown macro" error after tomcat restart
18:03 <npm> is that issue fixed in 3.5.1? (i'm on 3.5)
18:05 <npm> this didn't happen back when it was setup as a non-virtual wiki, but when i switched to virtual, http://www.nielsmayer.com/bin/view/Macros/YouTubeCaptioner_Test would poot regularly after a restart
18:09 <npm> what i'm seeing is more like http://jira.xwiki.org/browse/XWIKI-6180
18:09 <npm> Wiki Macro loses its PR and becomes unregistered
18:10 <mflorea> has quit
18:15 <mflorea> has joined #xwiki
18:28 <Enygma`1> has quit
18:28 <Enygma`> has joined #xwiki
18:44 <evalica> has quit
18:47 <Enygma`> has quit
19:03 <npm> i've just confirmed that the issue w/ macros has to do w/ them being "global" if set to "current wiki" then they work after restart in a virtual wiki
19:03 <npm> on 3.5
19:04 <npm> is this fixed in 3.5.1 or 4.X?
19:04 <npm> or should I reopen http://jira.xwiki.org/browse/XWIKI-6180
19:14 <jvdrean1> has quit
19:42 <rrodriguez> has joined #xwiki
19:58 <abusenius> has joined #xwiki
20:08 <mflorea> has quit
20:42 <polx> has joined #xwiki
20:53 <mflorea> has joined #xwiki
21:56 <jvdrean> has joined #xwiki
22:01 <sburjan`> has quit
22:01 <sburjan`> has joined #xwiki
22:37 <Denis1> for velocity date manipulation, what is better: datetool or jodatime ?
22:37 <Denis1> is now known as <Denis>
22:37 <@sdumitriu> Depends
22:38 <@sdumitriu> Jodatime is better for more complex date manipulation
22:38 <@sdumitriu> Btw, which datetool?
22:38 <+Denis> $datetool
22:39 <+Denis> this is velocity datetool, and I wonder why we have both in fact
22:40 <@sdumitriu> datetool is good for smaller tasks
22:40 <+Denis> I prefer yodatime, easier to develop, but I would like to know if it is a good choice, since what I should do is simple: add 1 day, and format ISO 850 and 8601
22:41 <@sdumitriu> And I'd say it's better to use that one, since $xwiki.jodatime is using a deprecated mechanism (plugins) and it's going to be replaced by a service soon enough
22:41 <+Denis> ok
22:41 <@sdumitriu> Well, $datetool doesn't have a simple "add one day" method
22:41 <@sdumitriu> So it's better to use joda here
22:44 <+Denis> a Calendar could do that
22:45 <+Denis> and datetool provide toCalendar()
23:00 <+Denis> but you cannot do anything with it :(
23:00 <+Denis> so Joda is my friend !
23:17 <mflorea> has quit
23:29 <vmassol> has quit
23:34 <slugz> has joined #xwiki
23:51 <abusenius> has quit
23:53 <slugz> has quit