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

[01:01:05] <bytor99999> Man. So all the assert methods have reversed the parameter order. Instead of the String message being the first parameter, it is now the last in all the asserts. Lots of code to fix. ;)

[01:06:15] <bytor99999> Actually, what would be much easier than me changing at least 500-700 lines of assertions. Would be to include versions of the each assert method in vertx-unit that still take the message as the first parameter and they just call the newer version. I am going to pull and try to do that and do a pull request. Just that I have no clue what my username/password to make contributions are anymore. :D

[01:25:39] <bytor99999> I also suck at github and pull requests. I just fixed the documentation to show TestContext instead of Context in the index.adoc for groovy, java, js, and ruby. But can't get it to github. I guess I didn't fork, but just cloned on my computer.

[01:26:11] <bytor99999> Good thing this is in vertx-unit so I guess I don't have to know my Eclipse login. ;)

[07:29:50] <pcjoshi_> is vert.x 3 stable released yet ???

[09:04:46] <purplefox_> temporal_: hi julien

[09:04:53] <temporal_> purplefox_ hi

[09:05:03] <purplefox_> temporal_: good morning

[09:05:23] <temporal_> how is it going ?

[09:05:26] <purplefox_> temporal_: just to give you an update on the redeploy/isolation stuff

[09:05:32] <temporal_> yes

[09:05:54] <purplefox_> I've removed redeploy

[09:06:06] <purplefox_> as it doesn't really work anyway

[09:06:37] <temporal_> ok

[09:07:20] <purplefox_> and I've changed isolation groups - so now you provide a list of classes/packages which are isolated and the rest is not isolated

[09:07:42] <purplefox_> this means everything else is parent first delegation and should just work

[09:08:11] <temporal_> ok, so I think that in the metrics + groovy case, it should work out of the box

[09:08:27] <purplefox_> yes

[09:08:36] <purplefox_> it's in the isolation_fixes branch

[09:08:53] <purplefox_> all core tests passing but we need to write a few more tests for the new behaviour

[09:09:08] <purplefox_> if we do this together it will be quicker. can you help me with that?

[09:09:53] <temporal_> of course I can do that

[09:10:47] <purplefox_> actually isolation groups make a lot more sense now imho as it's very explicit what is isolated

[09:11:10] <purplefox_> the isolating classloader takes a list of string which is basically class names, or wildcards, e.g.

[09:11:16] <purplefox_> com.foo.MyClass

[09:11:19] <purplefox_> com.bar.*

[09:11:20] <purplefox_> etc

[09:11:34] <purplefox_> and if the class does not match then it's not isolated

[09:11:58] <purplefox_> redeploy never really worked anyway as it watched every url on the main classpath and redeployed if anything changed

[09:12:35] <purplefox_> and the concept of fine grained redeploy in vert.x (i.e. redeploy on the per deployment level) is hard to express

[09:12:58] <purplefox_> because you'd have to express which classes you want isolated and which urls to watch

[09:13:19] <purplefox_> e.g. if you do vertx.deployVerticle(myClass) with redeploy

[09:13:37] <purplefox_> then how does Vert.x know which classes to isolate. just myClass? what about the classes that myClass uses

[09:13:57] <purplefox_> there's no way that vert.x can really know unless the user provides this information

[09:14:27] <purplefox_> so i don't think redeploy really makes sense on a fine grained level

[09:15:08] <purplefox_> so.. test wise.. it's not much. we need a test that isolation groups with more than one class and tests the wildcard functionality

[09:15:21] <purplefox_> and we need to renenable the extra cp test which i commented out

[09:15:26] <purplefox_> that's pretty much it

[09:15:59] <temporal_> ok

[09:16:06] <purplefox_> i can do the wildcard stuff, can you do the extra cp one?

[09:16:25] <purplefox_> also we need to update the docs

[09:19:29] <temporal_> where is the code so I can have a look at it ?

[09:20:22] <cescoffier> purplefox_ temporal_ pmlopes : hi guys

[09:20:33] <pmlopes> hello, good morning

[09:21:09] <purplefox_> temporal_: it's in the isolation_fixes branch

[09:21:19] <purplefox_> cescoffier: pmlopes morning

[09:21:32] <temporal_> purplefox_ ok

[09:22:21] <cescoffier> purplefox_ temporal_ pmlopes : what about doing a quick status point on IRC around 11:00 Paris time (10:00 Tim's time) ? We need to take a decision on the mysql/postgres stuff, as well as a quick overview of the pending issues. I'm on the hazelcast / openshift issue right now.

[09:24:15] <pmlopes> cescoffier: good for me

[09:24:39] <temporal_> ok

[09:39:11] <purplefox_> cescoffier: yes, good idea, let's do that

[09:43:03] <purplefox_> temporal_: i've updated the docs and more tests (pushed to that branch)

[09:44:46] <temporal_> so there are two way to trigger child first: either uses setIsolatedClasses or use extraClassPath , right ?

[09:47:30] <purplefox_> no, extraclasspath doesn't do child first

[09:47:40] <temporal_> ok

[09:47:49] <purplefox_> the only time child first is used, if if the class matches one of the isolated classes matches

[09:47:57] <purplefox_> so it's very explicit now

[09:47:58] <temporal_> event if specified in the setIsolatedClasses ?

[09:49:17] <temporal_> ok I see an existing comment test for extra classpath, it checks urls but does not check classloading

[09:49:36] <temporal_> I will first add at least add a test that check a class not in the current CL is loaded via the mechanism

[09:51:36] <purplefox_> +1

[10:05:35] <pmlopes> purplefox_ temporal_ cescoffier: can i help in any open release related task?

[10:07:16] <purplefox_> pmlopes: temporal_ there's one that's currently assigned to julien on waffle

[10:07:44] <purplefox_> ah maybe this is one we're currently fixing ;) https://github.com/vert-x3/vertx-dropwizard-metrics/issues/2

[10:08:05] <cescoffier> as redeploy has been removed, we need to update the documentation

[10:08:16] <cescoffier> the core documentation has a section on it

[10:08:34] <purplefox_> pmlopes: cescoffier: ok so I don't think there are oustanding tasks as such - what would be useful would be perhaps to go through and check the documentation, and make sure all the examples work, and check the website

[10:08:46] <purplefox_> cescoffier: yes, I've removed that in our wip branch

[10:09:00] <pmlopes> ok, i'll start checking the website

[10:09:14] <cescoffier> I've checked all links from the different manuals

[10:09:19] <cescoffier> so mainly examples

[10:12:19] <temporal_> this https://github.com/vert-x3/vertx-dropwizard-metrics/issues/2 should be fixed automagically with the current work

[10:17:52] <purplefox_> temporal_: how are you creating classes which aren't on the main test classpath for testing?

[10:17:56] <temporal_> yes

[10:18:04] <temporal_> ah

[10:18:08] <temporal_> using the CompilingClassLoader

[10:18:20] <temporal_> I do a verticle

[10:18:30] <temporal_> and then I try to load this verticle in another verticle

[10:18:41] <temporal_> using the bytes of the first verticle in extra classpath

[10:18:56] <temporal_> actually I'm getting a test failure

[10:20:40] <temporal_> I think there might be a small bug

[10:20:45] <temporal_> in the IsolatingClassLoader

[10:20:48] <purplefox_> if you can share the part that creates the class not on the classpath, i can use that to write some more tests

[10:21:29] <temporal_> one sec

[10:21:35] <temporal_> I am almost done with test and fix

[10:21:40] <temporal_> I can push and then you iterate on it :-)

[10:21:50] <temporal_> it should take me a couple of mins

[10:25:18] <temporal_> it's pushed

[10:25:34] <temporal_> https://github.com/eclipse/vert.x/commit/25915fc9e34becbf2479d7572466641813c6e6b4

[10:26:18] <temporal_> so I think you can encapsultate this part in a test method

[10:26:47] <temporal_> I did the simplest and faster compilation (so a verticle), later we can improve this and make somehting better

[10:28:13] <temporal_> purplefox_ there is a change in the IsolatingClassLoader to make the test loading work

[10:28:24] <purplefox_> ok

[10:30:51] <purplefox_> is it pushed?

[10:31:23] <temporal_> yes

[10:31:29] <temporal_> in the branch

[10:44:36] <temporal_> purplefox_ I've added a test that check the case when the loaded class is already in the parent loader

[10:45:03] <temporal_> and I pushed it

[10:50:57] <purplefox_> cescoffier: temporal_ pmlopes can we postpone the meeting a bit, i think we will need another 30 mins to finish this

[10:51:10] <pmlopes> sure

[10:51:10] <purplefox_> (classloader stuff)

[10:51:56] <purplefox_> temporal_: could you check that this solves the groovy and metrics issues and works with the maven service factory while I am completing tests?

[10:52:04] <temporal_> yes

[10:52:22] <temporal_> otherwise it would be extra (classpth) fun

[10:52:38] <cescoffier> purplefox_ no problem

[10:52:51] <purplefox_> lol

[10:53:10] <temporal_> so actually

[10:53:19] <temporal_> both tests use setRedeploy(true)

[10:53:21] <temporal_> and this is removed

[10:53:27] <temporal_> so I believe issues are fixed :-)

[10:53:36] <temporal_> [ERROR] /Users/julien/java/vertx-lang-groovy/src/test/java/io/vertx/lang/groovy/DeploymentTest.java:[319,64] cannot find symbol

[10:53:37] <temporal_> symbol: method setRedeploy(boolean)

[11:23:04] <purplefox_> temporal_: cescoffier pmlopes PR is here https://github.com/eclipse/vert.x/pull/1086

[11:23:14] <purplefox_> I squashed all the commits

[11:25:38] <purplefox_> cescoffier: pmlopes temporal_ ok shall we have a meeting now

[11:25:48] <cescoffier> purplefox_: yes

[11:26:01] <temporal_> ok

[11:26:20] <pmlopes> ok

[11:26:45] <purplefox_> is there a meeting url?

[11:27:31] <cescoffier> it was planned for IRC

[11:27:35] <cescoffier> do you want BJ ?

[11:27:43] <purplefox_> ah no, irc is fine

[11:27:54] <cescoffier> it's just a quick status

[11:27:56] <purplefox_> just assumed it was bj but it's not necessary

[11:28:05] <purplefox_> ok cool

[11:28:19] <cescoffier> so, the redeploy - probably fixed (looking at your PR)

[11:28:25] <purplefox_> well…

[11:28:31] <purplefox_> it's not fixed, it's been removed

[11:28:38] <purplefox_> as it was inherently broken

[11:28:51] <cescoffier> well, fixed in the sense it does not block the release ;-)

[11:29:03] <purplefox_> ok, in that sense, true ;)

[11:29:21] <cescoffier> So that discar https://github.com/eclipse/vert.x/pull/1085 ?

[11:29:25] <cescoffier> discards

[11:29:44] <purplefox_> yep

[11:29:48] <purplefox_> i've just closed it

[11:29:57] <cescoffier> About https://github.com/vert-x3/vertx-unit/issues/9 (Asserts have reversed parameter order compared to Junit)

[11:30:08] <cescoffier> temporal_ has mentionned the reason why it's like that

[11:30:25] <purplefox_> right

[11:30:40] <purplefox_> it's unfortunate but i don't know how else we can do it becoz of codegen

[11:31:17] <cescoffier> yes, nothing we can really do, except providing a completely different API (so people won't be confused as it's really different)

[11:31:48] <pmlopes> just wondering, should we make the unit polyglot? for example i don't see ppl using javascript testing with it where there are “better” async frameworks for js

[11:32:33] <temporal_> if we don't provide a polyglot testing, then I think we should support testing with existing solution per language

[11:32:33] <cescoffier> pmlopes: you mean something like qunit, jasomine or karma ?

[11:32:47] <pmlopes> also for groovy (and java) one can use spock, should we really invest on making unit polyglot and have these limitations?

[11:32:53] <temporal_> and we lose the unified api

[11:33:21] <cescoffier> one does not avoid the other, if people want to use spock or karma, they can

[11:33:37] <purplefox_> what is existing solution for Java?

[11:33:40] <pmlopes> cescoffier, for example internjs is far more easy to use and with nice API

[11:33:47] <cescoffier> (if they are able to configure them of course ;-))

[11:33:53] <temporal_> I think what we should document and provide is how to use vertx-unit internals to integrate and make async tests like it is done for junit

[11:34:23] <temporal_> this morning I added a junit runner for groovy btw

[11:34:27] <temporal_> https://github.com/vert-x3/vertx-unit/issues/6#issuecomment-114417967

[11:34:32] <temporal_> it was not a big deal

[11:34:33] <pmlopes> yes document it is a good point

[11:34:37] <temporal_> and asked by Arnaud

[11:35:00] <purplefox_> ok, this is all good discussion but we're not going to make major changes in vertx-unit before the 3.0 release

[11:35:11] <purplefox_> so this should be deferred until after

[11:35:12] <temporal_> nope :-)

[11:35:16] <cescoffier> is this blocking the release or can it wait after the release

[11:35:19] <pmlopes> no, we know :)

[11:35:26] <cescoffier> ok, so, great

[11:35:30] <purplefox_> it's not blocking

[11:35:43] <cescoffier> so, hazelcast and openshift, it's fixed

[11:35:45] <temporal_> I think we can at least add a Spock integration like I did for JUnit after 3.0 :-)

[11:36:17] <pmlopes> spock does not need anything special

[11:36:45] <cescoffier> so next issue is https://github.com/vert-x3/vertx-dropwizard-metrics/issues/2 2 metricsService.getMetricsSnapshot(vertx) return null when redeploy is enabled.

[11:36:57] <cescoffier> it is also discarded right ?

[11:36:59] <temporal_> this should be fixed

[11:37:00] <temporal_> yes

[11:37:06] <temporal_> because anyway setRedeploy does not exist anymore

[11:37:11] <temporal_> so the test would not even compile

[11:37:27] <purplefox_> is the code updated to now use setRedeploy?

[11:37:31] <purplefox_> s/now/not

[11:37:44] <temporal_> what is using setRedeploy are tests

[11:37:55] <temporal_> this is a test provided by a user that use setRedeploy

[11:37:59] <purplefox_> we need to remove anything that does setRedeploy in any other repos

[11:38:03] <temporal_> yes

[11:38:06] <temporal_> there is one in Groovy

[11:38:06] <pmlopes> here a spec example: https://gist.github.com/pmlopes/459d4205acf89173dca4

[11:38:09] <temporal_> I can push it

[11:38:14] <temporal_> after we merge vertx core

[11:38:30] <cescoffier> once vertx core is merged, it gonna trigger all the build

[11:38:37] <cescoffier> so, we would detect such issues

[11:38:59] <cescoffier> however that means we need to wait until all builds have successfully completed

[11:39:09] <purplefox_> well, we can fix any we know about now

[11:39:16] <pmlopes> in regards to the async mysql-psql this post is making me doubt if it is ready for production: https://groups.google.com/forum/#!topic/vertx/81XVzno5xTs

[11:39:19] <purplefox_> then as soon as we push core, they will triggeer again and pass

[11:39:34] <pmlopes> the issue there is that both jdbc and asyncsql do not have the same behavior

[11:39:46] <temporal_> so I do have pending commits for vertx-lang-groovy that removes the workaround + redeploy unit test

[11:40:03] <temporal_> I'll push them when core is up to date

[11:40:23] <purplefox_> pmlopes: do you mean the mysql/postgres client?

[11:40:57] <pmlopes> yes

[11:41:19] <purplefox_> right, we're going to drop that anyway

[11:41:23] <cescoffier> well, we still didn't fix the synchronization issue

[11:41:32] <purplefox_> exactly

[11:41:39] <cescoffier> I looked at the scala code yesterday, won't be that easy

[11:41:58] <cescoffier> so, I'm in favor to remove it from the release and from the stack

[11:42:34] <cescoffier> one thing is that during the rewriting we may introduce some API changes, that will be tricky to handle in a compatible way

[11:42:54] <purplefox_> agreed we remove it

[11:42:58] <pmlopes> in that case lets remove it

[11:42:59] <purplefox_> we also need to remove jgroups cluster manager

[11:43:09] <purplefox_> but these can be on the vertx-awesome page

[11:43:23] <cescoffier> so, that means updating the stack distrib, mark it as 'experimental' on the web site, remove it from Julien's release script, update all example to copy the client locally

[11:43:33] <cescoffier> and add it to the vertx-awesome page

[11:44:21] <purplefox_> i'm thinking we should probably remove all the experimental from the documentation page

[11:44:44] <purplefox_> because that page contains the official, production ready stuf

[11:44:53] <temporal_> how about doing a vertx_3_1 doc page instead ?

[11:45:04] <temporal_> that contains the doc of the future components of 3.1

[11:45:46] <cescoffier> yes, we will need something like that anyway

[11:45:46] <purplefox_> we don't know what's going to be in 3.1 yet

[11:45:59] <temporal_> call it 3_x :-)

[11:46:21] <purplefox_> not sure i understand.. isn't that the roadmap?

[11:46:30] <temporal_> I'm kidding, never mind

[11:46:45] <purplefox_> ah, joke. ;)

[11:46:46] <cescoffier> we will need a way to publish “dev/snapshot” doc

[11:46:58] <cescoffier> but this can be handle once the release is doe

[11:47:11] <cescoffier> done

[11:47:31] <temporal_> perhaps we can branch also the website

[11:47:33] <purplefox_> so.. next steps - please review the PR for the isolation changes

[11:47:38] <temporal_> keep it in the master

[11:47:41] <temporal_> and clean the branch

[11:47:46] <purplefox_> we need to get that in asap

[11:48:04] <cescoffier> yep, then remove all reference to redeploy

[11:48:06] <purplefox_> we can do that in parallel

[11:48:12] <temporal_> purplefox_ in this PR I saw you removed a test I added after my first test

[11:48:16] <temporal_> is that on purpose ?

[11:48:18] <purplefox_> which test

[11:48:23] <cescoffier> remove the MYSQL / Posgres from the distribution, and related actions

[11:48:58] <temporal_> I added another test that check that even if the class is specified in the extraCP but loaded alrady by thge parent then it will remain laoded by parent

[11:49:05] <temporal_> I can add it again to the branch

[11:50:09] <purplefox_> i didn't deliberately delete anythinfg

[11:50:48] <temporal_> ok

[11:50:50] <temporal_> I will add it

[11:50:59] <temporal_> it's sitting on in my local repo

[11:50:59] <pmlopes> I was walking the website and there are a few broken links and several references to “Apex” this is a tricky task to fix since it needs to verify all reppos to fix it…

[11:51:22] <purplefox_> do you have some pointers?

[11:51:47] <cescoffier> crap forgot about checking Apex

[11:51:49] <pmlopes> Apex: http://vert-x3.github.io/docs/vertx-core/java/

[11:52:05] <pmlopes> broken links: http://vert-x3.github.io/docs/vertx-core/groovy/todo

[11:52:12] <pmlopes> http://vert-x3.github.io/docs/vertx-core/ruby/unavailable

[11:52:22] <pmlopes> http://vert-x3.github.io/docs/vertx-auth-common/groovy/groovydoc/io/vertx/groovy/ext/auth/User.html

[11:52:46] <pmlopes> etc…

[11:53:15] <pmlopes> and then some strange ones: http://vert-x3.github.io/docs/apidocs/io/vertx/core/spi/logging/kenny.macleod at kizoom dot com

[11:53:26] <pmlopes> i guess someone forgot a mailto: prefix

[11:54:15] <purplefox_> ok

[11:54:38] <cescoffier> I'm generating a report with the broken links

[11:55:06] <pmlopes> i am running wget in spider mode and grepping the 404

[11:56:05] <cescoffier> ok, let's dispath the tasks

[11:56:30] <cescoffier> I manage the mysql / postgres client removal

[11:56:41] <cescoffier> temporal_: you manager the redeploy PR ?

[11:56:53] <temporal_> cescoffier I'm adding a missing test

[11:56:56] <temporal_> and then I'll merge it

[11:56:58] <temporal_> after review

[11:57:00] <cescoffier> ok

[11:57:03] <purplefox_> ok

[11:57:19] <purplefox_> i'll start writing a release announcement

[11:57:35] <purplefox_> after merging the PR we need to check all examples

[11:57:46] <purplefox_> and also manually check command line vertx distro

[11:57:52] <purplefox_> i.e. vertx run -ha etc

[11:58:07] <pmlopes> I'll trace the broken links and update where broken

[11:58:25] <pmlopes> I'll try to find all Apex and replace

[11:59:39] <cescoffier> ok, are we good to go ?

[11:59:59] <purplefox_> i think so

[12:00:11] <pmlopes> me too

[12:00:13] <cescoffier> pmlopes: I've 499 broken links

[12:00:19] <pmlopes> lol

[12:00:19] <purplefox_> 499 !?

[12:00:42] <pmlopes> that's going to be a interesting day :)

[12:01:12] <purplefox_> are these manually created links or ones created by docgen

[12:01:13] <cescoffier> purplefox_: yes but this is not only 404, also badly formed url (often in javadoc)

[12:01:22] <cescoffier> and request time out

[12:01:42] <cescoffier> (connection was lost tfox.org ;-))

[12:01:48] <purplefox_> lol

[12:02:05] <purplefox_> weird works for me

[12:02:19] <purplefox_> maybe the spider was sending so many concurrent requests they timed out

[12:02:25] <purplefox_> because it's in my author tag in many places

[12:03:01] <purplefox_> you could probably just remove those ones from the report

[12:03:08] <cescoffier> hum the groovy doc contains lots of broken links because . are not replace by /

[12:03:35] <cescoffier> might be a bug no (temporalfox_)

[12:03:35] <cescoffier> For instance http://vert-x3.github.io/docs/vertx-unit/groovy/groovydoc/io.vertx.ext.unit.TestSuite.html

[12:04:44] <cescoffier> The “TestSuite” in the properties section is broken

[12:05:01] <temporal_> we can try to fix that

[12:05:24] <cescoffier> gonna be a long day ;-)

[12:06:57] <purplefox_> ok let's see what we can fix in an hour

[12:07:07] <purplefox_> but it's not the end of the world to release with some broken links

[12:07:28] <purplefox_> in api docs

[12:07:44] <purplefox_> as long as there are no obvious broken links in high profile places like the home page and docs page

[12:08:07] <cescoffier> I agree

[12:08:11] <temporal_> api docs is sometimes tricky

[12:08:16] <temporal_> because we have to reparse the content

[12:08:28] <cescoffier> so purplefox_ you confirm the removal of experimental modules from the web site ?

[12:08:59] <purplefox_> yes I think we should do this

[12:09:12] <cescoffier> ok, I will do it

[12:09:16] <purplefox_> otherwise I think people will be confused about whether they should use this stuff in production or not

[12:09:28] <cescoffier> I definitely agree, just needed a confirmation

[12:09:45] <cescoffier> Gonna create a couple of issues to track everything

[12:10:01] <purplefox_> we should probably put a note on the documentation page saying “this stuff is all production ready and part of the distros, but take a look at the vertx-awesome page for more stuff”

[12:10:26] <purplefox_> one thing we also need is some kind of explanation on what the distros are - full, min, web etc

[12:12:40] <cescoffier> yes

[12:15:23] <cescoffier> ok, grabing some food to be full speed (as well as half a liter of coffee)

[12:26:55] <temporal_> vertx-core has been merged, I'll take care of groovy update now

[13:01:27] <purplefox_> temporal_: once we're ready to do the actual release, how long does the process take?

[13:01:34] <purplefox_> to actually push everything

[13:01:50] <cescoffier> temporal_ has made a script

[13:14:48] <pmlopes> purplefox_ can i have push rights to vertx-lang-ruby i need to push a commit to remove the Apex reference

[13:15:18] <purplefox_> done

[13:16:20] <temporal_> purplefox_ the thing that takes time when doing a release is the file upload

[13:16:35] <temporal_> purplefox_ I'll probably use my cellphone 4h connection that is much faster than my DSL

[13:16:52] <purplefox_> approx how long does it take?

[13:17:12] <temporal_> I would say 1 hour to push on nexus maybe less

[13:17:26] <temporal_> I still have 2,36 gig of my cellphone

[13:17:32] <temporal_> so I can use this

[13:18:10] <temporal_> then it's in nexus and we should validate what is there with a staging repo :-)

[13:19:23] <purplefox_> now we have multiple distros it will take even longer to upload to bintray too

[13:20:34] <purplefox_> and we should take into account how long for maven to sync

[13:21:12] <purplefox_> i think the website switchover will be pretty instant as the dns is already pointing at github so we just change the CNAME on the repo

[13:22:24] <purplefox_> temporal_: maybe others can help with bintray upload once the release is pushed to maven

[13:22:33] <purplefox_> my connection is pretty slow too though

[13:22:44] <purplefox_> about 11 Mib/s

[13:24:22] <temporal_> I think that bintray can download the dep from maven central

[13:24:26] <temporal_> if we give ti the URL

[13:24:37] <temporal_> and anyway we need to wait for the central sync

[13:24:56] <temporal_> (we release on central the dists since they are built via maven)

[13:31:55] <purplefox_> we push the distros to maven as artifacts too?

[13:32:17] <purplefox_> in the past we didn't do this and I just uploaded them manually to bintray

[13:35:19] <temporal_> they are build by the assembly plugin

[13:35:30] <temporal_> so they are attached to the vertx-stack when deploying/installing

[13:35:40] <temporal_> we can change and make attach=false

[13:39:21] <temporal_> purplefox_ the maven-service-factory has a test failing now, the test that use a Guava dependency from the deployed service

[13:39:46] <temporal_> before guava was loaded by the IsolatingClassLoader

[13:40:11] <temporal_> now it is loaded by the URLClassLoader created by the MavenServiceFactory

[13:41:54] <temporal_> that is parent of the IsolatingClassLoader

[13:42:08] <temporal_> so I think it's fine

[13:42:26] <temporal_> the test should be corrected, as it fails testing that the Guava class has the same loader than the Verticle

[13:42:43] <purplefox_> ok

[13:43:06] <purplefox_> that means Guava must be on the Vert.x classpath, is that right?

[13:43:11] <temporal_> no

[13:43:25] <temporal_> it is loaded by an intermediary URLCL created by MavenServiceFactory

[13:43:28] <temporal_> set on the DeploymentOptions

[13:43:48] <cescoffier> pmlopes: you are on Some official components missing #5 ?

[13:44:29] <purplefox_> tekmaster: i don't understand why it creates another classloader

[13:44:30] <pmlopes> yes i was looking at it, i am going through the projects we have on vert-x3 org and check which ones are missing

[13:44:38] <temporal_> I think we generate this in order to have the parent ServiceFactory to find the service descriptor

[13:44:50] <temporal_> I agree with you it should not be needed

[13:45:04] <temporal_> perahps we don't set it on deployment options

[13:45:40] <temporal_> I'm saying rubish things

[13:45:44] <temporal_> actually I don't understand now how ti URLClassLoader becomes parent of the IsolatingCL

[13:45:48] <temporal_> I will recheck

[13:46:19] <purplefox_> well you changed all the resolve code some time back ;)

[13:46:29] <purplefox_> but the idea is with resolve is you can change the deploymentOptions

[13:46:30] <temporal_> I made it async :-)

[13:47:05] <purplefox_> so you should just be able to add the extra cp

[13:47:08] <purplefox_> then let resolve complete

[13:47:17] <temporal_> ah actually never mind

[13:47:23] <purplefox_> then the deployement manager will lookup the verticle factory again

[13:47:23] <temporal_> it's the test that set a similar classloader

[13:47:28] <temporal_> as Thread context classloader

[13:47:30] <purplefox_> based on the new deployemnt options

[13:47:34] <temporal_> that's why it's used from theere

[13:47:56] <temporal_> and as you said it's a test that reproduces if the class is already loaded by Vert.x main

[13:48:06] <temporal_> so this is fine

[13:48:31] <purplefox_> not sure I follow

[13:48:40] <purplefox_> I can see an extra CL in MavenVerticleFactory

[13:48:45] <purplefox_> which is not a test

[13:48:53] <temporal_> yes but it is only used by the service factory to find the dscriptor

[13:49:03] <temporal_> not used for classloading purpose

[13:49:20] <temporal_> and the test I'm changing set a similar URLClassLoader as TCCL

[13:49:27] <temporal_> so it's expected to be loaded from there

[13:49:31] <temporal_> and not from the IsolatingCL

[13:49:46] <purplefox_> ok, i won't try and understand it for now, but I trust your judgement on this :)

[14:11:13] <temporal_> I'm done with propagating the classloading changes in groovy and maven-service-factory

[14:12:03] <temporal_> should I proceed to the release ?

[14:22:42] <temporal_> purplefox_ about mysql+postgres should we release it even if it's not in the stack ?

[14:23:45] <purplefox_> hmmm, good question

[14:23:59] <purplefox_> probably not as if people see it has the same version number they might assume it's part of the main release

[14:25:53] <temporal_> ok

[14:28:16] <cescoffier> deploying the web site with the changes (removed mysql and experimental modules, add distros description, mention vert.x awesome)

[14:30:01] <pmlopes> i've added all missing projects to awesome

[14:42:01] <temporal_> so shall we go :) ?

[14:43:15] <cescoffier> should examples be fixed before ?

[14:43:19] <purplefox_> ok, announcement messages is written

[14:43:37] <cescoffier> what about https://github.com/vert-x3/vertx-http-service-factory/issues/4

[14:43:59] <temporal_> it's fixed

[14:44:01] <purplefox_> ok so let's have a quick recap of where we are

[14:44:03] <temporal_> I just closed it

[14:44:04] <cescoffier> https://github.com/vert-x3/vertx-dropwizard-metrics/issues/2 need to be explicitly closed

[14:44:19] <temporal_> closed

[14:44:35] <cescoffier> we have the reference to 'redeploy'

[14:44:53] <cescoffier> running a full compilation right now

[14:45:09] <cescoffier> (src + test)

[14:45:18] <purplefox_> we need to trigger everything on ci to make sure there is a clean run

[14:45:29] <purplefox_> i can see some components haven't been built for some time

[14:45:56] <cescoffier> yep

[14:45:58] <temporal_> ok

[14:48:32] <purplefox_> have we tested all examples?

[14:49:40] <cescoffier> not yet

[14:49:44] <cescoffier> some don't even compile

[14:50:29] <cescoffier> to try them, make sure you use the update to date stack

[14:50:54] <purplefox_> they compile for me using mvn clean install

[14:51:10] <purplefox_> ah you mean command line?

[14:51:26] <purplefox_> ok, if you test on command line i will test in IDE

[14:51:26] <cescoffier> yep vertx run …..

[14:51:31] <cescoffier> ok

[14:51:37] <purplefox_> brb

[14:51:42] <cescoffier> (someone magically fix the compilation issue ;-))

[15:14:45] <pmlopes> all built, blue!!!

[15:15:07] <cescoffier> Yeah !

[15:15:20] <cescoffier> checking web from the command line, then ruby

[15:23:40] <purplefox_> temporal_: just running you metrics dashboard for the first time, it's actually pretty cool :)

[15:23:49] <temporal_> isn't it ?

[15:24:04] <temporal_> we should add more vertx-web inside

[15:24:06] <temporal_> like securing it

[15:24:41] <purplefox_> it's more fun than most examples as it has a graphical aspect to it

[15:24:55] <purplefox_> no readme thought! tut tut ;)

[15:25:01] <purplefox_> s/thought/though

[15:25:24] <temporal_> ah ok

[15:25:27] <temporal_> hyou are on the old version

[15:25:34] <temporal_> I mean not old

[15:25:40] <temporal_> but a copy of the actual one

[15:25:44] <temporal_> that is more complex

[15:26:00] <temporal_> https://github.com/vietj/vertx-reactive-dashboard

[15:26:32] <temporal_> I forgot I copied it in the examples

[15:26:37] <temporal_> or perhaps I did that one first

[15:28:51] <purplefox_> temporal_: pmlopes: cescoffier: we should do a quick test on windows too before release, just to make sure a few examples work

[15:29:01] <purplefox_> does anyone have a windows install handy?

[15:29:12] <temporal_> I don't

[15:29:43] <pmlopes> nope…

[15:30:32] <cescoffier> the web examples are kind of hard to launch from the command line

[15:30:38] <cescoffier> the webroot makes things a bit complicated

[15:30:52] <cescoffier> (well I think it's the issue)

[15:32:40] <cescoffier> yes it is the issue

[15:32:59] <cescoffier> they need to be launched from the right directory with command like these:

[15:33:00] <cescoffier> vertx run io.vertx.example.web.angular_realtime.Server -cp ../../../../../../../../target/web-examples-3.0.0-SNAPSHOT.jar:.

[15:33:02] <purplefox_> hmm, they should work, what's the problem?

[15:33:24] <temporal_> clement

[15:33:29] <temporal_> you need to cd in the directory

[15:33:38] <temporal_> cd src/main/js/…../package

[15:33:43] <cescoffier> yes, but then the -cp is funny

[15:34:04] <temporal_> some examples cannot run indeed

[15:34:06] <temporal_> when they rely on CP

[15:34:18] <temporal_> we fixed some, the auth ones

[15:34:31] <temporal_> the one for Shiro that uses the properties file cannot really be fixed

[15:34:42] <purplefox_> are you referring to java examples?

[15:35:44] <cescoffier> some example are not polyglot (angular_realtime)

[15:35:52] <cescoffier> java.lang.RuntimeException: java.lang.NoSuchMethodException: Can't unambiguously select between fixed arity signatures [(java.util.Map), (java.lang.String)] of the method io.vertx.core.json.JsonObject.<init> for argument types [jdk.nashorn.internal.runtime.Undefined]

[15:36:01] <purplefox_> which example exactly is this?

[15:36:04] <cescoffier> nothing blocker, just something we need to improve

[15:36:08] <cescoffier> web / angular realtime

[15:36:09] <purplefox_> (which lang)

[15:36:09] <temporal_> yes some may have problems

[15:36:13] <cescoffier> js

[15:36:30] <cescoffier> in java it works, just need to be launched in the right directory with then a really long -cp

[15:36:55] <purplefox_> hmmm

[15:37:11] <purplefox_> i don't understand why it needs a cp

[15:37:17] <purplefox_> it's just a single java file

[15:37:49] <cescoffier> yes, the cp is not mandatory, you can directly launch from the .java file

[15:37:52] <cescoffier> just testing both

[15:37:58] <temporal_> which one is failing ?

[15:38:08] <cescoffier> angular_realtime in js

[15:38:10] <purplefox_> ah you're trying to run it using the class file from the command line?

[15:38:26] <cescoffier> yes, I've run all example from the command line

[15:38:32] <temporal_> I can't run angular_realtime by default

[15:38:37] <temporal_> because it needs the properties file

[15:38:38] <purplefox_> ah ok, but from the command line the expectation is to run the .java file

[15:38:48] <temporal_> No server chosen by PrimaryServerSelector from cluster description ClusterDescription{type=UNKNOWN, connectionMode=SINGLE, all=[ServerDescription{address=127.0.0.1:27017, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoInternalException: Opening the AsynchronousSocketChannelStream failed}, caused by {com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection

[15:38:48] <temporal_> refused}}]}. Waiting for 30000 ms before timing out

[15:38:49] <temporal_> Failed in deploying verticle

[15:38:49] <temporal_> org.apache.shiro.ShiroException: Error reading properties path [classpath:vertx-users.properties]. Initializing of the realm from this file failed.

[15:38:49] <temporal_> at org.apache.shiro.realm.text.PropertiesRealm.loadProperties(PropertiesRealm.java:246)

[15:38:49] <temporal_> at org.apache.shiro.realm.text.PropertiesRealm.loadProperties(PropertiesRealm.java:214)

[15:38:50] <purplefox_> it's much simpler

[15:38:55] <temporal_> (sorry for flooding :-) )

[15:38:59] <cescoffier> temporal_ no it just need mongo

[15:39:03] <temporal_> yes that too

[15:39:14] <cescoffier> in my case I run mongo in the docker, and update the example to use the right connection_string

[15:39:23] <temporal_> how do you run mongo with docker ?

[15:39:29] <cescoffier> docker run –name some-mongo -d -p 27017:27017 mongo

[15:39:34] <temporal_> thanks

[15:39:39] <temporal_> I will copy/paste that somewhere

[15:39:48] <cescoffier> then in the verticle

[15:39:49] <cescoffier> mongo = MongoClient.createShared(vertx, new JsonObject()

[15:39:50] <cescoffier> .put(“db_name”, “demo”)

[15:39:50] <cescoffier> .put(“connection_string”, “mongodb:192.168.59.103:27017”)); [15:40:14] <cescoffier> and obviously this fail in JS [15:40:20] <cescoffier> because of string:string [15:40:38] <temporal_> how is it code translated ? [15:40:58] <cescoffier> mongo = MongoClient.createShared(vertx, { [15:40:58] <cescoffier> “db_name” : “demo”, [15:40:58] <cescoffier> “connection_string” : “mongodb:192.168.59.103:27017”

[15:40:58] <cescoffier> });

[15:41:01] <cescoffier> should work

[15:41:05] <temporal_> mongo = MongoClient.createShared(vertx, {

[15:41:06] <temporal_> “db_name” : “demo”

[15:41:06] <temporal_> });

[15:41:11] <temporal_> I think it's a codetranslation bug

[15:41:15] <temporal_> in chaining

[15:41:29] <temporal_> I will try to fix it

[15:41:32] <temporal_> now

[15:42:36] <cescoffier> temporal_ the issue I have in this verticle is somewhere else

[15:42:42] <temporal_> ok

[15:42:42] <cescoffier> something with the forEach

[15:43:01] <temporal_> on my side I don't have the same JS than you

[15:43:15] <cescoffier> yes, I modified the java code

[15:43:22] <cescoffier> to get my connection_string parameter

[15:43:35] <cescoffier> (to connect to the mongo instance running in docker)

[15:43:43] <temporal_> so code translation is wrong right ?

[15:43:57] <temporal_> ah ok

[15:44:00] <temporal_> got it

[15:44:06] <temporal_> no localhost

[15:44:11] <cescoffier> Caused by: java.lang.NoSuchMethodException: Can't unambiguously select between fixed arity signatures [(java.util.Map), (java.lang.String)] of the method io.vertx.core.json.JsonObject.<init> for argument types [jdk.nashorn.internal.runtime.Undefined]

[15:44:20] <cescoffier> on:

[15:44:20] <cescoffier> Array.prototype.forEach.call(albums, function(album) {

[15:44:21] <cescoffier> db.insert(“albums”, album, function (res, res_err) {

[15:44:22] <cescoffier> console.log(“inserted ” + JSON.stringify(album));

[15:44:22] <cescoffier> });

[15:44:24] <cescoffier> });

[15:44:35] <temporal_> what line does it bug at ?

[15:45:25] <temporal_> I think this must fail in a codegenerated js file

[15:45:42] <temporal_> can you give a larger stack trace ?

[15:47:17] <cescoffier> Here is the whole ST:

[15:47:18] <cescoffier> Unhandled exception

[15:47:18] <cescoffier> java.lang.RuntimeException: java.lang.NoSuchMethodException: Can't unambiguously select between fixed arity signatures [(java.util.Map), (java.lang.String)] of the method io.vertx.core.json.JsonObject.<init> for argument types [jdk.nashorn.internal.runtime.Undefined]

[15:47:20] <cescoffier> at jdk.nashorn.internal.runtime.arrays.IteratorAction.apply(IteratorAction.java:116)

[15:47:20] <cescoffier> at jdk.nashorn.internal.objects.NativeArray.forEach(NativeArray.java:1607)

[15:47:22] <cescoffier> at jdk.nashorn.internal.scripts.Script$Recompilation$182$1566AA$\^eval\_#88\!17\^eval\_.L:1$loadData$L:47(server.js:83)

[15:47:22] <cescoffier> at jdk.nashorn.internal.scripts.Script$Recompilation$176$19479A$\^eval\_#88\!17\^eval\_.L:1$MongoClient$dropCollection$L:471(vertx-mongo-js/mongo_client.js:473)

[15:47:24] <cescoffier> at io.vertx.core.Handler$$NashornJavaAdapter.handle(Unknown Source)

[15:47:24] <cescoffier> at io.vertx.ext.mongo.impl.MongoClientImpl.lambda$null$33(MongoClientImpl.java:324)

[15:47:26] <cescoffier> at io.vertx.ext.mongo.impl.MongoClientImpl$$Lambda$12/463812514.handle(Unknown Source)

[15:47:26] <cescoffier> at io.vertx.core.impl.ContextImpl.lambda$wrapTask$3(ContextImpl.java:314)

[15:47:28] <cescoffier> at io.vertx.core.impl.ContextImpl$$Lambda$7/866488267.run(Unknown Source)

[15:47:28] <cescoffier> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:357)

[15:47:30] <cescoffier> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)

[15:47:30] <cescoffier> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)

[15:47:32] <cescoffier> at java.lang.Thread.run(Thread.java:745)

[15:47:32] <cescoffier> Caused by: java.lang.NoSuchMethodException: Can't unambiguously select between fixed arity signatures [(java.util.Map), (java.lang.String)] of the method io.vertx.core.json.JsonObject.<init> for argument types [jdk.nashorn.internal.runtime.Undefined]

[15:47:34] <cescoffier> at jdk.internal.dynalink.beans.OverloadedMethod.throwAmbiguousMethod(OverloadedMethod.java:224)

[15:47:34] <cescoffier> at jdk.nashorn.internal.scripts.Script$Recompilation$171$1099A$\^eval\_#88\!17\^eval\_.L:1$convParamJsonObject(vertx-js/util/utils.js:22)

[15:47:36] <cescoffier> at jdk.nashorn.internal.scripts.Script$Recompilation$185$3584AAA$\^eval\_#88\!17\^eval\_.L:1$MongoClient$insert(vertx-mongo-js/mongo_client.js:96)

[15:47:36] <cescoffier> at jdk.nashorn.internal.scripts.Script$Recompilation$183$2339AJA$\^eval\_#88\!17\^eval\_.L:1$loadData$L:47$L:83(server.js:84)

[15:47:38] <cescoffier> at jdk.nashorn.internal.objects.NativeArray$9.forEach(NativeArray.java:1604)

[15:47:38] <cescoffier> at jdk.nashorn.internal.runtime.arrays.IteratorAction.apply(IteratorAction.java:110)

[15:47:40] <cescoffier> … 12 more

[15:47:40] <temporal_> gist :-)

[15:47:46] <cescoffier> (cloning stack and example on windows)

[15:48:52] <temporal_> so it wants to instantiate JsonObject but does not know which constructor to use

[15:49:08] <temporal_> but I'm not sure certain where this happens

[15:49:11] <temporal_> “it”

[15:49:34] <cescoffier> https://gist.github.com/cescoffier/fabe23ac3f2a0bc1a164

[15:49:52] <temporal_> what is line 83 for you ?

[15:50:04] <temporal_> (since you inserted some code, we don't have the same source map)

[15:50:16] <pmlopes> that js code could be fixed with “var albums = []” and later with albums.forEach(function(album) {…});

[15:50:24] <temporal_> issues seems to be in

[15:50:27] <temporal_> at jdk.nashorn.internal.scripts.Script$Recompilation$171$1099A$\^eval\_#88\!17\^eval\_.L:1$convParamJsonObject(vertx-js/util/utils.js:22)

[15:50:52] <temporal_> yep

[15:50:53] <temporal_> return param != null ? new JsonObject(JSON.stringify(param)) : null;

[15:51:01] <cescoffier> 83 → Array.prototype.forEach.call(albums, function(album) {

[15:51:01] <cescoffier> db.insert(“albums”, album, function (res, res_err) {

[15:51:02] <cescoffier> console.log(“inserted ” + JSON.stringify(album));

[15:51:02] <cescoffier> });

[15:51:14] <cescoffier> });

[15:51:16] <temporal_> yes but the problem is actually in utils.js

[15:51:26] <temporal_> let me patch this with explicit constructor choice

[15:51:52] <temporal_> I think it is because of “null”

[15:52:25] <temporal_> mongo_client.js:96 calls json transformation with null

[15:52:45] <temporal_> well not sure actually :-)

[15:53:36] <temporal_> anyway it should be String constructor to use

[15:54:32] <temporal_> ok

[15:54:39] <temporal_> I read the line fully and we have Undefined

[15:54:41] <temporal_> jdk.nashorn.internal.runtime.Undefined

[15:55:04] <temporal_> so this is server.js at line 84 that calls with undefined

[15:55:47] <temporal_> ok it is a codetrans bug

[15:55:59] <temporal_> function (res, res_err) {

[15:56:00] <temporal_> console.log(“inserted ” + JSON.stringify(album));

[15:56:00] <temporal_> }

[15:56:12] <temporal_> should be album / album_err in params

[15:56:30] <temporal_> ah no

[15:56:32] <temporal_> it's correct

[15:56:38] <temporal_> but this is rather a JS issue

[15:56:53] <temporal_> we refer to album and I think it cannot be anymore referenced from the function

[15:57:01] <temporal_> I'm not a JS expert

[15:57:08] <temporal_> Array.prototype.forEach.call(albums, function(album) {

[15:57:08] <temporal_> db.insert(“albums”, album, function (res, res_err) {

[15:57:08] <temporal_> console.log(“inserted ” + JSON.stringify(album));

[15:57:08] <temporal_> });

[15:57:09] <temporal_> });

[15:57:19] <temporal_> JSON.stringify(album) → album == undefined

[15:57:37] <temporal_> if we tweak the example to use an intermediary var it should work better

[15:59:04] <temporal_> in that case it works better I think

[15:59:05] <temporal_> Array.prototype.forEach.call(albums, function(album) {

[15:59:05] <temporal_> var toto = album;

[15:59:06] <temporal_> db.insert(“albums”, album, function (res, res_err) {

[15:59:06] <temporal_> console.log(“inserted ” + JSON.stringify(toto));

[15:59:06] <temporal_> });

[15:59:06] <temporal_> });

[15:59:15] <temporal_> at least intellij seems more happy

[16:00:25] <temporal_> so instead I would refactor the example

[16:00:29] <temporal_> and make an insert album function

[16:00:41] <temporal_> and call it with the content of the list

[16:00:52] <temporal_> is that fine with you ?

[16:00:54] <cescoffier> same issue with:

[16:00:54] <cescoffier> Array.prototype.forEach.call(albums, function(album) {

[16:00:55] <cescoffier> var json = album;

[16:00:56] <cescoffier> db.insert(“albums”, json, function (res, res_err) {

[16:00:56] <cescoffier> var al = json;

[16:00:58] <cescoffier> console.log(“inserted ” + JSON.stringify(al));

[16:00:58] <cescoffier> });

[16:01:00] <cescoffier> });

[16:01:46] <temporal_> really ?

[16:01:54] <cescoffier> yep

[16:01:59] <temporal_> I'm not JS expert :-)

[16:02:03] <cescoffier> same error with console.log(“inserted ” + JSON.stringify(json));

[16:02:04] <temporal_> why ?

[16:02:08] <cescoffier> something is really weird here

[16:02:16] <cescoffier> ok, well, not blocker

[16:02:17] <temporal_> should these be resolved ?

[16:02:32] <temporal_> I mean I'm not an expert in JS resolution

[16:02:32] <purplefox_> ok folks, i have run examples in the IDE and a few small issues nothing a blocker

[16:02:37] <temporal_> ok

[16:02:44] <purplefox_> what about you guys, just this JS issue?

[16:06:08] <cescoffier> a typo in a README file

[16:06:16] <cescoffier> running some examples on windows right now

[16:09:02] <cescoffier> won't be able to test the clustering on windows

[16:13:11] <cescoffier> ok, I've made basic tests on windows

[16:13:15] <cescoffier> it seems to works

[16:13:39] <purplefox_> cool

[16:14:07] <purplefox_> btw, the column formatting on the website community page has gone wrong after after the vertx-awesome was added

[16:14:41] <purplefox_> http://vert-x3.github.io/community/

[16:15:26] <purplefox_> not sure how to fix that, who's a bootstrap expert?

[16:15:43] <purplefox_> it needs a column offset i guess

[16:16:00] <cescoffier> let me check

[16:16:18] <cescoffier> (just ran a ruby example on windows, it's…. slow, but works)

[16:16:36] <temporal_> cescoffier it's because you don't let the JIT optimize :-)

[16:16:49] <cescoffier> :-)

[16:16:54] <cescoffier> purplefox_ : gonna fix the web site

[16:18:28] <purplefox_> cescoffier: also i don't think we should add the info on the distributions on the beginning of the docs there

[16:18:37] <purplefox_> tbh most users probably won't use distributions at all

[16:18:55] <cescoffier> right now it's in the explore section

[16:19:05] <purplefox_> yes

[16:21:15] <purplefox_> maybe we can just put this info on bintray

[16:21:53] <purplefox_> also the full distribution doesn't contain everything in the stack (e.g. jca)

[16:22:50] <pmlopes> web examples are fixed

[16:22:56] <purplefox_> great

[16:23:55] <purplefox_> cescoffier: i'm thinking we should probably move the information on distros to the vertx-examples main README - as that's where the installation process is currently documented

[16:24:08] <cescoffier> ok

[16:24:10] <cescoffier> we can do that

[16:30:16] <cescoffier> uploading the web site with the fixed column

[16:30:23] <cescoffier> Working on the distros

[16:30:35] <cescoffier> so, we remove the text from the web site ?

[16:32:37] <purplefox_> yes I think so, and just copy it into the main examples README in the section that talks about installing a distro

[16:35:34] <cescoffier> well need some edits ;-)

[16:36:06] <cescoffier> http://vert-x3.github.io/community/

[16:36:13] <cescoffier> pmlopes: can you try this page with your windows phone ?

[16:38:04] <pmlopes> just a sec

[16:39:35] <pmlopes> works fine

[16:42:38] <temporal_> how about I start the release soon if no one objects ?

[16:48:34] <purplefox_> temporal_: pmlopes ok are we all set?

[16:48:50] <temporal_> I hope so

[16:49:11] <purplefox_> ok let's have one last check

[16:49:26] <cescoffier> purplefox_ temporal_ pmlopes : Done

[16:49:53] <purplefox_> ok cool, so just to check:

[16:49:58] <purplefox_> all examples more or less ok

[16:50:02] <purplefox_> command line checks ok

[16:50:05] <purplefox_> windows ok

[16:50:17] <purplefox_> all clear on CI

[16:50:40] <purplefox_> hmm

[16:50:48] <purplefox_> vertx-auth and mail client are grey on CI…

[16:51:45] <cescoffier> we need to restart them

[16:51:49] <cescoffier> they timed out

[16:53:37] <purplefox_> ok, i'm just checking them locally too

[16:54:35] <purplefox_> cescoffier: i think it's the yard docs (gems) they take ages to build

[16:54:58] <purplefox_> especially for auth where there are multiple sub modules

[16:55:04] <cescoffier> purplefox_: yes, this combined with the donwload of the whole internet, I should increase the timeout

[16:57:16] <temporal_> I see an issue with vertx-min distrib

[16:57:21] <temporal_> when I run a core examples

[16:57:26] <temporal_> Failed to initialize a channel. Closing: [id: 0x39921be6, /127.0.0.1:63691 ⇒ /127.0.0.1:8080]

[16:57:26] <temporal_> java.lang.NoClassDefFoundError: io/netty/handler/codec/ByteToMessageDecoder

[16:57:26] <temporal_> at java.lang.ClassLoader.defineClass1(Native Method)

[16:57:26] <temporal_> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)

[16:57:27] <temporal_> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)

[16:57:27] <temporal_> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)

[16:57:27] <temporal_> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)

[16:57:52] <temporal_> I do have the netty-codec-http-4.0.28.Final jar in /lib though

[16:58:08] <temporal_> actually the underlying error is

[16:58:09] <temporal_> Caused by: java.lang.ClassNotFoundException: io.netty.handler.codec.ByteToMessageDecoder

[16:58:31] <temporal_> we are missing one jar in verts-stack min

[16:58:42] <temporal_> netty-codec

[16:58:46] <temporal_> going to update stack

[16:59:00] <cescoffier> weird, we have it in the other stacks ?

[16:59:39] <temporal_> I don't know

[17:00:30] <cescoffier> which example is it ?

[17:00:40] <temporal_> simpleform

[17:00:46] <temporal_> in core

[17:00:50] <purplefox_> personally i think the template engines should not be part of the web stack as most users will use at most one template engine (and many none)

[17:01:43] <temporal_> so we need per template distrib ?

[17:01:48] <temporal_> web-thymeleaf

[17:01:50] <temporal_> etc.. ?

[17:02:42] <purplefox_> no, i think users can copy libs in manually

[17:02:50] <temporal_> so we remove all template engines ?

[17:04:13] <purplefox_> which ones are the actual distros? the pkg ones or the stack ones?

[17:04:35] <temporal_> all of them

[17:04:52] <temporal_> thymeleaf handlebars

[17:04:55] <temporal_> jade4j

[17:04:59] <temporal_> mvel

[17:05:09] <purplefox_> hmm, i'm not sure

[17:05:57] <purplefox_> maybe we just leave as is for now

[17:06:07] <cescoffier> sounds tricky to remove them right now

[17:06:23] <cescoffier> temporal_: simpleform works using the full stack….

[17:06:51] <purplefox_> ok let's just leave it for now

[17:07:04] <temporal_> maybe because of netty all ?

[17:07:10] <cescoffier> oh yes !

[17:07:12] <temporal_> I don't know what it uses actually

[17:07:19] <temporal_> what are you netty jars in full ?

[17:07:28] <temporal_> I think we need t oremove netty all maybe

[17:07:35] <purplefox_> temporal_: where is netty all?

[17:08:16] <temporal_> question is why netty all ?

[17:08:26] <temporal_> I don't know, clement see that in full distrib

[17:08:30] <purplefox_> what is referencing netty all?

[17:08:37] <temporal_> I don't know

[17:08:50] <purplefox_> ah ok ;)

[17:08:50] <temporal_> that's why I asked him :-)

[17:08:52] <purplefox_> i removed netty all some time back

[17:08:52] <temporal_> yes

[17:08:54] <temporal_> you forgot netty-codec :-)

[17:09:13] <temporal_> but then netty-all got in full distrib and I don't see how

[17:09:42] <purplefox_> hmm what needs netty-codec?

[17:10:14] <temporal_> io/netty/handler/codec/ByteToMessageDecoder

[17:10:21] <temporal_> needs

[17:10:31] <purplefox_> it's not in vertx-core and that works ok

[17:10:33] <temporal_> at io.vertx.core.http.impl.HttpServerImpl$1.initChannel(HttpServerImpl.java:202)

[17:10:38] <temporal_> yes because it is transitive

[17:10:47] <purplefox_> ah you mean in the stack

[17:10:49] <temporal_> now in distrib we removed transitivity to not pull everything

[17:10:50] <temporal_> yes

[17:11:16] <temporal_> maybe clement has an old stack ?

[17:11:20] <temporal_> or milestone6 ?

[17:11:34] <cescoffier> nope

[17:11:41] <cescoffier> I've built the stack 30 minutes ago

[17:12:12] <cescoffier> I've tried the groovy verticle

[17:12:16] <cescoffier> let me try with the java one

[17:12:53] <cescoffier> (I'm using the full stack)

[17:14:50] <purplefox_> i've just built the full distro and it doesn't contain netty-all for me

[17:14:54] <cescoffier> in the full stack we have netty-codec-http

[17:15:27] <purplefox_> i built and unzipped the full:

[17:15:49] <purplefox_> and buffer toop

[17:15:50] <temporal_> yes I fixed it

[17:16:22] <purplefox_> so I think it's ok as long as temporal_ doesn't see netty-all as it's temporal that's going to push

[17:16:23] <temporal_> toop ?

[17:16:26] <purplefox_> too

[17:16:53] <purplefox_> temporal_: so.. wanna start?

[17:17:00] <temporal_> well

[17:17:11] <temporal_> I'm trying vertx-min with core examples :-)

[17:17:16] <temporal_> before

[17:17:18] <temporal_> to build some confidence

[17:17:33] <purplefox_> ok

[17:18:04] <purplefox_> btw… why do we have mongo-embedded in the distro?

[17:18:24] <temporal_> no particular reason

[17:18:50] <purplefox_> hmm, doesn't seem right to me

[17:18:52] <temporal_> it can be useful sometimes, although maybe ppl today will start it with docker

[17:18:53] <cescoffier> purplefox_: are you handling the DNS registration ?

[17:19:11] <temporal_> you mean switching website ?

[17:19:11] <temporal_> I'm gong to remove it

[17:19:11] <cescoffier> yes

[17:19:15] <purplefox_> that's typicallt used for testing, but ppl won't use the distro for that

[17:19:40] <purplefox_> cescoffier: the switchover should be pretty quick as the DNS already points at gigthub

[17:19:42] <cescoffier> yes I think it should be removed, should have dropped it

[17:19:54] <purplefox_> so we just need to move the CNAME file from the old website repo to the new one

[17:20:11] <purplefox_> (fingers crossed)

[17:20:32] <cescoffier> the docker upload it going to take a while (because docker is stupid and upload all layers)

[17:23:25] <cescoffier> so ?

[17:25:32] <temporal_> removed flapdoodle embedded

[17:26:04] <purplefox_> temporal_: also… vertx-unit?

[17:26:08] <temporal_> guys let me remind you that http://www.commitstrip.com/en/2014/05/07/the-truth-behind-open-source-apps/

[17:26:11] <purplefox_> that's not going to be used at deploy time

[17:26:25] <temporal_> so we remove it from what ?

[17:26:33] <temporal_> we keep it in full ?

[17:27:20] <purplefox_> not sure, would someone use it at the command line?

[17:27:29] <temporal_> you create a small test in foo.js

[17:27:32] <temporal_> and you run it

[17:27:46] <temporal_> it's more for non java

[17:27:52] <purplefox_> ok fair enough

[17:27:54] <temporal_> that's why I didn't add junit

[17:29:32] <purplefox_> so basically when your confident lets push the artifacts :)

[17:30:29] <temporal_> yes

[17:30:42] <cescoffier> yes, you are confident

[17:30:53] <cescoffier> yes, you did push the red “danger” button ?

[17:31:09] <temporal_> I'm in warpzone 7 at the moment

[17:31:23] <cescoffier> :-)

[17:31:29] <purplefox_> temporal_: WAIT STOP! WE FORGOT SOMETHING… OH SHIT…

[17:32:15] <purplefox_> temporal_: just kidding… please continue

[17:35:36] <pmlopes> :P

[17:41:04] <temporal_> allright

[17:41:11] <temporal_> let's start this after all

[17:41:40] <temporal_> I do have a couple of questions

[17:41:48] <temporal_> before starting

[17:42:09] <temporal_> 1/ version = “3.0.0” ?

[17:42:30] <temporal_> 2/ next version = “3.1.0-SNAPSHOT” or “3.0.1-SNAPSHOT” ?

[17:42:59] <purplefox_> 1) we have traditionally used -final for final releases in vert.x:

[17:43:09] <temporal_> 3/ do we vertx-examples depend on 3.0.0 and make a tag somewhere, so people can use these examples

[17:43:11] <purplefox_> hmm

[17:43:17] <purplefox_> actually we stopped doing that, lol

[17:43:30] <purplefox_> v2.0.0-beta3

[17:43:30] <purplefox_> v2.0.1-final

[17:43:30] <purplefox_> v2.0.2-final

[17:43:30] <purplefox_> v2.1

[17:43:31] <purplefox_> v2.1.1

[17:43:33] <purplefox_> v2.1.2

[17:43:35] <purplefox_> v2.1.3

[17:43:37] <purplefox_> v2.1.4

[17:43:39] <purplefox_> v2.1.5

[17:43:41] <purplefox_> so I gues we just call it 3.0.0

[17:43:46] <temporal_> ok

[17:43:50] <purplefox_> so we don't change the convention again

[17:44:10] <pmlopes> i vote for 3.0.0

[17:44:23] <cescoffier> yep, me too

[17:44:35] <cescoffier> the big question is the second one, 3.1.0 or 3.0.1 ?

[17:44:48] <purplefox_> next version snapshot probably 3.1.0-SNAPSHOT as that's the next feature release

[17:45:03] <purplefox_> if we do a 3.0.1 it will be a maintenance release

[17:45:03] <temporal_> ok

[17:45:10] <pmlopes> i would say: 3.1.0-SNAPSHOT based on http://semver.org/

[17:45:11] <Sticky> http://semver.org/

[17:45:11] <purplefox_> in case there's some bug we have to fix

[17:45:23] <cescoffier> if we need bug fixing, we can still create a branch on the impacted components and in the stack

[17:45:37] <Sticky> last number is supposed to only be for bug fixes

[17:45:47] <purplefox_> cescoffier: yes

[17:47:11] <purplefox_> when we release i will post to the google group, twitter and dzone. can anyone think where else we should announce this?

[17:47:11] <cescoffier> for examples, what about keeping master with 3.0.0, and creating a 3.1.0 branch where we put the new examples (except if they work on the 3.0.0, so they go to master). WDYT ?

[17:47:18] <purplefox_> hackernews, reddit?

[17:48:12] <pmlopes> cescoffier if we have a master and develop branch we are half way to start using git-flow :)

[17:48:13] <temporal_> for examples I was thinking at a tag

[17:48:22] <temporal_> we change master to ref 3.0.0

[17:48:27] <temporal_> then back to whatever else

[17:48:31] <temporal_> and we tag this particular commit

[17:48:44] <temporal_> and github allows to download zip from tags

[17:48:55] <cescoffier> oh yes, forgot this feature

[17:48:56] <temporal_> or point to this particular tag source tree

[17:49:03] <cescoffier> so yes, would be better

[17:49:04] <pmlopes> humm git tags can be easily moved so if someone makes a mistake we might loose the reference to the release…

[17:49:35] <temporal_> anyway my point was about having a particular commit that use 3.0.0 as maven dependency :-)

[17:50:13] <temporal_> then we can either branch or tag or both

[17:50:18] <purplefox_> well we should certainly tag everything anyway

[17:50:23] <cescoffier> some examples can be improved and some added

[17:50:28] <cescoffier> so branch would be better

[17:50:52] <purplefox_> but the question is: do we continue with master meaning “current development head” or “latest stable version”

[17:50:58] <purplefox_> that's a good question

[17:51:16] <purplefox_> I guess we can discuss that over the next few days, I don't think there is any need to come to a conclusion now

[17:51:28] <cescoffier> when people will look for example, they except to use the latest stable version

[17:51:42] <purplefox_> cescoffier: yes, especially with the examples

[17:51:47] <pmlopes> i agree

[17:51:53] <cescoffier> so, when they land to the github repo it should use the latest stable

[17:52:09] <purplefox_> I agree with examples, not 100% sure about all repos though

[17:52:18] <cescoffier> no, only example

[17:52:37] <cescoffier> other repos gonna have a 3.0.0 tag.

[17:54:00] <temporal_> purplefox_ I need to update the repos with a new version though, can't use 3.0.0-SNAPSHOT anymore :-)

[17:54:15] <temporal_> I'll use 3.1.0-SNPASHOT as said earlier

[17:54:23] <temporal_> we can still branch / change / whatever after

[17:55:03] <temporal_> last question about nexus staging

[17:55:24] <temporal_> do you want to validate staging ?

[17:55:27] <temporal_> I'll do some validation myself

[17:55:38] <temporal_> before closing the staging

[17:55:52] <purplefox_> i'm happy if you are

[17:55:53] <temporal_> I'll give you the URL

[17:55:59] <temporal_> I can't do all :-)

[17:56:05] <cescoffier> in apache felix we have a script checking signatures, but not sure it's useful here

[17:56:18] <temporal_> that's all about confidence

[17:58:13] <cescoffier> nexus is checking a couple of things, especially that all required files are present

[17:59:16] <purplefox_> one thing to check - that vertx -version returns the right value

[17:59:33] <purplefox_> (if not checked already)

[17:59:53] <cescoffier> well right now it's 3.0.0-SNAPSHOT

[18:00:57] <cescoffier> once the staging it there, I will check that the stack can be built from scratch

[18:01:02] <temporalfox> I'll check

[18:05:23] <cescoffier> ok, offline for the next 20 minutes - back afterwards

[18:31:07] <cescoffier> back

[18:43:58] <purplefox_> temporalfox: how's it going? still uploading?

[18:44:08] <temporalfox> yes I had to redo a few times

[18:44:15] <purplefox_> bad connection?

[18:44:16] <temporalfox> having issues with javadoc generation that hangs

[18:44:22] <purplefox_> hmm

[18:44:27] <temporalfox> it is suppoed to use a more recent plugin

[18:44:30] <temporalfox> but it uses 2.7

[18:44:36] <temporalfox> so I'm in “retry” mode

[18:44:45] <temporalfox> I'm investigating

[18:44:49] <temporalfox> with my maven guru atm

[18:44:51] <temporalfox> in of releasing [18:46:47] <temporalfox> it looks like a maven bgu [18:46:55] <temporalfox> basically our vertx-parent extends sonatype parent [18:47:08] <temporalfox> that has javadoc 2.7 plugin [18:47:09] <temporalfox> in a profile [18:47:11] <temporalfox> for the release we activate that profile (it signs artifacts among all) [18:47:22] <temporalfox> and even if our vertx-parent redefines the plugin version [18:47:26] <temporalfox> it uses 2.7 [18:47:33] <temporalfox> and 2.7 has this bug : https://amdatu.atlassian.net/browse/AMDATU-474 [18:47:40] <temporalfox> (that I never had before) [18:48:00] <temporalfox> (but it's a particular case as I wiped my io/vertx local repo before doing release) [18:48:23] <temporalfox> so our conclusion is that we are hitting a maven bug [18:49:03] <purplefox_> what can we do about it? [18:49:15] <temporalfox> for now I'm just trying to achieve the release [18:49:18] <temporalfox> and address this later [18:49:41] <temporalfox> one solution would be to redefine the plugin version in a profile with the same name [18:49:46] <temporalfox> sonatype-oss-release [18:49:49] <temporalfox> in our vertx-parent [18:49:59] <temporalfox> to see if that change the plugin version [18:50:06] <temporalfox> when the profile is activated [18:50:10] <temporalfox> there are good chances it does [18:51:26] <purplefox_> how much more is there to upload? [18:51:44] <temporalfox> now I'm doing the components [18:51:50] <temporalfox> maven-service-factory [18:52:21] <temporalfox> now vertx-unit [18:52:39] <temporalfox> 3 to go :-) [18:52:48] <temporalfox> after that I will do vertx-stack itself [18:53:04] <temporalfox> and I should close the staging repo [19:00:49] <purplefox_> temporalfox: damn, and I thought my connection was slow ;) [19:00:55] <temporalfox> Uploaded: https://oss.sonatype.org/service/local/staging/deploy/maven2/io/vertx/vertx-stack-dist/3.0.0/vertx-stack-dist-3.0.0-min.tar.gz (36909 KB at 1573.7 KB/sec) [19:09:46] <temporalfox> here is the staging URL [19:09:47] <temporalfox> https://oss.sonatype.org/content/repositories/iovertx-1826 [19:10:01] <temporalfox> now I will take have dinner :-) [19:10:07] <temporalfox> take care of dinner [19:10:50] <temporalfox> after validation [19:10:57] <temporalfox> I will push to the repo [19:11:01] <temporalfox> the tags [19:11:05] <temporalfox> and close the staging [19:11:11] <purplefox_> what does validation involve? [19:11:23] <temporalfox> for instance you add this repo in examples [19:11:32] <temporalfox> and you use the jars to check they are good [19:11:37] <temporalfox> or you download the binary distrib [19:11:40] <temporalfox> and you run it [19:11:49] <temporalfox> it's basically the last minute check [19:11:56] <temporalfox> in theory it is the smae work we did before [19:12:02] <purplefox_> ok, tbh i have never done this before with previous releases [19:12:10] <purplefox_> is it really necessary? [19:12:19] <temporalfox> it depends on your mantra [19:12:27] <temporalfox> :-) [19:12:35] <temporalfox> for instance some ppl stage stuff for weeks [19:12:48] <temporalfox> and they test the binaries [19:13:00] <temporalfox> for example if you have distributed release [19:13:02] <temporalfox> a team does stage something [19:13:02] <purplefox_> but we already tested this before upload [19:13:07] <temporalfox> another team consumes it [19:13:08] <purplefox_> so unless the upload did something really weird [19:13:08] <temporalfox> yes [19:13:11] <temporalfox> it should be ok [19:13:16] <temporalfox> I'm not asking full validation [19:13:18] <temporalfox> but more like [19:13:22] <temporalfox> use a couple of examples [19:13:30] <temporalfox> or even run “vertx version” [19:13:53] <purplefox_> my only worry is i want to get this done today and if it takes much longer it's going to be tomorrow [19:13:59] <temporalfox> ok [19:14:04] <temporalfox> I can push that now also [19:14:12] <purplefox_> it's already out of business hours in europe [19:14:19] <temporalfox> ok [19:14:21] <temporalfox> the most probablematic issue is the time it takes to go to central [19:14:46] <cescoffier> ok, I'm going to built it from scratch (empty maven repo) [19:15:04] <cescoffier> this is going to take a while, but it's a good way to know if we are ok [19:16:10] <purplefox_> we also need to upload to bintray [19:17:30] <purplefox_> cescoffier: what are you building from scratch? [19:17:38] <cescoffier> the stack [19:17:47] <cescoffier> to check we don't miss a project or something [19:17:56] <purplefox_> not sure i understand [19:18:32] <cescoffier> the stack project is going to assembly of distribution [19:18:47] <cescoffier> these artifact need to be served either by maven central or by the staging repo [19:19:11] <purplefox_> you mean you're building the stack locally and getting dependencies from oss staging? [19:19:19] <cescoffier> yep [19:19:52] <purplefox_> ok, not really sure what that proves [19:20:06] <cescoffier> that proves we don't depend on an unreleased artifacts [19:20:22] <cescoffier> as it won't not be in the staging repo or in maven central [19:20:27] <purplefox_> can't we just count them? they're not many ;) [19:20:47] <cescoffier> transitive matter in this case ;-) [19:21:42] <purplefox_> i'm thinking we might have to continue tomorrow, because there are clearly more steps than I anticipated [19:21:58] <cescoffier> we are close [19:22:04] <purplefox_> and then once we push to maven central we need to wait [19:22:07] <cescoffier> once the staging is done and the tags are created [19:22:09] <purplefox_> then we need to update bintray [19:22:12] <purplefox_> then the website [19:22:16] <cescoffier> the most expensive operation is the docker push [19:22:22] <purplefox_> and do all the announcements [19:22:49] <cescoffier> pushing docker images is going to take around 2 hours [19:23:04] <cescoffier> announcement should wait until everything is made [19:23:08] <cescoffier> including maven central sync [19:23:21] <purplefox_> where are docker images pushed to? [19:23:21] <cescoffier> docker hub [19:23:22] <cescoffier> (the Docker Maven Central) [19:23:28] <purplefox_> sigh. so it's definitiely going to be tomorrow [19:23:43] <cescoffier> yes, might be tomorrow my time [19:23:49] <cescoffier> might still be today your time ;-) [19:24:18] <purplefox_> i don't want to make an announcement when most of the world is asleep, that's quite important too [19:24:36] <cescoffier> yep [19:24:52] <purplefox_> so I guess we try and get everything pushed today, then do the website and announcements tomorrow [19:24:53] <cescoffier> announcement shoudl be tomorrow [19:25:02] <cescoffier> yes, sounds like a good plan [19:25:21] <cescoffier> actually the build from scratch is an apache habits [19:25:28] <cescoffier> in apache we release the source not binaries [19:25:42] <cescoffier> so we make sure the binaries can be built from scratch [19:25:58] <cescoffier> (binaries are only provided because it's convenient) [19:26:38] <purplefox_> ok cool. let's do that [19:27:08] <purplefox_> cescoffier: temporalfox pmlopes_ also…. if you can think of any other places to announce the release [19:27:15] <purplefox_> so we can get the maximum coverage [19:27:58] <cescoffier> there is a planet redhat blog thiny no ? [19:28:16] <cescoffier> I saw Emmanuel Bernard mentioning it on an internal mailing list [19:30:09] <purplefox_> ok i can ask on core about that, no idea who manages it [19:31:14] <purplefox_> temporalfox: do you know who manages it? [19:31:39] <cescoffier> Libor Krzyžanek [19:31:39] <temporalfox> no I don't know [19:31:50] <cescoffier> at least it proposed his help to emmanuel [19:32:12] <cescoffier> We should also announce it on Eclipse [19:32:28] <cescoffier> don't know we handle that there …. [19:34:44] <cescoffier> we may want to announce it on a couple of mailing list such as the netty one ? [19:35:09] <pmlopes_> Hackernews? [19:37:48] <cescoffier> temporalfox: everything fine from docker: docker run -i -t vertx/vertx3-exec -version ⇒ 3.0.0 [19:39:00] <purplefox_> pmlopes_: yep, hackernews [19:39:06] <purplefox_> also reddit, dzone, infoq [19:39:14] <purplefox_> jboss.org and eclipse.org [19:39:41] <purplefox_> freshmeat.net [19:40:41] <purplefox_> does anyone read the serverside.com any more? [19:41:19] <temporalfox> I don't [19:45:02] <temporalfox> I'm ready to push the tags and close the staging repository [19:45:02] <cescoffier> nope [19:45:10] <cescoffier> ok for me [19:45:12] <temporalfox> ok [19:45:33] <temporalfox> jenkins won't be happy with this massive update [19:46:14] <cescoffier> well :-D [19:46:40] <temporalfox> ok then [19:46:53] <cescoffier> ok getting diner now [19:46:58] <cescoffier> once the tag is done [19:47:02] <cescoffier> I will push docker images [19:49:13] <temporalfox> so repos are pushed and nexus repository closed [19:49:18] <temporalfox> let's hope Central gods are with us [19:49:22] <temporalfox> and will sync quickly [19:49:29] <temporalfox> congrats all :-) [19:50:08] <temporalfox> after that I'll take care of rest of the process : docker (clement), eclipse (me), examples (me), bintray (me) [19:52:49] <cescoffier> ok great [19:52:58] <cescoffier> starting docker push [19:54:10] <cescoffier> (need to wait the maven central sync) [19:54:51] <cescoffier> I'm dreaming ? [19:55:17] <cescoffier> already synced ! [19:55:28] <cescoffier> Maven Gods are definitely with us [19:56:33] <purplefox_> yep: http://repo1.maven.org/maven2/io/vertx/vertx-core/3.0.0/ [19:57:46] <cescoffier> unit and web not synced yet [19:57:52] <purplefox_> temporalfox: i think we should probably wait to add the bintray links until tomorrow [19:58:08] <purplefox_> otherwise people will see it today when they go to downloads [19:58:38] <aesteve> Clap, clap, clap guys :) I've just seen vertx-core 3.0.0 popping in Maven Central ! [19:59:34] <temporalfox> purplefox_ ok, I can upload them but not publish them though [19:59:35] <purplefox_> aesteve: thanks! although it's not officially released until tomorrow. so sshhhh ;) [19:59:35] <temporalfox> aesteve really ? [20:00:06] <purplefox_> temporalfox: ok [20:00:17] <temporalfox> I don't seem them on central [20:00:21] <temporalfox> where ? [20:00:35] <purplefox_> can you see here: http://repo1.maven.org/maven2/io/vertx/vertx-core/3.0.0/ [20:00:47] <temporalfox> ok [20:00:56] <temporalfox> I'm always using search.maven.org [20:01:00] <temporalfox> it's not yet indexed so [20:01:06] <purplefox_> search.maven.org takes ages to update [20:01:07] <temporalfox> ok great [20:01:09] <temporalfox> yes [20:01:32] <cescoffier> unit and web are still not synced [20:01:37] <cescoffier> I don't really get why [20:01:51] <cescoffier> unit just landed [20:01:57] <temporalfox> funny [20:02:03] <cescoffier> same for web…. [20:02:06] <purplefox_> probably some batch process that runs every few minutes ;) [20:02:33] <purplefox_> the archetype indexing used to run only twice per week :( [20:02:53] <purplefox_> that was a pita when you release a new archetype and wait several days after the release before it pops up [20:03:34] <purplefox_> ok cool, I guess we can update the examples dependency to point to 3.0.0 [20:06:28] <purplefox_> i'll do that and tag it [20:06:57] <sqz_> hi folks..amazing to see these examples (https://github.com/vert-x/vertx-examples/tree/master/src/raw)..any idea whether its possible to start a project in coffeescript and *require* some code written in java/python etc? (polyglot require) ? [20:08:06] <sqz_> in other words: requiring modules which contain code written in another programming language (supported by vertx) [20:09:42] <purplefox_> cescoffier: temporalfox: examples are now updated to 3.0.0 and tagged [20:11:47] <temporalfox> super [20:12:10] <temporalfox> I'll update bintray later tonight but not publish [20:12:24] <temporalfox> and tomorrow I'll proceed to the eclipse release [20:12:47] <purplefox_> what's involved in the eclipse release? [20:13:00] <purplefox_> just uploading core to the eclipse server? [20:13:22] <aesteve> such a pleasure to remove all this ugly maven { url 'http://oss.sonatype.org/content/repositories/snapshots/' } stuff [20:13:29] <purplefox_> aesteve: yep. :) [20:14:01] <temporal_> I think what you said [20:14:11] <purplefox_> ok cool [20:14:22] <temporal_> and also pushing some button I need to discover :-) [20:14:25] <temporal_> hidden in the UI [20:14:31] <purplefox_> ha lol [20:14:38] <purplefox_> ok folks, let's reconvene tomorrow morning [20:14:49] <purplefox_> and finish this off [20:14:53] <temporal_> +1 [20:15:34] <purplefox_> cyall [20:15:50] <cescoffier> ok, will let you know when the docker image will be up [20:15:59] <cescoffier> (pushing right now, gonna take some time) [20:23:33] <sqz_> aha found the answer to my question above on the website here: “Verticles can be written in JavaScript, Ruby, Java, Groovy or Python (Scala and Clojure support is in the pipeline).” [20:24:46] <sqz_> I noticed a coffeescript example here as well: https://github.com/vert-x/vertx-examples/tree/master/src/raw, so can i assume a coffeescript verticle can require verticles written in other languages [20:24:57] <jeremy_prime> @sqz_ you can communicate over the eventbus with verticles created in any languages, but that's not the same as “require” [20:25:11] <jeremy_prime> verticles are effectively service listeners, not libraries [20:25:38] <jeremy_prime> I'm not sure about direct inclusion of code written in coffeescript in another verticle in javascript, sorry [20:26:00] <jeremy_prime> you can call code in another verticle via the eventbus which would let you wrap libraries written in different languages [20:27:16] <sqz_> ok, so the eventbus is clearly the interface between the myriad of programming languages [20:27:30] <aesteve> Michel has worked on Typescript iirc but I haven't seen anything on cofeescript [20:29:03] <sqz_> in what way does vertx offer more than just a redis queue/pubsub system and redis-clients written in all programming languages? [20:29:31] <aesteve> you'd have trouble deploying a webserver using redis ;) [20:30:49] <aesteve> vertx is a toolkit really handling http, tcp, websockets, and indeed embedding an eventbus to handle pub/sub [20:30:59] <aesteve> but the eventbus is just a part of Vert.x [20:33:01] <sqz_> im used to express on node, is there an equivalent for vertx? [20:34:49] <sqz_> or could one easily build a rest service without an additional module [20:37:15] <AlexLehm> sqz_, express is the equivalent of vertx-web in vert.x 3.0 [20:37:27] <AlexLehm> for simple http stuff you can use vert.x directly [20:43:51] <AlexLehm> jeremy_prime, coffeescript gets compiled to javascript I think, that should be possible to use in a javascript verticle directly like typescript [20:45:03] <jeremy_prime> I'm not sure if we offer that compilation to a library though (e.g. then using requireJS to expose features of that module directly to a verticle) - that's where I think it gets confusing [20:45:43] <jeremy_prime> I know you can write a verticle in coffeescript and run it, I thought sqz_ was asking about a tighter coupling of the code [20:50:56] <AlexLehm> i haven't used vert.x with javascript much yet, but I think it should be possible to call javascript without the event bus [20:51:22] <jeremy_prime> from Python? [20:52:00] <jeremy_prime> I'm not convinced that the interpreted langs play quite so nicely together without the event bus acting as an intermediary [20:52:37] <jeremy_prime> sqz_ honestly think your question would be a good one to put on the google group for vert.x with an outline of how tightly you want to couple the code and what langs you want to couple [20:53:08] <jeremy_prime> someone might have already done it and either identified the gotchas or be able to guide you through (or at least just say “Ah, that's easy”) [20:53:44] <jeremy_prime> the JVM compiled languages will always play nicely together, the question's about how the interpreted langs (and in the case of coffeescript a lang which will be compiled into an interpreted lang) will interoperate [20:53:56] <AlexLehm> it works between javascript and java, but i have used vert.x 3 only recently, not sure about vert.x 2 [20:54:40] <jeremy_prime> yeah but you can envisage that there's interop for using JVM bytecode through Nashorn [20:54:58] <AlexLehm> yes [20:55:07] <jeremy_prime> where my big question mark comes in is where both sides of the coupling are interpreted [20:55:46] <jeremy_prime> e.g. I've got this coffeescript library I want to use in a Javascript verticle [20:55:57] <jeremy_prime> (directly, without the eventbus) [20:56:29] <jeremy_prime> where does the precompile to javascript happen? and how is the library loaded? It might be easy with Nashorn, I just don't know [20:58:57] <jeremy_prime> sqz_ https://groups.google.com/forum/#!forum/vertx is worth a look, keeps your question there for posterity as well if someone doesn't spot it on this chat [21:22:49] <AlexLehm> temporal_, looks like the order of builds is not correct in jenkins, with 3.1-SNAPSHOT, some modules missing [21:24:28] <purplefox_> AlexLehm: it will take some time for them to go blue as the deps are complex [21:29:44] <AlexLehm> I can click a few builds if that is ok [22:17:46] <temporal_> I relaunched a few builds [22:19:56] <AlexLehm> so did i, i think we are mostly blue with the new version now [22:26:47] <temporal_> yes when one is red you need to look at the missing dependency and restart the build [23:00:39] <temporal_> all blue