15:51:57 <sebersole> #startmeeting
15:51:57 <jbott> Meeting started Tue Feb 25 15:51:57 2014 UTC.  The chair is sebersole. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:51:57 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:52:05 <hardy_> I did not think about these metamodel classes when I wrote the code
15:52:28 <sebersole> i just find they are also general concepts
15:52:42 <sebersole> so thats what i try to apply consistently
15:52:46 <hardy_> but as said, makes sense. As you say, you should be able to re-purpose a lot of the existing code
15:52:53 <sebersole> right
15:53:01 <sebersole> and then moving a lot of it to binder
15:53:06 <sebersole> well, not alot
15:53:07 <sebersole> some
15:53:08 <hardy_> also +1 for deferring to Binder
15:53:14 <sebersole> cool
15:53:40 <sebersole> gbadner: was just catching up with hardy_ about the work i have been doing in org.hibernate.metamodel.internal.source.annotations
15:53:49 <hardy_> another reason I might have done to much in the source package was that the Binder was very unstable for some time
15:53:59 <sebersole> sure
15:54:16 <sebersole> i think me looking across everything has helped there too
15:54:24 <hardy_> all the jpav experiments with "chasing" etc
15:54:28 <sebersole> as i can see the bigger picture across then all
15:54:36 <sebersole> oh yes, i remember
15:54:39 <hardy_> how is the reflite stuff coming
15:54:56 <sebersole> jason now ducks my pings :)
15:54:59 <hardy_> do you have this ready for use for the rewrite of source.annotations
15:55:03 <hardy_> lol
15:55:21 <sebersole> so i have no idea where that stands in terms of what jandex may or may not do
15:55:32 <hardy_> ok
15:55:34 <sebersole> atm i just expose ClassInfo
15:56:01 <sebersole> what i found is that we often need to access the annotations "both ways"
15:56:05 <hardy_> I guess for the first release you will need to mix things together - aka use Jandex, but also class loading via the tmp classloader
15:56:08 <sebersole> 1) specific to a target
15:56:10 <sebersole> 2) generally
15:56:17 <hardy_> aggregate all together and put it behind reflite
15:56:21 <sebersole> right
15:56:30 <sebersole> i still need to tie in classmate
15:56:32 <hardy_> hopefully Jandex will catch up and take some of the responsibiltites
15:56:46 <sebersole> i dont have the full picture of classmate, so its hard
15:56:57 <sebersole> i know you say its easy
15:57:09 <sebersole> but that was not my experience :)
15:57:15 <hardy_> it is, just a few lines really
15:57:25 <sebersole> well yes, but
15:57:27 <hardy_> and as said, you can optimise when you are not dealing with hierachies
15:57:32 <hardy_> then it is not needed at all
15:57:32 <sebersole> then i have to interpret the outputs
15:57:35 <sebersole> thats the concern
15:58:20 <sebersole> anyway, i plan to look at it as part of the reworking of the annotation-based source
15:58:29 <sebersole> since thats the main user of it
15:58:35 <sebersole> but even there...
15:58:39 <sebersole> that should be in binder
15:58:56 <hardy_> really?
15:59:18 <sebersole> sure in both we need to interpret collection element types, e.g.
15:59:34 <sebersole> we just did not do that historically in hbm binder
15:59:44 <hardy_> right, but in the Binder you are dealing with concrete types, e.g. List<User>
15:59:52 <sebersole> nope
16:00:01 <sebersole> binder builds Metadata
16:00:14 <sebersole> which is all Class and ClassLoader free ideally
16:00:20 <hardy_> whereas the purpose of classmate is to figure out that List<T> is actually a List<User> (loosely speaking)
16:00:30 <sebersole> yep, i underdstand
16:00:36 <sebersole> see above
16:01:03 <sebersole> what we really want...
16:01:11 <sebersole> is for reflite to expose that info
16:01:16 <hardy_> right
16:01:40 <hardy_> that is more impl specfic
16:01:43 <sebersole> so for a method return (e.g.) what are the param types
16:01:50 <sebersole> impl?
16:02:00 <hardy_> so you don't really want a User class, but the Name instance for it
16:02:19 <sebersole> well, the JavaTypeDescriptor
16:02:21 <hardy_> what I mean is that I just tried to conceptually explain what classmate is doing
16:02:27 <sebersole> ah
16:02:29 <sebersole> ok
16:02:52 <hardy_> and yes, concretely you would have to deal with JavaTypeDescriptor & Co
16:03:03 <sebersole> exactly
16:03:05 <hardy_> the pita here will be, that classmate works with classes
16:03:13 <sebersole> so thats where the concern over using classmate comes in
16:03:21 <sebersole> i have the class
16:03:23 <hardy_> so when you do the resolution you will load classes
16:03:29 <sebersole> thats not a problem
16:03:39 <hardy_> however, you should then be able to go from Class to JavaTypeDescriptor
16:03:39 <sebersole> i can feed classmate the class
16:03:49 <sebersole> well, can i?
16:03:56 <hardy_> in the reflite impl
16:04:02 <sebersole> sure, can i?
16:04:16 <sebersole> this is where (imo) classmate is not clear
16:04:27 <sebersole> for example...
16:04:34 <sebersole> org.hibernate.metamodel.reflite.spi.MethodDescriptor
16:04:47 <sebersole> so back to your example.. List<User>
16:04:59 <sebersole> so i have a method:
16:05:08 <sebersole> List<User> getUsers() { ... }
16:05:26 <sebersole> how do i expose that on method?
16:05:34 <sebersole> org.hibernate.metamodel.reflite.spi.MethodDescriptor#getReturnType
16:05:42 <sebersole> is not really the right place i dont think
16:05:55 <sebersole> likely org.hibernate.metamodel.reflite.spi.MethodDescriptor#getReturnType should be the "erased" ype
16:05:57 <sebersole> type
16:06:26 <sebersole> so does MethodDescriptor expose "return param types"?
16:06:57 <sebersole> so that for this exmaple...
16:07:25 <sebersole> MethodDescriptor("getUsers")#getReturnType -> JavaTypeDescriptor(java.lang.List)
16:07:27 <sebersole> and
16:07:51 <hardy_> still there, keep going, looking at the same time
16:07:59 <sebersole> MethodDescriptor("getUsers")#getReturnParamTypes -> [JavaTypeDescriptor(com.acme.User)]
16:08:01 <sebersole> ?
16:08:32 <sebersole> we can cheat a little ;)
16:08:44 <sebersole> so we only care about the return type param types
16:08:53 <sebersole> we dont have to make this general purpose
16:09:26 <hardy_> should a JavaTypeDescriptor not have something like  	getTypeParameters()
16:09:27 <sebersole> class param types, method return param type, and field param types
16:09:37 <sebersole> [10:17] <sebersole> likely org.hibernate.metamodel.reflite.spi.MethodDescriptor#getReturnType should be the "erased" ype
16:09:47 <hardy_> which in this case you be User
16:10:05 <sebersole> i'd really rather not get into duplicating JavaTypeDescriptor for each parameterized type
16:10:21 <sebersole> yes, thats is an option though
16:10:36 <sebersole> JavaTypeDescriptor(List)
16:10:36 <hardy_> that's how I thought it would work
16:10:39 <sebersole> JavaTypeDescriptor(List<User>)
16:10:42 <sebersole> JavaTypeDescriptor(List<T>)
16:10:47 <hardy_> and do you really need to duplicate
16:10:50 <sebersole> JavaTypeDescriptor(List<Car>)
16:10:52 <sebersole> etc
16:11:02 <sebersole> how would you not?
16:11:26 <hardy_> ahh
16:11:27 <sebersole> if like you said  JavaTypeDescriptor has   getTypeParameters()
16:11:29 <hardy_> i see
16:11:30 <sebersole> you'd have to
16:12:08 <sebersole> thats why i was saying i almost think its best to have JavaTypeDescriptor be the erased type
16:12:18 <sebersole> well, not even almost... :)
16:12:20 <hardy_> still, it would be the most intuitive way from a client perspective using the reflite API
16:12:37 <sebersole> again, i dont think thats true eirther
16:13:07 <sebersole> as a client, how would i know that JavaTypeDescriptor(List<User>) and JavaTypeDescriptor(List<Car>) are "the same"?
16:13:52 <hardy_> are they?
16:14:19 <sebersole> in terms of erased type, yes
16:14:23 <hardy_> sure from a JVM perspective we are just dealing with erased types
16:14:41 <hardy_> question is whether this is the view you want to have
16:14:49 <sebersole> well, no
16:14:54 <sebersole> i think the question is...
16:15:08 <sebersole> what lends the resolution of this to List?
16:15:16 <sebersole> is it the List (aka, the type)?
16:15:29 <sebersole> or is it the context in which List is used
16:15:35 <sebersole> i'd say the later
16:15:41 <sebersole> aka, the metod
16:15:45 <sebersole> method
16:16:00 <hardy_> i see, is see
16:16:06 <sebersole> or
16:16:27 <hardy_> sp you think more along the line MethodDescriptor#getReturnTypeParameters()
16:16:33 <sebersole> MethodDescriptor#getReturnType returns something other than a JavaTypeDescriptor
16:17:03 <sebersole> maybe:
16:17:13 <sebersole> ParameterizedType MethodDescriptor#getReturnType
16:17:25 <sebersole> but
16:17:57 <sebersole> i think we are moving out of the realm of "simpliest thing that meets our needs" to a full-on generic solution
16:18:14 <hardy_> right
16:18:25 <sebersole> heck we could even go the jre route here
16:18:34 <hardy_> imo there is no need to deal with anything else than fully resolved types outside reflite
16:18:45 <sebersole> w/ ParameterizedType as an optional contract for JavaTypeDescriptor
16:19:11 <sebersole> well i am also concerned with the duplication
16:19:41 <sebersole> List, List<User>, List<Car> are all the same and yet all different at the same time
16:19:51 <sebersole> and no this is not about premature opt
16:19:57 <hardy_> bugger
16:20:02 <hardy_> I was about to say that
16:20:05 <sebersole> its about being logical imo
16:20:14 <sebersole> a List is a List
16:20:39 <hardy_> but a List<User> is something else than a List<Car>
16:20:53 <sebersole> again...
16:20:59 <hardy_> it really comes down to which view regarding "sameness" you have here
16:20:59 <sebersole> thats a function of its context
16:21:02 <sebersole> not its type
16:21:29 <sebersole> there are certain semantics about one list versus another *based on its placement* that we use to interpret that context
16:21:42 <sebersole> in our use it is not inherent to the type
16:21:56 <sebersole> again, i am looking for *our* solution
16:22:09 <sebersole> not a general all-purpose generics resolution solution
16:22:15 <hardy_> I hear you
16:22:20 <hardy_> and you have a point for sure
16:22:58 <sebersole> i can play with ParameterizedType for fields and methods
16:23:31 <sebersole> ParameterizedType{ erasedType/simpleType + parametertypes)
16:23:35 <hardy_> ok
16:23:53 <sebersole> where both are simple JavaTypeDescritpros
16:24:01 <hardy_> if you scope it out we can discuss it a bit more
16:24:02 <sebersole> gbadner: wdyt?
16:24:19 <hardy_> easier to discuss existing code/interfaces
16:24:29 <gbadner> about the ParameterizedType?
16:24:29 <sebersole> i just mean that we care about this in 2 places
16:24:42 <sebersole> 1) org.hibernate.metamodel.reflite.spi.FieldDescriptor#getType
16:24:50 <sebersole> 2) org.hibernate.metamodel.reflite.spi.MethodDescriptor#getReturnType
16:25:04 <sebersole> both of which today return JavaTypeDescriptor
16:25:18 <sebersole> so one option here for generics...
16:25:40 <sebersole> have both of these return a new ParameterizedType interface
16:25:51 <hardy_> but I like how this is all going conceptually
16:26:00 <sebersole> where ParameterizedType encompasses 2 things:
16:26:04 <hardy_> not only regarding what we just discussed
16:26:09 <sebersole> 1) erased or simple type
16:26:17 <sebersole> 2) resolved parameter types
16:26:30 <sebersole> sorry, to be specific...
16:26:40 <sebersole> 1) erased or simple type as a JavaTypeDescriptor
16:26:52 <sebersole> 2) resolved parameter types as an array of JavaTypeDescriptor
16:26:54 <sebersole> but
16:27:05 <sebersole> certain things throw a monkey wrench in here
16:27:08 <sebersole> like arrays
16:27:18 <sebersole> well maybe not
16:27:40 <sebersole> a field like `User[] users`
16:28:09 <sebersole> would have ParatemerizedType with just an erased JavaTypeDescritor for the array i guess
16:28:19 <gbadner> can't ParameterizedJavaTypeDescriptor extend JavaTypeDescriptor?
16:28:24 <sebersole> so that could work
16:28:31 <hardy_> it should
16:28:44 <sebersole> i think thats a bad idea
16:29:27 <sebersole> the whole idea with JavaTypeDescriptor is to make sure i have a 1-1 correlation
16:29:37 <sebersole> in regards to the repository of these things
16:29:42 <hardy_> talking about ORM 5, it seems sebersole you are looking into reflite, annotations, xml (schema) and gbadner is working on the binders/persisters. Is this correct?
16:30:01 <gbadner> I'm integrating envers atm
16:30:05 <sebersole> not really
16:30:21 <sebersole> right, atm gbadner is looking at envers
16:30:29 <sebersole> i am looking overall
16:30:34 <hardy_> ok
16:31:09 <sebersole> just getting second eyes on the work pulled over from metamodel
16:31:17 <sebersole> gbadner will look over my stuff then
16:31:26 <sebersole> thats how you get good stuff :)
16:32:08 <hardy_> you mean you are learning from Search and Validator ;-)
16:32:08 <sebersole> i'd really like hbmk binding to go away tbh
16:32:10 <gbadner> yep, definitely getting better
16:32:34 <sebersole> hardy_: no comment
16:32:35 <sebersole> :)
16:33:07 <hardy_> :-)
16:33:18 <sebersole> i just mean that overall that binder initially grew out of what existed previously
16:33:41 <sebersole> which was (1) not always right and (2) always very hbm-centric
16:34:04 <sebersole> now is a good time to apply better practices
16:34:06 <gbadner> (2) definitely
16:34:29 <sebersole> i think it helps that i am looking across both code bases tbh
16:34:51 <sebersole> because i can make better consistency decisions
16:34:54 <gbadner> yes, definitely
16:35:13 <sebersole> we said that even back to meeting in austin...
16:35:34 <sebersole> adding features to metamodel should work across both
16:35:49 <sebersole> so that we see the consistency
16:36:02 <sebersole> this is just the same principal at a higerhg level
16:36:09 <sebersole> anyway...
16:36:18 <sebersole> gbadner: all that said, i am not done yet :)
16:36:27 <gbadner> heh, np
16:36:46 <sebersole> but i think i am getting close (this reflite + generics thing notwithstanding)
16:36:48 <hardy_> sebersole: no!?
16:36:55 <hardy_> ;-)
16:36:58 <sebersole> hehe
16:37:07 <sebersole> so... anyone else want to discuss
16:37:19 <hardy_> I am fine
16:37:35 <sebersole> gbadner: btw, lukasz was saying he can help if/when/where you need
16:37:40 <hardy_> I have some questions for sannegrinovero, but I think I have to catch him later
16:38:28 <emmanuel> hardy_: me too, wanted to discuss the next HSsearch release plan
16:38:32 <emmanuel> to align star
16:38:34 <emmanuel> s
16:38:47 <hardy_> :-)
16:38:55 <sebersole> i thought you guys started your own meeting(s)?
16:39:07 <sebersole> i mean feel free.. just curious
16:39:15 <hardy_> every two weeks
16:39:19 <hardy_> before this meeting
16:39:33 <hardy_> the next "official" meeting is next week I think
16:39:46 <hardy_> my questions are just about the current issue I am working
16:39:59 <hardy_> sebersole: funny enough a ClassloaderService for Search
16:40:08 <emmanuel> it does not look like sannegrinovero is here though so that settles it :)
16:40:20 <hardy_> well, I need a break though
16:40:26 <sannegrinovero> emmanuel: ?
16:40:31 <emmanuel> ah
16:40:36 <sannegrinovero> hardy_: sorry missed your ping
16:40:36 <hardy_> I have a hungry mouth to feed
16:40:44 <hardy_> I am back a little later on
16:40:47 <sannegrinovero> hardy_: cool np, I'll be online later too
16:40:58 <emmanuel> sannegrinovero: what's your plan for the search release
16:41:08 <emmanuel> I'm working on the documentation for MLT
16:41:19 <emmanuel> so on my side it will be good enough in an hour or so
16:41:30 <sebersole> so end this meeting?
16:41:38 <hardy_> emmanuel: I think so
16:41:46 <hardy_> I'll be back a bit after 7
16:41:46 <sannegrinovero> emmanuel: you're too quick :) I'm not done with other issues yet, but tomorrow should be fine
16:41:49 <sebersole> gbadner: nothing you want to discuss?
16:42:23 <emmanuel> sannegrinovero: I ahve pushed back the other priorities to give the MLT baby in a good shape
16:42:25 <gbadner> sebersole, nope, not really
16:42:57 <sannegrinovero> emmanuel: thanks, still I haven't figured out if the quality we're getting out of it is good or not :-/
16:42:58 <gbadner> I'm making progress; hoping to have integration working converting dom to jaxb
16:43:07 <gbadner> in a day or so
16:43:08 <sannegrinovero> emmanuel: any idea how to measure it?
16:43:35 <sannegrinovero> by "quality" I mean in sense of information retrieval
16:43:35 <sebersole> emmanuel, sannegrinovero: do you want me to keep this meethign going>?
16:43:38 <emmanuel> as in absolute measure? no
16:43:46 <sannegrinovero> sebersole: no thanks
16:43:50 <sebersole> #endmeeting