[09:55] few minutes early, but y'all ready to start? [09:55] sebersole: epbernard btw, when I started Intellij today I got a notification that my license expires in 4 days. Do we have a new license key? [09:55] yep, its on my list for today :) [09:55] to discuss [09:56] uhh - I wonder what that means [09:56] first i wanted to thank hans__ and lightguard_jp for joining [09:57] both work on gradle and agreed to join in case y'all had questions on that later [09:57] hardy: we can start there [09:57] * lightguard_jp waves. Hi all [09:58] i just mean that i had the same experience [09:58] we need to find out if they plan on continuing to give use licenses for utlimate [09:58] hi hans__ I have seen many times of your name from gradle's source code :D [09:59] stliu: :) [09:59] epbernard: have you contacted them yet? [10:00] sebersole: have they indicated once that we should use the community version [10:00] they gave us problems last time the license came up [10:01] we'll see [10:01] so i guess we'll circle back to that [10:01] did anyone get time to look over the temp table stuff? [10:02] not from me [10:02] not more than reading your email and the wiki page [10:03] ok [10:03] so i'll probably just move forward on that then [10:03] the last thing i had was gradle [10:04] has anyone looked at that? [10:04] i checked out the gradle branc and built it [10:04] have you finsihed that mead+gradle plugin? i saw from you mail [10:05] also tried to get familiar with the whole concept and syntax [10:05] stliu: no [10:05] i like the fact that it overcomes some of the maven problems [10:05] if not all [10:06] i think it fits better [10:06] and I share the same frustrations about maven as you described on your wiki page [10:06] which at the end of the day is all we really need to decide [10:06] gradle is young and will have some pains [10:07] but does the conept match better with what we want to do [10:07] but as I also mentioned before is whether it's worth changing now where the maven build is working (admitingly with hacks) [10:07] hardy: it already 75% done [10:08] and as you just said, i am sure we will have some pains with gradle as well [10:08] that branch is pulled from trunk recently [10:08] the one thing that still gnaws at me is releases [10:09] sebersole, i'd think it would better to wait for gradle GA [10:09] just to be safe [10:09] stliu: well that effectively means not doing it for 3.6 [10:09] hans__, btw, i haven't find a way to join gradle mail list [10:10] stliu: You mean you could not find instructions how to do it? [10:11] http://www.gradle.org/lists.html [10:11] I had another community member say it took him a long time to join, like the subscrition emails were taking a long time to be delivered. [10:11] sebersole: do you think there will be implications for contributors and patches when we switch to gradle? [10:11] It is the codehaus infrastructure we are using. [10:12] hardy, good point [10:12] hardy: i dont see how [10:12] my guess is most people use IDE [10:12] I mean pretty much everyone runs maven now. What will contributors/ patch submitters say if we ask them to run gradle [10:12] not sure about this one [10:12] about what? [10:12] yes, not very much people know/familiar with gradle for now [10:13] hardy: The good thing is that people don't need to install it locally. [10:13] which was the case when we switched to maven 2.5+ years ago [10:13] using gradle might add another barrier to provide runable unit tests [10:13] hans__: You don't need to install it locally? [10:13] hardy: They can use the gradlew scripts which automatically downloads Gradle. [10:14] hardy: They just checkout and type ./gradlew build [10:14] If you have the wrapper in svn then there's really nothing you'd have to do just tell them to gradlew and you're done. [10:14] we have the scripts [10:14] right, I didn't know that. sounds promising [10:14] yes we just need to document the 3 or 4 tasks they are likely to need to know [10:14] that's cool [10:14] heres how you jar [10:15] heres how you test [10:15] etc [10:15] jupp, that's a must [10:15] and if I understand correctly with gradle we can actually have a build which works out of the box [10:15] yes [10:16] i mean without having to configure repos in settings.xml [10:16] yes [10:16] that a big plus [10:16] hans__: is there a plan to better allow deployments in OSS projects [10:16] For what its worth: You could also define a default task which gets executed if you just type ./gradlew [10:17] specifically better support for externalization of user name and passwords [10:17] hans__: yeah we do have default tasks setup [10:17] sebersole: You mean beyond putting them in gradle.properties in GRADLE_USER_HOME? [10:17] sebersole: One thing we want to offer is encryption. [10:18] hans__: well i mean that works but [10:18] it would be a lot nicer if gradle.properties could inject those values [10:18] sebersole: You mean into the tasks? [10:18] right now the script has to account for them *and* account for them not being set [10:19] the other thing we have been asked about is the notion of an "altDeploymentRepository" [10:19] sebersole: How would injection look like? [10:20] i'm thinking something like ".username=" [10:20] sebersole: the altDeploymentRepository would be used if the other one is not reachable? Or would that be a static thing? [10:20] hans__: consider you want to build hibernate [10:21] but that your company hosts a corporate repository [10:21] so you need to deploy to that repo [10:21] since you probably dont have creds to deploy to the hibernate (jboss) one [10:21] sebersole: There are a couple of ways you could implement that. [10:22] sebersole: You can always provide an init.gradle (either via -I or in the gradle user home). [10:22] which would do what? [10:22] sebersole: With that you can hook deeply into any Gradle build. And for example replace the upload task. [10:23] sebersole: Regarding the injection. Something like this is planned. [10:23] ok [10:23] sebersole: A project and user specific settings where you can reconfigure task properties. [10:23] sebersole: Alt deployment probably isn't as easy in Gradle atm as adding servers in the settings.xml [10:24] sebersole: But you could provide a skeleton to make it very easy. [10:24] But I'm not that familiar with the deployment portion of gradle [10:25] hans__: yeah, i know there are ways to do it [10:25] just have not gotten there yet [10:26] hans__: do you have any idea of ga timeframe? [10:26] sebersole: You could have something like: if there is a script alt-repo.gradle in some location, apply it. [10:27] sebersole: First there won't be a 0.10 :) [10:27] sebersole: We want to have a couple of 4-weeks 1.0-milestones [10:27] i used to be a castor users, so i appreciate that ;) [10:27] And hopefully release 1.0 at the end of summer. [10:28] Worst case JavaOne from my understanding [10:28] At least an RC. [10:29] <-- adamw1pl has left this server (Quit: adamw1pl). [10:29] We are very focused but of course we don't know. [10:29] On the other hand I wouldn't bother too much about the GA. [10:29] me either :) [10:29] The quality is I think very good. Gradle is used already in production for very big enterprise builds. [10:30] our friends at spring too it seems like [10:30] Baring the little Win 64-bit JVM bugs (which I believe are fixed), 0.9 is very stable. [10:30] sebersole: what's our time plan? 3.6 when and what comes then? [10:30] 3.6 is largely ready to go [10:31] but we are holding because of merging modules [10:31] lightguard_jp: We would need a more elaborate CI infrastructure to capture those. [10:31] and we need to remember that testsuite is a big hold up here [10:31] and maven offers us no hope of a better solution [10:31] hans__: True, just relying on users to report those 64-bit issues right now. [10:32] sebersole: so you were planning to do the gradle switch for 3.6? [10:32] yes [10:32] lightguard_jp: We would need a CI build for the whole matrix: JavaX-osY We would need our own machines for that and hopefully will get them soon. [10:32] the timing was good [10:33] did anyone try the eclipse project generation? [10:33] me :) [10:33] how did it go? [10:33] it is good [10:33] from my perspective we could have done 3.6 with maven and then switch which would more align with a CR/Ga of gradle [10:34] and the testsuite? [10:34] merging all these modules just means that that issue gets bigger and bigger [10:34] now annotations will have the same problem [10:35] stliu: do we have the necessary stuff in hudson for gradle? [10:35] no [10:36] what does that take? [10:36] our hudson does not have that gradle plugin [10:36] i was planing rise an feature request [10:36] You can always take the wrapper. [10:36] lets do that anyway [10:36] but do not hope they can apply it soon [10:37] stliu: You can run the Hudson build with ./gradlew [10:37] i should have requested this long time ago [10:37] stliu: As long as the plugin is not available. [10:37] yes it takes forever to get stuff done around here [10:37] yeah [10:37] no comment [10:37] :) [10:37] How long does your full test-suite takes to run> [10:37] ? [10:38] depends on the db [10:38] right now on h2 i think its like 5 minutes maybe [10:38] but [10:38] we are expanding it by alot [10:39] thinking an hour or more then? [10:39] an hour? [10:39] yikes, i hope not [10:39] sebersole: So the Gradle parallel testing feature might be interesting. [10:39] How many DBs will you be testing? [10:39] hans__: parallel as in threaded? [10:39] 8? [10:40] sebersole: It uses multi-processes. [10:40] threaded wont work for us [10:40] sebersole: So no probs with in-memory-dbs. [10:40] sebersole: They all get their own forked JVM. [10:40] now we have a db matrix hudson job which run them parallel [10:40] hans__: oh i think i understand [10:41] no we only run one db at a time [10:41] stliu: Any idea which one would be slowest? We're talking about standard DBs and in-memory? Like mysql, pg, oracle, etc? [10:41] this plays into the discussion we were having the other day hans [10:41] sebersole: Multiple-DB's shouldn't be an issue at all of course. [10:42] different dbs, no [10:42] sebersole: Right, different I mean. [10:42] but we only run one db per build [10:43] though i am not against thinking through this new way [10:43] sebersole: Then it depends on the db and on the isolation of the tests. [10:43] sebersole: It would be easy to group according to that dynamically. [10:43] sebersole: Then run some tests in parallel and others sequentially. [10:44] sebersole: For us parallel testing has been a big time saver. And it works on the dev machine, not just on CI. [10:44] our schemas are very test specific is the problem [10:45] most tests create their own schema on the fly [10:45] But you run each test for each DB? [10:45] but, i think its worth considering in the CI case [10:46] http://hudson.jboss.org/hudson/view/hibernate/job/hibernate-core-testsuite/ [10:46] lightguard_jp: we run the all the tests against a database for that build [10:46] then we kick off other builds for the other databases [10:47] Couldn't we run each database at the same time in different vms? [10:47] [10:43] though i am not against thinking through this new way [10:47] its just not what we do today [10:47] of course we can :D [10:48] Is that what is / will be happening (in the near future)? If it is, then we can let Gradle do the work of spawning each of those out. [10:48] and it would reduce the ci time, you know, for now, each db job checks out the source [10:49] lightguard_jp: i think thats an option [10:49] You're doing a full checkout / rebuild for each db? [10:49] it checks out the testsuite [10:49] the modules are already built [10:50] it is the behavior from hudson job matrix :( [10:50] though thats not the same if you move testsuite back into core/src/test [10:50] it would reduce the need for extra check outs [10:51] stliu: is right, it would speed things up a bit [10:51] so we could have a series of hibernate.properties files [10:51] and iterate them [10:52] maybe we just need inject the properties [10:52] how? [10:52] if its all the same build run [10:52] -D is not going to work [10:52] oh, right, i was thinking something like maven profile :( [10:53] i used too much maven :( [10:53] sebersole: no, I've not contacted JetBrains [10:54] stliu: how do i go about requesting that gradle plugin be added? [10:54] sebersole: We talked about this injection thing with the hibernate.properties and I think we came up with a couple of possible solutions. [10:54] sebersole, i can do that [10:55] hans__: is there any real diff to using gradlew versus the hudson plugin? [10:55] sebersole: The diff is in regard to reporting and aggregation of reports. [10:55] sebersole: Re building there is no difference. [10:55] sebersole: can I ask some doc questions before we get further into gradle. I need to head off soon. [10:55] so its worth using the plugin if possible [10:56] hardy: sure [10:56] sebersole: Yes. [10:56] sebersole: But not critical. [10:56] hans__: ok [10:57] just some general style questions. We said the other day that we wrap code examples into 'example' nodes, right? [10:57] right [10:57] all of them or do we leave eg one liners without example? [10:57] also, the font used for the example title in pdf is ways to big. how do we go about this? [10:58] who is maintaining the styles? [10:58] hardy: no clue [10:58] we maintain our styles [10:58] whihc extend fron the jboss styles [10:58] sebersole: hardy what's the benefit to externalize all examples [10:58] that's a lot of work and make the editing harder :( [10:58] its not externalized epbernard [10:58] ah ook nm :) [10:58] no externalize, but having some in an example [10:59] he just means [10:59] ah ok, to give a title and co [10:59] its a wrapper for etc [10:59] this way you can give it a title and you can xref the example [10:59] and its better consistency wise [10:59] and you can (if wanted) an index of examples [10:59] hardy: wrt one liners, i guess it depends [11:00] ok [11:00] examples are generally not one line [11:00] not all are examples [11:01] sebersole, https://jira.jboss.org/browse/JBQA-3458 [11:01] --> epbernard_ has joined this channel (~epbernard@redhat/jboss/epbernard). [11:01] stliu: ty! [11:01] true, but for example the collection chapter has lines like '' in a programlisting [11:02] sebersole: is there a jira project for the hibernate styles [11:02] for ours yes and for the jboss ones [11:03] hardy: ours is keyed STYLE in our jira [11:03] forget the jboss one [11:03] <-- epbernard_ has left this server (Client Quit). [11:03] ok [11:03] guys real quick on gradle... [11:04] hardy: it seems like you have looked around [11:04] i'm okay if you want to move to gradle in 3.6 [11:04] but i'd really like to have a consensus here [11:04] so [11:04] this week i will find some time to finish up the gradle2 branch [11:05] please keep an eye on it [11:05] --> epbernard_ has joined this channel (~epbernard@redhat/jboss/epbernard). [11:05] and next week we decide [11:05] yeah, okay [11:05] ok [11:05] so thats all i had [11:05] i'll find out about the intellij license too [11:06] sweet [11:06] regarding the docs again [11:06] another thing i'd like bring to your attention is that now we have hudson setup, then we should spend some time on the failure test cases [11:06] hardy: you know jared and the pressgang folks? [11:06] is there some sort of standard for cross reference names? For example 'example-xyz' or 'section-xyz' [11:07] to date not [11:07] sebersole: i've heard about the pressgang project, yes [11:07] those are good folks to ask [11:07] for standards you mean? [11:07] for styles [11:08] right [11:08] though they are docbook people [11:08] <-- epbernard_ has left this server (Client Quit). [11:08] misty in #jboss-docs [11:08] and now you are going to tell me on which irc channel they are hanging out [11:08] ROFL [11:08] \ [11:08] she is in australia [11:08] --> epbernard_ has joined this channel (~epbernard@redhat/jboss/epbernard). [11:09] they hang out o a few [11:09] yeah they created a public one for pressgang [11:10] here on freenode [11:10] i think I've seen that [11:10] but for sure there is #jboss-docs here and on redhat [11:11] i will contact them and see what they say. But basically we don't have any naming standards yet and regarding the styles maintain our own [11:11] epbernard: do you think my type chapter should go before this mapping one you are working on? [11:11] btw, hans__, lightguard_jp very glad to talk to you guys, i was spending some time on that jdocbook-gradle plugin development, and has used gradle for awhile, it is great [11:11] fair enough. Just wanted to make sure that I am not breaking some conventions here [11:12] hardy: i tried being a little more categorical in that type chapter [11:12] but i use dots [11:12] (mainly just as a trial but forgot to convert them) [11:13] sebersole: i have a look to see what you've done there, thanks [11:13] sebersole: I'd say after [11:13] k [11:13] Mine is the basics to get people familiar [11:13] and then we dinve into detailed subject (like type) [11:13] <-- lightguard_jp has left this server (Read error: Connection reset by peer). [11:14] ok, then, thank everyone [11:14] thanks hans__ [11:14] Thanks for looking into Gradle :) [11:14] hardy: le me know what you think of the set of patches I've sent [11:16] epbernard: ok. I quickly browsed through them. Generally, I have no problem breaking the existing contracts.