This week we discussed progress on 3.6: 1) both of the main features (types and key-many-to-one) are largely done; so I will start making the pre-release schedule for alphas/betas
2) discussed merging of annotations again; basically holding until the docs are merged. 3) discussed possibility of merging jmx code back into core as well now that we have moved to JDK 1.5 which includes the jmx classes 4) discussed possibility of merging testing/testsuite back into core as well. revisited why, maven limitations, and discussed move to gradle as a way to alleviate this as well as other issue we have with maven. 5) As a follow up to the gradle discussion we agreed to not decode today. We will put this off until next week. But if importing a gradle project into both eclipse and intellij is working and we can get the jdocbook stuff working in gradle, then i plan on moving to gradle for the build. 6) move to H2 as default test database complete on trunk. This led to a general realization that we may need to revamp our temp table usage a bit on a few databases. I will send a follow up email about that topic a little later. -- Steve Ebersole <st...@hibernate.org> http://hibernate.org
[10:00] <sebersole> i guess we'll get started [10:01] <sebersole> first i wanted to talk a bit about 3.6 [10:01] <sebersole> i finished up the major task for 3.6 last week [10:02] <stliu> type? [10:02] <sebersole> so we should start planning some pre-releases [10:02] <sebersole> types and key-many-to-one stuff [10:03] <sebersole> we had a hole in jpa2 support with the key-many-to-one stuff [10:03] <sebersole> so it was important to fix [10:03] <sebersole> please jboss wanted it for specj [10:03] <sebersole> well needed it for specj [10:03] <hardy_> do we pass specj now? [10:04] <sebersole> not sure [10:04] <sebersole> stale hadnt had a chance to try it out last we talked [10:04] <hardy_> ok [10:04] <sebersole> but the test case we wrote in core based on the specj usage is passing [10:05] <sebersole> just a few loose ends to tie up for 3.6 [10:05] <sebersole> 1) documentation [10:05] <sebersole> was really hoping emmanuel would be here so we could find out how far he got [10:05] <hardy_> it's public holiday in France [10:06] <sebersole> i started a new chapter on types [10:07] <sebersole> another issue is temp table support [10:07] <sebersole> (2) temp table support [10:07] <hardy_> what's that? [10:07] <sebersole> sql temporary tables [10:08] <sebersole> that how we implement "bulk hql" [10:08] <sebersole> in cases where the update or delete spans multiple tables [10:08] <sebersole> we break it down into 2 steps... [10:09] <sebersole> first we populate a temp table with all the IDs that match [10:09] <sebersole> then we execute the update/delete against all the entity tables matching on the ids in the temp table [10:09] <sebersole> far more efficient [10:09] <sebersole> then pulling all the ids back into memory [10:10] <hardy_> thanks. I did not know that. Do all databases support temp tables? [10:10] <sebersole> yes and no [10:10] <sebersole> thats the issue :) [10:10] <hardy_> :) [10:10] <sebersole> temp tables are ansi standard [10:10] <sebersole> so they all have them (hsqldb aside, surprise [10:11] <hardy_> seems we should really not use hsql anymore [10:11] <sebersole> however, they do not all support them correctly [10:11] <sebersole> (hardy_ well i have switched the default profile) [10:11] <hardy_> I noticed. I am doing the same for Search [10:11] <sebersole> some times we can work around the lack of support [10:12] <sebersole> sometimes we really cannot [10:12] <sebersole> well cannot as-is [10:12] <sebersole> in those cases we either (1) need a new paradigm [10:12] <sebersole> or (2) say we dont support it on those dbs [10:13] <sebersole> the issue is that the number of dbs is not small [10:13] <sebersole> perhaps this is better mapped out in an email; [10:14] <sebersole> i'll write one up today to the dev list [10:14] <hardy_> maybe - seems quite lengthy [10:14] <sebersole> its involved yes [10:14] <sebersole> last thing for me & 3.6 is module merging [10:15] <sebersole> we decided to merge annotations into core [10:15] <hardy_> how did it go so far? [10:15] <sebersole> i have not started [10:15] <stliu> have hat started yet? [10:15] <stliu> oh [10:15] <stliu> okay [10:15] <sebersole> was kind of waiting to see about docs [10:15] <sebersole> another likely candidate is jmx [10:16] <sebersole> since 1.5 bundles jmx no iirc [10:16] <sebersole> since 1.5 bundles jmx now iirc [10:16] <hardy_> i think so [10:16] <sebersole> and we also need to discuss testing/testsuite [10:17] <hardy_> you mean jconsole and the like [10:17] <sebersole> hardy_: i guess [10:17] <hardy_> what about jmx? You want to expose statistics via JMX? [10:17] <sebersole> we have all this already :) [10:17] <sebersole> hibernate-jmx [10:17] <sebersole> its just that its a separate module [10:18] <hardy_> ahh - got it [10:18] <sebersole> because previously the jdk did not provided the needed classes [10:18] <sebersole> jse that it [10:18] <hardy_> I was just about to say that this stuff is already there [10:18] <sebersole> is [10:18] <hardy_> makes sense [10:18] <hardy_> the less unnecessary modules the better [10:18] <sebersole> testing/testsuite is the bigger issue [10:19] <sebersole> maven imposes serious limitations here [10:19] <sebersole> we spoke with john casey last week [10:19] <sebersole> and he was going to try to get this workable [10:19] <sebersole> http://jira.codehaus.org/browse/MCOMPILER-128 [10:20] <jbossbot> [MCOMPILER-128] "Extra" Compiler mojo for non-test, non-main code [Open, Major, John Casey] http://jira.codehaus.org/browse/MCOMPILER-128 [10:20] <sebersole> but i am not hopeful [10:20] <sebersole> i have seen the maven guys shoot down similar enhancements b4 [10:20] <sebersole> sooo... [10:20] <sebersole> (wait for it) [10:20] <sebersole> is this the time to move to gradle? [10:20] <hardy_> drum rolls [10:21] <sebersole> hehe [10:21] <gbadner> hi everyone; sorry, overslept :( [10:21] <sebersole> np [10:21] <hardy_> i am still undecided. [10:21] <sebersole> oddly, as john was here talking to us about that, hans (the gradle lead) was pinging me to let me know that the long-awaited intellij intg should be released this week or next [10:22] <sebersole> hardy_: what is the concern? [10:22] <hardy_> i completely agree that maven has limitations (quite a few), but otoh we sorted most things out after a lot of pain and now we move to gradle/ [10:23] <sebersole> hardy_: we have not sorted anything out [10:23] <sebersole> thats the issue :) [10:24] <sebersole> we lived the limitations and contortions maven enforced on us [10:24] <hardy_> well, you wrote a docbook mojo [10:24] <sebersole> and i wrote a jdocbook gradle plugin [10:24] <hardy_> created magically an dist assembly, etc [10:24] <hardy_> :) [10:24] <sebersole> the dist stuff is total hack as well [10:24] <hardy_> i am aware of this [10:25] <sebersole> because its not TheWayMavenWantsIt [10:25] <hardy_> but will this all be a piece of cake in gradle [10:25] <hardy_> and super easy to understand? [10:25] <hardy_> I am sure at some stage we will have to "hack" as well [10:25] <sebersole> i have had a pretty complete gradle POC sitting in svn for quite some time now [10:25] <hardy_> on the plus side that is more encouraged in gradle/groovy [10:26] <sebersole> it comes down to this with gradle... [10:26] <sebersole> maven is nice because of build-by-convention [10:27] <sebersole> however it takes an extremely inflexible view of this [10:27] <hardy_> agreed [10:27] <sebersole> gradle (,and buildr, etc) have a nice mix of build-by-convention and scripting [10:27] <sebersole> imo obviously [10:28] <hardy_> have you tried any of the other build tools? Why did you chose gradle for the POC? [10:28] <sebersole> i love that i have build-by-conventionm but can then script stuff i need to script, like building a dist [10:28] <sebersole> i tried sbt and buildr [10:29] <sebersole> i am not a scala fan [10:29] <hardy_> ok [10:29] <sebersole> and i found gradle/groovy easier to understand that buildr/ruby [10:29] <hardy_> is there not also raven or something like this? [10:29] <sebersole> and the groovy plugin system is amazing [10:29] <sebersole> there is gmaven [10:30] <sebersole> but its just a maven plugin [10:30] <hardy_> so you reckon gradle has the biggest community support? [10:30] <sebersole> in fact i use it for the javadocs [10:30] <sebersole> out of the 3 i mentioned, yeah i think so [10:30] <hardy_> ok [10:31] <hardy_> and when it comes to depednecies it works with the maven repo (consuming + deploying), right? [10:31] <sebersole> personally I am inclined to say that if this intellij importing works, we can get the jdocbook stuff working and the eclipse imports work that we do this move [10:31] <stliu> hardy_, right [10:31] <sebersole> yes, it uses ivy [10:32] <sebersole> so in terms of naming dependencies it supports anything ivy supports [10:32] <hardy_> if bloody ivy would have come earlier we could still be using ant + ivy ;-) [10:32] <sebersole> nope [10:33] <hardy_> you are missing the project description stuff? [10:33] <sebersole> that, and scripting [10:33] <hardy_> fair enough [10:33] <sebersole> xml is simply an inflexible medium for this [10:34] <sebersole> look we dont have to decide today [10:34] <sebersole> but i would really like people to look around [10:34] <stliu> i agree with you of moving to gradle once those problems resolved [10:34] <sebersole> and maybe even play around with it [10:34] <hardy_> what's about NetBeans? Does this support gradle? Just out of interest [10:35] <sebersole> see, i got stliu hooked on it from the jdocbook stufff :) [10:35] <stliu> don't know about netbeans [10:35] <sebersole> no clue about netbeans [10:35] <stliu> and netbeans support is not in the gradle support ide list from the doc i saw [10:35] <hardy_> sebersole: ping me once the idea plugin is available via the plugin site. I will give it a go as well [10:36] <sebersole> hardy_: not sure its that kind of plugin [10:36] <sebersole> i think it might be a gradle plugin [10:36] <stliu> hardy_, like mvn idea:idea i'd think [10:36] <sebersole> akin to the older style support for maven [10:36] <hardy_> i see [10:36] <hardy_> :( [10:37] <sebersole> there is already a plugin for it based on the gradle ui [10:37] <hardy_> well, anyways. Let me know when it's ready. I try both (IDE plugin and gradle plugin) [10:38] <hardy_> in fact I think I have the IDE plugin already installed [10:38] <stliu> idea does support run gradle build files i'd think [10:39] <sebersole> stliu: btw got that branch committed [10:39] <stliu> sebersole, good, i will look it tomorrow [10:40] <sebersole> stliu: it supports running them yes, that what the ui plugin does [10:40] <sebersole> its always more been about importing a gradle project into intellij [10:41] <sebersole> so thats all i had [10:41] <stliu> gbadner, you want to talk that issue with us? [10:41] <stliu> hardy_ and steve both here [10:42] <sebersole> stliu: the branch is called 'initial-resolvers-wip' [10:43] <gbadner> turns out that the aliastobean transformer was still broken [10:45] <gbadner> it was caching the result properly, but PropertyAccessor does not overload hashCode [10:45] <gbadner> so the QueryKey would never match [10:45] <sebersole> why is it caching the accessors? [10:46] <gbadner> it's in the transformer, which is in the QueryKey [10:48] <gbadner> I was going to look into that today [10:48] <gbadner> the other transformers I fixed work ok [10:58] <sebersole> so is there anything we need to discuss about it? [10:58] <gbadner> well, I kind of set it down on Friday to rest when I saw this [10:59] <gbadner> I saw there were a bunch of PropertyAccessor subclasses [11:00] <gbadner> anyhow, I'll look into overloading hashCode() and equals() today [11:00] <gbadner> I'll create a patch of what I have now [11:00] <gbadner> sebersole, is now a good time, it might take 15-30 min [11:01] <gbadner> 15-30 min to review it [11:01] <sebersole> well thats why we are here right? [11:01] <sebersole> hardy_: did you have anything? [11:01] <gbadner> ok, sec [11:02] <hardy_> not really [11:02] <hardy_> I am ready for another Validator release now [11:02] <hardy_> I could give a hand with the documentation [11:03] <hardy_> or maybe see if there are any urgent bugs in EM or Annotations [11:03] <hardy_> but we can take this as it comes
_______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
