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

[08:28:04] <cescoffier> temporal_ I've updated the docker PR, forgot to provide an example on how to launch a verticle using the docker executable image. There is a trick as you need to mount $PWD in the docker container and refer to this directory in the `-cp` argument. (so documentation was definitely required).

[09:33:01] <purplefox> cescoffier: temporal_ morning folks :)

[09:33:10] <cescoffier> purplefox morning !

[09:33:12] <temporal_> hello team

[09:33:45] <purplefox> cescoffier: how's it going, are you settling in ok?

[09:34:30] <cescoffier> purplefox: everything smoothly going, make good progress on the openshift support. The cartridge should be ready today (some test and doc to write)

[09:34:59] <purplefox> great

[09:35:05] <cescoffier> purplefox: I already provided a guide for people wanted a more low level integration (with a DIY cartridge)

[09:35:45] <cescoffier> temporal_: let me know when you made progress on the different stack, so I can reflect your changes in the docker images

[09:35:56] <temporal_> cescoffier I will

[09:36:26] <purplefox> i think we're all making good progress at the moment :0

[09:36:27] <purplefox> :)

[09:36:40] <purplefox> even Paulo and he hasn't even started officially yet

[09:37:10] <cescoffier> temporal_ purplefox : I've made a very small example of a distributed app. Do you think it worths contributing it to the examples ? I needed this to check the clustering on openshift

[09:37:25] <purplefox> temporal_: i am getting failures in vertx-rx and vertx-http-service-factory which is probaby related to latest JS changes. tests fail on command line but pass in IDE

[09:37:43] <temporal_> purplefox I 've seen jenkins is failing too on those

[09:38:04] <purplefox> cescoffier: yeah, an openshift example in the examples repo would be awesome

[09:38:06] <temporal_> purplefox perhaps we need to cleanup some JS files

[09:38:18] <temporal_> purplefox I'm trying to run mysql/postgres tests locally

[09:38:27] <purplefox> we are now more strict in JS and don't allow globals so maybe there are verticles in there that use globals?

[09:38:33] <temporal_> I'm getting

[09:38:50] <temporal_> purplefox what are globals :-) ?

[09:38:55] <purplefox> global variables

[09:38:59] <temporal_> ok

[09:39:12] <temporal_> how about top level functions ?

[09:39:16] <purplefox> we now run in JS strict mode which disallows accidental globals

[09:39:23] <purplefox> (which you shouldn't be doing anyway)

[09:39:38] <purplefox> what do you mean by top level function?

[09:39:52] <temporal_> RxJS uses functions like setTimeout

[09:40:15] <purplefox> in a verticle?

[09:40:34] <temporal_> rather by Rx.js

[09:40:55] <purplefox> you can USE globals that are already there, you can't create them

[09:41:18] <purplefox>

[09:41:32] <purplefox> it's to stop people doing mistakes like this:

[09:41:37] <purplefox> var myvariable

[09:41:43] <temporal_> I think actually what is failing is Rx.js itself

[09:41:52] <purplefox> myvarible = 2; note the typo - this would actually create a GLOBAL with that name [09:42:29] <purplefox> with strict it would throw an error on myvarible =2; as it hasn't been var'd [09:42:31] <temporal_> I see [09:42:45] <temporal_> yes, so it looks like Rx.js does not work in strict mode [09:43:27] <temporal_> so perhaps we need to drop rxjs support [09:43:35] <temporal_> unless there is a solution [09:44:22] <purplefox> temporal_: can you explain the issue? i'm not sure i understand [09:44:40] <temporal_> we do have Rx support for JS based on RxJS library [09:45:01] <temporal_> rx.js is provided by Microsoft [09:45:06] <temporal_> (I think) [09:45:14] <temporal_> and the implementation defines global functions [09:45:38] <temporal_> or use another rx.js library [09:45:47] <temporal_> that is compatible with strict mode [09:46:09] <temporal_> funny you say [09:46:13] <temporal_> they pass in ide [09:46:52] <purplefox> yes they pass in the IDE [09:46:53] <temporal_> I'm not sure they should pass in ide [09:47:31] <temporal_> it does for me too [09:47:35] <temporal_> but I don't see a good reason [09:47:52] <purplefox> who wroter rx.vertx.js ? [09:47:54] <temporal_> I mean if rx.js is not compatible with strict mode, I don't see how running in IDE would improve it [09:47:58] <purplefox> s/wroter/srote [09:47:59] <temporal_> I wrote it [09:48:02] <purplefox> grr, wrote [09:48:25] <purplefox> where is rx.js loaded? [09:48:55] <temporal_> in tests [09:49:05] <temporal_> rx.vertx.js is rather an extension of rx.js [09:49:35] <purplefox> not sure i follow… [09:49:48] <purplefox> i'm trying to understand how the rx.js library gets loaded and used [09:50:10] <temporal_> ah yes I see what you mean [09:50:45] <purplefox> ah i see it is requied from rx.vertx.js [09:50:58] <purplefox> (btw you should add a copyright/author header on that :) ) [09:51:13] <temporal_> yes it's required [09:51:21] <temporal_> this is how Rx.js extension are written [09:53:06] <purplefox> ah! [09:53:09] <purplefox> i know the issue [09:54:27] <AlexLehm> purplefox, I think I removed the Javascript test from mail, so i cannot say if the issue still shows up [09:54:34] <AlexLehm> not sure why I removed the test though [09:55:13] <purplefox> AlexLehm: we only should have java tests in our codegen components [09:56:09] <AlexLehm> ok, so i cannot say for sure if the file not found issue is gone away [09:58:02] <purplefox> AlexLehm: one of the reasons we do codegen is so we only have to maintain the api and tests in Java, this makes things much easier for us. if we start writing tests in other languages it defeats the purpose [09:58:37] <purplefox> temporal_: ok, firstly JS requires a later version of the JDK, as earlier nashorn doesn't have Java.synchronized [09:59:05] <purplefox> temporal_: secondly now I see failures on strict at the command line, but not in the IDE which is weird [09:59:10] <temporal_> yes [09:59:19] <temporal_> what version of JDK do we need ? [09:59:28] <temporal_> I updated jenkins a few weeks ago to run with a recent version [09:59:39] <purplefox> 45 [09:59:41] <temporal_> it's probably not the most recent [09:59:42] <temporal_> ok [09:59:54] <temporal_> I will update jenkins too now to see how it goes [10:01:06] <temporal_> so I added “OracleJDK 8” [10:01:12] <temporal_> it was using 0.40 at this time [10:01:16] <temporal_> u40 I mean [10:01:30] <temporal_> I'm updating it to u45, so all builds using OracleJDK 8 will use it [10:01:45] <temporal_> (openjdk version are lagging behind) [10:02:17] <purplefox> in rx.js it says: [10:02:18] <purplefox> “ Copyright © Microsoft Open Technologies, Inc. All rights reserved. See License.txt in the project root for license information.”

[10:02:30] <temporal_> I think we don't distribute it

[10:02:37] <temporal_> only for tests

[10:02:37] <purplefox> but there is no license.txt in there. we need to add that and make sure the license is compatible

[10:03:03] <purplefox> i beleive if it is in github that defines as “distributing” it

[10:03:46] <temporal_> ok

[10:04:14] <purplefox> do you know what license it is?

[10:04:42] <temporal_> apache

[10:04:45] <temporal_>

[10:04:46] <purplefox> 2?

[10:04:52] <temporal_> yes

[10:05:07] <purplefox> ok cool. we just need to make that clear in our repo

[10:05:11] <temporal_> about vertx-http-service-factory

[10:05:24] <temporal_> in tests it deploys a JS verticle from a local http server

[10:05:31] <temporal_> and it fails because of JS

[10:06:13] <temporal_> I'm thinking, in IDE it may be using a cached version of previous JS

[10:11:13] <purplefox> yeah, something like that.

[10:11:22] <purplefox> ok, i am going to get some breakfast then investigate

[10:13:40] <temporal_> I'm updating my JDK :-)

[10:13:59] <temporal_> the vertx-http-service-factory works locally for me though

[10:14:02] <temporal_> and not in jenkins

[10:44:19] <pmlopes> purplefox: i've completed the refactor of auth, we now have a isPermitted method and for providers that support roles (shiro, jdbc) a configurable prefix is used like: isPermitted(“role:admin”)

[10:51:17] <purplefox> pmlopes: awesome! I will take a look a little later. Any chance you could also look at the comments on your vertx-web PR for the JWT handler?

[10:52:01] <pmlopes> sure

[10:52:17] <purplefox> then hopefully we can get everything merged today and done :)

[10:52:47] <purplefox> one thing we need to do is create more examples in the vertx-examples repo, e.g. using auth, jwt etc

[10:59:03] <purplefox> temporal_: are you away on monday?

[10:59:11] <temporal_> yes the afternoon

[10:59:21] <purplefox> i'm just thinking about the milestone release

[10:59:28] <temporal_> you are supposed to do it :-)

[10:59:40] <purplefox> ok, i guess i need some practice :)

[11:00:03] <purplefox> i think right now i am not set up though with keys and stuff so can't push releases

[11:00:14] <temporal_> ok

[11:00:23] <temporal_> at the moment I'm working on stack

[11:00:35] <temporal_> and also I'm trying to get a full deploy on my machine

[11:00:42] <temporal_> with the vertx-aggregator project

[11:00:56] <temporal_> (stuck with mysql/postgres posted on vertx-dev)

[11:01:15] <temporal_> purplefox I was thinking we could create a vertx organization private key btw

[11:01:20] <temporal_> and not use our own keys

[11:03:08] <purplefox> temporal_: yes we should do this, but no idea how ;)

[11:03:30] <purplefox> i mean how to register an org user with sonatype etc

[11:03:30] <temporal_> ok :-)

[11:03:45] <temporal_> I don't think we need to do that

[11:03:56] <temporal_> I think we should just use it to sign the artifacts

[11:09:54] <purplefox> doesn't the keys for uploading have to match the keys for signing?

[11:12:01] <purplefox> temporal_: cescoffier pmlopes on other thing we need to do in the next week or two is also put out a 2.x maintenance release

[11:13:09] <cescoffier> purplefox: yes, definitely. There is some netty update (fixing a compression issue) - but it require a small change

[11:13:42] <purplefox> yeah, also there is critical hazelcast bug that we need to apply a workaround for

[11:15:00] <cescoffier> (for taceability - it's how we fixed in in wisdom:

[11:16:54] <purplefox> temporal_: ok, i fixed the JS issue, rx and http service factory should be ok now

[11:17:13] <temporal_> where did you fix it ?

[11:17:24] <temporal_> for http-service-factory in jenkins : it was still using openjdk

[11:17:30] <cescoffier>

[11:17:31] <purplefox> tekacs: in vertx-lang-js

[11:17:35] <temporal_> ok

[11:17:38] <purplefox> temporal_: ^

[11:17:56] <purplefox> so now we only use strict mode for actual verticles, but for other libs that are required we don't use strict

[11:18:11] <purplefox> because it seems many existing JS modules are written poorly

[11:18:11] <temporal_> I think it's wise

[11:21:37] <temporal_> why do we need strict for verticles ?

[11:22:05] <temporal_> (I mean besides the strict mode is there another reason ?)

[11:28:04] <pmlopes> purplefox: JWT handler is updated and some basic docs have been added

[11:48:05] <aesteve> purplefox: I have a very quick question regarding Server-Sent-Events implementation

[11:48:26] <aesteve> I'll need BridgeOptions and EventBusBridge, just like in the sockjs implementation

[11:49:06] <aesteve> and I don't know if I should name it BridgeOptions or SSEBridgeOptions for instance

[11:51:04] <aesteve> they would not be in the same package as sockJS BridgeOptions obviously, but if people use both Sockjs BridgeOptions and sse BridgeOptions in their own code that could force them to prefix with io.vertx.web.sse…

[11:51:25] <aesteve> let me know if you have an opinion (or a doc I could read) on this kind of issue

[11:58:54] <purplefox> temporal_: we use strict so verticles don't leak globals

[12:00:18] <purplefox> aesteve: i'm not sure I understand the question…

[12:00:41] <aesteve> sorry…

[12:00:58] <aesteve> I'm working on an EventBusBridge for server-sent-events

[12:01:39] <aesteve> so the API will be almost the same as the sockJSEventbusbridge (with BridgeOptions and inboundpermitted for example)

[12:01:47] <purplefox> not sure what that means

[12:02:00] <purplefox> i know what SSE means

[12:02:09] <purplefox> but how is that related to EventBusBridge?

[12:02:30] <aesteve> the same way you “forward” messages from the eventbus into a websocket

[12:02:48] <aesteve> you could forward them to people connected through SSE

[12:02:54] <purplefox> eventbusbridge means that we bridge the vert.x event bus to client side JS

[12:03:09] <aesteve> this way you could implement a very simple push-notification system

[12:03:56] <purplefox> pmlopes: when i run the vertx-auth testsuite i get lots of NPEs from the JWT implementation, but the tests pass, is this normal?

[12:04:26] <aesteve> yeah I see, bridge is not the right name, maybe “forwarder”

[12:04:29] <purplefox> aesteve: i think you are confusing me with the term “EventBusBridge” - this means specifically bridging the eventbus to client side JS

[12:05:16] <purplefox> aesteve: ok so you just mean a server that forwards event on the event bus as SSE to browsers?

[12:05:27] <aesteve> exactly

[12:06:26] <aesteve> I'll need the same kind of API that the EventBusBridge though, especially for inbound/outbound permitted (a subset of BridgeOptions)

[12:07:29] <purplefox> not sure what you mean… the eventbusbridge does not really have an API, it's just the bridge() method of a SockJSHandler

[12:07:46] <aesteve> in which you have BridgeOptions as parameter

[12:07:53] <aesteve> if I'm not mistaking

[12:08:18] <purplefox> that's just config

[12:08:47] <aesteve> what I'm interested in are the outboundpermitted

[12:09:42] <aesteve> (especially the regex address matching)

[12:10:11] <purplefox> aesteve: arnauld - this might be a good question for the dev forum as it seems quite involved :)

[12:10:32] <aesteve> ok I'll ask it there, sry for wasting your time :)

[12:10:42] <purplefox> you're not wasting my time

[12:11:32] <purplefox> pmlopes: can we discuss something related to the latest auth changes?

[12:11:53] <purplefox> aesteve: yes maybe we can reuse something with the permitted matching

[12:14:08] <aesteve> yes I think it's the thing, but I thought I'd need a subset of BridgeOptions, in fact I won't. I just need a List<PermittedOptions> which I can perfectly deal with (it's in the sockjs package but it doesn't matter)

[12:14:30] <purplefox> yeah i think the only similarity is the bridge options

[12:14:45] <purplefox> sorry the outbound permitted

[12:14:56] <aesteve> exactly

[12:15:21] <purplefox> and the auth stuff probably doesn't apply i guess

[12:15:59] <purplefox> i'm not sure you even need outbound permitted actually

[12:16:18] <purplefox> as its the sse server which will define what addresses it listens at

[12:16:20] <aesteve> I just need the regex address matchin

[12:16:25] <purplefox> it's not driven from the client side

[12:16:38] <purplefox> why would you need regex matching?

[12:17:03] <aesteve> what I would like to do is : the client opens an SSE connection, from server-side I get the SSEConnection object

[12:17:11] <aesteve> which I'd like to “map” on an eventbus address

[12:17:28] <purplefox> yes but that's just config isn;t it?

[12:17:50] <purplefox> the sse server must know what addresses it's going to listen at

[12:18:05] <purplefox> i don't think this is something the _client_ determines

[12:18:27] <aesteve> no, not the client indeed, I'm thinking about the server API

[12:18:28] <purplefox> in the eventbusbridge case it is the client that decides what to listen on so we need auth and permitted checking etc

[12:18:38] <aesteve> like :

[12:18:42] <purplefox> but if the client can't do that then why?

[12:19:16] <aesteve> sse.connectHandler { sseConnection → sseConnection.bridge(“*”); }

[12:19:37] <purplefox> what is sseconnection?

[12:19:53] <aesteve> a wrapper for the httpResponse

[12:20:10] <aesteve> with the sse primitives : data(“…”); event(“…”);

[12:20:12] <purplefox> hmm i don't really follow, perhaps some more detail on the dev forum would be a good idea :)

[12:20:20] <aesteve> yeah I'll do that :)

[12:20:27] <pmlopes> that is a warning log related to the fact that the keystore file does not contain all signature algorithms, i can lower it to info or debug…

[12:21:31] <purplefox> pmlopes: it's coming from this line in

[12:21:31] <purplefox> Signature signature = Signature.getInstance(certificate.getSigAlgName());

[12:21:45] <purplefox> so certificate is null I guess?

[12:21:58] <pmlopes> purplefox: yes, it is not present on the keystore file

[12:22:23] <purplefox> might be nicer to check this and fail more gracefully instead of a NPE?

[12:22:51] <pmlopes> sure, i'll update it and change the log level to info

[12:23:10] <purplefox> to me NPEs represent a programming error and shouldn't usually occur in normal use

[12:23:34] <pmlopes> brb

[12:23:44] <purplefox> pmlopes: ok the other thing I wanted to discuss is about isPermitted

[12:23:51] <purplefox> sure np, i will make a cup of tea

[12:23:53] <purplefox> brb too

[12:37:03] <purplefox> pmlopes: are you back?

[13:35:30] <pmlopes> purplefox: i am now

[13:36:08] <temporal_> purplefox do you mean that NPE should only be thrown by JVM when a member of null is accessed and not throw explicitly by code ?

[13:37:44] <purplefox> temporal_: no i mean it should only be thrown in the case of a programming error

[13:37:50] <temporal_> ok

[13:38:17] <purplefox> e.g. if a user passes null to a method then it's ok to throw a NPE

[13:38:39] <purplefox> but if a user calls a method findFile(“myfile.txt”) it should not throw an NPE if the file does not exist

[13:40:42] <temporal_> purplefox agreed, unless it's a side effect of an underlying layer :-)

[13:41:04] <temporal_> purplefox to fix such potentials NPE we should use AOP

[13:43:38] <pmlopes> ok, so i locally have a null check and if null throw a, now my question here is that this exception is just for information purposes, i can log it as .info or .debug but i think it should not be swallen

[14:03:24] <purplefox> pmlopes: tbh i am confused why it is being thrown, could you explain?

[14:05:01] <purplefox> pmlopes: it seems to be thrown from the setUp() of JWTAuthProviderTest:

[14:07:23] <purplefox> pmlopes: at the least:

[14:07:24] <purplefox> log.warn(alg + “ not supported”, e);

[14:07:34] <purplefox> i think the problem is you're logging the actual exception here

[14:08:00] <purplefox> it seems to me that it's normal that an alg is not supported so logging exceptions is going to scare users

[14:09:46] <purplefox> pmlopes: anyway, changing the subject ;) what i really wanted to talk about was isPermitted

[14:09:49] <purplefox> do you have 10 mins?

[14:11:17] <purplefox> pmlopes: can you ping me when you get back? think we keep missing each other ;)

[14:14:04] <aesteve> do event bus addresses support wildcards ? or regex ? (like in : eb.consumer(“news.*”), …) I can't find it in the docs but I think I've read it somewhere. Did I imagine that ?

[14:14:33] <purplefox> aesteve: no

[14:14:43] <aesteve> I must have dreamt about that…

[14:15:02] <purplefox> yes, that's why i didn't understand why regex matching for a sse server would make sense to you

[14:15:18] <aesteve> yes that's what I had in mind actually

[14:16:07] <aesteve> but nvm, forwarding an eb message published on a single address to the browser through sse should be enough

[14:30:25] <purplefox> temporal_: pmlopes cescoffier guys - you may have noticed I've been bending the rules a bit on getting everything reviewed before it goes into master, this is just a temporary thing because sometimes it just takes too long to get something reviewed and we only have a couple of days before the cutoff for 3.0

[14:30:53] <cescoffier> ok :-)

[14:30:54] <purplefox> so I don't feel I really have a choice if we're going to get everything done

[14:31:15] <temporal_> purplefox n/p with me

[14:31:18] <purplefox> so keep any eye on the commits list and if you see anything crazy - say something

[14:31:37] <cescoffier> however, I would like to have a review of my cartridge once pushed in a stable state

[14:31:51] <cescoffier> no java code, just bash ;-)

[14:32:23] <purplefox> agreed. but i think we don't need that for the last milestone :)

[14:32:34] <purplefox> so this is just until monday

[15:58:45] <pmlopes> purplefox: i am back for a bit, it is my last day so it is kind of hectic :-/

[16:04:08] <purplefox> pmlopes: hey, don't worry, i'm ok here :)

[16:04:29] <pmlopes> so what would you like to discuss?

[16:05:15] <purplefox> well.. i was just going to say I think we should rename isPermitted() to isAuthorised() because I think it makes more sense from an English language point of view especially when there are roles involved

[16:05:19] <purplefox> e.g.

[16:05:55] <pmlopes> well you're the native :) i am fine with isAuthorised

[16:05:57] <purplefox> because “isPermitted” implies that the argument is a permission, whereas isAuthorised doesn't have that implication

[16:06:27] <purplefox> yeah, well i made the change already anyway ;)

[16:06:53] <purplefox> some of the development process is going out the window for the next couple of days so we can stuff in before monday

[16:07:06] <purplefox> btw i really appreciate the stuff you've done this week :)

[16:07:15] <pmlopes> no problem!

[16:07:25] <purplefox> we should ask dave to give you some extra money for that ;)

[16:12:44] <purplefox> temporal_: cescoffier pmlopes : I have made some changes to CI so all builds occur at least once a day, because many of them hadn't been run for ages

[16:12:55] <temporal_> good idea

[16:12:58] <purplefox> temporal_: one thing i noticed is that vertx-unit currently fails

[16:13:06] <cescoffier> puplefox: that's great !

[16:13:14] <temporal_> purplefox maybe because it uses openjdk

[16:13:16] <cescoffier> do we get notifications ?

[16:13:40] <purplefox> yes we do they go to:

[16:13:45] <temporal_> I think it's because of openjdk

[16:13:47] <temporal_> and your changes

[16:13:53] <temporal_> I'm going to swithc it to oracle jdk

[16:14:02] <purplefox> vertx3-ci at googlegroups dot com

[16:14:49] <cescoffier> thanks !

[16:15:43] <temporal_> purplefox I pushed an initial version of packaging profiles in stack project with min+base+full

[16:15:58] <purplefox> cescoffier: i've added it to the list of groups here:

[16:17:12] <cescoffier> temporal_ the current docker image is the 'full'

[16:17:33] <purplefox> temporal_: looks good. i think i would also include another “light” one which does not include other languages (only java)

[16:18:01] <temporal_> ok

[16:18:31] <temporal_> need to find relevant names, and that it's one of the hardest computer science problem!

[16:19:09] <cescoffier> I don't really like the word 'base' just because it's a docker words, so we will have troubles to build such image

[16:19:19] <cescoffier> (a base image is an image made for extension)

[16:19:53] <temporal_> cescoffier makes sense

[16:20:02] <temporal_> I would say “classic” is the ultra light maybe

[16:20:25] <cescoffier> core ?

[16:20:28] <temporal_> ah yes

[16:20:36] <temporal_> good idea

[16:21:15] <temporal_> the “min” could be “polyglot” or something like that

[16:21:16] <cescoffier> so, the ultra min is 'core'

[16:21:24] <cescoffier> yep

[16:21:32] <purplefox> well core implies just vertx-core

[16:21:33] <cescoffier> nice to reflect the polyglot aspect

[16:21:56] <temporal_> I belive min should not have languages

[16:22:03] <temporal_> because min, means you cannot have less

[16:22:52] <purplefox> how about small, medium, large, XL, XXL ? ;)

[16:23:03] <purplefox> not serious

[16:23:39] <purplefox> i think the most important thing now is not to decide on what's in each distro but to have the machinery in place where it's easy to define a new distro just by configuring some xml :)

[16:23:41] <cescoffier> was thinking about pizza name…. (getting hungry)

[16:23:44] <temporal_> the Rx version should be called

[16:23:46] <purplefox> we can also tweak the actual distros later

[16:23:47] <temporal_> “hipster”

[16:23:54] <purplefox> lol

[16:24:01] <temporal_> the nothing version “purplefox”

[16:24:10] <temporal_> because he does not need Promises

[16:24:17] <temporal_> and compose them naturally

[16:24:24] <purplefox> i wonder how many users will use distros and how many will just maven to bring in deps

[16:24:33] <temporal_> it depends on the crowd

[16:24:38] <temporal_> tbh, I like distros

[16:24:42] <purplefox> hmmm…. here's a really cool idea

[16:24:42] <temporal_> specially for demos and talks

[16:24:58] <temporal_> specially if I need to run clustering demos

[16:25:10] <temporal_> I prefer to have several terminals

[16:25:13] <purplefox> and it does require a bit of web site work: how about we let them design their distro on the website by ticking checkboxes then it creates it on the fly and they can download it?

[16:25:15] <temporal_> than several “ide” tabs

[16:25:23] <temporal_> ahahahah

[16:25:28] <temporal_> I was sure you were going to say that

[16:25:37] <purplefox> it actually wouldn't be that hard

[16:25:44] <aesteve> purplefox: that's actually a freaking good idea

[16:25:45] <purplefox> just an vert.x web app could do it :)

[16:26:22] <temporal_> let's do that after milestone6 :-)

[16:26:39] <temporal_> purplefox I would rather put in maven all possible combinations :-)

[16:26:56] <cescoffier> well the tricky thing is the dependencies

[16:27:14] <temporal_> I think we can do something easy with an hardcoded list of dependencies

[16:27:16] <cescoffier> how to be sure it embeds the right set of dependencies

[16:27:16] <purplefox> true

[16:27:18] <temporal_> like it is now

[16:27:32] <temporal_> at the end we said for distro we don't use transitivie dependencies

[16:27:36] <temporal_> and isntead list them manually

[16:27:38] <cescoffier> we can embed aether and let its magic compute the _right_ set

[16:27:42] <temporal_> so we don't pull up unnecessary stuff

[16:27:57] <cescoffier> yes, would prefer that to aether

[16:28:19] <temporal_> one thing we can do is use assembly plugin however

[16:28:27] <temporal_> and reuse the components.xml I've done

[16:28:41] <temporal_>

[16:28:45] <temporal_> stack-base.xml

[16:28:48] <temporal_> etc…

[16:29:22] <temporal_> full is min + base + data + mail + web

[16:29:43] <temporal_> so potentially we can have a checkbox per components.xml

[16:30:00] <temporal_> the full :

[16:30:37] <temporal_> and we can also release one zip file per stack-*.xml

[16:30:41] <temporal_> and later just merge them in the webapp

[16:30:59] <temporal_> we use classfier stack-*

[16:31:45] <purplefox> temporal_: quick questoin on rx, it's failing on CI due to a groovy test

[16:32:08] <purplefox> testScheduledBuffer, which appears to rely on timing

[16:32:18] <purplefox> test.assertTrue(“Was expecting to have time taken | $timeTaken - 1000 | < 200”, Math.abs(timeTaken - 1000) < 1000);

[16:32:38] <temporal_> yes this depends a bit on the runtime indeed

[16:32:57] <purplefox> right, timing tests like this are problematic, especially on CI

[16:33:12] <purplefox> I guess i will just increase the latitude

[16:33:24] <temporal_> the current rx is also failing because of openjdk

[16:33:34] <temporal_> I'm chaning it

[16:34:05] <temporal_> usually this test works quite well on Jenkins though

[16:34:17] <temporal_> I believe it is confused because of openjdk / nashorn problems

[16:35:05] <purplefox> well.. thread schedling and GC can introduce pauses too

[16:35:11] <purplefox> especially on virtualised machines

[16:35:32] <purplefox> i had the same issue on other projects. sometimes could see pauses of several seconds

[16:35:50] <temporal_> Starting test: GroovyIntegrationTest#testTimeMap

[16:35:50] <temporal_> Starting test: GroovyIntegrationTest#testObserverToHandler

[16:35:50] <temporal_> Starting test: GroovyIntegrationTest#testScheduledTimer

[16:35:50] <temporal_> Starting test: GroovyIntegrationTest#testHttpClient

[16:35:50] <temporal_> Starting test: GroovyIntegrationTest#testHttpClientFlatMapUnmarshall

[16:35:53] <temporal_> in jenkins :-)

[16:36:11] <temporal_> I will try to rewrite this test in a better way

[16:36:22] <purplefox> it's ok i'm increasing the timeout

[16:36:51] <purplefox> but in general any test that relies on some timing is likely to fail sooner or later depending on the environment

[16:37:18] <temporal_> yes

[16:37:29] <temporal_> however sometimes there is no other choice

[16:37:45] <purplefox> well… what you can test is that it takes longer than a certain time

[16:37:59] <purplefox> e.g. if you are expecting a pause of 500

[16:38:06] <purplefox> then you can test that actual pause >= 500

[16:38:11] <purplefox> and that should always be true

[16:38:30] <purplefox> but what you shouldn't test is pause ⇐ 500 && pause < some_upper_bound

[16:38:45] <purplefox> coz that makes it nondeterministic

[16:38:52] <purplefox> imho

[16:39:00] <temporal_> agreed

[16:40:32] <purplefox> temporal_: dropwizard tests fail too at the moment

[16:40:40] <temporal_> I think it's also openjdk

[16:41:24] <temporal_> the recent changes in vertx-lang-js mandates to use oracle JDK for all builds

[16:41:39] <temporal_> (well not all)

[16:41:57] <temporal_> actually does not seem related to that :-)

[16:42:17] <temporal_> but CI now seems to be on fire

[16:43:04] <purplefox> temporal_: the dropwizard tests also fail for me locally if i run them in a loop. i'd guess you also have nondeterministic tests in there too

[16:43:13] <temporal_> probably :-)

[16:43:16] <temporal_> which ones ?

[16:43:29] <purplefox> e.g. testScaleHttpServers

[16:43:46] <temporal_> this test I think attempts to put requests on several servers

[16:44:03] <temporal_> to check the various http servers reports correctly to the same underlying metrics

[16:44:18] <temporal_> I think instead of sending a fixed number of requests

[16:44:24] <purplefox> yep, so i bet in this test you update the request count *after* you send the response

[16:44:27] <temporal_> it should send requests until all metrics rea reported

[16:44:29] <purplefox> so you have a race there

[16:44:47] <temporal_> given that we changed things recently in vertx core related to that :-)

[16:44:58] <temporal_> I will take care of it now

[16:45:35] <purplefox> one thing you can do is to use waitUntil() to wait for something to happen

[16:45:44] <purplefox> if there's possibility there's a small delay

[16:45:53] <purplefox> that's how i fixed the last metrics test

[16:46:24] <temporal_> ok

[16:46:47] <temporal_> it failed for me but after 756 runs :-)

[16:46:49] <temporal_> 756/1000

[16:47:24] <temporal_> and not the second time

[16:48:06] <purplefox> ha ;) but on CI the indeterminacy will be greatly amplified

[16:49:23] <purplefox> as they're running on EC2 so there are probably many virtual machines running on the real server, so scheduling is much more chunky

[17:02:26] <temporal_> purplefox I suspect that CI may have an problem

[17:02:36] <temporal_> like an infinite loop on project build reaction

[17:02:45] <temporal_> we do have many concurrent builds

[17:02:52] <temporal_> and triggers looks like this :

[17:04:01] <temporal_> there is a current hazelcast build and one in the queue for instance

[17:04:13] <temporal_> same for core

[17:04:23] <temporal_> I'm cancelling the builds in the queue

[17:06:11] <temporal_> 30 builds just popped up in the queue :-)

[17:06:13] <temporal_> I don't know why

[17:07:16] <purplefox> they're all triggered to run when vertx-core changes

[17:07:23] <purplefox> so maybe something changed in vertx-core

[17:07:30] <temporal_> yes but that was quite insane :-)

[18:23:41] <aesteve> purplefox: regarding your advice on setTimer vs. setPeriodic this could be noted in the docs somewhere :)

[18:24:06] <aesteve> this is actually a very common issue among javascript beginners with setTimer vs. setInterval

[18:35:46] <purplefox> aesteve: +1

[22:08:31] <gigo1980_> hi together, is the vertx instance a singleton representation. or does i have to inject it elsethere ?

[22:39:07] <AlexLehm> purplefox, i think we can just close the issue