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

[07:04:25] <kuwv> Anyone can help with MessageCodec?

[09:47:45] <aesteve> hi cescoffier :)

[09:48:01] <aesteve> https://github.com/aesteve/vertx-typesafe-config ⇒ wdyt ? eligible for vertx-awesome ?

[09:50:32] <cescoffier> aesteve : I would change the name to avoid being to close to the Typesafe Config lib

[09:50:43] <cescoffier> (https://github.com/typesafehub/config)

[09:51:36] <aesteve> that's the worst thing you could have told me :D

[09:52:27] <aesteve> tell me to change the implementation, tell me to create another project, to code in another language, I don't care. But finding a name is the worst thing to do :D

[09:53:05] <aesteve> srsly tho, typed-verticle, maybe ?

[09:53:32] <aesteve> or pojo-config

[09:59:14] <aesteve> and actually I was thinking about pushing it a little further : if the a JSR 303 is present in the classpath, use it to validate the configuration

[09:59:24] <aesteve> do you think it makes sense ?

[10:00:09] <cescoffier> What's the JSR 303 ? (sorry, I don't read all the JSRs)

[10:00:26] <cescoffier> oh Bean Validation

[10:00:42] <cescoffier> that would be cool !

[10:03:49] <aesteve> Ok I'll add it

[10:04:54] <aesteve> (actually I'll add it to nubes, too. imo it's very useful for mapping form/query params to a java bean)

[10:44:18] <aesteve> generics are driving me nuts…

[11:10:35] <fado61082> Hi guys I am new here I wanted to ask which vertx subproject generates the vertx.io website? is it vertx-web-site or vert-x3.github.io

[11:13:29] <aesteve> I think (but wait for cescoffier to confirm) that vertx-web-site actually generates vertx-3.github.io ?

[11:13:39] <aesteve> what are you looking for precisely ?

[11:15:03] <aesteve> for instance most of the docs in the website come from the projects directly, the contributors' list is generated automatically, the company list is generated from vertx-web-site etc. so depending on what you're looking for I might point you at the right direction

[11:19:21] <fado61082> Thanks for the answers. I wanted to make some correction in the documentation

[11:20:20] <aesteve> just tell me where, I'll tell you which file you should change

[11:24:48] <fado61082> in the groovy doc http://vertx.io/docs/vertx-core/groovy/#_json there is a minor typo 'dev val1 = ….' and another at http://vertx.io/docs/vertx-core/groovy/#_buffers under 'Reading from a Buffer' in the example 'for (def i = 0;i < buff.length();4) {'

[11:26:08] <aesteve> https://github.com/vert-x3/vertx-lang-groovy/blob/dc0632d51822b4b659313b01a44356063dadf792/src/main/docoverride/docoverride/json/package-info.java#L84

[11:26:31] <fado61082> also I think under 'Creating buffers' the phrase 'Buffers can create by using one of the static Buffer.buffer methods.' should be 'Buffers can be created by using one of the static Buffer.buffer methods.'

[11:27:13] <fado61082> oh I see. Cool thanks

[11:28:19] <fado61082> is there a blog describing how the documentations are generated? I would like to learn more about it.

[11:29:22] <aesteve> I don't remember :( I just remember some examples are generated from other languages

[11:30:00] <aesteve> so in the case of groovy / js / … it might be a little different to make changes in the documentation

[11:30:45] <aesteve> btw (a little bit of advertising) if you're interested in Groovy you might want to have a look at : https://github.com/aesteve/grooveex

[11:31:09] <Maziz> vertx-codegen generated groovy and its docs

[11:31:19] <Maziz> s/generated/generates

[11:31:32] <Maziz> javadoc that is..

[11:33:32] <fado61082> yeah I have been also looking into the grooveex dsl. nice work!

[11:40:11] <cescoffier> fado61082 : hi !

[11:40:35] <aesteve> thanks. You can use the DSL if needed, but also the groovy default extension (only adding convenience methods)

[11:41:00] <cescoffier> fado61082 : it's complicated ;-) the documentation are generated from each project (package-info.java with javadoc containing asciidoc). The rest comes from the web-site project

[11:41:39] <cescoffier> fado61082 : read https://github.com/vert-x3/wiki/wiki/How-is-manage-vert.x-documentation and https://github.com/vert-x3/wiki/wiki/Documentation

[11:44:23] <aesteve> “How is Vert.x documentation managed” ? :\

[11:45:59] <fado61082> cool thanks. will read the wiki pages now

[12:21:07] <aesteve> ok cescoffier I added the POJO config stuff to vertx-awesome :)

[16:40:52] <aesteve> temporal_ or cescoffier if you have a sec I'd like to talk about some topic. Nothing urgent though :)

[17:09:11] <temporal_> aesteve hi

[17:09:36] <aesteve> hi Julien how is it going ? Is it also sunny for you ?

[17:10:22] <temporal_> now yes

[17:10:25] <temporal_> doing good

[17:11:56] <temporal_> what do you want to talk about ?

[17:12:14] <aesteve> I was wondering if you're planning in a future version to make sort of a common “facade” for all Vertx / Router / … (codegenerated) stuff ?

[17:12:40] <aesteve> like java Vertx and groovy Vertx would have an interface in common

[17:12:56] <temporal_> I don't understand

[17:13:37] <aesteve> imagine router.route(…, …).handler(myHandler);

[17:13:57] <aesteve> I'm writing the exact same thing in both Java and Groovy

[17:14:49] <temporal_> and what would this interface allow to do ?

[17:15:15] <aesteve> but let's imagine I'm building, say… an annotation framework for example… and all I care about is that the end-user is passing me a Router. I'll attach routes to it, but it doesn't matter to me if it's a java or a groovy router

[17:16:27] <temporal_> can't make your framework code generated for this purpose ?

[17:17:03] <aesteve> this would require a lot of work

[17:17:12] <temporal_> why ?

[17:18:55] <aesteve> because a lot of objects are not codegen-friendly

[17:19:01] <aesteve> Locale, …

[17:19:33] <aesteve> https://github.com/aesteve/nubes/blob/master/src/main/java/com/github/aesteve/vertx/nubes/VertxNubes.java all this should be codegen-friendly

[17:19:42] <temporal_> there is a Locale code generated in vertx-web

[17:20:18] <temporal_> I think one thing we investigate rather

[17:20:25] <temporal_> is allowing Groovy lang without code generation

[17:20:44] <temporal_> using groovy extensions rather

[17:21:01] <temporal_> what are the current problems with groovy using java ?

[17:21:06] <temporal_> beside not having a GroovyVerticle factory

[17:21:18] <temporal_> but one can compile a Groovy verticle with Groovyc compiler

[17:21:22] <temporal_> and then use the generated class

[17:21:25] <temporal_> with java

[17:22:43] <aesteve> yes I guess users could do that, just work with the java Vertx instance

[17:22:54] <aesteve> and not use GroovyVerticle

[17:23:29] <temporal_> perhaps the GroovyVerticleFacotry

[17:23:33] <temporal_> could check after compilation

[17:23:45] <temporal_> if the groovy class extends io.vertx.core.Verticle directly

[17:25:04] <aesteve> so, from a groovy user point of view, he'll use the standard Java Vert.x instance, then call my code, and get back a standard java Router instance

[17:25:23] <temporal_> it would be everything with the java api

[17:25:35] <aesteve> and yes he should be able to deal with it even in groovy

[17:25:38] <aesteve> yes that'd do it

[17:25:38] <temporal_> actually I would like to knwo what are the java problems

[17:25:43] <temporal_> or groovy problems

[17:25:52] <temporal_> that one can have if he uses the java api directly

[17:26:07] <aesteve> I've never tried actually

[17:26:09] <temporal_> for example groovy has the “as” operator

[17:26:18] <temporal_> one thing that would be nice for data object

[17:26:24] <temporal_> is to either use the java data object

[17:26:28] <temporal_> or use maps/list

[17:26:30] <temporal_> literals

[17:26:35] <temporal_> like

[17:26:46] <temporal_> vertx.createHttpServer(new HttpServerOptions()…

[17:26:47] <temporal_> or

[17:27:04] <temporal_> vertx.createHttpServer([port:8080, host: “localhost”])

[17:27:11] <temporal_> perhaps doing

[17:27:18] <temporal_> [port:8080, host: “localhost”] as HttpServerOptions

[17:27:24] <temporal_> would work with extensions

[17:27:33] <aesteve> absolutely

[17:27:35] <temporal_> or maybe it's possible to make it work directly

[17:27:45] <temporal_> I'm thinking we should do some research

[17:27:50] <temporal_> in this direction

[17:27:54] <aesteve> or just annotate HttpServerOptions as @MapConstructor

[17:28:09] <temporal_> it would be too much intrusive

[17:28:31] <aesteve> but groovy extensions would absolutely work

[17:28:44] <temporal_> yes but that would mean vertx core depends on groovy :-)

[17:28:53] <aesteve> MapExtension would have a very very huge “asType” method but it'd work

[17:32:27] <aesteve> actually

[17:32:46] <aesteve> the map constructor isn't even needed it works out of the box

[17:35:29] <temporal_> one thing we could do is generate classes with static methods

[17:35:30] <aesteve> http://mrhaki.blogspot.fr/2009/09/groovy-goodness-using-lists-and-maps-as.html

[17:35:32] <temporal_> to use with java

[17:35:38] <aesteve> def url2 = ['http', 'www.mrhaki.com', 80, '/'] as URL

[17:35:44] <aesteve> no extension needed I guess

[17:36:40] <temporal_> yes

[17:36:47] <temporal_> would need to make a small project

[17:36:49] <temporal_> in groovy

[17:36:51] <temporal_> that uses java api

[17:36:56] <temporal_> and try many things

[17:37:01] <temporal_> and see what works and what does not work

[17:37:06] <temporal_> and try to make it work with some extensions

[17:37:18] <temporal_> like creating an http server

[17:37:18] <temporal_> with options

[17:37:23] <temporal_> use closures in Handlers

[17:37:29] <temporal_> etc…

[17:38:23] <aesteve> I can deal with it if you provide me with some specifications

[17:38:57] <temporal_> specification is : make a groovy code that uses variosu bits of java native api

[17:39:03] <temporal_> and see how it can work better

[17:39:12] <aesteve> problem is with “various” :D

[17:39:13] <temporal_> like constructing data object with map literals

[17:39:20] <temporal_> well it can start small as usual

[17:39:24] <temporal_> and then become more complex

[17:39:24] <aesteve> I'll take the “best effort” approache :p

[17:39:29] <temporal_> yes thanks

[17:39:32] <temporal_> I need to go now :-)

[17:39:39] <aesteve> thanks for your time

[17:39:44] <temporal_> glad to have disucssed this with you

[22:17:39] <aesteve> temporal_: https://github.com/aesteve/vertx-groovy-java if you want to track progress

[23:28:06] <temporal_> thanks