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