13:00:11 <gsmet> #startmeeting
13:00:11 <jbott> Meeting started Tue Sep 27 13:00:11 2016 UTC.  The chair is gsmet. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:11 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:00:14 <jbossbot> Title: MeetBot - Debian Wiki
13:00:26 <gsmet> topics apart overall progress?
13:00:42 <yrodiere> infrastructure documentation?
13:00:43 <gsmet> emmanuel: you wanted to talk about Java 9 modules the last time?
13:01:08 <emmanuel> gsmet: yes but that's a bit stale unfortunately
13:01:08 <gsmet> yrodiere: what's your point exactly?
13:01:59 <yrodiere> Is there a place where we collect all information about our projects' various CIs? URLs, logins?
13:02:16 <yrodiere> (even the private ones, I mean)
13:02:17 <gsmet> ok
13:02:36 <gsmet> let's start with progress
13:02:48 <gsmet> #topic Progress Guillaume
13:02:59 <sannegrinovero_> emmanuel: re Java9 would be good to discuss what we want to achieve, besides getting CI working on it
13:02:59 <gsmet> so I made some progress with alphabetical order :)
13:03:18 <gsmet> I addressed all the comments on grouping so far
13:04:07 <gsmet> fixed the last issue regarding navigational information for inverse associations
13:04:24 <gmorling> sannegrinovero_:
13:04:26 <gmorling> +1
13:04:40 <gsmet> I reviewed Neo4j Bolt
13:04:54 <gsmet> apart from a couple of minor issues, it's in good shape and should be committable soon
13:05:06 <gsmet> I spent some time tracking the CI issue for Validator
13:05:18 <gsmet> waiting for Davide to come back to hopefully fix it
13:05:20 <gmorling> gsmet: i couldn’t test with latest jdk 8 locally
13:05:22 <gmorling> yet
13:05:28 <gmorling> i’ll grab it and report back
13:05:33 <gsmet> ok, thanks
13:05:58 <gsmet> I also fix the checkstyle rules for ParenPad for Search and Validator
13:06:11 <gsmet> will wait for the big PRs to be merged before doing it for OGM
13:06:23 <gsmet> it should avoid a lot of review comments on formatting
13:06:37 <gsmet> (it won't be perfect due to a checkstyle bug still present in latest versions)
13:06:43 <gmorling> nice
13:07:02 <gsmet> (the bug has been reported but is not fixed and I don't have a lot of hope considering the comments in the code)
13:07:13 <emmanuel> gmorling: how did you fix the inverse side problem ?
13:07:33 <gmorling> you mean gsmet?
13:07:37 <gsmet> yes, gmorling, how did you fix it? :=
13:07:54 <gmorling> i could tell you ;)
13:08:04 <gmorling> but i thought i’ll let you find out by yourself ;)
13:08:05 <gmorling> harhar
13:08:16 <gsmet> I decided to remove the navigational information associated to the inverse associations owned by the entity on delete
13:08:47 <gsmet> I had to add a method to the dialect as all the dialects don't use navigational information
13:09:03 <gsmet> commit is here: https://github.com/hibernate/hibernate-ogm/pull/767/commits/671786a9c212f9b31b9ebc4760de3a50f9a51b0d
13:09:04 <jbossbot> git pull req [hibernate-ogm] (open) Guillaume Smet OGM-1064 Operation grouping https://github.com/hibernate/hibernate-ogm/pull/767
13:09:04 <jbossbot> jira [OGM-1064] Replace separate association management methods by upsertTupleWithAssociations() [In Progress (Unresolved) New Feature, Major, core, Guillaume Smet] https://hibernate.atlassian.net/browse/OGM-1064
13:10:22 <sannegrinovero_> gsmet: I don't remember the details, but we couldn't use the latest checkstyle because of some other issue.. so let's hope that when they merge that, they'll have a fix for the other problem too.
13:11:12 <gsmet> sannegrinovero_: yes, there is an issue with do / while
13:11:34 <gsmet> sannegrinovero_: I don't know if this one has been reported though, I'll check
13:12:08 <sannegrinovero_> gsmet: cool
13:12:24 <gsmet> that's all for me. Other questions?
13:13:32 <yrodiere> Seems not
13:13:49 <sannegrinovero_> +1 let's move on, questions can happen later at any time :)
13:13:55 <gsmet> #topic Progress Gunnar
13:14:12 <emmanuel> yes let\s progress gunnar a bit, he needs help
13:14:18 * emmanuel go hiding
13:14:21 <gmorling> hehe
13:14:27 <sannegrinovero_> Gunnar++
13:14:29 <sannegrinovero_> done!
13:14:46 <gmorling> so i’ve been working on a proposal for BVAL-214
13:14:47 <jbossbot> jira [BVAL-214] Ability to validate an object and a list of changes [Open (Unresolved) Improvement, Major, api/spec-general, Gunnar Morling] https://hibernate.atlassian.net/browse/BVAL-214
13:15:19 <gmorling> which essentially is about better support for class-level constraints during validation upfront, i.e. before populating a model
13:15:35 <gmorling> experimented a bit and will discuss with Hendrik from the EG next week the different options
13:15:47 <gmorling> that’s still a bit in flux though
13:16:08 <gmorling> then Michael from the EG made progress with the prposal for JSR 310 support
13:16:24 <gmorling> i.e. the new date/time types from J8 and their support in BV 2.0
13:16:45 <gmorling> i think we’ll have consensus there very soon on a first part
13:16:59 <gmorling> so we could do an Alpha1 of sorts soon-ish, too
13:17:05 <gmorling> release early and often
13:17:11 <gmorling> starting with the simple stuff we already have
13:17:34 <gmorling> other than that i’ve been dragged away a bit by looking how BV is supported in Swarm (and the MicroProfile)
13:17:47 <gmorling> for whatever reason i kept hitting some issues
13:17:57 <gmorling> my plan was/is to write up a quick post how BV can be used there
13:18:02 <sannegrinovero_> gmorling: I'm a bit confused about BVAL-214, would it be correct to say that it would be able to tell if the object A *would* be valid if a given chain of updates *were* to be applied?
13:18:03 <jbossbot> jira [BVAL-214] Ability to validate an object and a list of changes [Open (Unresolved) Improvement, Major, api/spec-general, Gunnar Morling] https://hibernate.atlassian.net/browse/BVAL-214
13:18:17 <emmanuel> sannegrinovero_: yes
13:18:21 <sannegrinovero_> cool, thanks
13:18:26 <gmorling> bottom line is though that BV works out of the box when using CDI on wildfly swarm as it happens to pull in everything right now
13:18:37 <gmorling> i.e. your microservice jar gets 89 MB when adding CDI
13:19:09 <gmorling> right now i’m writing a response on your slides, @emmanuel
13:19:21 <gmorling> also need to follow up on your other mail regarding bob and bruno
13:19:28 <gmorling> ah, and the CfP for JFokus is closing this week
13:19:45 <sannegrinovero_> gmorling: isn't it twisted that such an (interesting) feature would be discussed in the spec, rather than after years of feedback from an implementation first?
13:19:58 <gmorling> that’s about it from my side
13:20:10 <gmorling> sannegrinovero_: not sure i’m following
13:20:19 <gmorling> are you saying we should add it to the impl first?
13:20:36 <gmorling> if so, yes, that’d be the plan i think, add it in some alpha and let’s see what people say
13:20:40 <sannegrinovero_> gmorling: yes, and have plenty of feedback from the impl before proposing such a thing in a spec
13:20:41 <emmanuel> sannegrinovero_: custonmers for it are few actually
13:20:52 <emmanuel> and only interested in a standard way of doing it
13:21:18 <sannegrinovero_> excuses :)
13:21:19 <emmanuel> we have been discussing the needs and the issues for years though
13:21:28 <sannegrinovero_> but I trust you
13:21:44 <gmorling> it’s a common issue you’ll hit when using BV for UI input validation
13:22:09 * emmanuel will do a quick progress so sneak me in
13:22:16 <gmorling> emmanuel: btw. to answer your recent question, we don’t have an instance of that referenced object yet, hence the instanceof approach doesn’t fly
13:22:35 <emmanuel> ?
13:22:43 <emmanuel> that's the object you wanted to validate no?
13:22:54 <gmorling> we discussed about cascaded validation in the context of 214
13:22:57 <emmanuel> but I'm sure we have a different context
13:22:58 <sannegrinovero_> ok gsmet could you "sneak in" emmanuel ?
13:23:05 <gmorling> and i said we don’t know the runtime type of referenced elements
13:23:12 <gsmet> that's the plan, once they stop talking :)
13:23:14 <gmorling> hence we cannot determine hte constranits to validate
13:23:35 <sannegrinovero_> gsmet: ever seen a debate on tv? that approach doesn't work :) just set the bookmark
13:23:44 <gmorling> like the one yesterday's
13:23:46 <emmanuel> you mean referenced as in on the right side
13:24:01 <gmorling> yes, say Person (root) -> Address
13:24:03 <emmanuel> so when you want to cascade, you have this object right?
13:24:09 <emmanuel> this reference ot address
13:24:14 <gmorling> no, i don’ t have an Address object
13:24:18 <emmanuel> so you can check its *runtime* type
13:24:19 <gmorling> that’s the point
13:24:26 <gsmet> #topic Progress Emmanuel
13:24:31 <emmanuel> if you don't have an address obhect, no need to cascade
13:24:31 <gmorling> let’s take it later
13:24:34 <gmorling> sure
13:24:38 <emmanuel> ah you mean if it's created
13:24:40 <emmanuel> good point
13:24:45 <gmorling> values for Address may be bound in the UI
13:24:52 <gmorling> right
13:24:58 <emmanuel> interesting
13:25:02 <emmanuel> So about me
13:25:05 <gmorling> go :)
13:25:29 <emmanuel> My health is failing me these days. Most recently a pretty acute shoulder pain that irradiated to neck and around
13:25:46 <emmanuel> so being at a keyboard is not ideal, nor is in bed, nor anywhere really
13:25:51 <emmanuel> but getting a bit better
13:26:06 <gmorling> doh
13:26:11 <gmorling> i’d say *shoulderpad*
13:26:12 <sannegrinovero_> sorry to hear. I can recommend some feet-typing lessons?
13:26:14 <gmorling> bit it may hurt
13:26:27 <emmanuel> I still had no feedback on the collection contraint suport for BV
13:26:38 <gmorling> there is now, right?
13:26:41 <emmanuel> without which I don't feel I can continue
13:26:48 <emmanuel> so Gunnar will stirr up the EG
13:27:04 <emmanuel> but we might need one of you to pretend you are expect and give feedback too
13:27:15 <gmorling> yes, it’s on my list :/
13:27:31 <gmorling> btw. gustavonalle and yrodiere feel free to weigh in on that one, too
13:27:41 <emmanuel> I guess Guillaume and Yoann are the closest we have to real life developers
13:28:02 <gsmet> :)
13:28:13 <yrodiere> Not much real-life experience with Validators, but I can speculate, yes
13:28:19 <emmanuel> Otherwise, for the next 2 weeks I'll be heavily traveling
13:28:25 <gmorling> have you seen http://lists.jboss.org/pipermail/beanvalidation-dev/2016-September/001067.html
13:28:26 <jbossbot> Title: [bv-dev] Support for constraints on container values (e.g. Collection<@Email String>)
13:28:27 <emmanuel> 1 partner conf early next week
13:28:32 <emmanuel> then a meeting
13:28:38 <emmanuel> then the Infinispan meeting
13:28:45 <emmanuel> and then the red hat forum in france
13:28:54 <emmanuel> so don't expect much of me during 2.5 weeks
13:28:57 <emmanuel> 3 weeks really
13:29:26 <emmanuel> I'm working on presentations essentially
13:29:31 <emmanuel> and the OGM one is a big one
13:29:38 <emmanuel> so thanks for your feedback
13:29:51 <emmanuel> I'm planning on circling back to it this week
13:30:18 <emmanuel> Finally, I had interesting discussion on memory footprint
13:30:21 <sannegrinovero_> right I have some additional thoughts on that.. let me know when you're ready for a round 2 of thoughts-collection
13:30:31 <emmanuel> in this case in the context of Infinispan
13:30:32 <sannegrinovero_> (on the OGM presentation)
13:30:43 <emmanuel> sannegrinovero_: well, you can't push it all in one go?
13:31:01 <sannegrinovero_> emmanuel: ok
13:31:05 <emmanuel> or you need feedback on the feedback? sannegrinovero_
13:31:11 <emmanuel> cool
13:31:28 <emmanuel> So in some constrained environment like FeedHenry and 3scale
13:31:33 <sannegrinovero_> emmanuel: just that it's not structured yet, so might as well reduce the noisy by commenting on a clean sheet :)
13:31:45 <emmanuel> they want a cache service that consumes as less memory as possible (besides data)
13:32:07 <sannegrinovero_> emmanuel: no shit! they want off-heap and use virtual memory? :P
13:32:12 <emmanuel> Even with Wildfly+Infinispan consuming something like 20/25MB of heap
13:32:23 <sannegrinovero_> rvansa: ^
13:32:25 <emmanuel> it's still a 100-150MB process totall
13:32:37 <emmanuel> essentially the JVM overlead
13:32:47 <emmanuel> with ms set to 32MB AFAIR
13:33:23 <emmanuel> Compared to a Redis that starts at 10MB that's a tough fight unless you go on the multi-tenant approach to amortize your initial overhead
13:33:39 <emmanuel> Not much we could do but I wanted to share, I felt it was interesting
13:33:41 <sannegrinovero_> run as separate process, or as delta comparison with not starting an embedded cachemanager ?
13:33:55 <emmanuel> sannegrinovero_: ?
13:34:05 <emmanuel> sannegrinovero_: it's JDG one node
13:34:09 <sannegrinovero_> emmanuel: just wondering to which configuration your figures were referring at
13:34:25 <sannegrinovero_> so embedded mode or a JDG server node?
13:34:35 <emmanuel> a special customed one where Tristan ripped appart the useless bits like extra protocols besides HR etc
13:35:02 <emmanuel> we might contemplate a Swarm based deployment where you coudl add features
13:35:12 <emmanuel> but that's not fully relevant to the problem at bay
13:35:15 <sannegrinovero_> yes interesting
13:35:26 <emmanuel> the VM seem to only start at 1-00MB
13:35:49 <emmanuel> And finaly rat hole topic
13:35:53 <sannegrinovero_> although you might remember we had Infinispan nodes running on the pogo plug micro computers for the 2011 demo?
13:36:07 <gmorling> so why is it that redis starts with that much less?
13:36:17 <emmanuel> gmorling: C
13:36:29 <gmorling> hum
13:36:33 <sannegrinovero_> gmorling: its data is stored in virtual memory rather than pre-allocating the JVM heap
13:36:55 <gmorling> the “tailored jdk distirbution” approach from jdk 9 may be very interesting for this one
13:37:03 <sannegrinovero_> yes
13:37:09 <gmorling> create a jdk distro just with the bits needed for such node
13:37:15 <emmanuel> gmorling: did not make a different when Tristan tested JDK9
13:37:17 <gmorling> i.e. no AWT :)
13:37:28 <emmanuel> so at least OOTB it does not help reduce class loads that much
13:37:41 <sannegrinovero_> but we'll also need to cut down on Infinispan itself, i.e. extract stuff which one doesn't need in non-required modules
13:38:18 <gsmet> mmmh, maybe we continue on progress and get back to that later if we have some time left?
13:38:25 * emmanuel read "but we'll also need to cut down on Tristan itself" and laughed
13:38:38 <sannegrinovero_> emmanuel: I don't think Tristan ever got it fully working on JDK9 so I'm surprised we have any metric already
13:39:00 <emmanuel> sannegrinovero_: we tested just the start and one get/put
13:39:04 <emmanuel> nothing else
13:39:10 <sannegrinovero_> threating to cut down an arm or two might do wonders :) emmanuel
13:39:13 <emmanuel> s/we/he/
13:39:39 <emmanuel> final topic is the git flow conversation I did during the asylum podcast recording
13:39:47 <sannegrinovero_> cool, thanks for these. interesting.
13:40:05 <emmanuel> it made me considering using merge for git PR
13:40:21 <emmanuel> and even consider tabs as superior (for a different set of reasons)
13:40:27 <gmorling> i haven’t listened to the pod cast
13:40:31 <gmorling> but why merge?
13:40:33 <emmanuel> so go listen to it and we can discuss the rebase vs merge at the next meeting
13:40:37 <emmanuel> or at a hangout
13:40:45 <sannegrinovero_> I haven't listened yet either, but will download it for sure.
13:40:45 <gmorling> k
13:40:52 <gmorling> i don’t like pod casts :)
13:41:02 <gmorling> do you have a transcript ;)
13:41:03 <sannegrinovero_> Speaking of git, I just learned about "git worktree" .. amazingly useful :)
13:41:09 <gmorling> +1
13:41:15 <emmanuel> that's because you spell them wrong, they are podcasts, not pod casts
13:41:42 <gsmet> let's get back on track!
13:41:47 <gsmet> #topic Progress Sanne
13:42:21 <sannegrinovero_> not much progress, have been on holidays and now trying to catch up with emails while having a cold
13:42:53 <sannegrinovero_> I'll treat feedback and organizational emails first, then catch up with Search PR integrations
13:43:14 <sannegrinovero_> and finally will need to finish applying all your comments on my OGM dialect
13:43:57 <sannegrinovero_> gmorling: I believe your student had some complex questions too.. not sure if I can figure that out
13:44:07 <sannegrinovero_> especially on how to refactor his code to avoid the static references
13:44:20 <gmorling> puh, ok
13:44:24 <sannegrinovero_> that's it for me
13:44:33 <gsmet> ok
13:44:37 <gsmet> thanks
13:44:43 <gsmet> #topic Progress Yoann
13:44:52 <yrodiere> So, still working on Elasticsearch integration
13:45:07 * emmanuel learning about git worktree. I used hardlink cloning before
13:45:19 <yrodiere> I opened a PR adding support for queries beyond the 10000th result (using the Scroll API)
13:45:32 <gmorling> emmanuel: yes it does what your manual approah did before
13:45:56 <yrodiere> There are a few gotchas, but I think we can't do more atm
13:46:16 <yrodiere> Also, I'm about to add better support for Java 8 date/time types in the Elasticsearch integration
13:46:36 <gmorling> nice
13:46:41 <yrodiere> Mostly a matter of user the date type and the right formats
13:46:42 <gsmet> yrodiere: please add a title to your PRs :). I missed its purpose.
13:47:07 <yrodiere> gsmet: ok
13:47:10 <sannegrinovero_> emmanuel: re git worktree.. I also used to have multiple clones of the same checkout to have different IDE windows open on different maintenance branches.. which was quite complex to maintain.
13:47:36 <yrodiere> And finally, I have been working on the VALIDATE index management strategy and the Elasticsearch mapping export tool
13:48:02 <yrodiere> For VALIDATE, it's already working, but the export tool is another matter
13:48:26 <sannegrinovero_> yrodiere: sounds all great, definitely need to get rid of my other tasks as I'm eager to see these.
13:48:53 <yrodiere> I asked sannegrinovero_ some questions on JIRA. The issue with the CLI export tool is that currently, Hibernate Search starts the index managers as soon as the metamodel is built
13:49:18 <yrodiere> So the CLI export tool would need to be able to connect to the Elasticsearch instance, which is a shame :/
13:49:46 <gmorling> why would it have to connect?
13:50:53 <yrodiere> gmorling: because that's what the indexmanager does. I may be able to work this around with a NONE index management strategy, but I suspect missing configuration properties would trigger other problems...
13:52:00 <gsmet> currently, I think you need the IndexManager to deal with analyzers and so on
13:52:25 <gsmet> yup
13:52:34 <yrodiere> gsmet: for generating the model, you mean? Don't think so
13:52:41 <gsmet> yes
13:52:47 <yrodiere> Because I already extracted the model generation from the indexmanager...
13:53:32 <yrodiere> https://github.com/yrodiere/hibernate-search/tree/HSEARCH-2260
13:53:46 <yrodiere> And more precisely https://github.com/yrodiere/hibernate-search/commit/46e25492bd0113923553c1dcb5fbc3f3d141ff8e
13:53:47 <jbossbot> git [hibernate-search] 46e2549.. Yoann Rodière HSEARCH-2260 Moved all schema management code out of ESIndexManager...
13:53:48 <jbossbot> jira [HSEARCH-2260] Deal with index mappings creation/upgrade/concurrency in the Elasticsearch case [In Progress (Unresolved) Task, Major, elasticsearch, Yoann Rodière] https://hibernate.atlassian.net/browse/HSEARCH-2260
13:54:08 <yrodiere> Argh, miss: I meant https://github.com/yrodiere/hibernate-search/commit/8a4f54e2c9e144572c33fecef901ecc27c40ba82
13:54:09 <jbossbot> git [hibernate-search] 8a4f54e.. Yoann Rodière HSEARCH-2260 Moved schema translation code outside of IndexManager...
13:54:09 <jbossbot> jira [HSEARCH-2260] Deal with index mappings creation/upgrade/concurrency in the Elasticsearch case [In Progress (Unresolved) Task, Major, elasticsearch, Yoann Rodière] https://hibernate.atlassian.net/browse/HSEARCH-2260
13:54:24 <gsmet> yrodiere: ah ok, of course, if you extracted this code, it's not in the IndexManager anymore :)
13:54:31 <sannegrinovero_> nice cleanup
13:54:55 <sannegrinovero_> but like gmorling asked I'm not sure why you need to connect to validate the schema?
13:54:59 <yrodiere> gsmet: yeah, what I mean is there's no need for a connection to ES for the model generation
13:55:29 <yrodiere> sannegrinovero_: well to *validate* it, I think it's pretty straightforward I need access to the stuff I validate
13:55:44 <yrodiere> Now, to generate a JSON file, I don't *need* it
13:56:33 <sannegrinovero_> sure, sorry I meant a different question than what I typed :)
13:56:54 <yrodiere> But the current HS startup process *forces* me to connect, because it starts the indexmanager just after generating the metamodel. For the CLI tool, I only need to get the metamodel, but I can't generate it without HS starting the indexmanagers, which connect to ES
13:56:58 <sannegrinovero_> I mean, you need access to the Jest Client, but not necessarily to the IndexManager
13:57:04 <yrodiere> Not even that
13:57:14 <sannegrinovero_> which is a problem as we configure connections based on index names
13:57:22 <yrodiere> Ah, wait
13:57:34 <yrodiere> Still about the validation?
13:57:41 <sannegrinovero_> me? yes
13:58:10 <yrodiere> Well, validation in the CLI tool is not what I meant to do (yet)
13:58:25 <gmorling> yrodiere: so it seems you are almost there if you extracted the code for the model genreation into a separate class which you could invoke separately from a new CLI entry point?
13:59:00 <yrodiere> gmorling: yes, but I need to bring some changes (maybe heavy ones) to HS's startup process
13:59:37 <gmorling> that one i don’t understand
14:00:23 <yrodiere> because right now metamodel generation is all tangled up with the startup process, and I can't tell HS "just do anything needed for metamodel generation and stop there": it will always create and start the indexmanager, thus connect to an elasticsearch instance
14:00:57 <yrodiere> to be clear: I'm not speaking about Elasticsearch metadmodel generation. That already works, though it's only done at starting, not in a separate CLI tool.
14:01:39 <yrodiere> What I'm talking about is adding a separate CLI tool that, given some jars and settings, would generate JSON files with the ES mappings in them, so that users could compare that to their ES instance
14:02:11 <yrodiere> Hibernate ORM has a similar tool, but for SQL databases obviously
14:02:41 <gmorling> i guess it depends on what “starting hsearch” means
14:02:48 <yrodiere> Argh... I meant: "to be clear: I'm not speaking about Elasticsearch metadmodel **validation**"
14:03:17 <gmorling> i thought one could just run your extracted code for metamodel generation without “starting hsearch” proper
14:03:30 <gmorling> but i’m a bit away from the code admittedly
14:03:51 <gmorling> if you need to fully start it, maybe have some fake IM for usage within that tool which doesn’t connect actually?
14:03:51 <yrodiere> I need to "start HSEARCH" so it inspects the @Indexed classes and their annotations
14:04:25 <yrodiere> And actually build its metamodel.
14:05:15 <emmanuel> yes so you're advocating for a two phase SF build
14:05:24 <yrodiere> Yeah, I may be able to work this around... I could also stub the JestClient...
14:05:27 <emmanuel> so that your cli could use phase 1 to do its job
14:05:27 <gmorling> either have a fake IM or configure the current ES IM to not do anything?
14:05:29 <yrodiere> emmanuel: yes
14:06:01 <emmanuel> yrodiere: I'd put that as a 6 requirement candidate, sannegrinovero_  ?
14:06:23 <yrodiere> Conceptually I think it would be the proper way to do things. But I'm not sure how difficult it would be to implement.
14:07:09 <sannegrinovero_> emmanuel: +1
14:07:31 <yrodiere> Now, if you tell me you don't see huge problems with that, I can give it a try. I was about to, but I just stopped and told myself "seems a bit bold..."
14:07:34 <sannegrinovero_> I'd still prefer a 5.6 "as small as possible"
14:07:44 <sannegrinovero_> even Validation is optional :)
14:08:15 <yrodiere> Ok, so I can just open a PR for Validation an keep the CLI tool for 6.0
14:08:31 <sannegrinovero_> yes yrodiere that sounds cool
14:08:50 <sannegrinovero_> especially the IndexManagers might not be known at boot time
14:08:54 <sannegrinovero_> but only appear "later"
14:09:09 <sannegrinovero_> so that definitely requires major-version class changes in the general usage
14:09:39 <yrodiere> Right. Okay, so I'll do that. Thanks everyone :)
14:09:54 <yrodiere> And I think that's all on my side
14:10:00 <gsmet> ok
14:10:12 <emmanuel> let's discuss quickly J9
14:10:18 <gsmet> #topic Java 9
14:10:55 <emmanuel> to answer your question sanne, we want to make sure we won't make life harder for Hibernate * (and CDI etc) developers in a modularlized Java 9 universe
14:11:08 <emmanuel> Hence for the request for feedback
14:11:38 <emmanuel> but it happens that we were too slow and david lloyd did reply to Oracle on RHT's behalf without or feedback
14:11:50 <emmanuel> so it's half too late
14:11:56 <sannegrinovero_> yrodiere: still thinking on the "two phase" boot.. we actually already have that, I'll show you later; but still this tool is better postponed.
14:12:30 <sannegrinovero_> yes I saw Davids's answers. A but harsh but to the point :)
14:13:07 <yrodiere> sannegrinovero_: I'd be very interested. I couldn't see in the startup code how I could make it stop where I wanted.
14:13:23 <gmorling> where was that answer?
14:13:39 <sannegrinovero_> I see no definite issue with the proposal, in the sense that we could probably make it work.. The problem might be as you suggest emmanuel with usability but that's far less clear as it requires to know what kind of tooling we might expect
14:13:55 <sannegrinovero_> gmorling: on the jogsaw ML
14:14:05 <sannegrinovero_> s/jogsaw/jigsaw/
14:15:07 <sannegrinovero_> so for example if the user's domain classes need to have some "marker" file (e.g. declare the visibility to JPA providers) that could be auto-included by IDE modelers generating the model.
14:15:36 <sannegrinovero_> Especially when making a new application, I expect the "model jar" to be bootstrapped by some tool
14:15:40 <emmanuel> sannegrinovero_: I'me quite skeptical of these tooling add-ons
14:15:48 <gmorling> yes, same here
14:15:55 <sannegrinovero_> could be seam-gen, Hibernate tools, Forge, ec..
14:15:56 <emmanuel> annotation processors turned out to be a mostly failure
14:16:17 <gmorling> there is one famous exception of course :)
14:16:19 <emmanuel> and look how long it took build tools and idea sot support maven
14:16:23 <emmanuel> and then gradle
14:16:25 <emmanuel> etc
14:16:53 <sannegrinovero_> sure I understand that
14:16:57 <emmanuel> anyways
14:17:04 <sannegrinovero_> but so we agree there's a tradeoff..
14:17:07 <emmanuel> I just wanted to address your question
14:17:17 <sannegrinovero_> the problem is how far can X go against Y and be acceptable?
14:17:19 <emmanuel> I do't think we need to debate more on J9 collectively
14:17:22 <sannegrinovero_> There's good value in the proposal.
14:17:39 <emmanuel> just have someone closely follow to be able to help DAvid and the openjdk teams overall
14:18:02 <sannegrinovero_> Obviously one should Veto it if there's no way to make it work, but while I don't have a working POC I don't see why it shouldn't be doable.
14:18:37 <sannegrinovero_> emmanuel: should we make a POC of Hibernate using (and engaging) modules?
14:18:43 <gmorling> sannegrinovero_: is this the answer you mean: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009424.html
14:18:44 <jbossbot> Title: Alternatives and fixes to #ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation proposals
14:19:00 <emmanuel> they don't have an impl of the proposal so we can't make a poc :)
14:19:00 <sannegrinovero_> gmorling: yes exactly
14:19:07 <gmorling> k
14:19:14 <sannegrinovero_> emmanuel: good point :)
14:19:28 <emmanuel> end of the meeting?
14:19:39 <emmanuel> Got a lot of slides to chrun
14:19:41 <emmanuel> churn
14:19:43 <gsmet> Yoann wanted to talk about infrastructure documentation?
14:19:49 <emmanuel> ah my bad
14:19:55 <emmanuel> sure go document the infra ;)
14:19:56 <gsmet> I don't think your presence is required for this though
14:19:56 <yrodiere> Yes
14:19:57 <emmanuel> ahahahaha
14:20:05 <gsmet> #topic Infrastructure documentation
14:20:08 <sannegrinovero_> ok but I guess emmanuel isn't interested in infra :)
14:20:21 <emmanuel> there is a private resource with passwd and some info on how to access things
14:20:31 <emmanuel> I'll send it to you
14:20:36 <yrodiere> That's what I was looking for
14:20:36 <gsmet> he already has it
14:20:48 <yrodiere> gsmet: do I?
14:20:52 <gsmet> I think so
14:20:57 <sannegrinovero_> I guess he was hoping for something more extensive :)
14:21:04 <sannegrinovero_> yrodiere: shoot your questions
14:21:24 <gsmet> the list of resources a dev team member should have access to
14:21:35 <gsmet> I think we discussed it
14:21:40 <gsmet> but there might be things missing there
14:21:42 <yrodiere> I just wanted to know where this doc is, so I can refer to it later
14:22:04 <yrodiere> But okay, if you say I have it, I'll search though my mails
14:22:22 <gsmet> I'll send the link to your RH email
14:22:39 <yrodiere> I'll see if I can update it, if necessary
14:22:39 <gsmet> Maybe I haven't sent it to you because your access were not set
14:22:53 <yrodiere> Maybe
14:22:58 <yrodiere> Thanks :)
14:23:10 <gsmet> that being said, I don't see the RH internal CI on it
14:24:23 <emmanuel> so the access setting page has changed
14:24:39 <emmanuel> and I don't know how to change settings anymore in this dam wiki :/
14:25:14 <gsmet> the permissions are ok. You can wait for the next onboarding :)
14:25:29 <gsmet> ok, so we can end the meeting?
14:25:51 <emmanuel> ah found it
14:26:02 <emmanuel> yes close this monster!
14:26:18 <gsmet> #endmeeting