Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1435788000 [2017/05/27 13:44] (current)
Line 1: Line 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