[hibernate-dev] IRC meeting 6/7

[Steve Ebersole]

Here are the notes from todays meeting.  Thanks to Hans and Jason for
joining and answering Gradle questions.

-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org
-------------- next part --------------
[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 (~epbernard at 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 (~epbernard at 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 (~epbernard at 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.