Approvals: 0/1
[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