IRC Archive for channel #xwiki

Last modified by Vincent Massol on 2012/10/18 19:18

00:07 <polx> has quit
02:24 <jvdrean> has quit
03:11 <mar3lis> has quit
04:41 <venkatesh> has joined #xwiki
04:42 <venkatesh> has quit
04:49 <DrLou> has quit
04:57 <DrLou> has joined #xwiki
05:01 <venkatesh> has joined #xwiki
05:06 <DrLou> has quit
07:41 <mflorea> has joined #xwiki
08:11 <Chami1> has joined #xwiki
08:16 <vmassol> has joined #xwiki
08:27 <Denis> has joined #xwiki
08:36 <bbc581> has quit
08:37 <bbc581> has joined #xwiki
09:10 <arkub> has joined #xwiki
09:11 <cjdelisle> has quit
09:13 <cjdelisle> has joined #xwiki
09:23 <sdumitriu> has joined #xwiki
09:23 <@sdumitriu> cjdelisle: Did you disable building all the branches from jenkins?
09:25 <@cjdelisle> yes and I added the M1 jobs
09:30 <@cjdelisle> rebuilding platform since the problem seems to be a flicker
09:35 <@cjdelisle> Where do I download the translations from l10n?
09:39 <sburjan> has joined #xwiki
09:39 <@sdumitriu>
09:40 <@sdumitriu> There are links to download "Get as Application Resource pack"
09:40 <@sdumitriu> In the table
09:40 <@cjdelisle> thanks
09:40 <@sdumitriu> If you don't see them, decrease font size, or increase window width
09:40 <bbc581> has quit
09:45 <jvdrean> has joined #xwiki
09:50 <tmortagne> has joined #xwiki
10:19 <Chami1> has quit
10:19 <Enygma`> has joined #xwiki
10:27 <pulasthi> has joined #xwiki
10:28 <pulasthi> has left #xwiki
10:42 <lucaa> has quit
10:50 <vmassol> found that on github you can also notify a developer by using his id in a comment for ex
10:51 <vmassol> (by prefixing with '@')
10:53 <+sburjan> what's with the 3.1M1-SNAPSHOT dir on maven ?
10:53 <@sdumitriu> The builds for the upcoming release
10:54 <@cjdelisle>
10:54 <+sburjan> well this is new.. at least for me
10:55 <+tmortagne> yep this is
10:55 <+sburjan> did we change the release procedure ?
10:55 <+sburjan> let me check the mailing list
10:56 <sburjan`> has quit
10:58 <@cjdelisle> heh more like an informal change which was decided on irc
10:59 <+sburjan> so which one is trunk atm ?
11:00 <@cjdelisle> trunk is 3.1-SNAPSHOT but since that is not going to be released for a few more weeks and M1 is going to be released today, it makes sense to test M1
11:02 <+tmortagne> sburjan: trunk is still the same but if what you want to validate what will be release then use 3.1M1-SNAPSHOT
11:03 <@cjdelisle> Are all of the translations for wysiwyg here?
11:03 <+tmortagne> since trunk could contains others unstable things not planned for M1 which is why this branch has been created (to not block trunk)
11:03 <@cjdelisle> Or are there others hiding somewhere else?
11:03 <+tmortagne> cjdelisle: they are all here
11:03 <@cjdelisle> thanks
11:05 <arkub> has quit
11:21 <arkub> has joined #xwiki
11:23 <@cjdelisle> If I'm going to do any releasing on jira I'm going to have to have permission
11:25 <+tmortagne> cjdelisle: looking
11:25 <lucaa> has joined #xwiki
11:26 <+tmortagne> cjdelisle: should be ok now
11:26 <+tmortagne> (you are admin)
11:27 <@cjdelisle> thanks
11:30 <evalica> has joined #xwiki
11:31 <@cjdelisle> Is manager not released in milestones?
11:31 <@sdumitriu> Nope
11:31 <@sdumitriu> That was the practice so far
11:31 <@sdumitriu> We could change it, since it's easier to release it
11:31 <@cjdelisle> I had planned on releasing it but then I didn't know.
11:32 <@sdumitriu> I'm +0 for releasing XEM
11:32 <@cjdelisle> Makes no difference to me, I'll let you guys decide
11:32 <@sdumitriu> There's no - to it, just that it takes some more time
11:32 <+tmortagne> yep since it's pretty easy now i would say +1 for release manager
11:33 <+tmortagne> especially since it make no difference to you ;)
11:33 <@sdumitriu> And it would be good to make a practice release before the final needs to be released
11:33 <@cjdelisle> So I should add 3.1M1 and 3.1M2 versions to XEM then right?
11:34 <@cjdelisle> (jira)
11:34 <+tmortagne> cjdelisle: yep
11:38 <@cjdelisle> My plan is to stop hudson from building M1, commit new version numbers, release from here, and let maven push the versions to the repo. Sound right?
11:39 <@sdumitriu> What?
11:39 <@sdumitriu> Why would you do that?
11:39 <@cjdelisle> ... to release?
11:39 <@sdumitriu> mvn release:prepare will change the version numbers automatically
11:39 <abusenius> has joined #xwiki
11:39 <@sdumitriu> mvn release:perform will upload to the repository
11:40 <@cjdelisle> Yes I was planning to use release:perform to do the push.
11:40 <@sdumitriu> There's no need to change numbers manually
11:40 <@sdumitriu> And you can't do release:perform without release:prepare
11:41 <@cjdelisle> Is maven going to commit the changed versions to git?
11:42 <@sdumitriu> Yes
11:42 <@cjdelisle> Ok so I do have to stop hudson.
11:43 <@cjdelisle> I'll see what I can do re release:prepare because it will try to change version numbers of the trunk which is wrong
11:44 <@sdumitriu> Why would it?
11:44 <@sdumitriu> It will push to the M1 branch
11:47 <+tmortagne> cjdelisle: you haver to make sure the <scm> informations are right before using maven
11:47 <+tmortagne> then it will not touch master branch
11:47 <+tmortagne> I can look at it
11:48 <@sdumitriu> I think it will push to the currently tracking branch
11:48 <+tmortagne> one more reason to use maven branch instead of branch youself ;)
11:48 <@sdumitriu> We'll see
11:50 <@cjdelisle> haha -DpushChanges=false
11:50 <@cjdelisle> that'll let me review the mess it makes before it pushes it
11:50 <+tmortagne> cjdelisle: you don't need that, there is an option to do a virtual prepare
11:50 <+tmortagne> dryRun
11:51 <+tmortagne> see
11:52 <@cjdelisle> I know about dry run. I don't trust maven.
11:53 <mflorea> has quit
11:55 <+tmortagne> about git branched "Since version 1.3, we assume that the name of the branch in the  upstream repo is the same as the name of the current local branch. So  whenever you invoke a maven-scm action which has to access the upstream  repository, e.g. start a release, you should be on that very branch. " ( )
11:55 <+tmortagne> cjdelisle: I don't see the point and anyway the worst it can do is to change all version in the pom which is not very hard to cancle
11:55 <+tmortagne> cancel
12:04 <@cjdelisle> On as a side note, sometime I'd like to get ssh on one of the hudson executors, I want to try increasing thread counts but I really need to be watching top while it runs so I can stop it if it starts swap thrashing
12:06 <@sdumitriu> cjdelisle: You'll need SSH on the executor to perform the release
12:06 <@sdumitriu> It's in the release process
12:06 <@sdumitriu>
12:06 <@cjdelisle> I can't release from this box?
12:07 <@sdumitriu> You can, but it's better from the executor
12:07 <@sdumitriu> It's the standard release machine
12:07 <@cjdelisle> ahh right java5, ok sold
12:07 <@sdumitriu> Do you have JDK 1.5?
12:07 <@cjdelisle> yes...ish
12:08 <@sdumitriu> I have the one from IBM
12:08 <@sdumitriu> Since the Sun one is no longer in the official gentoo repository
12:09 <+sburjan> how come ?
12:10 <@sdumitriu> Well, 1.5 is dead-ish
12:12 <@cjdelisle> got it, thanks
12:19 <@cjdelisle> now how is this hudson agent going to commit anything to github?
12:34 <jvdrean1> has joined #xwiki
12:35 <@sdumitriu> cjdelisle: add the hudsonagent public key to your github account, copy your .gitconfig to the machine, checkout, release
12:36 <jvdrean> has quit
12:42 <@cjdelisle> Make a directory for 3.1 and 3.1M1 inside of it or a 3.1M1 top level dir?
12:43 <@sdumitriu> TLD
12:43 <@sdumitriu> Actually it should be a global git-trunks
12:43 <@sdumitriu> To replace the current trunks
12:44 <@cjdelisle> releases/xwiki-trunks/
12:44 <@cjdelisle> like that?
12:44 <@sdumitriu> Yes
12:53 <arkub> has quit
12:55 <arkub> has joined #xwiki
13:00 <@cjdelisle> Is it important to stop the hudson executor? It doesn't seen like it would be, I don't think it's maxing out the machine.
13:02 <@sdumitriu> It's not about maxing out
13:03 <@cjdelisle> oh concurrency in the .m2/repo dir?
13:03 <@sdumitriu> Yes
13:03 <@sdumitriu> Sometimes the local repo gets in a conflict state, since the release build tries to read something that the agent is writing
13:03 <@cjdelisle> k, am I on agent 1 or 2?
13:03 <@sdumitriu> I think
13:03 <@sdumitriu> 1
13:03 <@cjdelisle> Ok, stopping
13:03 <@sdumitriu> Also, sometimes something is killing the Java process
13:04 <@sdumitriu> I don't know what and why
13:04 <@sdumitriu> Just that the build sometimes ends with "Killed"
13:04 <@cjdelisle> monster
13:04 <@cjdelisle> "disconnect", "mark temporarily offline" ?
13:05 <@sdumitriu> mark
13:12 <DrLou> has joined #xwiki
13:15 <abusenius> has quit
13:20 <mflorea> has joined #xwiki
13:27 <vmassol> cjdelisle: working on fixing org.xwiki.test.ui.SectionTest
13:28 <vmassol> cjdelisle: the verison is wrong
13:28 <vmassol> it's 3.1-milestone-1
13:28 <vmassol> not 3.1M1
13:29 <vmassol> (I mentioned that a few days ago already but it must have been lost in the flow ;))
13:32 <@cjdelisle> oh then I broke it because I just did release:perform with version 3.1M1
13:32 <@cjdelisle> err release:prepare
13:32 <vmassol> you can still revert
13:32 <vmassol> release:rollback
13:33 <@cjdelisle> -DreleaseVersion=3.1-milestone-1
13:37 <@sdumitriu> Or you can really forget the release, with git reset --hard <version before the release> && git push --force origin xwiki-3.1M1:xwiki-3.1M1
13:37 <@cjdelisle> yea but that is D:
13:37 <vmassol> better use maven
13:37 <@cjdelisle> I did
13:37 <@sdumitriu> Not nice, but it can hide the mistakes :D
13:37 <vmassol> since you don't know what it does with your local repo for ex
13:37 <vmassol> might do stuff
13:38 <vmassol> (or it could)
13:38 <vmassol> although I don't think it does
13:38 <vmassol> I'm pretty sure it doesn't actually
13:38 <vmassol> :)
13:38 <vmassol> it's release:perform that would do that
13:39 <vmassol> hmm hoverOverMenu() seems wrong
13:39 <vmassol> it does this:
13:40 <vmassol>         WebElement spaceMenuDiv = getDriver().findElement(;
13:40 <vmassol>         executeScript("showsubmenu(arguments[0])", spaceMenuDiv);
13:40 <vmassol> but it doesn't wait for the menu entry to be visible
13:40 <vmassol> I'll fix it
13:41 <tmortagne1> has joined #xwiki
13:43 <vmassol1> has joined #xwiki
13:43 <tmortagne> has quit
13:43 <Enygma`> has quit
13:43 <Enygma`> has joined #xwiki
13:44 <vmassol> has quit
13:47 <bbc581> has joined #xwiki
13:55 <evalica> has quit
13:55 <mflorea> has quit
13:56 <mflorea> has joined #xwiki
13:56 <evalica> has joined #xwiki
13:58 <@sdumitriu> cjdelisle: Change the git username as well
13:58 <@sdumitriu> You're not Jenkins
13:58 <Enygma`1> has joined #xwiki
13:58 <Enygma`> has quit
13:59 <@cjdelisle> I have to fix the SCM URL, it won't let me release otherwise
14:02 <tmortagne1> cjdelisle: actually as the thing I copy/pasted indicate git is working with current branch so the scm just contains the repository I think
14:03 <tmortagne1> see
14:03 <tmortagne1> so you should just need to make sure you did the right checkout before starting the release
14:07 <@cjdelisle> hmm well I am sure I am on the xwiki-3.1M1 branch
14:09 <@sdumitriu> And what's the problem?
14:09 <@sdumitriu> The previous commits were on the right branch
14:10 <@sdumitriu>
14:13 <@cjdelisle> "No SCM URL was provided to perform the release from"
14:17 <@sdumitriu> Make sure you're in the right directory
14:18 <@cjdelisle> I wonder if it's because the dir is named commons and not xwiki-commons like the repo
14:23 <@cjdelisle> hmm that should be it
14:25 <@cjdelisle>
14:25 <@cjdelisle> yay I is a winnar
14:26 <@cjdelisle> oh I can release from the local repo so that means anyone can commit anywhere and it won't mess up the release itself.
14:28 <venkatesh> has quit
14:29 <@sdumitriu> And the root:
14:29 <@sdumitriu> cjdelisle: I don't understand your last remark
14:29 <@sdumitriu> "I can release from the local repo"
14:30 <@cjdelisle> mvn release:prepare -DpushChanges=false -DreleaseVersion=3.1-milestone-1 -DdevelopmentVersion=3.1-SNAPSHOT -DautoVersionSubmodules=true
14:31 <@sdumitriu> You should push changes
14:31 <@cjdelisle> mvn release:perform -DpushChanges=false -DlocalCheckout
14:32 <@cjdelisle> when it blows up half way through perform I can just reset HEAD~2
14:32 <@cjdelisle> I do push. Manually
14:34 <@sdumitriu> K
14:35 <venkatesh> has joined #xwiki
14:41 <sburjan> has quit
14:42 <sburjan> has joined #xwiki
14:46 <@cjdelisle> How have we in the past dealt with:
14:46 <@cjdelisle> There are still some remaining snapshot dependencies.
14:46 <@cjdelisle> : Do you want to resolve them now? (yes/no) no: :
14:46 <@cjdelisle> Can I provide a command line flag to have them all handled automaticly?
14:47 <tmortagne1> what snapshot dependencies you have ? you should not have any since you are supposed to resolve the one in the root pom before releasing
14:47 <tmortagne1> if you have others then it's a bug
14:48 <@cjdelisle> Dependency 'org.xwiki.commons:xwiki-commons-component-api' is a snapshot (3.1M1-SNAPSHOT)
14:49 <tmortagne1> as a dependency to what ?
14:50 <@cjdelisle> rendering
14:50 <tmortagne1> as I said you are supposed to set the proper version in the root pom of the project you are releasing
14:50 <@sdumitriu> Manual commit
14:50 <@cjdelisle> I see
14:50 <tmortagne1> so you need to modify commons.version
14:51 <tmortagne1> the "${project.version}" was more a temporary thing for snapshot
14:52 <tmortagne1> but it's not really correct since the version is not really project.version, it just happen to be the same in some conditions
14:53 <@cjdelisle> They're not depending on ${project.version}
14:54 <@cjdelisle> find ./ -name 'pom.xml' -exec grep 'SNAPSHOT' {} \; | wc -l
14:54 <@cjdelisle> 298
14:54 <@cjdelisle> So I suppose that needs to be fixed as well
14:58 <@cjdelisle> hmm no nevermind
15:03 <venkatesh> has quit
15:27 <vmassol1> is now known as <vmassol>
15:30 <@cjdelisle> Ok I see now. I have to edit all the root poms when releasing to change the version number and version of the parent.
15:31 <@cjdelisle> I didn't get it because I was thinking maven took away all the manual stuff
15:33 <vmassol> note that this can be automated with the versions maven plugin but I haven't tried it yet
15:33 <vmassol>
15:33 <vmassol> (cjdelisle)
15:34 <vmassol> for ex:
15:34 <vmassol>
15:35 <@cjdelisle> yup, just got done trying mvn versions:use-releases
15:36 <vmassol> cool, it worked fine?
15:37 <@cjdelisle> not yet, still tinkering...
15:40 <tmortagne1> cjdelisle: not that's it's in the release process ;) ("Resolve all SNAPSHOT dependencies. The Release plugin  will not let you release the module if it has SNAPSHOT dependencies.")
15:40 <vmassol> hmmm agent1 is offline
15:40 <vmassol>
15:41 <vmassol> any idea why?
15:41 <vmassol> "Disconnected by CalebJamesDeLisle : 3.1M1 release"
15:41 <tmortagne1> vmassol: release
15:41 <vmassol> why is that a problem?
15:41 <vmassol> I wanted it to run enterprise tests on trunk
15:42 <tmortagne1> we always disconnect it when releasing otherwise you have several expensive maven build at the same time
15:42 <tmortagne1> we do the release for the agent1
15:42 <tmortagne1> it's not a source issue
15:42 <vmassol> it's to prevent false positives?
15:42 <vmassol> (which shouldn't happen btw)
15:42 <tmortagne1> no
15:42 <tmortagne1> it's because it's a pain
15:43 <tmortagne1> to release during a test build
15:43 <vmassol> why, I don't understand?
15:43 <tmortagne1> it's takeing pratty much all the CPU of the computer
15:43 <vmassol> oh same machine?
15:43 <tmortagne1> again we do the release on the agent itself
15:43 <vmassol> ok I see, so that's the issue
15:43 <@cjdelisle> I asked about that and sdumitriu said it was actually a concurrency issue in ~/.m2/repo
15:43 <vmassol> I'm not sure about the concurrency issue
15:44 <vmassol> but possibly
15:44 <tmortagne1> I don't think for the concurrency issue since maven is supposed to take care of that but that's not the most painful reason
15:44 <vmassol> so basically even thogh we have branches
15:44 <vmassol> devs who commit stuff don't get them tested fully ;)
15:44 <vmassol> (during a release)
15:45 <tmortagne1> it's just during the release build itself which is not very long
15:45 <tmortagne1> and only for integration tests
15:45 <vmassol> ok
15:45 <vmassol> cjdelisle: when do you think it'll be back?
15:45 <vmassol> in 1-2 hours or more?
15:46 <vmassol> (just to schedule my work)
15:46 <@cjdelisle> I wouldn't expect it in 1-2 hours. Hope but don't expect.
15:46 <vmassol> ok I'll stop working on fixing tests FTM
15:47 <@cjdelisle> btw:
15:47 <@cjdelisle> mvn versions:set -DnewVersion=3.1-milestone-1
15:47 <@cjdelisle> seems to work
15:47 <@cjdelisle> creats a lot of garbage backups because it thinks it's git
15:47 <vmassol> that sets everything no?
15:47 <vmassol> not just parents
15:48 <@cjdelisle> hmm it only sets parents
15:48 <@cjdelisle> is that correct?
15:48 <vmassol>
15:48 <mbryant> has joined #xwiki
15:48 <newbie> has joined #xwiki
15:48 <vmassol> it says it updtaes them all AFAIU
15:48 <newbie> has quit
15:49 <@cjdelisle> I'm looking at git diff HEAD and I can say for sure that it sets all parents and the root.
15:49 <vmassol> yes but not only
15:49 <vmassol> it's also going to change deps
15:49 <vmassol> (again I haven't used it but that's what I understand from the link I pasted above)
15:49 <tmortagne1> vmassol: the deps are in a proparty in the root pom
15:50 <tmortagne1> so it's probably no seing it
15:50 <vmassol> yes that's just pure luck
15:50 <vmassol> :)
15:50 <vmassol> if you run it on a pom which has explciit versions it'll change them
15:50 <@cjdelisle>
15:51 <vmassol> cjdelisle: yes but you're lucky
15:51 <@cjdelisle> it doesn't set the parent of the root though
15:51 <tmortagne1> that's correct, there is nothing else to change than parent here
15:51 <vmassol> just don't expect it to only change the parents
15:51 <tmortagne1> s/parent/parents/
15:51 <vmassol> it's working because you eitgher don't have deps specified or because their versions are set using properties
15:52 <@cjdelisle> From reading it what I got was that it changed the version of the root and only the root.
15:52 <@cjdelisle> IE wherever you execute it is where it sets the version
15:52 <@cjdelisle> but it updates parents so that the change is not wrong
15:53 <@cjdelisle> but if there are multiple layers then everything fails
15:55 <vmassol> cjdelisle: cehck
15:55 <vmassol> it has examples
15:56 <vmassol> anyway the correct goal is for updating the parents
15:58 <@cjdelisle> I see, if that recurses over generations of parent/child then it will eork
15:58 <vmassol> it probably works in a reactor indeed
15:59 <vmassol> (ie gets exectued on all projects in a reactor build)
16:03 <@cjdelisle> hmm nope, non-recursive
16:09 <@cjdelisle> looks like sedfu is the best solution.
16:10 <@cjdelisle>
16:12 <@cjdelisle> What is the danger of modifying everything and not just the parents?
16:14 <tmortagne1> cjdelisle: I think vmassol meant that it was even modifying version of external dependencies
16:14 <tmortagne1> but seems weird that such a goal even exist
16:16 <@cjdelisle> It should be in the release plugin since the release plugin sets the version.
16:17 <@cjdelisle> There is no way I can see to set all parents recursively, it's probably because it makes no sense and would produce an unbuildable project.
16:18 <@cjdelisle> I have not found a way to set parents _and_ versions recursively either.
16:21 <vmassol> not external
16:21 <vmassol> but ours
16:21 <@cjdelisle> [INFO] You don't have a SNAPSHOT project in the reactor projects list.
16:21 <vmassol> it just means release:prepare won't modify them which is maybe ok
16:21 <@cjdelisle> I see the problem now
16:22 <@cjdelisle> wheee multiline sed
16:32 <abusenius> has joined #xwiki
16:44 <lucaa> has quit
16:58 <sburjan> has quit
16:59 <lucaa> has joined #xwiki
17:01 <@cjdelisle> I don't know if there is any clean way to do compound releases.
17:01 <@cjdelisle> IE release a module with submodules
17:02 <@cjdelisle> If I modify all of the version fields then there is nothing to release (no SNAPSHOT)
17:03 <@cjdelisle> If I modify all of the parent version fields then it fails to lookup the parent because it's trying to release the parent and child simultaniously
17:04 <tmortagne1> you mean release commons and rendering at the same time for example ?
17:05 <@cjdelisle> No I mean release rendering/ and rendering/xwiki-rendering-macros/ at the same time
17:06 <@cjdelisle> iterating over every subdirectory is what I want to avoid
17:06 <tmortagne1> cjdelisle: that's exactly what you are supposed to do and that doe snot require anything special
17:06 <tmortagne1> you are not supposed to release spearately each submodule...
17:07 <@cjdelisle> Right but when dependencies are all against ${project.version} the project version has to be updated before it is released then there is nothign to release.
17:08 <tmortagne1> no it's not
17:08 <tmortagne1> don't mix external and internal dependencie
17:08 <tmortagne1> as I already said you only have one things to change: the commons version property and  nothing else
17:08 <@sdumitriu> $project.version should stay at 3.1-SNAPSHOT before starting the release
17:09 <tmortagne1> you have to keep $project.version for internal dependencies
17:09 <@sdumitriu> release:prepare will update that one, and it does it pretty well
17:10 <@cjdelisle> ahh I see, I can change this <commons.core.version>${project.version}</commons.core.version>
17:11 <tmortagne1> otherwise doing a release would be a real pain..
17:12 <@sdumitriu> Yes, that's the only one you have to change
17:12 <@sdumitriu> Replace ${project.version} with 3.1-milestone-1
17:12 <@sdumitriu> release
17:12 <@sdumitriu> Then change back
17:12 <@cjdelisle> How about the parent of the root, does that need to change?
17:12 <tmortagne1> yep
17:12 <@cjdelisle> k
17:12 <tmortagne1> any external
17:29 <evalica> has quit
17:31 <@cjdelisle> It would make sense to have commons.core.version be set to ${parent.version} wouldn't it? Then there would be one place to make a change.
17:32 <mar3lis> has joined #xwiki
17:33 <mar3lis> hey guys, don't want to be a spamer, but yesterday i posted a question but it probably was too late at nigth
17:33 <mar3lis>
17:33 <mar3lis> do you know the answer to this threat?
17:34 <tmortagne1> cjdelisle: make sense
17:35 <vmassol> it's debatable
17:35 <vmassol> it's kind of a coincidence
17:35 <vmassol> 3.0M1 for commons is not the same 3.0M1 for platform
17:36 <vmassol> but anyway it's a small detail
17:36 <tmortagne1> vmassol: that's not what cjdelisle is saying
17:36 <vmassol> we used to use project.version and changed it in a few places
17:36 <vmassol> oh ok
17:36 <vmassol> sorry
17:36 <tmortagne1> parent.version is root pom (so commons) version
17:36 <vmassol> I read project.version
17:37 <vmassol> are you planning to use properites in parent declaration?
17:37 <tmortagne1> project.version does not work with release plugin anyway
17:37 <@cjdelisle> IMO project.version or parent.version are both equally bad but parent.version makes life so easy and it's not like we're using it everywhere, it's one place where commons.version is defined.
17:37 <vmassol> (becuase I remember some gotchas with that - don't remember exactly though would need to google it)
17:37 <tmortagne1> cjdelisle: they are not, rendering version does not have to be the same as commons version technically
17:37 <@sdumitriu> Hi mar3lis, sorry for ignoring you, we're all a bit busy at the moment
17:37 <mar3lis> no prob
17:38 <mar3lis> i can wait
17:38 <mar3lis> :)
17:38 <@sdumitriu> mar3lis: Patience is key when dealing with open source communities :)
17:38 <mar3lis> hehe
17:38 <mar3lis> yep :)
17:56 <@cjdelisle>
17:56 <@cjdelisle> wild assumption that this needs to change to commons.core.version
17:57 <tmortagne1> cjdelisle: yep it has been forgotten
17:58 <mflorea1> has joined #xwiki
17:58 <sdumitriu> has quit
17:58 <Enygma`> has joined #xwiki
17:58 <mflorea> has quit
17:58 <tmortagne1> cjdelisle: you did not need to do the 3.1-SNAPSHOT -> 3.1-milestone-1 that's release plugin job
17:58 <Enygma`1> has quit
17:58 <evalica> has joined #xwiki
17:59 <@cjdelisle> Where did I do that?
17:59 <tmortagne1> just seen a github commit
17:59 <tmortagne1>
17:59 <tmortagne1> several actually but that's one of theù
18:00 <tmortagne1> them
18:00 <tmortagne1> but maybe you reverted in another commit actually i did not cheked all of them
18:00 <@cjdelisle> That perticular one was because the parent is not changed.
18:01 <tmortagne1> ha sorry indeed i missread
18:01 <@cjdelisle> There are commits mixed in which are generated by the plugin, they also have my name on them
18:02 <tmortagne1> yes is from release plugin so this one is ok
18:02 <tmortagne1> so sorry about that
18:03 <@cjdelisle> if we change all of those core.commons.version numbers to reference off of ${parent.version} then we can use mvn versions:set-parent for everything
18:03 <tmortagne1> (s/so sorry/so, sorry/ I'm not that sorry ;))
18:03 <@cjdelisle> hehe
18:06 <sdumitriu> has joined #xwiki
18:06 <tmortagne1> hmm btw "core.commons.version" should be "commons.version" since there is no separation between commons core and tools anymore
18:06 <@sdumitriu> mar3lis: I just answered the mail thread
18:07 <tmortagne1> another thing we forgot inthe refactoring
18:07 <tmortagne1> platform have the right one
18:08 <@cjdelisle> release:perparing platform and going to get something to eat.
18:08 <tmortagne1> so the mistake is only in rendering
18:08 <tmortagne1> will fix it after your release
18:08 <tmortagne1> ha I can fix it on master actually
18:09 <@cjdelisle> you can fix it wherever you want but if this release is not broken then I intend to delete the M1 branch
18:09 <@cjdelisle> be back
18:16 <mar3lis> sdumitriu: thank you
18:18 <vmassol> tmortagne1: why did you replace xwiki-commons by commons/?
18:18 <vmassol> -    <relativePath>../xwiki-commons/xwiki-commons-pom</relativePath>
18:18 <vmassol>  
18:18 <vmassol> 31
18:18 <vmassol> +    <relativePath>../commons/xwiki-commons-pom</relativePath>
18:18 <vmassol> I had done this on purpose
18:18 <tmortagne1> vmassol: because of
18:19 <vmassol> xwiki-trunks is wrong
18:19 <vmassol> it needs to be fixed
18:19 <tmortagne1> then it should be fixed
18:21 <vmassol> personally I don't use xwiki-trunks and I don't really see the need for it but that's another discussion
18:22 <tmortagne1> don't use it either but since it exists I took it as the official reference
18:22 <tmortagne1> (just reverted my modification)
18:22 <vmassol> (ok thanks)
18:24 <vmassol> sdumitriu: trying to fix$xwiki-enterprise-test-ui/591/testReport/org.xwiki.test.ui/EditObjectsTest/testEmptyGroupObjects/
18:24 <vmassol> the object editor does'n't display objects in js right?
18:24 <vmassol> (when viewed, not when adding new objecets)
18:28 <@cjdelisle> I have to say, this release process is awesome.
18:31 <@sdumitriu> vmassol: WDYM doesn't display objects?
18:31 <@cjdelisle> What does that relitive path do? Is something going to break because it is misalligned with trunks?
18:32 <@sdumitriu> Nope
18:32 <tmortagne1> cjdelisle: no it's just here to speed up things, maven use it to try getting the pom using it before downloading
18:32 <@sdumitriu> Depends how the users checkout the sources
18:33 <evalica> has quit
18:33 <tmortagne1> vmassol: just forbidden js and I do have the object listed
18:33 <@cjdelisle> Ok, I saw it and changed it because I thought it was causing the build to break.
18:34 <vmassol> sdumitriu: I was wondering if the page was first rendered and then objects added in js (when js is enabled)
18:34 <vmassol> probably not, but that would explain a potential test error....
18:34 <vmassol> I just want to eliminate this possibility
18:34 <@sdumitriu> No, JS just handles the collapse/expand
18:35 <vmassol> (and the add apparently)
18:35 <vmassol> ok
18:37 <tmortagne1> ha not very nice if it's impossible to add object without js
18:37 <Enygma`> has quit
18:38 <tmortagne1> vmassol: the add kind of work for me
18:38 <vmassol> tmortagne1: I never said it was broken!
18:39 <vmassol> (all I said is that when js is enabled it uses js to not have to reload the page to displayed added objects)
18:39 <tmortagne1> I understood "and the add apparently" following "JS just handles the collapse/expand"
18:39 <tmortagne1> was not that detailed :)
18:40 <vmassol> you cannot read in my mind? :)
18:40 <tmortagne1> but there is still a bug with add since you are redirected to wiki editor after clicking on the button
18:40 <tmortagne1> creating a jira issue
18:40 <vmassol> ok
18:41 <vmassol> right now I'm triyng to find out what could cause an xobject not to be displayed when this code executes
18:41 <vmassol>         ObjectEditPage oep = vp.editObjects();
18:41 <vmassol>         oep.addObject("XWiki.XWikiGroups");
18:41 <vmassol>         vp = oep.clickSaveAndView();
18:41 <vmassol>         oep = vp.editObjects();
18:41 <vmassol>         Assert.assertEquals(1, oep.getObjectsOfClass("XWiki.XWikiGroups").size());
18:41 <vmassol> getObjectsOfClass starts with:
18:41 <vmassol>         List<WebElement> titles = getDriver().findElement("xclass_" + className))
18:41 <vmassol>             .findElements(By.className("xobject-title"));
18:41 <vmassol> and findElement fails to find the web element on jenkins apparently
18:43 <vmassol> hmmm editObjects() does this:
18:43 <vmassol>         clickContentMenuEditSubMenuEntry("tmEditObject");
18:43 <vmassol>         return new ObjectEditPage();
18:43 <vmassol> which calls:
18:43 <vmassol>         hoverOverMenu("tmEdit");
18:43 <vmassol>         getDriver().findElement(By.xpath("//a[@id='" + id + "']")).click();
18:44 <vmassol> I've now made hoverOverMenu wait
18:44 <vmassol> but if it was not watining it would have cause an issue with the click() so that's not the problem
18:44 <vmassol> click() is a waiting api I guess so that shouldn't the issue either
18:45 <vmassol> we'd need to display the content when the find fails to debug it
18:45 <vmassol> maybe we should have an api to not use findelement and instead use our api which logs the content when it fails....
19:00 <mar3lis> sdumitriu: so as i understood, i have to add a value to the DBList property and not the User list?
19:05 <tmortagne1> a shame we have to answer something like that, we really need to get this userlist property improved
19:07 <arkub> has quit
19:11 <mar3lis> tmortagne1: so can you answer that? :)
19:11 <tmortagne1> mar3lis: basically userlist property is not really a list behind the scene
19:11 <sdumitriu> has quit
19:12 <tmortagne1> so if you want a real list from storage POV you should use static list property
19:12 <sdumitriu> has joined #xwiki
19:12 <tmortagne1> (until userlist is improved when someone finally get nuts about it)
19:14 <mar3lis> ok, thanks
19:20 <vmassol> cool selenium gurus pointed me to EventFiringWebDriver… will try that to provide debugging support
19:21 <@cjdelisle> is XWIKI-6571 finished?
19:21 <tmortagne1> does not seems to be committed
19:21 <tmortagne1> according to jira at leasst
19:21 <tmortagne1> least
19:21 <@cjdelisle> ok, removing fix for version then
19:22 <sdumitriu> has quit
19:26 <@cjdelisle> hmm second page has a bunch of stuff that's unresolved and fix for 3.1M1
19:26 <tmortagne1> cjdelisle: just move them to next version, if something is fixed it's supposed to be closed
19:27 <tmortagne1> usually it's stuff planned for 3.1 in general
19:27 <@cjdelisle> I don't like this business of kicking the can along to the next version every release.
19:27 <tmortagne1> not specifically on 3.1M1
19:27 <tmortagne1> it's not that
19:27 <tmortagne1> it's stuff planned for 3.1 branch so you can
19:28 <tmortagne1> when going to 3.2 it's another matter
19:30 <@cjdelisle> take for instance XWIKI-913 which was opened in february of 07
19:30 <@cjdelisle> Do you really think it's going to get done in the 3.1 frame?
19:32 <@cjdelisle> If you insist I'll change them all to M2 but I think it takes away from jira's credibility.
19:34 <@cjdelisle> hrmf, another thing to automate
19:41 <mar3lis> when i select multiple values from a dblist in inline mode, ir normal view the values ar shown one beside the other, is there a way to display them one under another?
19:41 <mar3lis> does it have to do something with custom dislpay?
19:43 <Chami1> has joined #xwiki
19:48 <tmortagne1> cjdelisle: this issue should not even have fix for 3.1M1 in the first place
19:49 <tmortagne1> what i'm saying is that this has nothing to do with the release
19:49 <@cjdelisle> That's the problem, they all are set to fix for the next release but they drag along until the "fix for" becomes flat out absurd.
19:49 <tmortagne1> that's supposed to be fixed when we do the plan for 3.2
19:49 <sdumitriu> has joined #xwiki
19:54 <mflorea1> has quit
19:58 <sburjan`> has joined #xwiki
19:58 <tmortagne1> has quit
20:09 <@cjdelisle> hmm looks like -Darguments="-N" nolonger makes sense when releasing enterprise.
20:09 <@cjdelisle> So I just pushed a pom file to the maven repo, can I just perform the release again and clobber it?
20:11 <@sdumitriu> Where was that, prepare or perform?
20:11 <@sdumitriu> Yes, you can re-run perform, it will override what's on maven
20:12 <@cjdelisle> cool
20:12 <Chami1> has quit
20:12 <@cjdelisle> removing -N since it only pushes one little .pom with it.
20:13 <@sdumitriu> Was that in the process?
20:13 <@cjdelisle> yes
20:13 <@sdumitriu> -N was for top level poms on apps and plugins, IIRC
20:13 <@sdumitriu> But not for enterprise
20:13 <@cjdelisle> "For enterprise and manager: mvn release:prepare -Pci,hsqldb,mysql,pgsql,derby,jetty,glassfish -Darguments="-N" "
20:14 <@sdumitriu> Just on prepare
20:14 <@sdumitriu> And that was supposed to skip the test build before pushing the changed poms
20:16 <@sdumitriu> The process during release:prepare is:
20:16 <@cjdelisle> so I'm supposed to use that for prepare but not for perform, ok.
20:16 <@sdumitriu> - change the poms to the released version
20:16 <@sdumitriu> - do a forked build, for which -Darguments applies
20:16 <@sdumitriu> - commit the poms
20:16 <@sdumitriu> - change them to the next version
20:16 <@sdumitriu> - commit again
20:16 <@sdumitriu> + push when using git
20:17 <@cjdelisle> of course I'm on a branch which will soon be dead so getting it back into chape is not critical
20:17 <@sdumitriu> And there was a bug with the process, since the inner build inherited the outer profiles, which caused multiple profiles to be activated (mysql+hsql+phsql+jetty+glassfish) which ended up as invalid hibernate settings
20:17 <@sdumitriu> So the -N is needed for prepare
20:18 <@cjdelisle> hmm
20:20 <@sdumitriu> Cool, tags were pushed:
20:20 <@cjdelisle> I had to git push --tags
20:21 <@sdumitriu> Manually?
20:21 <@cjdelisle> yup
20:21 <@cjdelisle> ofc I pushed everything manually
20:21 <@sdumitriu> Ah, you didn't let it push
20:21 <@cjdelisle> you'll never know how many times I ran release:prepare ;)
20:21 <@sdumitriu> :D
20:23 <@cjdelisle> I've been setting it back to 3.1-SNAPSHOT after finishing but at least for enterprise I intend to manually set it to 3.1-milestone-1 so that the tests will pick it up and go start testing the release.
20:23 <@cjdelisle> I know I know, abusing the branch...
20:25 <sdumitriu> has quit
20:34 <evalica> has joined #xwiki
20:39 <evalica> has quit
20:41 <sdumitriu> has joined #xwiki
20:43 <@cjdelisle> any idea what to do about this? It's blocking the enterprise release
20:43 <@cjdelisle>
20:43 <@cjdelisle> xwiki-enterprise-database-hsqldb/target/maven-shared-archive-resources/hibernate.cfg.xml
20:43 <@cjdelisle> is pulling in derby by default
20:44 <@sdumitriu> What command are you using to build?
20:44 <@cjdelisle> mvn release:prepare -DpushChanges=false -DlocalCheckout=true -DreleaseVersion=3.1-milestone-1 -DautoVersionSubmodules=true -Pci,hsqldb,mysql,pgsql,derby,jetty,glassfish -Darguments="-N"
20:44 <@cjdelisle> mvn release:perform -DpushChanges=false -DlocalCheckout=true -Pci,hsqldb,mysql,pgsql,derby,jetty,glassfish
20:45 <@cjdelisle> it's all because of "-DpushChanges=false -DlocalCheckout=true" those right?
20:45 <@sdumitriu> Perform should only have -Pci,hsqldb,jetty
20:45 <@sdumitriu> "For enterprise: mvn release:perform -Pci,hsqldb,jetty -Darguments='-Pci,hsqldb,jetty -DskipTests' -DskipTests"
20:45 <@cjdelisle> ahh, my fault for not RTFMing carefully enough
20:45 <@sdumitriu> :)
20:46 <@cjdelisle> you have to pass them twice? ad -D* and -Darguments="-D*"
20:48 <@sdumitriu> Yes
20:48 <@sdumitriu> It builds twice
20:48 <@cjdelisle> running it now
20:48 <@cjdelisle> thanks for the help
20:49 <@cjdelisle> same commands for manager?
20:50 <@sdumitriu> The process during release:perform is:
20:50 <@sdumitriu> - checkout the sources from the tag
20:50 <@sdumitriu> - do a forked build, for which -Darguments applies, to test that the build is successful
20:50 <@sdumitriu> - do a new build, uploading the produced jars/wars/zips to the repository
20:50 <@sdumitriu> - cleanup
20:51 <@sdumitriu> No, not the same for manager
20:51 <@sdumitriu> RTFM :)
20:51 <@sdumitriu> "For manager: mvn release:perform -Pmysql -Darguments='-Pmysql'"
20:51 <@cjdelisle> oh right
20:52 <@sdumitriu> XEM is built with mysql, since the way we use hsqldb doesn't support virtual wikis
20:52 <@sdumitriu> Something to fix in the future
20:52 <@cjdelisle> I'll take the commands that worked and put them somewhere on the release page so people like me can spot blocks of commands and copy-paste them
21:39 <lucaa> has quit
21:55 <mar3lis> if i have a static list with some values, how can i display in another page the name of the value
21:56 <mar3lis> like value1= The first value
21:56 <mar3lis> how to display the The first value
21:56 <mar3lis> #set($prop = $obj.getProperty('a').value displays only the value)
21:56 <mar3lis> #set($prop = $obj.getProperty('a').value)
21:57 <@cjdelisle> then prop.get(0)
21:57 <@cjdelisle> $prop.get(0)
21:57 <@cjdelisle> the value is the list
21:58 <mar3lis> hm doesnt seem to work
22:00 <mar3lis> it still shows the value
22:01 <mar3lis> and not the "name"
22:02 <@cjdelisle> what is the value?
22:02 <mar3lis> vienas
22:02 <mar3lis> and the "name" is Vienas
22:02 <mar3lis> with capital V
22:02 <mar3lis> vienas=Vienas | du=Du | trys=Trys
22:02 <@cjdelisle> oh so you need to lookup values given keys?
22:03 <mar3lis> yes
22:03 <@cjdelisle> you could establish one list for keys and one list for values
22:03 <@cjdelisle> unfortunately we do not support storing maps at the moment
22:04 <mar3lis> so its not possible at the moment?
22:05 <@cjdelisle> it's possible, you just need to use 2 lists to do it.
22:06 <mar3lis> ok
22:06 <mar3lis> i stll have trouble with adding values to the properties
22:07 <mar3lis> if the values in the DBlist are from hibernate query
22:07 <@cjdelisle> if you know exactly how many entries you will have then then you can define custom objects but if it's an expanding map then you will need to use a pair of lists
22:07 <mar3lis> can i add one more value to those ones programicly?
22:08 <@cjdelisle> it's complex and has few use cases
22:08 <@cjdelisle> static list does everything you're looking for (load, store, add names, remove names)
22:09 <mar3lis> ok then how to add values to a static list? :)
22:09 <mar3lis> and after that, how to remove a value from a static list
22:09 <mar3lis> programicly
22:11 <+Denis> euh, why not using translations for your maps ?
22:13 <+Denis> we usually use keys in storage, and then we use a translation bundles for names
22:14 <mar3lis> hmmmm
22:14 <+Denis> if your list is expansable, using DBlist is for me the way to go, since you can easily get all XObjects of a given XClass in a list
22:15 <+Denis> s/expansable/expendable/
22:16 <mar3lis> i'm not sure i understand the concept of this method
22:16 <+Denis> if your list is static or almost static, use static list of course
22:17 <+Denis> it is obviously easier
22:18 <mar3lis> well for my project the list wont be static
22:18 <mar3lis> it will be a list of registered users
22:18 <@cjdelisle> static list is a misnomer, you can add values to and resize a static list
22:18 <@cjdelisle> what makes it static is that it is not generated on the fly when you ask for it
22:19 <@cjdelisle> IE generated from a database query
22:21 <mar3lis> i got confused
22:21 <+Denis> sorry, on the phone, please stay tune :)
22:22 <mar3lis> ok :)
22:23 <ihalip_> has joined #xwiki
22:26 <+Denis> well, too choose between staticlist or dblist, you should consider two things, does I need to expand the list often, and does I need to have other information than the "name" linked with each item of the list
22:27 <+Denis> you can expand both
22:28 <+Denis> static list are just describe in the class definition as a pipe or comma separated list of values
22:28 <+Denis> you can free add, and even remove values from it
22:28 <+Denis> data records store these values, so the list can be reorganized
22:29 <+Denis> if you need to display a pretty names for items in a static list (opposed to values), you may use a translation bundles
22:30 <+Denis> but, you if you are talking about a list of users, do you means a list of registered users in the current wiki ?
22:31 <mar3lis> users from current wiki registered to a lecture
22:32 <mar3lis> there will be few documents with object that have info about lectures
22:32 <+Denis> you means, any user could be part of the list, or just a subset ?
22:32 <mar3lis> any xwiki user could register to the lecture
22:32 <mar3lis> and more than one lecture
22:33 <mar3lis> and i need ti display the list of users registered to the current lecture
22:33 <mar3lis> and display a list of lectures, that that user is registered to
22:34 <mar3lis> and ofcourse the ability for the user to register to the list and remove him self from the list
22:34 <+Denis> if you are storing the information on the lectures, you should simply choose a 'List of users' type of field in the definition of your Xclass
22:35 <+Denis> this will list all available users, and store xwiki user name in the fields
22:35 <mar3lis> but i found it difficult to add users programicly to that list
22:36 <+Denis> if you plan to store the list of lecture in the user object, you will probably need a dblist field, which is based on a query of all the available lectures
22:38 <mar3lis> that was my first idea with the user list in the lecture info object, but as i said i found it difficult to add user programicly to that list
22:40 <+Denis> either way, you will have to manage a multiple select list
22:41 <+Denis> this is stored internally as a pipe or coma separated list of values, where values would be xwiki user names in this case
22:41 <+Denis> in fact you may choose the separator freely
22:41 <+Denis> but I recommande pipes
22:42 <mar3lis> what are pipes? :D
22:42 <+Denis> |
22:42 <mar3lis> sook
22:42 <+Denis> so this may looks like "XWiki.User1|XWiki.User2|XWiki.User3"
22:44 <+Denis> just define the separator in the "Multiselect separators (for editing)" to "|"
22:47 <mar3lis> has quit
22:51 <lucaa> has joined #xwiki
22:51 <mar3lis> has joined #xwiki
22:52 <mar3lis> damn i lost connection or smth like that
22:52 <mar3lis> what was your last message Denis ?
23:00 <mar3lis> so how do you add a value and remove a value if needed programicly from a list?
23:11 <@cjdelisle> I think you can just get the value then call add on the value then set it to the new value
23:12 <@cjdelisle> you might try looking up examples in the extensions wiki.
23:14 <abusenius> has quit
23:16 <vmassol> has quit
23:20 <mar3lis> hm
23:20 <mar3lis> nothing on the extensios
23:20 <mar3lis> so i should make a string
23:21 <mar3lis> of all the values from the list and then add another value that i need and then set the value to the property?
23:22 <@cjdelisle> put the value into the list and set the list as the propery I think
23:22 <@cjdelisle> I have to finish up some release stuff so I can't help today
23:25 <mar3lis> ok i understand
23:25 <mar3lis> thank you

Get Connected