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

[10:31:32] <purplefox> temporalfox: hi julien

[10:31:38] <temporalfox> hi purplefox

[10:31:44] <purplefox> how are you?

[10:32:22] <temporalfox> a bit tired, went to bed late yesterday :)

[10:32:30] <temporalfox> and you ?

[10:32:59] <purplefox> and not bad, ready for a fun day of docs ;)

[10:33:08] <purplefox> i have a question on docgen..

[10:33:11] <temporalfox> yes

[10:33:17] <temporalfox> I usually answer them :-)

[10:33:25] <purplefox> i am trying to get the vertx-hazelcast project to produce some asciddocs

[10:33:39] <purplefox> does the pom parent have to be vertx-ext-parent for this to work?

[10:34:19] <purplefox> i only need the docs in Java don't need in groovy, js, ruby etc, as cluster manager is only used from java, but if I had vertx-ext-parent then it seems to create docs in all languages

[10:34:35] <temporalfox> purplefox no it does no need that

[10:34:47] <temporalfox> look at vietj/vertx-materials pom

[10:34:57] <temporalfox> vertx-ext-parent is rather for polyglot proejct indeed

[10:35:03] <temporalfox> because there is a lot of configuration

[10:35:08] <temporalfox> vertx-rx for instance

[10:35:13] <temporalfox> does not extend vertx-ext-parent

[10:35:27] <temporalfox> perhaps later we should have vertx-ext-polyglot-parent and vertx-ext-parent

[10:35:35] <temporalfox> but maybe it's too complicated if we do that

[10:36:02] <purplefox> ok cool, i can just copy this one. thx :)

[10:36:03] <temporalfox>

[10:36:14] <temporalfox> it's just an annotation processor

[10:36:22] <temporalfox> it does not event depend on vertx actually

[10:36:28] <temporalfox> (which makes sense after all)

[10:56:19] <purplefox> cool, it's working now

[11:06:40] <aesteve> hi everyone !

[11:23:59] <temporalfox> aesteve hi

[11:42:04] <aesteve> purplefox:in groovy template engines there's a little something that users might find confusing

[11:42:17] <aesteve> the routingcontext injected into the templates is the Java RoutingContext

[11:42:58] <aesteve> I think I should mention it in the docs since people using groovy template engines will probably be groovy-lang users

[11:43:08] <purplefox> sounds like a bug to me

[11:44:55] <purplefox> aesteve: looking at the code here:

[11:45:04] <purplefox> i can see it is creating the correct groovy routing context wrapper

[11:45:08] <purplefox> so it looks right to me

[11:45:16] <purplefox> do you have a repoducer for this?

[11:45:19] <purplefox>

[11:45:41] <aesteve> no no that's my implementation for now which might be buggy

[11:45:55] <purplefox> this is handled by codegen not your implementation

[11:46:52] <aesteve> oh

[11:46:59] <aesteve> so this :

[11:47:08] <purplefox> if you just write yours in java, codegen will do all the magic :)

[11:47:11] <aesteve> will be handled smoothly by codegen ?

[11:47:40] <aesteve> how in hell… Well OK this is voodo magic indeed

[11:48:41] <purplefox> yes it handles that

[11:48:44] <purplefox> you can see how here:

[11:48:45] <purplefox>

[11:48:58] <purplefox> so it takes the groovy context and gets the java context from it before passing it to the java class

[11:49:14] <purplefox> so inside the java class it will be dealing with only the java api objects not the groovy ones

[11:49:29] <purplefox> that's the role of the codegen mapping layer to convert between java and other language objects

[11:49:53] <aesteve> mmh

[11:50:13] <aesteve> I'm not sure I've made myself clear actually ::P

[11:50:29] <aesteve> from within the template

[11:50:39] <aesteve> the “context” variable

[11:51:07] <aesteve> will always be the Java RoutingContext, no ?

[11:51:22] <purplefox> which template - the java one?

[11:51:44] <aesteve> by template I mean like the handlebars template or the mvel template

[11:51:58] <aesteve> (well handlebars doesn't have context, so mvel)

[11:52:09] <purplefox> which context are you referring to? the routingcontext?

[11:52:35] <aesteve> yes the RoutingContext which is available in mvel, jade as “context”

[11:52:51] <purplefox> yes always Java, we only develop using the Java objects

[11:52:59] <purplefox> everything else is done by codegen

[11:53:04] <aesteve> ok that's what I meant :)

[11:53:13] <purplefox> everything in vertx-web is java objects

[11:53:25] <aesteve> what I found confusing when writing the docs was the following use case :

[11:53:30] <purplefox> then we take codegen which auto generates the mapping layer for a language from the java api

[11:53:55] <purplefox> the idea here is we only have to maintain one API in Java which is a lot less work than maintaining N APIs

[11:54:16] <aesteve> yes I get that perfectly :)

[11:54:29] <aesteve> just let me explain the use case I was referring to

[11:55:06] <aesteve> imagine I'm a Groovy-lang user. I'm writing my webapp using Groovy, the only RoutingContext I know about is the Groovy one, etc.

[11:55:23] <aesteve> then I'll use the “GroovyTemplateEngine” for rendering stuff

[11:55:43] <aesteve> within my template, the RoutingContext will be the Java one I've never heard about

[11:57:00] <aesteve> I don't think it's a real issue since they're quite similar

[11:57:10] <purplefox> ok, that's true

[11:57:24] <purplefox> but what does an example groovy template look like?

[11:57:45] <purplefox> i suspect it doesn't care if its the java or groovy one as the properties are the same

[11:58:14] <aesteve> yes I think they pretty much are

[11:58:52] <aesteve> i was sndering if there wasn't something which would be a Map in groovy and not in java (abit like the options on HttpClient for example, but didn't check)

[11:59:12] <aesteve> an example of groovy template from my tests :

[12:06:47] <temporalfox> that's the template engine done by C[unknown:eacute]dric

[12:07:35] <temporalfox> aesteve you mean that the template engine would behave differently if it's used in java and groovy ?

[12:08:01] <aesteve> no

[12:08:02] <temporalfox> for JsonObject I think you can have some groovy integration to make it behave like a map

[12:08:10] <temporalfox> with Groovy extension methods

[12:08:31] <aesteve> mmh actually not sure what you meant Julien

[12:08:56] <aesteve> what I mean is, with the actual implementation, within a groovy template the RoutingContext will always be the Java one

[12:09:15] <aesteve> and _maybe_ (idk in fact) Groovy users would be confused it's not the Groovy one

[12:09:51] <aesteve> but I think we should go like this, even not mention it in the docs actually and see if someone gets confused

[12:09:59] <aesteve> I'm pretty sure noone will ever notice

[12:13:14] <temporalfox> ah ok

[12:13:20] <temporalfox> sorry I totally misunderstood it :-)

[12:13:39] <temporalfox> did you the gtpl integration ?

[12:14:07] <aesteve> so you're using gtpl as extension ? you didn't look at my code ?

[12:14:38] <aesteve> that's comfortnig cause I didn't know what to pick as an extension :)

[12:15:08] <aesteve>

[12:15:14] <aesteve> I'm writing the docs right now

[12:26:54] <temporalfox> I mean have you written it :-)

[12:49:48] <aesteve> oh you mean the original Groovy implementation ? oh no

[12:49:58] <aesteve> I'm just writing a vertx wrapper

[13:12:17] <AlexLehm> what i meant to ask, could you add a commit webhook to the mail-client project? I think I cannot do that since I am not the owner of the repo

[13:30:08] <purplefox> AlexLehm: there's already a commit mail webhook on that project

[13:31:30] <AlexLehm> hm, the GitHub Hook Log says Polling has not run yet., so its not being received

[13:35:10] <purplefox> what hook are you referring to, the commits list mail hook or the cloudbees hook?

[13:36:25] <purplefox> you can see the commit hook is working by looking at the commits list:

[13:36:25] <purplefox>!searchin/vertx-commits/vertx-mail-client%7Csort:date

[13:40:47] <AlexLehm> the mail hook is working, but it doesn't trigger a cloudbees build when I push to github

[13:40:57] <AlexLehm> there should be hook called I think

[13:50:13] <purplefox> right so you're referring to the cloudbees hook not the mail hook

[13:51:15] <purplefox> i don't know how to configure the cloudbees hook sorry

[13:53:49] <AlexLehm> the jenkins instance is set to manual configuration, so i think you can add the hook to the github project (the same should be configured in the eclipse/vert.x project)

[13:54:47] <AlexLehm> i could live with manually triggering the build though if it doesn't work

[13:59:31] <purplefox> AlexLehm: i can add you as admin, and you can try and configure it yourself…

[13:59:41] <AlexLehm> yes ok

[13:59:53] <AlexLehm> i think its already configured, its just not being called

[14:00:02] <AlexLehm> yes please i should say

[14:00:46] <purplefox> sure, it's don't. just please don't delete the repository ;)

[14:00:53] <purplefox> s/don't/done

[14:01:07] <AlexLehm> ok

[14:06:53] <AlexLehm> ah, that is actually being called but the call fails

[14:06:54] <AlexLehm> hm

[14:14:27] <aesteve> purplefox: since it's my first “major” PR, just tell me if I did something wrong (apart from the code review)

[14:17:27] <purplefox> temporalfox: any chance you could do a quick review of that core PR? I need it merged soon as I need to make changes to other projects because of the logging change

[14:17:35] <temporalfox> ok will do now

[14:18:28] <purplefox> it's basically just some docs + changed logging class packages (moved from impl to spi)

[14:19:18] <purplefox> temporalfox: ah don't worry, looks like clement has already done this

[14:19:32] <temporalfox> cool

[14:19:34] <temporalfox> yes

[14:19:50] <temporalfox> purplefox next week I'll be away thursday/friday btw for a conf

[14:19:57] <purplefox> which conf?

[14:20:05] <temporalfox> riviera dev oncf in nice

[14:20:11] <temporalfox> the conf of stephane epardaud

[14:20:15] <temporalfox> not far from marseille

[14:20:18] <purplefox> ah cool, well have fun

[14:20:34] <temporalfox> it's a small conf

[14:21:01] <temporalfox> I should be done I think with the member rending by tomorrow I think

[14:21:10] <temporalfox> rendering

[14:33:34] <purplefox> grea

[14:33:36] <purplefox> t

[14:36:25] <purplefox> temporalfox: i'm getting some errors when trying to rebuild vertx-lang-groovy:

[14:36:38] <temporalfox> what is it ?

[14:36:40] <purplefox> Cannot generate EventBusExamples#example7 : Unsupported method addHeader on object model

[14:36:40] <purplefox> Cannot generate ConfigurableVerticleExamples#start : Invoking a method of the same class is not supported

[14:36:40] <purplefox> Cannot generate CoreExamples#example14 : Illegal type T[] of kind ARRAY

[14:36:40] <purplefox> java.lang.UnsupportedOperationException: CLASS

[14:37:02] <temporalfox> but that does not block the build right ?

[14:37:07] <purplefox> yeah it stops the build

[14:37:27] <temporalfox> I think it's recent changes in documentation

[14:37:36] <temporalfox> let me try

[14:38:48] <temporalfox>

[14:38:55] <temporalfox> I don't know if it works but the IDE seems happy

[14:40:26] <purplefox> not sure i follow

[14:40:41] <temporalfox> it builds for me

[14:40:50] <temporalfox> ah no indeed

[14:40:53] <temporalfox> java.lang.UnsupportedOperationException: CLASS

[14:40:53] <temporalfox> at io.vertx.codegen.TypeParamInfo.create(

[14:40:54] <temporalfox> at io.vertx.codegen.TypeInfo$Factory.create(

[14:40:54] <temporalfox> at io.vertx.codegen.TypeInfo$Factory.create(

[14:40:54] <temporalfox> at io.vertx.codegen.TypeInfo$Factory.create(

[14:40:54] <temporalfox> at io.vertx.codegen.TypeInfo$Factory.create(

[14:41:12] <temporalfox> so we do have one new example

[14:41:26] <temporalfox> that uses a Class object

[14:41:35] <temporalfox> that is not supported by codegen

[14:41:44] <temporalfox> (that is used by codetrans)

[14:42:00] <purplefox> can we make it that codetrans just logs a warning but doesn't stop the build when this occurs?

[14:42:01] <temporalfox> I need to check the examples

[14:42:04] <temporalfox> yes

[14:42:07] <temporalfox> normally it does

[14:42:30] <temporalfox> the bug happens in GroovyDocGenerator

[14:42:33] <temporalfox> taht is local

[14:42:39] <temporalfox> so it's not event codetrans I think

[14:43:00] <temporalfox> ah I see

[14:43:10] <temporalfox> in GroovyDocGenerator we do use codegen types

[14:43:19] <temporalfox> for building cross doc links

[14:43:38] <temporalfox> I think that the parent doc generator

[14:43:42] <temporalfox> should catch these errors

[14:43:47] <temporalfox> and just log them for the record

[14:44:13] <purplefox> what's the new example in core? can just comment it out for now so I can proceed…

[14:44:16] <temporalfox> let me fix it

[14:44:28] <purplefox> ok

[14:44:28] <temporalfox> it's a try/catch block anyway

[14:44:35] <temporalfox> in groovy lang itself

[14:45:46] <temporalfox> it's not example I think

[14:45:49] <temporalfox> it's {@link}

[14:46:49] <temporalfox> Could not resolve doc likn for type java.util.ServiceLoader

[14:46:58] <temporalfox> that's an {@link} to ServiceLoader

[14:48:06] <temporalfox> it's pushed

[14:49:26] <purplefox> awesome, thanks j

[14:51:16] <temporalfox> did you revert again ?

[14:56:18] <purplefox> revert what?

[14:58:57] <temporalfox> the jsonobject map patch

[14:59:33] <purplefox> yeah, i showed you the commit yesterday (the inception one) ;)

[15:01:55] <AlexLehm> purplefox, i fixed the commit hook, you can un-admin me if you like

[15:02:11] <purplefox> it's ok, i trust you

[15:02:28] <purplefox> if the repo disappears we know who to hunt down ;)

[15:03:08] <AlexLehm> the hook didn't work since jenkins requires the request to use application/x-www-from-urlencoded

[15:03:15] <purplefox> temporalfox: man, the ruby yard doc generation is sooooooooooo slooooooooow ;)

[15:03:25] <temporalfox> yes I know

[15:03:38] <temporalfox> one option would be to package this yard ourself in a jar

[15:03:53] <temporalfox> so we wouldn't have to reinstall it

[15:04:11] <temporalfox> <troll>and it's ruby so it's slow</troll>

[15:04:33] <purplefox> i stil think we should probably do the doc generation in a single separate project, not in the actual projects themselves

[15:04:44] <temporalfox> from the sources you mean ?

[15:04:55] <temporalfox> that's something to consider after 3.0

[15:05:00] <temporalfox> to be done in stack project

[15:05:05] <temporalfox> like we actually doc for javadoc

[15:05:10] <purplefox> yeah something like that

[15:05:19] <temporalfox> perahps we could have one big repo with apidocs too

[15:05:23] <temporalfox> I mean each doc

[15:05:24] <temporalfox> merged

[15:05:31] <temporalfox> probably going to be messy though

[15:05:35] <purplefox> i think that would also solve the problem of having all the docs in the repo and every time you rebuild they change so you have to commit 100 files

[15:05:50] <temporalfox> no that would not

[15:05:59] <temporalfox> because the generated doc is never commited

[15:06:18] <purplefox> i mean the asciidoc

[15:06:22] <temporalfox> ah

[15:06:36] <temporalfox> yeah maybe :-)

[15:06:52] <temporalfox> I was at leastm entionning the yardoc / groovydoc / jsdoc

[15:06:55] <temporalfox> those takes time

[15:07:00] <purplefox> yeah

[15:07:01] <temporalfox> asciidoc generation is very cheap

[15:07:11] <purplefox> true so those are two separate issues

[15:07:15] <temporalfox> and it's done in compilation phase

[15:30:18] <AlexLehm> ah, i just changed the log package in the wip branch, should have waited

[15:30:29] <AlexLehm> but on the plus side, the commit hook build trigger is now working

[16:13:26] <guillemsalas> hi all

[16:14:08] <guillemsalas> I would ask if there's some module for helping testing against mongo-persistor

[16:15:38] <guillemsalas> I'm developing an application that uses multiple modules and I want to define test for each module, but I want to be able to run the tests without a mongodb instance available on the network, is it possible?

[16:43:25] <purplefox> temporalfox: i can't seem to build the stack now as it requires docker - is this now a mandatory requirement?

[17:10:40] <purplefox> temporalfox: nvm -DskipDocker :)

[17:19:41] <temporalfox> yes skipDocker

[17:20:29] <purplefox> temporalfox: i wonder if you could take a quick look at something? vertx-hazelcast I have it producing the docs but it's not exporting the correct docs zip to be consumed by the stack

[17:20:43] <purplefox> so basically i'm missing something in the pom.xml

[17:20:54] <temporalfox> which pom.xml ?

[17:20:58] <temporalfox> stack or hazelcast ?

[17:22:19] <purplefox> hazelcast

[17:22:26] <temporalfox> ok

[17:23:33] <temporalfox> the xml packaging must be added

[17:23:51] <temporalfox> so you need a doc.xml

[17:23:53] <temporalfox> + the plugin

[17:24:03] <temporalfox> like in vertx-rx

[17:24:44] <temporalfox> perhaps we should later reinstate the maven mixin plugin I tried a few months ago

[17:25:33] <temporalfox> the assembly in vertx-rx is in the parent

[17:25:41] <temporalfox> I can do it if you prefer

[17:27:01] <purplefox> hmm i've tried but I'm now getting:

[17:27:14] <purplefox> ERROR] no protocol: /home/tim/projects/vert-x3/vertx-hazelcast/assembly/docs.xml

[17:28:15] <temporalfox> ok

[17:28:19] <temporalfox> I will do it

[17:33:30] <temporalfox> it's pushed

[17:39:44] <purplefox> temporalfox: thx!

[17:45:37] <purplefox> temporalfox: i am going insane? I think i might of reverted the jsonobject patch revert too many times, or was it too few? ;) because it still seems to be there

[17:45:58] <temporalfox> yes it's there

[17:46:01] <temporalfox> that's why I asked

[17:46:05] <temporalfox> earlier today

[17:46:20] <purplefox> lol

[17:46:34] <temporalfox> then I felt stupid when you replied :-)

[17:46:37] <purplefox> ok, in 10 mins I will wake from the dream into the next layer of inception

[17:47:00] <temporalfox> I will surely feel less stupid in that other layer

[17:47:14] <purplefox> ok…. time to revert the revert of the revert of the revert!

[17:47:29] <purplefox> ha i'm the one who should be feeling stupid

[17:50:05] <purplefox> if someone looks at our commit log they are going to have a laugh

[17:53:08] <purplefox> temporalfox: lol

[17:54:02] <temporalfox> that probably can be in the guinness book

[17:57:47] <purplefox> The world record for the most reverted commit :)