[Monday 26 April 2010] [10:02:42] hey everyone [Monday 26 April 2010] [10:03:03] welcome to meeting number 2! [Monday 26 April 2010] [10:03:15] :D [Monday 26 April 2010] [10:03:20] :) [Monday 26 April 2010] [10:03:38] others? [Monday 26 April 2010] [10:03:42] i guess the first order of business is whether there were any follow ups to last week [Monday 26 April 2010] [10:03:43] hi [Monday 26 April 2010] [10:04:18] one thing still undecided was whether to merge entitymanager into core [Monday 26 April 2010] [10:04:43] i think the majority consensus was no last time [Monday 26 April 2010] [10:04:56] i think so [Monday 26 April 2010] [10:05:10] merge annotations and leave entitymanager separate [Monday 26 April 2010] [10:05:16] ok, easy enough [Monday 26 April 2010] [10:05:23] that my opinion [Monday 26 April 2010] [10:06:10] hardy_: did you make any head way on the docs index.html pages? [Monday 26 April 2010] [10:06:42] not yet, I hit a bug in HV. Once that is fixed I will get onto it [Monday 26 April 2010] [10:07:55] i was going to fix hudson, but got a weird failure, steve, did you get my mail about that failure? [Monday 26 April 2010] [10:08:19] stliu: the "cant reproduce it" one? [Monday 26 April 2010] [10:08:28] yes [Monday 26 April 2010] [10:08:32] :) [Monday 26 April 2010] [10:08:45] stliu, that ASTParserLoadingTest failure? [Monday 26 April 2010] [10:08:47] i mean not much i can do to trouble shoot if we cannot reproduce it [Monday 26 April 2010] [10:08:58] yes, gail [Monday 26 April 2010] [10:09:29] stliu, I can reproduce it; I'll see if I can figure it out [Monday 26 April 2010] [10:09:37] cool, thanks [Monday 26 April 2010] [10:09:52] i tried lots of ways, but looks like that failure only like hudson and gail :D [Monday 26 April 2010] [10:10:02] yeah, bugs love me [Monday 26 April 2010] [10:10:13] we also need to finish up the general hudson discussion [Monday 26 April 2010] [10:10:58] this is very much a maven discussion though [Monday 26 April 2010] [10:11:13] 1 job run whole trunk on hsqldb, no filure then publish snapshot, and triger another job that runs on DB matrix ? [Monday 26 April 2010] [10:11:20] since the difficulty is maven induced [Monday 26 April 2010] [10:11:33] stliu: ideally yes [Monday 26 April 2010] [10:11:50] stliu: well [Monday 26 April 2010] [10:12:02] which problem are we talking about? [Monday 26 April 2010] [10:12:04] maybe not the testsuite on initial "phase" [Monday 26 April 2010] [10:12:27] hardy_: which which problem? ;) [Monday 26 April 2010] [10:12:37] the failure? or hudson? [Monday 26 April 2010] [10:12:42] regarding maven and hudson [Monday 26 April 2010] [10:12:50] hardy_, the problem is publich hudson result and release snapshot [Monday 26 April 2010] [10:13:28] and why is that a maven problem? [Monday 26 April 2010] [10:13:33] hardy_: given the current set up and desire to publish nightly snapshots, what build actually pushed snapshots? [Monday 26 April 2010] [10:13:43] *pushes [Monday 26 April 2010] [10:13:59] because in maven i cannot script the test plan [Monday 26 April 2010] [10:14:08] you cant "script" anything [Monday 26 April 2010] [10:14:30] true, I hate this as well [Monday 26 April 2010] [10:14:38] but what do you want to script? [Monday 26 April 2010] [10:14:51] yeah, that's my question too :) [Monday 26 April 2010] [10:14:55] was the idea not to use a build against hsql db for publishing the snapshots? [Monday 26 April 2010] [10:15:07] in a scripting build, i'd say (1) produce jars (thereby running module tests); (2) pub artifacts; (3) run functional tests [Monday 26 April 2010] [10:15:37] its not scripting so much [Monday 26 April 2010] [10:15:48] in maven how would you do what i just said? [Monday 26 April 2010] [10:16:08] iiuc there is a way [Monday 26 April 2010] [10:16:08] you mean pub artifacts without functional testes pass? [Monday 26 April 2010] [10:16:11] but its fugly [Monday 26 April 2010] [10:16:19] no [Monday 26 April 2010] [10:16:22] look [Monday 26 April 2010] [10:16:32] you have hibernate-core et al [Monday 26 April 2010] [10:16:36] the actual modules [Monday 26 April 2010] [10:16:54] so you want them built and published [Monday 26 April 2010] [10:17:08] i think I know now where you are getting, but continue [Monday 26 April 2010] [10:17:34] now you have a "testsuite" you want to run against the "matrix" [Monday 26 April 2010] [10:17:37] could you not have two Hudson builds [Monday 26 April 2010] [10:18:02] we will have multiple jobs i believe [Monday 26 April 2010] [10:18:06] first runs install and only if that succeeds we run the 'deploy' as postbuild [Monday 26 April 2010] [10:18:13] in fact we have multiple now, correct jcosta [Monday 26 April 2010] [10:19:04] hardy_: ideally i'd not want hibernate-testsuite run at all during the initial build [Monday 26 April 2010] [10:19:15] sebersole, one sec, let me read what you guys were discussing [Monday 26 April 2010] [10:19:27] its not a killer i guess if we run it against hsqldb/h2 for the initial job [Monday 26 April 2010] [10:20:14] yeah, I don't see this as problem either (running hibernate-testsuite) [Monday 26 April 2010] [10:20:24] hardy_: how? [Monday 26 April 2010] [10:21:22] perhaps we should discuss this with paul and john [Monday 26 April 2010] [10:21:55] paul gier? and john ? [Monday 26 April 2010] [10:22:01] john casey [Monday 26 April 2010] [10:22:14] i know their suggestions from the past [Monday 26 April 2010] [10:22:48] basically you'd have a maven project for each "matrix coord" (or each db at least) [Monday 26 April 2010] [10:22:48] sebersole, by "multiple" you meant multiple jobs ? if so, yes [Monday 26 April 2010] [10:23:02] jcosta: yes, one per right? [Monday 26 April 2010] [10:23:08] per db/jdk [Monday 26 April 2010] [10:23:08] one per module [Monday 26 April 2010] [10:23:23] module? [Monday 26 April 2010] [10:23:45] sebersole, we have a few "jobs", basically one per module (as they were in the past, like EM, ANN, Core) [Monday 26 April 2010] [10:24:05] so not "module" in the maven sense [Monday 26 April 2010] [10:24:22] sebersole, and each of them are "matrix", running on X databases [Monday 26 April 2010] [10:24:40] so, there are X runs of the same job, for each database (if that's what you asked) [Monday 26 April 2010] [10:25:10] sebersole, stliu can tell you better how are the Hudson jobs for trunk/comm branches as he is taking care of it [Monday 26 April 2010] [10:25:19] but that's how I understand they are [Monday 26 April 2010] [10:25:20] this is taking a lot of time, do y'all have other things to discuss in the meeting? If so we can table this and discuss after [Monday 26 April 2010] [10:25:21] now we are discussing how to setup Hudson to run the full "matrix", which we need for QA, this is not really linked to the smoke test build and deploying SNAPSHOTS, right? [Monday 26 April 2010] [10:26:08] how about that port fix into branch 33 thing? [Monday 26 April 2010] [10:26:34] hardy_, you are right... what you guys were suggesting in the last meeting (and stliu said earlier today) sounds good: running one database (hsqldb) for smoke/publishing, and then a "full suite" with all databases, for publishing the results [Monday 26 April 2010] [10:26:50] lets table the hudson duscussion for a little [Monday 26 April 2010] [10:27:02] and come back in a few minutes [Monday 26 April 2010] [10:27:05] :) [Monday 26 April 2010] [10:27:13] * jcosta goes back to QA tasks :-) [Monday 26 April 2010] [10:27:28] stliu: yes, we have to decide if we want to do one last 3.3 release [Monday 26 April 2010] [10:27:36] personally i dont [Monday 26 April 2010] [10:27:41] its not worth it imo [Monday 26 April 2010] [10:27:50] me either [Monday 26 April 2010] [10:27:54] k, done [Monday 26 April 2010] [10:27:55] ;) [Monday 26 April 2010] [10:28:12] :) [Monday 26 April 2010] [10:28:19] 482 #hibernate-dev You're not channel operator You're not channel operator [Monday 26 April 2010] [10:28:23] haha [Monday 26 April 2010] [10:28:33] op #hibernate-dev [Monday 26 April 2010] [10:28:33] Mode ChanServ gives channel operator privileges to you. [Monday 26 April 2010] [10:28:38] Invite You invited pgier to channel #hibernate-dev. [Monday 26 April 2010] [10:28:47] sebersole, will you blog this? [Monday 26 April 2010] [10:28:48] Invite You invited jdcasey to channel #hibernate-dev. [Monday 26 April 2010] [10:28:54] Join jdcasey has joined this channel (~jdcasey@adsl-074-170-244-147.sip.gnv.bellsouth.net). [Monday 26 April 2010] [10:29:00] hey jdcasey [Monday 26 April 2010] [10:29:02] hi [Monday 26 April 2010] [10:29:21] we are talking about the hibernate build and hudson [Monday 26 April 2010] [10:29:28] cool [Monday 26 April 2010] [10:29:35] and were hoping to get some of your insight [Monday 26 April 2010] [10:29:45] np, what's up? [Monday 26 April 2010] [10:29:47] deop #hibernate-dev [Monday 26 April 2010] [10:29:48] Mode ChanServ takes channel operator privileges from you. [Monday 26 April 2010] [10:30:02] stliu: blog about what? [Monday 26 April 2010] [10:30:12] no more 3.3 release [Monday 26 April 2010] [10:30:36] no more 3.3 community release [Monday 26 April 2010] [10:30:37] stliu: thats kind of implied in the final of the next major release [Monday 26 April 2010] [10:30:55] okay [Monday 26 April 2010] [10:31:22] jdcasey: to refresh... [Monday 26 April 2010] [10:31:45] we have a separate "testsuite" that we run against different databases/jdks [Monday 26 April 2010] [10:31:57] literally a separate module [Monday 26 April 2010] [10:32:04] sure [Monday 26 April 2010] [10:32:10] contains all your test code [Monday 26 April 2010] [10:32:14] no [Monday 26 April 2010] [10:32:24] it contains our "functional" test code [Monday 26 April 2010] [10:32:24] k [Monday 26 April 2010] [10:32:36] each module still has some unit tests [Monday 26 April 2010] [10:32:40] sure [Monday 26 April 2010] [10:33:17] so ideally, we'd like one "job" to build all the modules and publish snapshots [Monday 26 April 2010] [10:33:37] k [Monday 26 April 2010] [10:33:42] either with running the testsuite module against a default db (hsqldb/h2) [Monday 26 April 2010] [10:33:45] or not [Monday 26 April 2010] [10:34:26] the second job(s) would pick up those snapshots and run the testsuite against the various dbs/jdks [Monday 26 April 2010] [10:35:05] ok [Monday 26 April 2010] [10:35:36] iiuc, how the second job(s) set up depends on whether the testsuite is run/published as part of first "deploy" build [Monday 26 April 2010] [10:36:14] in the past at least y'all had recommended separate projects for the database/jdk variants [Monday 26 April 2010] [10:36:36] it would "suck in" the test suite and the needed deps [Monday 26 April 2010] [10:37:06] is this still the recommended approach? [Monday 26 April 2010] [10:37:12] hm [Monday 26 April 2010] [10:37:38] its putting you a bit on the spot perhaps [Monday 26 April 2010] [10:37:49] just thinking my way through it... [Monday 26 April 2010] [10:37:56] if you need some time to think it through thats cool [Monday 26 April 2010] [10:37:58] ok [Monday 26 April 2010] [10:39:11] so, what if the testsuite project had a dependency specified partially in properties, like ${dbDriverArtifactId} or similar...with a default value of, say, hsql? then, you could probably override that property from the command-line in your hudson job definition, and simply run that testsuite build multiple times... [Monday 26 April 2010] [10:39:12] ? [Monday 26 April 2010] [10:39:27] this is what we do today [Monday 26 April 2010] [10:39:29] I'm probably missing something important here, but that seems simple [Monday 26 April 2010] [10:39:37] ok, and where is that falling down? [Monday 26 April 2010] [10:39:44] today it build the whole project every time [Monday 26 April 2010] [10:39:58] the whole testsuite you mean? [Monday 26 April 2010] [10:40:01] no [Monday 26 April 2010] [10:40:05] oh [Monday 26 April 2010] [10:40:05] i mean the whole project [Monday 26 April 2010] [10:40:06] ugh [Monday 26 April 2010] [10:40:08] yep [Monday 26 April 2010] [10:40:41] ...but if you did it this way and told it to just build the testsuite itself, not the rest each time, couldn't you resolve snapshots that were just deployed? [Monday 26 April 2010] [10:41:01] not sure why the whole thing has to be built... [Monday 26 April 2010] [10:41:36] not sure the modules can be built individually [Monday 26 April 2010] [10:41:53] that was never a point of focus for me [Monday 26 April 2010] [10:42:29] IIRC you can tell hudson which POM file to use in a build...that might be worth investigating, to see if you can make that testsuite build by itself when needed [Monday 26 April 2010] [10:42:46] that would make the test build for each db/jdk lighter I imagine [Monday 26 April 2010] [10:42:56] jcosta: ? [Monday 26 April 2010] [10:43:28] Join pgier has joined this channel (~pgier@redhat/jboss/pgier). [Monday 26 April 2010] [10:43:33] i think you'd just tell it to check out that module [Monday 26 April 2010] [10:43:38] another possibility might be to dependency:unpack the testsuite jar into target/test-classes in a module that's preconfigured for a given db/jdk, then avoid recompiling the tests each time [Monday 26 April 2010] [10:43:42] * jdcasey shrugs [Monday 26 April 2010] [10:43:49] sebersole: yeah, maybe so [Monday 26 April 2010] [10:44:00] esp. if you're triggering the testsuite builds on the completion of the main build [Monday 26 April 2010] [10:44:07] yep [Monday 26 April 2010] [10:44:45] so i guess the first step is to verify the testsuite module will build/run stahndalone [Monday 26 April 2010] [10:44:46] IMO the dependency:unpack approach may be more fragile, though...not sure [Monday 26 April 2010] [10:44:51] yeah, I'd say so [Monday 26 April 2010] [10:45:06] try to decouple it as much as you can, so you can build it standalone [Monday 26 April 2010] [10:45:12] well the problem with the non-unpack approach is the profiles [Monday 26 April 2010] [10:45:26] i have come to dislike profiles [Monday 26 April 2010] [10:45:35] perhaps we misuse them [Monday 26 April 2010] [10:45:39] sebersole, the reason for building everything everytime is that most of the jobs are based on official QA ones, which are ant-based (and should run against the official binaries, not maven artifacts) [Monday 26 April 2010] [10:45:53] but for community builds, we can certainly use the "maven" plugin for Hudson [Monday 26 April 2010] [10:46:46] jcosta: i thought we were already? [Monday 26 April 2010] [10:46:50] sebersole: In my experience, profiles can make things pretty hard to manage...they have their uses, but it's tricky for sure [Monday 26 April 2010] [10:47:04] jdcasey: but we need them [Monday 26 April 2010] [10:47:06] sebersole, well, there were some before I started, and I didn't touch them... [Monday 26 April 2010] [10:47:10] I know... [Monday 26 April 2010] [10:47:13] ok [Monday 26 April 2010] [10:47:29] sebersole, but I'm not speaking about them (they don't run in multiple databases, AFAIK) [Monday 26 April 2010] [10:47:52] then why are they there? [Monday 26 April 2010] [10:48:43] jcosta: i mean if jobs arent being used cant we just cut them out? [Monday 26 April 2010] [10:48:45] sebersole, well, I once asked and you said to keep them there :-) [Monday 26 April 2010] [10:48:56] ? [Monday 26 April 2010] [10:49:09] I think some of them still runs [Monday 26 April 2010] [10:49:09] anyway [Monday 26 April 2010] [10:49:56] jcosta: hudson has a notion of triggering events right? [Monday 26 April 2010] [10:50:05] sebersole: so, what do the profiles mess up WRT the non-unpack approach [Monday 26 April 2010] [10:50:30] trying to think through the best way to set up these jobs [Monday 26 April 2010] [10:50:31] hudson can trigger one build on the completion of another, or trigger a build before the one in question runs... [Monday 26 April 2010] [10:50:32] sebersole, rudimentar, but yes... it can start jobs once one finishes [Monday 26 April 2010] [10:50:46] jcosta: thats all i need, cool [Monday 26 April 2010] [10:50:56] Quit AnthonyHib has left this server (Quit: Leaving.). [Monday 26 April 2010] [10:51:21] jdcasey: its the inclusion/exclusion of modules based on profiles when multiple profiles are involved [Monday 26 April 2010] [10:51:41] and then fact that it is *horrible* to leverage in IDE [Monday 26 April 2010] [10:51:43] sebersole: in the deps list, or in the reactor? [Monday 26 April 2010] [10:52:00] profiles, you mean? yes, I know a little about that... [Monday 26 April 2010] [10:52:02] in the reactor i guess [Monday 26 April 2010] [10:52:25] yes it makes running tests in the IDE amazingly difficult [Monday 26 April 2010] [10:52:39] so, you may need to build a given project multiple times with different profiles active to get everything into the repository...interesting when you mix that with the default concept of a release, too... [Monday 26 April 2010] [10:53:08] jdcasey: this is just for snapshots/nightly builds [Monday 26 April 2010] [10:53:17] sure, ok [Monday 26 April 2010] [10:53:22] yes it has common charactersitics with a release [Monday 26 April 2010] [10:53:36] but much different too [Monday 26 April 2010] [10:54:01] like i can skip docs completely (for the time being anyway_ [Monday 26 April 2010] [10:54:20] sure [Monday 26 April 2010] [10:55:35] jcosta: so what i envision then is a job that checks out all source and runs "deploy" on a particular profile [Monday 26 April 2010] [10:56:19] completion of that job triggers a number of jobs which then checkout the testsuite and run it against various dbs/jdks [Monday 26 April 2010] [10:57:03] is this something we can set up and try? or is it something you need to set up? [Monday 26 April 2010] [10:57:42] stliu, ^^ do you think you can do that ? [Monday 26 April 2010] [10:58:06] was on anthor channel, looking [Monday 26 April 2010] [10:58:22] hardy_: what do you think about splitting annotations/entitymanager *functional* tests into the testsuite module too? [Monday 26 April 2010] [10:58:30] stliu, about setting up a job that runs one profile (hsqldb) and triggers other on success (for all other databases) [Monday 26 April 2010] [10:58:48] sebersole: I think we always said it would make sense [Monday 26 April 2010] [10:58:49] the profile will be different [Monday 26 April 2010] [10:58:55] another is only testsuite? [Monday 26 April 2010] [10:59:05] actually there will be 2 profiles for the first job [Monday 26 April 2010] [10:59:43] i guess for annotations it the moving of the tests will have to happen anyways [Monday 26 April 2010] [10:59:54] so the first job would do something like: `mvn deploy -P hudson -P h2` [Monday 26 April 2010] [11:00:10] hardy_: yeah true [Monday 26 April 2010] [11:00:31] stliu: so the first job would do something like: `mvn deploy -P hudson -P h2` [Monday 26 April 2010] [11:00:51] ^^ provided we run the testsuite for this first build [Monday 26 April 2010] [11:00:51] what does the hudson profile do? [Monday 26 April 2010] [11:01:12] disables doc modules and dist module [Monday 26 April 2010] [11:01:26] it will :) [Monday 26 April 2010] [11:01:30] its not there yet [Monday 26 April 2010] [11:01:44] why not just '-DdisableDistribution' ? [Monday 26 April 2010] [11:02:25] hardy_, again, that's my question too :D [Monday 26 April 2010] [11:02:30] well it depends on my still undecided question about running the testsuite here [Monday 26 April 2010] [11:02:31] mvn deploy -P h2 -DdisableDistribution=true [Monday 26 April 2010] [11:02:45] [11:00] ^^ provided we run the testsuite for this first build [Monday 26 April 2010] [11:03:08] but if we change mind about this later [Monday 26 April 2010] [11:03:15] would you rather change the pom? [Monday 26 April 2010] [11:03:25] or change the hudson job? [Monday 26 April 2010] [11:03:37] thats why i prefer specific set ups [Monday 26 April 2010] [11:04:09] well, i'd think change hudson setup will be easier [Monday 26 April 2010] [11:04:12] with "-P hudson" you know exactly what and why [Monday 26 April 2010] [11:04:50] for you maybe [Monday 26 April 2010] [11:05:04] if i have access to do such things i have no clue how to do it [Monday 26 April 2010] [11:05:32] okay, that's true [Monday 26 April 2010] [11:05:57] on the other hand it makes the hudson job harder to understand [Monday 26 April 2010] [11:06:08] -P hudson ? [Monday 26 April 2010] [11:06:10] -P hudson does not tell me anything [Monday 26 April 2010] [11:06:25] but -DdisableDistribution does? [Monday 26 April 2010] [11:06:30] yes [Monday 26 April 2010] [11:06:32] i dont get that [Monday 26 April 2010] [11:06:49] it "means more" to you because you know what it does [Monday 26 April 2010] [11:07:20] aka, it has meaning to you because you know the meaning :? [Monday 26 April 2010] [11:07:21] it has been documented in the source page [Monday 26 April 2010] [11:08:43] yep its hard to edit that thing to add a blurb about a special profile ;) [Monday 26 April 2010] [11:09:23] i don't think this is so important. Personally I would have configured this options in the Hudson job and not used a hudson profile [Monday 26 April 2010] [11:09:32] anyway, stliu, so is this something you can set up? [Monday 26 April 2010] [11:09:33] sebersole, how about let's use the simpler one first [Monday 26 April 2010] [11:09:35] but I can see the benefit of the profile as well [Monday 26 April 2010] [11:09:40] yes, i can do it [Monday 26 April 2010] [11:09:53] look at it like this guys [Monday 26 April 2010] [11:10:16] of course we have never gotten in trouble in hibernate code by overloading values right? [Monday 26 April 2010] [11:10:37] when some terms means multiple things you are asking for trouble down the road [Monday 26 April 2010] [11:11:08] if you want to start off using -D fine [Monday 26 April 2010] [11:12:11] stliu: is this something you can work on asap? [Monday 26 April 2010] [11:12:42] I can finish it in this week, is it soon enough? [Monday 26 April 2010] [11:13:10] thats great [Monday 26 April 2010] [11:13:17] :D [Monday 26 April 2010] [11:13:39] we may need to do some work on the testsuite pom to get it work work "standalone", not sure [Monday 26 April 2010] [11:13:56] it can works standalone [Monday 26 April 2010] [11:14:00] cool [Monday 26 April 2010] [11:14:25] real quick, in terms of 3.6 [Monday 26 April 2010] [11:14:45] the poms are now jdk 1.5 source/target