[05:25:56] * ChanServ sets mode: +o temporalfox [08:39:45] * ChanServ sets mode: +o purplefox

[09:52:12] <cescoffier> guys, vertx-web build is failing because of : Build timed out (after 15 minutes). Marking the build as aborted.

[09:52:25] <cescoffier> will increase the timeout.

[09:56:21] <purplefox> why is taking so long?

[09:57:43] <cescoffier> we have several module resolving the yard gem

[09:57:57] <cescoffier> we need to have a look to this

[09:58:31] <purplefox> ah the doc generation

[09:59:16] <purplefox> i think we should really look at moving all doc gen to a separate project after 3.1 as we discussed

[10:01:20] <cescoffier> yes, that would make things much faster

[10:03:17] <cescoffier> purplefox: we are dealing with a few things about the new eventbus.js, once done, we should be able to start the release

[10:03:25] <cescoffier> we would need the release notes

[10:03:44] <purplefox> are we going to put the notes in the release?

[10:04:31] <purplefox> i'll do the release notes

[10:04:37] <purplefox> also I want to look at https://github.com/eclipse/vert.x/pull/1157

[10:04:40] <purplefox> maybe we include it too

[10:15:07] <cescoffier> purplefox: do you want me to review it ?

[10:15:43] <purplefox> i'm doing it. there are a few issues with it still, but I'm correcting those myself

[10:18:41] <temporalfox> if you include this, please annotate the enum with @VertxGen and add doc

[10:24:13] <purplefox> he already did that

[10:28:02] <temporalfox> cool

[10:36:02] <purplefox> temporalfox: ok all done

[10:38:55] <pmlopes> @temporalfox i've a PR on jsproxygen that runs all test using the real vertx-eventbus.js

[10:38:56] <pmlopes> https://github.com/vert-x3/vertx-service-proxy/pull/27

[10:39:18] <temporalfox> ok

[10:39:30] <temporalfox> how does it work ?

[10:39:43] <temporalfox> that makes me more comfortable given that we did not have real test of proxy creation

[10:40:06] <temporalfox> it's nashorn based ?

[10:40:43] <temporalfox> I see

[10:40:43] <temporalfox> var SockJS = require('sockjs-client');

[10:40:52] <temporalfox> how does it use a sockjs client in the tests ?

[10:40:58] <pmlopes> the same script works on nashorn, node and browsers, the trick was that i've created a stub of the sockjs-client to use the real eventbus

[10:41:25] <temporalfox> I see

[10:41:35] <temporalfox> it reuses parts of the previous bus.js

[10:41:59] <temporalfox> good job

[10:42:11] <pmlopes> the stub uses exactly the same API as the real implementation so i just map the calls to the eventbus and return the raw strings to vertx-eventbus.js and it then handles it

[10:42:47] <temporalfox> do you use the same in vert.x web ?

[10:44:06] <pmlopes> yes exactly the same

[10:44:21] <pmlopes> oh you mean to test it on vert.x web?

[10:44:28] <pmlopes> not yet but that is the plan

[10:46:25] <temporalfox> yes

[10:57:30] <cescoffier> temporalfox, purplefox what about https://github.com/vert-x3/issues/issues/45

[10:57:56] <temporalfox> yes I said I would take care of it, but it slept in my schedule

[10:58:17] <temporalfox> I can do it before release

[10:58:28] <purplefox> it's a doc issue i think

[10:58:40] <purplefox> btw vertx-shell is failing on CI

[10:58:55] <temporalfox> CI has transient issues

[10:59:00] <temporalfox> we need to double check

[10:59:08] <temporalfox> vertx-rx and another one were failed yesterday

[10:59:34] <temporalfox> I'm running it again

[11:00:04] <purplefox> temporalfox: hmm, doesn't look like a CI issue, it's a failing test

[11:00:08] <temporalfox> yes

[11:00:09] <purplefox> maybe a race condition there?

[11:00:18] <temporalfox> I was thinking about that indeed

[11:00:33] <purplefox> CI is often very good for finding race conditions in code :)

[11:00:37] <temporalfox> indeed

[11:00:48] <temporalfox> and such race conditions are one of our worst enemy

[11:01:29] <temporalfox> I see the problem

[11:01:47] <temporalfox> it may be a vertx problem

[11:02:04] <purplefox> How does the command registry get closed?

[11:02:21] <temporalfox> the command registry deploys a verticle in vertx

[11:02:27] <temporalfox> to be notified of vertx close

[11:02:43] <temporalfox> so the test assumes that the close callback has all verticles undeployed

[11:03:09] <temporalfox> CommandRegistry does

[11:03:10] <temporalfox> vertx.deployVerticle(this, ar → {

[11:03:10] <temporalfox> if (!ar.succeeded()) {

[11:03:10] <temporalfox> registries.remove(vertx);

[11:03:10] <temporalfox> }

[11:03:10] <temporalfox> });

[11:03:20] <temporalfox> and

[11:03:27] <temporalfox> public void stop() throws Exception {

[11:03:28] <temporalfox> closed = true;

[11:03:28] <temporalfox> registries.remove(vertx);

[11:03:28] <temporalfox> }

[11:03:55] <temporalfox> and the test does not seem wrong to me

[11:06:56] <purplefox> doesn't that test exit without waiting for close to occur?

[11:07:14] <purplefox> if i add a countdownlatch it seems to pass every time

[11:07:53] <temporalfox> context.asyncAssertSuccess should prevent exit

[11:08:53] <purplefox> If I change it to this it passes every time for me:

[11:08:54] <purplefox> https://gist.github.com/purplefox/4b72f8b891d846ce68a6

[11:09:03] <purplefox> without those changes it fails most times for me (in IDE)

[11:09:13] <temporalfox> otherwise it fails for you ?

[11:09:16] <purplefox> yes

[11:09:43] <temporalfox> ok then please change it this way and I'll investigate

[11:12:22] <temporalfox> locally it fails sometimes

[11:12:25] <temporalfox> I've added some logging

[11:12:30] <temporalfox> when it passes it prints

[11:12:33] <temporalfox> closed

[11:12:33] <temporalfox> removed

[11:12:33] <temporalfox> done

[11:12:38] <temporalfox> when it fails

[11:12:38] <temporalfox> closed

[11:12:38] <temporalfox> done

[11:12:52] <temporalfox> “removed” is the verticle undeployment

[11:13:00] <temporalfox> so there is something unclear

[11:13:01] <temporalfox> to me

[11:13:15] <temporalfox> it means that when it fails “stop” has not been called on the verticle

[11:16:14] <temporalfox> ah I see the issue

[11:16:16] <temporalfox> I think

[11:16:20] <temporalfox> the problem is above

[11:16:24] <temporalfox> CommandRegistryImpl registry = (CommandRegistryImpl) CommandRegistry.get(vertx);

[11:16:29] <temporalfox> does deploy the verticle

[11:16:37] <temporalfox> but it may close vertx before the verticle is deployed

[11:16:47] <temporalfox> in this case the verticle is not stopped

[11:19:34] <temporalfox> prb solved ^^

[11:24:37] <purplefox> hmm it seems to me the get() method should be async. otherwise you can return an uninitialised instance

[11:25:16] <purplefox> btw… why does it need to be a verticle?

[11:31:51] <purplefox> cescoffier: is vertx3-examples-it used any more?

[11:38:43] <cescoffier> yes

[11:38:43] <cescoffier> it's the one automating the examples

[11:41:01] <purplefox> ok, it's failing on CI

[11:41:02] <cescoffier> yes

[11:41:04] <cescoffier> right now it's because the stack artifact looks corrupted

[11:41:13] <cescoffier> and before it was because of some failing ITs

[11:41:31] <cescoffier> I also run it everyday on my machine

[11:41:38] <cescoffier> (on mac, linux and windows)

[11:42:31] <cescoffier> “metrics#groovy.metrics#groovy, metrics#java.metrics#java, metrics#js.metrics#js, metrics#ruby.metrics#ruby” were broken because of the new vertx-eventbus.js

[11:43:07] <cescoffier> while this one “sync-mongo#java.sync-mongo#java” was a missing dependency

[11:44:26] <purplefox> what is sync-mongo?

[11:44:42] <cescoffier> the vertx-sync example using the mongo client

[11:45:21] <cescoffier> (you implemented it )

[11:47:28] <purplefox> sorry, just didn't recognise the syntax you used above

[11:47:39] <cescoffier> it's my syntax

[11:48:03] <cescoffier> just a way to identify the example and the “execution” of this example (java, js, groovy….)

[11:48:38] <cescoffier> the maven plugin running the example use this syntax in the generated reports

[11:49:08] <cescoffier> for instance net-echo#ruby is the echo example using the Net client and server in ruby

[11:50:48] <cescoffier> (this syntax is far from perfect, I just needed something easy when I implemented the plugin)

[12:23:48] <purplefox> cescoffier: pmlopes: have you seen jhipster: http://jhipster.github.io/tech_stack.html ?

[12:24:14] <purplefox> I was thinking maybe we could ddo something similar with vert.x,

[12:48:40] <pmlopes> yes jhipster is like mean.io for node, i see it as a stack and a scafolding tool

[13:06:12] <purplefox> yeah, it would be cool if we had a simple way of bootstrapping an end-end vert.x application with front-end too so users could get started quixkly

[13:09:02] <purplefox> pmlopes: cescoffier: release notes is going to be a pain - should we list every change in every component of the official stack?

[13:50:56] <pmlopes> i don't the wiki were we have the API changes would be enough, otherwise it will be a huge list of changes and i don't see the benefit of it, but that's my opinion…

[14:01:24] <purplefox> yeah, i've never been a huge fan of long release notes. who actually reads them?

[14:02:53] <cescoffier> purplefox: sorry was out for lunch

[14:02:53] <cescoffier> so yes I know jhipster

[14:02:59] <cescoffier> and yes we could do something like that with vert.x

[14:03:01] <cescoffier> release notes: I'm pretty sure I can get something using the github api

[14:03:01] <cescoffier> give me 30 minutes

[14:03:13] <cescoffier> oupsy, I should not have updated the bower repo this morning….

[14:04:00] <cescoffier> all examples are ok

[14:04:05] <purplefox> you mean a list of commits from the git log??

[14:04:31] <cescoffier> nope, the gihub API and get the issue and PR

[14:04:40] <cescoffier> for each component since the last release

[14:05:08] <cescoffier> It's what I do for Wisdom…. will just adapt the script to support all our repositories

[14:05:32] <cescoffier> we would just need to remove duplicates, but that's would be much easier no ?

[14:12:56] <cescoffier> purplefox: https://api.github.com/repos/eclipse/vert.x/issues?state=closed&since=2015-06-23T19:00:00Z

[14:13:08] <cescoffier> this would give you all closed issues on vert.x core since the last released

[14:14:51] <cescoffier> purplefox: for PRs: https://api.github.com/repos/eclipse/vert.x/pulls?state=closed&since=2015-06-23T19:00:00Z

[14:42:47] <amr> can i just pass a MongoClient instance around when i want to reuse it a few times

[14:42:58] <amr> or do i need to new up some more?

[15:14:16] <amr> also, can i use vertx's futures?

[15:41:37] <cescoffier> purplefox: here are the release note for core: https://gist.github.com/cescoffier/3f6074769b6499b2bb5f

[15:42:44] <purplefox> ok that's pretty nice

[15:42:57] <purplefox> could we aggregate them for all the official projects?

[15:49:33] <purplefox> cescoffier: i've just kicked off examples-it on CI as it hasn't run for a while

[15:49:46] <cescoffier> this morning ?

[15:49:54] <cescoffier> I've run them at lunch

[15:50:27] <cescoffier> it's normal to have failure as the NPM and bower artifacts are not yet in sync

[15:50:46] <cescoffier> the rest of the examples were all fine (on linux, windows and mac)

[15:50:56] <purplefox> i guess I'm a little confused. aren't we supposed to have all green on CI before a release?

[15:52:42] <purplefox> if it's not useful to have that build on CI we should remove it (although I prefer not to rely on private runs on people's machines)

[15:54:00] <purplefox> it's currently failing with this:

[15:54:13] <purplefox> Could not resolve dependencies for project io.vertx:vertx-integration-test-maven-plugin:maven-plugin:3.1.0-SNAPSHOT: Could not find artifact io.vertx:vertx-stack-dist:zip:full:3.1.0-SNAPSHOT

[15:56:37] <cescoffier> corrupted artifact

[15:56:42] <cescoffier> I don't know from where this is coming

[15:56:51] <cescoffier> something internal to cloudbees

[15:57:07] <cescoffier> this job is not a canari build telling you about the state of the system

[15:57:15] <cescoffier> it generate reports.

[15:57:44] <cescoffier> and as we are close to a release, some of our example do not work anymore as they depends on not yet updated artifacts (NPM and bower)

[15:58:28] <cescoffier> I can make it green/blue if you want

[15:59:25] <purplefox> can you elaborate on what you mean by not yet updated artifacts (npm and bower) ?

[16:00:14] <purplefox> i can't see a report on CI

[16:00:32] <cescoffier> yes, you can't see the report because of the stack artifact that is not there

[16:00:46] <cescoffier> so, some examples use the NPM and bower package

[16:00:48] <purplefox> so how can we tell if things are ok?

[16:01:01] * purplefox confused

[16:01:02] <cescoffier> these packages are not yet published as it will be after the release

[16:01:09] <cescoffier> things are OK

[16:01:20] <purplefox> which packages?

[16:01:26] <cescoffier> I wrote it there a 14:04

[16:01:38] <cescoffier> NPM and Bower package embedding the vertxbus.js

[16:01:58] <purplefox> i saw you said that, but that wasn't enough information for me to unsderstand what those things are

[16:02:01] <cescoffier> there are still providing the vertxbus 3.0.0

[16:02:07] <cescoffier> and not 3.1.0

[16:02:31] <cescoffier> don't worry, if something would have been broken here, I would have reported the issue

[16:02:41] <cescoffier> as I did this morning for the vertxbus.js client

[16:02:52] <cescoffier> this job is misleading

[16:02:59] <cescoffier> I will move it to another tab

[16:03:17] <purplefox> so how do i know if the examples are ok without seeing a report?

[16:04:07] <cescoffier> because this is not the only CI executing them

[16:04:18] <cescoffier> my linux CI, and windows one are also executing this job

[16:04:29] <cescoffier> pmlopes: can you check and report the “won't fix element from https://gist.github.com/cescoffier/7e8a41aeaa35fcb44734

[16:05:21] <purplefox> ok but I don't like to rely on private CI runs…

[16:05:33] <cescoffier> have in windows CI would be nice

[16:05:37] <purplefox> how does it work privately but fails publicly?

[16:05:38] <cescoffier> but pricey

[16:06:04] <cescoffier> the current failure is weird, and I seriously have no idea from where it comes

[16:06:09] <cescoffier> it cannot resolve the vertx-stack

[16:06:20] <cescoffier> which works on my CIs

[16:06:20] <purplefox> have you tried deleting the workspace?

[16:06:29] <purplefox> i will do this

[16:06:31] <cescoffier> the workspace and maven repo are deleted every time

[16:07:24] <cescoffier> BTW: the report of the previous build are therE: https://vertx.ci.cloudbees.com/view/vert.x-3/job/vertx3-examples-it/243/

[16:08:51] <cescoffier> and there: https://vertx.ci.cloudbees.com/view/vert.x-3/job/vertx3-examples-it/243/testReport/

[16:11:07] <cescoffier> oh, you restarted the job

[16:11:10] <cescoffier> it won't work

[16:11:13] <cescoffier> well already failed

[16:11:21] <cescoffier> the vertx-stack artifact is missing from the repo

[16:12:09] <purplefox> I wonder why it's trying to look in the cloudbees private repo. that artifact is on oss.sonatype

[16:13:25] <purplefox> weird, did it ever work?

[16:14:01] <cescoffier> yes that the tricky thing

[16:14:05] <cescoffier> it works sometimes

[16:14:14] <cescoffier> I've no idea from where this is coming

[16:14:48] <purplefox> one thing to notice - if you look in oss.sonatype there are no actual -SNAPSHOT artifacts, only timestamped

[16:15:32] <purplefox> oh well…

[16:15:42] <purplefox> if you're happy then let's make an exception this time

[16:16:03] <purplefox> it might be an idea to open a ticket with support at cloudbees dot com though

[16:21:48] <cescoffier> ah ah I'm forcing the repo, let's check

[16:22:30] <cescoffier> that's notmal there are only timestamps artifacts, it's the oss.sonatype repo policy

[16:22:45] <cescoffier> ok, by forcing the repo, it works

[16:23:13] <cescoffier> howver it will be red again, because of the web tests that need to be skipped (NPM/Bower issue)

[16:29:43] <purplefox> what's the process for getting the npm/bower stuff updated?

[16:34:22] <cescoffier> after the release

[16:34:40] <cescoffier> we need to publish to NPM and bower

[16:34:56] <cescoffier> NPM: you need a special account and do a npm publish

[16:35:08] <cescoffier> Bower, you just need to create a tag with the right version

[16:35:29] <cescoffier> webjar: I don't know if it's going to be automatic or not, it relies on the NPM package

[16:44:51] <cescoffier> pmlopes: I've made some cleanup

[16:44:52] <cescoffier> https://gist.github.com/cescoffier/7e8a41aeaa35fcb44734

[17:10:59] <cescoffier> purplefox: here are the release notes: https://github.com/vert-x3/wiki/wiki/3.1-Release-Notes

[17:11:49] <purplefox> cescoffier: looks nice :)

[17:12:18] <cescoffier> julien has checked them

[17:12:30] <cescoffier> but it would be good if paulo can check the web ones

[17:14:21] <cescoffier> so, on my side, it's ok

[17:35:43] <purplefox> cescoffier: pmlopes: temporalfox: ok, so what's the plan - are we going to do it today, or tomorrow (it's getting a bit late now)?

[17:35:55] <temporalfox> rather tomorrow

[17:36:01] <temporalfox> I need to release termd tonight

[17:36:03] <purplefox> +1

[17:36:06] <temporalfox> I waited last minute

[17:36:15] <temporalfox> to handle issues with termd

[17:36:31] <purplefox> ok good.

[17:36:40] <purplefox> so tomorrow we just need to build everything and push right?

[17:36:50] <temporalfox> kind of

[17:36:57] <temporalfox> there are several phases

[17:37:07] <temporalfox> build + push will handle the jars

[17:37:07] <purplefox> what i mean is.. there are no outstanding code changes :)

[17:37:13] <purplefox> (other than termd)

[17:37:17] <temporalfox> yes nobody should push

[17:37:31] <temporalfox> then after jars we need to do the bintray

[17:37:34] <temporalfox> eclipse

[17:37:38] <temporalfox> npm

[17:37:40] <temporalfox> etc…

[17:43:38] <cescoffier> youhou !

[17:43:49] <cescoffier> tomorrow is the day I need to remember all my password

[17:45:59] <temporalfox> yes

[17:46:05] <temporalfox> and Thursday I can upgrade my OS

[17:46:23] <temporalfox> haven't done that for a while

[19:10:51] <pmlopes> Sorry guys i was away +1 for tomorrow

[20:08:34] <temporalfox> termd 1.0.0 has been released on should be on central

[20:43:20] <amr> whats' the best way to new up a new future? Future.factory.future() ?

[20:49:20] * ChanServ sets mode: +o purplefox [20:53:00] <pmlopes> @purplefox @temporalfox if you have trouble sleeping i just pushed the tcp bridge :| I also add a nodejs client that uses the same API as the SockJS client [21:20:55] <temporalfox> pmlopes so the tcp bridge working with the jsproxygen ? [23:24:15] * ChanServ sets mode: +o purplefox