This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[10:05:28] <footos> hi all

[10:07:28] <footos> I have a question, if i am using gradle for build, etc. Is there somewhere I can get all the information about creating a ful build of vertx3?

[10:08:04] <footos> full distribution I should say.

[10:11:17] <cescoffier> footos: here: https://github.com/vert-x3/vertx-examples/blob/master/gradle-verticle/build.gradle

[10:48:23] <pmlopes> purplefox_ you can merge the PR on core for the shutdown gracefully

[11:03:06] <footos> thanks cescoffier. I've already used this as an example. What I mean is that there are 3 download distributions of v3

[11:03:12] <footos> min base and full

[11:03:27] <footos> it seems like the current sample gradle project represents min

[11:04:56] <footos> I've found through trial and vertx-auth i need to add it in as a depencency but it also has other dependencies that are not getting included at all

[11:10:14] <cescoffier> footos: a fat jar contains the dependency you declared, so if you declare only vertx core then yes you are close to the min distribution

[13:36:14] <jstrachan> purplefox_ I was gonna raise an issue for the camel / eventbus bridge thingy; davsclaus might have time next week to hack on it - wasn't sure where to put it - should I raise it here for now until we make a new git repo for it? https://github.com/vert-x3/issues

[14:27:38] <purplefox_> jstrachan: hey james, yes that's a good place for it

[14:32:40] <jstrachan> thx

[15:27:34] <pmlopes> cescoffier could you review: https://github.com/vert-x3/vertx-redis-client/pull/18

[15:27:51] <cescoffier> pmlopes: I'm actually on it ;-)

[15:28:09] <pmlopes> cool, i'd like to close it :)

[15:29:01] <pmlopes> purplefox_ if you're bored you can also look at https://github.com/vert-x3/vertx-web-site/pull/88 :)

[15:31:52] <purplefox_> pmlopes: looks good!

[15:32:08] <pmlopes> i don't have push rights on web-site can you fix that for me?

[15:32:55] <purplefox_> pmlopes: cescoffier temporalfox: i was thinking, now that the team is growing, instead of asking individuals to review pull requests (e..g. @vietj please review on a comment), instead we should post something on the dev-list list, e.g.

[15:33:14] <purplefox_> “I have just submitted this PR, can someone review it please?”

[15:33:26] <purplefox_> wdyt?

[15:33:36] <purplefox_> then also the larger community can review stuff too

[15:34:02] <cescoffier> purplefox_: yes it's probably better

[15:34:06] <pmlopes> we could also create a column on waffle “to review” where we drag items there and whoever picks up a item assigns to himself

[15:34:21] <cescoffier> I also periodically review the PR on waffle, and see which one need to be reviewed

[15:34:23] <pmlopes> just thinking out loud…

[15:35:14] <purplefox_> pmlopes: yes, that sounds reasonable

[15:48:48] <temporalfox> purplefox_ I'm thinking about Handler<Future<» that is today handled in any other kind of VertxGen interface so only Handler<Future<T» is allowed and so we do have a Handler<Future> (raw type) in HttpServerResponse that should instead be a Handler<Future<Void»

[15:49:23] <temporalfox> and so we can handle this by having special treatment of Future in codegen or allow VertxGen generic types to have “Void” type in addition of <T>

[15:49:52] <temporalfox> do you have any particular opinion on the subject ? (or anyone else :-) )

[15:50:53] <temporalfox> so basically if we use Handler<Future<Void» it just fails and so there is Handler<Future> as work around in HttpServerResponse

[15:55:00] <temporalfox> I think we can allow Handler<GenericType<Type» with any Type that is not generic

[15:55:17] <temporalfox> like Handler<GenericType<AnotherGenericType<T»> could not owrk

[15:55:47] <temporalfox> but Handler<GenericType<String» would work

[15:57:07] <temporalfox> and probably we can support the same than Handler<AsyncResult<?» supports

[15:57:44] <temporalfox> will investigate this :-)

[16:07:44] <temporalfox> actually found solution around in vertx-core for Handler<Future> , replacing with Handler<Future<?» should be ok :-)

[16:08:36] <temporalfox> and actually ? and Void should be more or less equivalent I think

[16:08:44] <temporalfox> you can only call method on both with “null”

[16:08:57] <temporalfox> (and Future.complete() does that)

[16:15:42] <cescoffier> pmlopes - your post has been published

[16:22:01] <temporalfox> imho you should not post so often and instead carefuly plan the posts

[16:25:59] <cescoffier> temporalfox: from now, let's limit to maximum 2 posts per week

[16:26:16] <cescoffier> post can be marked as 'draft' and not be published

[16:26:35] <cescoffier> however, there is no way to schedule a publication

[16:27:50] <cescoffier> BTW, thanks to purplefox_ the blog is aggregated by planet eclipse

[16:33:18] <temporalfox> we can schedule manually I think

[16:37:34] <purplefox_> we should be aggregated on jboss.org too soon

[16:38:43] <purplefox_> temporalfox: cescoffier pmlopes : maven question

[16:39:06] <purplefox_> if i exclude some depdencies that hazelcast pulls in, in the vertx-core project

[16:39:18] <purplefox_> sorry i mean i the vertx-hazelcast project

[16:39:30] <temporalfox> they won't be exported I think

[16:39:39] <purplefox_> then any project that depends on vertx-hazelcast won't pull them in either?

[16:39:45] <temporalfox> cescoffier can confirm

[16:40:18] <purplefox_> because in vertx-examples we were explicitly exclusing some deps, but that seems redundant to me if we exclude them in vertx-hazelcast…

[16:40:31] <cescoffier> no they won't be exported

[16:40:50] <purplefox_> the hazelcast build looks a bit of a mess, it looks like they leaked a bunch of test time deps into compile in 3.5 :(

[16:40:56] <cescoffier> it's because the <Exclusion> is cutting the dependency tree.

[16:41:12] <cescoffier> purplefox_: in which example ?

[16:41:23] <temporalfox> I think our poms anyway should have the most restricted dependency as we can

[16:41:45] <temporalfox> moving away from netty all was a good idea in core

[16:42:00] <purplefox_> i've removed the explicit exclusions from examples now, but if you do mvn dependency:tree in anything that depends on vertx-hazelcast in examples

[16:42:09] <purplefox_> then you can see it pulls in a few things like freemark, findbugs etc

[16:42:28] <cescoffier> are they excluded in the vertx-hazelcast pom file ?

[16:42:38] <cescoffier> (excluded in all the dependencies pulling them)

[16:43:32] <purplefox_> [unknown:lrm]https://groups.google.com/d/msg/hazelcast/IVqFmbgxlao/7pIi_YYdDtcJ

[16:43:37] <purplefox_> yeah looks like it

[16:43:47] <purplefox_> http://repo1.maven.org/maven2/com/hazelcast/hazelcast/3.5/hazelcast-3.5.pom

[16:44:04] <purplefox_> e.g. they have findbugs as a compile dep (!)

[16:47:26] <cescoffier> findbugs annotation

[16:47:46] <cescoffier> it's because of @NonNull I think

[16:49:52] <purplefox_> I've excluded it and the vertx-hazelcast testsuite seems to run ok

[17:01:54] <purplefox_> we also now have a banner on jboss.org (second on carousel) http://www.jboss.org/

[17:18:20] <aesteve> wow, for a flat design design, this is flat design

[17:18:25] <aesteve> no bells & whistles :D