[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