IRC Archive for channel #xwiki on 20 March 2014
<abusenius_> has quit
00:06 <vmassol> has quit
00:15 <risherry> has quit
00:32 <vmassol> has joined #xwiki
00:42 <sbaloul> has quit
01:36 <OSIMasson> has joined #xwiki
01:37 <OSIMasson> has quit
01:38 <OSIMasson> has joined #xwiki
02:13 <OSIMasson> has quit
02:27 <Denis> has quit
02:29 <OSIMasson> has joined #xwiki
02:31 <OSIMasson> has quit
02:38 <OSIMasson> has joined #xwiki
02:45 <OSIMasson> has quit
02:52 <OSIMasson> has joined #xwiki
03:02 <OSIMasson> has quit
03:36 <OSIMasson> has joined #xwiki
03:36 <OSIMasson> has left #xwiki
04:30 <Denis> has joined #xwiki
04:41 <Chuguniy> has quit
05:40 <vmassol> has quit
06:02 <Denis> has quit
06:38 <andreeapopescu> has joined #xwiki
06:57 <sbaloul> has joined #xwiki
06:59 <evalica> has joined #xwiki
07:03 <mflorea> has joined #xwiki
07:26 <polx> has joined #xwiki
07:43 <polx> has quit
07:58 <vmassol> has joined #xwiki
08:07 <mflorea> has quit
08:10 <mflorea> has joined #xwiki
08:11 <mflorea> vmassol: ping
08:11 <vmassol> hi mflorea
08:11 <mflorea> is there a way to serialize and resolve a document reference with locale?
08:12 <vmassol> no
08:12 <mflorea> 
08:12 <vmassol> there's no text format with the locale
08:12 <vmassol> doesn't exist
08:12 <vmassol> the concept of locale currently only exists at the Java Object level
08:12 <vmassol> (ie DocumentReference)
08:12 <mflorea> so if I want to target a specific locale with a request I have to send to parameters, the document reference and the locale
08:13 <vmassol> yes
08:13 <vmassol> or
08:13 <vmassol> you create the DocumentReferene
08:13 <vmassol> and add the locale
08:13 <vmassol> that's hte best actually
08:13 <vmassol> and is what we do in other places
08:13 <mflorea> and?
08:13 <mflorea> how do I parse it on the server?
08:14 <vmassol> again, if you want to pass a ref and locale you can pass a documentreference as a single parameter of a method
08:14 <mflorea> s/parse/resolve
08:14 <vmassol> now if you ask user input
08:14 <mflorea> I'm not talking about calling a method, I'm talking about submitting a request
08:15 <vmassol> you'll need to ask for both ref and locale
08:15 <vmassol> and add the locale
08:15 <vmassol> as I said you cannot resolve/serialize w/ locales
08:15 <vmassol> as there's no textual representation
08:15 <vmassol> that would need to be invented
08:15 <mflorea> it's a pain when you have a "document picker" where you can select multiple values, including document translations
08:16 <vmassol> and it's not just locale
08:16 <vmassol> it's also versions
08:16 <vmassol> if you want to pick a given version of a doc
08:16 <vmassol> yes it's a pain
08:17 <mflorea> indeed, but that's not my case 
08:17 <mflorea> anyway, I'll find a way
08:17 <vmassol> I proposed some textual representation options in the past on yhe list
08:17 <vmassol> *the
08:17 <mflorea> sending two parameters probably
08:17 <vmassol> basically we need a way to define parameters
08:17 <mflorea> reference parameters
08:18 <vmassol> yes
08:18 <vmassol> we have it at the java level but not at the text level
08:18 <vmassol> something like:
08:18 <vmassol> wiki:space.page[param1=value1,param2=value2]
08:18 <vmassol> but not that we will have to break backward compat
08:18 <vmassol> *note
08:19 <vmassol> but could be done intelligently
08:19 <vmassol> to not break much
08:19 <msmeria> has joined #xwiki
08:19 <vmassol> (for example checking for […] AND for 2 texts surrounded by an equal sign as a minimum
08:19 <vmassol> )
08:19 <mflorea> indeed
08:21 <vmassol> was discussed quickly at http://markmail.org/thread/rjtoldp6wntf662h
08:22 <polx> has joined #xwiki
08:24 <tmortagne> has joined #xwiki
08:47 <vmassol> tmortagne: I'm here
08:48 <tmortagne> found my window
08:48 <vmassol>
08:48 <woshilapin> has joined #xwiki
08:48 <tmortagne> do we have a release manager for 5.4.3 ?
08:48 <vmassol> better loose one's window than one's mind 
08:49 <vmassol> it's guillaumeD
08:49 <polx> has quit
08:49 <tmortagne> ok
08:51 <vmassol> mflorea: are we ready for 5.4.3 release today?
08:52 <vmassol> I see 2 issues are still open
08:52 <vmassol> http://jira.xwiki.org/issues/?filter=12712&jql=category%20in%20(%22Top%20Level%20Projects%22)%20AND%20fixVersion%20in%20(%225.4.3%22)%20AND%20resolution%20in%20(Unresolved)%20AND%20component%20not%20in%20(%22Development%20Issues%20only%22)
08:52 <mflorea> I'm not sure, I'm finishing http://jira.xwiki.org/browse/XWIKI-9595
09:01 <sbaloul> has quit
09:07 <sbaloul> has joined #xwiki
09:17 <Denis> has joined #xwiki
09:21 <polx> has joined #xwiki
09:21 <vmassol> forgot to announce the XWiki Day today
09:21 <vmassol> sorry about that
09:21 <vmassol> so what do you want to do?
09:27 <vmassol> what about a "Violation Fixing Day"?
09:27 <vmassol> "reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform)"
09:28 <vmassol> tmortagne, mflorea, Denis, evalica, wdyt?
09:29 <tmortagne> Code Coverage would be nice
09:29 <evalica> well… if we are doing this than I'm going to work on apps
09:29 <vmassol> code coverage, ok for me
09:30 <vmassol> unit tests level?
09:30 <vmassol> or both unit and functional?
09:31 <vmassol> both is best, it's just harder to measure
09:31 <vmassol> ok we can count the # of tests added (unit and functional)
09:31 <tmortagne> do we have easy metric for functional tests to do before after ?
09:31 <tmortagne> it's easy with unit tests
09:32 <vmassol> we can get the total #
09:32 <vmassol> of tests that is
09:32 <vmassol> it's easy to know how many more we've added
09:32 <tmortagne> well coverage is more important than number of tests IMO
09:32 <vmassol> and then sonar provides figures
09:32 <vmassol> sure
09:32 <vmassol> the only problem is that platform on sonar doesn't work becuase of VNC
09:32 <tmortagne> that's for integration tests
09:32 <vmassol> see http://sonar.xwiki.org/
09:33 <vmassol> (overall coverage column)
09:36 <mflorea> I'm fine with either of them, violations and code coverage
09:37 <vmassol> mail sent
09:41 <tmortagne> vmassol: like with the deprecation fixing day we should probably annonce what module we are starting to work on as a response to your mail
09:41 <vmassol> fine
09:49 <mflorea> vmassol: would be probably good to rewrite some of the existing unit tests using mockito
09:49 <vmassol> mflorea: yes indeed, we should not add more tests using old ways
09:49 <vmassol> if we want to add a new tests in a "oldish" test class, we should update the class
09:50 <mflorea> yep
09:51 <tmortagne> +1
09:59 <cjd> has joined #xwiki
10:11 <mflorea> has quit
10:13 <woshilapin> has quit
10:20 <woshilapin> has joined #xwiki
10:20 <ClemensR> has joined #xwiki
10:26 <GuillaumeF> has joined #xwiki
10:45 <mflorea> has joined #xwiki
10:47 <gdelhumeau> has joined #xwiki
10:48 <msmeria1> has joined #xwiki
10:49 <lucaa> has joined #xwiki
10:52 <msmeria> has quit
11:16 <lucaa> has quit
11:54 <xwikibot> has joined #xwiki
12:11 <lucaa> has quit
12:14 <xwikibot> has joined #xwiki
12:27 <cjd> has joined #xwiki
12:41 <Slashman> has joined #xwiki
12:43 <lucaa> has joined #xwiki
13:35 <polx> has quit
13:36 <polx> has joined #xwiki
13:38 <polx> has quit
13:42 <evalica> has quit
13:44 <msmeria1> gdelhumeau: hi
13:44 <gdelhumeau> hi msmeria1
13:45 <msmeria1> I see that after migrating to 5.4.3 I still don't see the templatexe subwiki in the Wiki Index
13:45 <msmeria1> I remember talking to you about this
13:46 <msmeria1> I migrated from 4.5.4 to 5.4.3-snapshot
13:48 <gdelhumeau> it might be: http://jira.xwiki.org/browse/XWIKI-10091 isnt it?
13:49 <msmeria1> gdelhumeau: yes, that's exactly the issue
13:49 <gdelhumeau> we have not provided any fix about this
13:49 <msmeria1> I thought it was supposed to be fixed
13:49 <gdelhumeau> I think me need, once again, a migrator
13:49 <gdelhumeau> WDYT tmortagne, vmassol, mflorea?
13:50 <vmassol> why not list them?
13:50 <vmassol> (instead of providing a migrator)
13:51 <vmassol> we can't write a query that returns results when the prettyname is not defined?
13:52 <vmassol> ok I've read the issue, so it seems the issue is the "order by prettyname"
13:54 <vmassol> so we'll have the same issue if someone creates a wiki descriptor without a pretty name
13:54 <vmassol> ?
14:08 <tmortagne> I doubt it since you will get empty string as a minimum I guess if you go trough the API
14:08 <tmortagne> it's the general issue we have in many places with queries on object having missing properties
14:12 <polx> has joined #xwiki
14:28 <vmassol> gdelhumeau: so I guess this is a blocker for 5.4.3 ?
14:28 <vmassol> I wonder why it wasn't scheduled for 5.4.3?
14:31 <andreeapopescu> has quit
14:31 <msmeria1> vmassol: hello
14:32 <msmeria1> I'm looking at XWIKI-10114
14:32 <msmeria1> I've tested on both 3.4m1 and 5.4.3 and don't see any issue
14:32 <msmeria1> can you give me more details ?
14:37 <vmassol> msmeria1: see https://github.com/xwiki/xwiki-platform/commit/f8e57df06de241cff9896d24ecd5e21f0c8640d0
14:38 <vmassol> so the issue is when using the "reference" parameter
14:38 <vmassol> as you can see at line 6402 it only checks for "document"
15:03 <polx_> has joined #xwiki
15:03 <polx> has quit
15:25 <vmassol> gdelhumeau: ping, see message above
15:27 <gdelhumeau> yep
15:27 <gdelhumeau> I was looking at it
15:27 <gdelhumeau> It seems a migrator seems necessary
15:27 <vmassol> when will you be able to fix it? we're really late for 5.4.3
15:28 <vmassol> (and thus becoming even later for 6.0 )
15:28 <gdelhumeau> I just commit my stuff right now about Code coverage and I switch to it
15:28 <vmassol> mflorea: any ETA on your side for 5.4.3? yesterday you mentioend you'd have finished yesterday so I assume you're close?
15:29 <vmassol> gdelhumeau: we need your fix before tommorrow ideally because you're not here tomorrow and we need to release
15:30 <mflorea> I'm close, hope to finish today
15:37 <msmeria1> has quit
15:56 <polx> has quit
16:11 <sbaloul> Hi everyone,
16:12 <sbaloul> I tried to release forum application, unfortunately, maven release:perform fails due to this rule :
16:12 <sbaloul> <rules>
16:12 <sbaloul> <evaluateBeanshell>
16:12 <sbaloul> <message>Missing Javadoc JAR</message>
16:12 <sbaloul> </evaluateBeanshell>
16:13 <sbaloul> in the plugin org.apache.maven.plugins:maven-enforcer-plugin:1.0.1
16:13 <sbaloul> maven message :
16:13 <sbaloul> [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-javadoc-exists) @ application-forum ---
16:13 <vmassol> sburjan: you should use pastebin, gist, etc
16:14 <vmassol>
16:14 <sbaloul> of course
16:14 <vmassol> (next time)
16:14 <sbaloul>
16:14 <sbaloul> Thanks for tip
16:14 <sbaloul> As I'm running maven under windows os, the condition in the rule always fails.
16:14 <vmassol> your project is a xar
16:14 <sbaloul> yes
16:14 <vmassol> so I'm not sure why the rule fails
16:14 <tmortagne> yep seems weird
16:15 <tmortagne> what version of maven are you using ?
16:15 <sbaloul> this fails :
16:15 <vmassol> maybe windows
16:15 <vmassol> you seem to be on windows
16:15 <vmassol> it's very possible it doesn't work on windows
16:15 <sbaloul> because it can be parsed as JAVA OR GROOVY
16:15 <vmassol> as I can see there's a mix of \ and /
16:16 <vmassol> now the File() shouldn't even be evaluated normally
16:16 <sbaloul> the \ must be replaced by \\
16:16 <tmortagne> it should not even try to find the javadoc so windows should not be an issue (a this mix works on windows anyway)
16:16 <sbaloul> int " "
16:16 <sbaloul> in the " "
16:16 <vmassol> what JDK are you using?
16:17 <sbaloul> I used both 7 and 6
16:17 <sbaloul> I tried the both ones
16:17 <sbaloul> "a\a\" is syntax error in java
16:17 <sbaloul> the correct one is "a\\a\\a"
16:18 <sbaloul> so why the condition fail in windows
16:18 <sbaloul> because path use \
16:18 <tmortagne> yes it's probably because we end up with \ for the base path in windows
16:20 <cjd> 16:14 < sbaloul> As I'm running maven under windows os <-- if there's any way at all that you can change this, overall you'll find your life to be much more pleasent afterwords.
16:20 <tmortagne>
16:20 <sbaloul>
16:20 <tmortagne> (but true, doing command line on Windows is a nightmare compared to any Unix)
16:21 <vmassol> btw you should use cygwin under windows for building xwiki or you'll have issues
16:21 <vmassol> (with long path names)
16:21 <tmortagne> I don't thin he have very long path in this plugin
16:22 <vmassol> actually that's not true
16:22 <vmassol> he'll have problems when running XE
16:22 <vmassol> with long path names in the xwiki data dir
16:22 <vmassol>
16:22 <sbaloul> I'm going to use a ubuntu vmware
16:22 <sbaloul> I'm installing git and maven
16:22 <tmortagne> note that long path issue is now fixed
16:22 <tmortagne> see https://github.com/msysgit/git/pull/85
16:22 <tmortagne> in git 1.9
16:22 <vmassol> so that you can fix our build on windows!
16:22 <vmassol>
16:23 <vmassol> it would be nice that it work on window
16:23 <vmassol> *windows
16:23 <sbaloul> Ok
16:25 <vmassol> so we need to replace \ with / in ${project.build.directory} IMO
16:25 <vmassol> for: <condition>("${project.packaging}" != "jar") || ("${project.packaging}" == "jar" && new java.io.File("${project.build.directory}/${project.build.finalName}-javadoc.jar").exists())</condition>
16:25 <vmassol> I would have expected ${project.build.directory} to contain only "/"
16:26 <vmassol> since this is from java
16:26 <vmassol> and in java the separator is "/"
16:26 <tmortagne> vmassol: no
16:26 <tmortagne> the separator is not / in java
16:26 <tmortagne> it depends of the system, there is no special java path separator
16:26 <vmassol> it is /
16:27 <vmassol> all the java api uses "/"
16:27 <tmortagne> what java API ?
16:27 <vmassol> File, etc
16:27 <vmassol> everything in java always use "/"
16:28 <cjd> Windows will accept /
16:28 <cjd> but it will always provide crazy \
16:28 <vmassol> sure but even indepently of this cjd
16:29 <ClemensR> Java under windows seems even to accept all kind if crazy combinations between \ and / in my experience
16:29 <tmortagne> vmassol: I don't think you read the javadoc
16:29 <tmortagne> the separator depend on the system in Java
16:29 <cjd> http://stackoverflow.com/a/2417546
16:29 <tmortagne> "The default name-separator character is defined by the system property <code>file.separator</code>, and is made available in the public static fields <code>{@link #separator}</code> and <code>{@link #separatorChar}</code> of this class."
16:29 <cjd> looks like vmassol is correct, Today I Learned....
16:29 <sbaloul> maven uses "\" as file separator on windows, I'm not sur, but the parameter ${project.build.directory} contains \ as separator
16:30 <vmassol> tmortagne: that's something else
16:30 <tmortagne> ClemensR: it's not java, windows itself accept /
16:30 <vmassol> it's not because java defined path.separator that have you to use it
16:30 <ClemensR> ah, ok, thats why
16:30 <vmassol> it's for when you need to
16:30 <vmassol> for example
16:30 <vmassol> when you have some user input
16:30 <vmassol> but if you use the java api I believe you just need to use "/"
16:31 <cjd> ``This also might be a problem with the performance, since you are expecting the separator to be converted into something else at runtime.'' <-- comment of the day
16:31 <vmassol> well doing complex replaces is not better from performance POV
16:32 <vmassol> I wouldn't use this as something to care about
16:32 <cjd> yeah
16:32 <vmassol> I've always used "/" and I've always been happy so far…
16:32 <cjd> windows accepts it so it's ok, just be careful of the crap it will provide you with when you ask for a file's path
16:33 <sbaloul> jvm converts paths according to underlying os
16:33 <vmassol> yep
16:33 <sbaloul> but in java code we use only "/"
16:33 <vmassol> exactly
16:34 <sbaloul> but in java that runs on windows accepts \ as seprator too
16:35 <vmassol> sure but then you need to use File.SEPARATOR as otherwise you're becoming os-specific
16:35 <vmassol> (and you need to escape it ofc)
16:35 <polx> has joined #xwiki
16:36 <cjd> For me, seeing File.SEPERATOR is a sign that someone has too much time on their hands...
16:36 <vmassol> yup
17:04 <polx> has quit
17:09 <sbaloul> I think this could be a solution
17:09 <sbaloul> http://hastebin.com/yasuxopede.xml
17:09 <sbaloul> the plugin usage (that I used to make replacement) http://mojo.codehaus.org/build-helper-maven-plugin/usage.html
17:25 <vmassol> this is too compelx sbaloul
17:25 <vmassol> you just need to replace the chars
17:25 <vmassol> you replace File.SEPARATOR by "/"
17:25 <vmassol> or \ by /
17:25 <vmassol> using beanshell
17:31 <sbaloul> Ok Vincent, I'll try to use File.SEPARATOR using beanshell
17:34 <sbaloul> vmassol : if you think about using "${project.build.directory}".replaceAll("\\\\", "/")
17:34 <sbaloul> in condition
17:34 <sbaloul> that won't be work
17:35 <sbaloul> we get the same issue as we have just had
17:37 <sbaloul> "${project.build.directory}".replaceAll("\\\\", "/") ===> "D:\p1\p2\p3".replaceAll("\\\\", "/")
17:39 <tmortagne> you sure ${project.build.directory} is resolved before beanshell script is executed ?
17:39 <sbaloul> "D:\p1\p2\p3" this string doesn't follows java syntax (to put \ in literal string we have to use \\ )
17:39 <sbaloul> Yes
17:40 <tmortagne> then yes it's going to be hard
17:40 <sbaloul> message of maven :
17:40 <sbaloul> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.EvaluateBeanshell failed with message:
17:40 <sbaloul> Couldn't evaluate condition: ("xar" != "jar") || ("xar" == "jar" && new java.io.File("D:\dev\git\xwiki-app\application-forum2\target\checkout\target/application-forum-1.1-SNAPSHOT-javadoc.jar").exists())
17:40 <tmortagne> right
17:40 <sbaloul> I suggest this solution http://hastebin.com/yasuxopede.xml
17:41 <sbaloul> but according to vmassol, it's too complex
17:42 <Chuguniy> has joined #xwiki
17:51 <andreeapopescu> has joined #xwiki
17:55 <OSIMasson> has joined #xwiki
17:59 <woshilapin> has quit
18:00 <tmortagne> has quit
18:10 <polx> has joined #xwiki
18:10 <polx> has quit
18:13 <ClemensR> anyone knows where to look how stable the tests are currently ?
18:13 <gdelhumeau> vmassol: XWIKI-10091 fixed
18:13 <ClemensR> I would like to check in a new integration test - with my luck I am sure to break something ....
18:18 <polx> has joined #xwiki
18:18 <polx> has quit
18:20 <ClemensR> I guess I better wait till tomorrow with pushing my stuff ...
18:21 <cjd> has quit
18:22 <lucaa> has quit
18:31 <polx> has joined #xwiki
18:37 <lucaa> has joined #xwiki
18:40 <vmassol> gdelhumeau: cool
18:40 <vmassol> ClemensR: ci.xwiki.org
18:40 <vmassol> not in a good shape ATM
18:41 <ClemensR> ah, ok, its still god old jenkins .... the activeinstall test that fails there is nothing I can reproduce locally
18:41 <vmassol> seems thomas broke stuff
18:41 <vmassol> activeinstalls fails?
18:41 <vmassol> java.lang.NoClassDefFoundError: Failed to get fields for class [org.xwiki.extension.repository.aether.internal.AetherExtensionRepositoryFactory] because the class [org/codehaus/plexus/component/repository/exception/ComponentLookupException] couldn't be found in the ClassLoader.
18:42 <vmassol> that's probably related to the change thomas did
18:42 <vmassol> we updated maven
18:42 <vmassol> s/we/he
18:42 <vmassol> so all tests are going to fail since XE doesn't start
18:42 <vmassol> because of this
18:42 <ClemensR> the failing module in xwiki-platform is "XWiki Platform - Active Installs - Tests - Functional Tests" - see http://ci.xwiki.org/job/xwiki-platform/5165/consoleText (very long log ...)
18:43 <ClemensR> but these tests pass locally ... so it is maybe a flicker
18:43 <ClemensR> anyway, I see I better wait for tomorrow or next week, when the dust hopefully has set
18:44 <vmassol> where od you see it failing?
18:44 <vmassol> it's passing on http://ci.xwiki.org/job/xwiki-platform/5166/consoleFull
18:44 <GuillaumeF> has quit
18:44 <vmassol> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
18:44 <mflorea> has quit
18:45 <vmassol> you can search for "org.xwiki.activeinstalls.test.ui.AllTests"
18:45 <ClemensR> ah, good, then it passed on the next run, and it was just a fluke
18:45 <ClemensR> it runs for me locally, too ... so it was just jenkins in bad mood, as usual
18:46 <vmassol> it wasn't an activeinstall issue
18:46 <vmassol> but a packager plugin ussue
18:46 <vmassol> Caused by: java.io.FileNotFoundException: JAR entry META-INF/components.txt not found in /home/hudsonagent/hudson_root/workspace/xwiki-platform/.repository/org/xwiki/commons/xwiki-commons-component-api/6.0-SNAPSHOT/xwiki-commons-component-api-6.0-SNAPSHOT.jar
18:46 <vmassol> actually not even a packager issue
18:46 <vmassol> I got this one too and I fixed it locally by removing the bad dependency from my local repo
18:47 <vmassol> (not this exact same issue but something similar)
18:47 <vmassol> I don't know the reason for it
18:47 <vmassol> so
18:47 <vmassol> the issue that exist now is the aether issue
18:47 <vmassol> which prevents XE to start
18:48 <lucaa> has quit
18:50 <polx> has quit
19:00 <lucaa> has joined #xwiki
19:03 <ClemensR> has quit
19:04 <lucaa> has quit
19:26 <Slashman> has quit
19:49 <OSIMasson> has quit
19:55 <sbaloul> has quit
19:58 <gdelhumeau> has quit
19:59 <lucaa> has joined #xwiki
20:05 <lucaa> has quit
20:08 <abusenius_> has joined #xwiki
20:22 <sbaloul> has joined #xwiki
20:46 <vmassol> has quit
20:59 <sbaloul> has quit
21:07 <andreeapopescu> has quit
21:27 <polx> has joined #xwiki
22:36 <polx_> has joined #xwiki
22:39 <polx> has quit
22:55 <lucaa> has joined #xwiki
22:57 <vmassol> has joined #xwiki
23:01 <vmassol> has quit
23:26 <OSIMasson> has joined #xwiki
23:42 <OSIMasson> has left #xwiki
23:57 <vmassol> has joined #xwiki
