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

[09:44:17] <a_> g

[09:44:19] <a_> test

[10:00:45] <purplefox> #help

[10:01:29] <purplefox> temporalfox: cescoffier pmlopes: do any of you know how to get channel ops status in an irc channel if there are no channel ops here already?

[10:01:59] <pmlopes> sorry, no

[10:07:53] <purplefox> pmlopes: cescoffier temporalfox: can we postpone the meeting 15 mins - just in the middle of something right now :(

[10:08:02] <temporalfox> ok

[10:08:10] <cescoffier> purplefox: no problem we are already there

[10:08:11] <pmlopes> no problem

[10:14:34] <SLedunois> Hi!

[10:14:47] <SLedunois> I got an issue with vertx at starting

[10:15:22] <SLedunois> it said : “Unable de find or load the main class org.vertx.java.plateform.impl.cli.Starter”

[10:15:28] <SLedunois> it-'s on windows 7

[10:15:40] <SLedunois> I tried on linux and there is no issues

[10:15:46] <SLedunois> can someone help me about it?

[10:20:17] <purplefox> SLedunois: “plateform” ?

[10:20:41] <purplefox> pmlopes: temporalfox: cescoffier meeting

[10:20:45] <SLedunois> purplefox: Yes. It's the error that appear

[10:22:16] <purplefox> that's the wrong class name: https://github.com/eclipse/vert.x/blob/2.x/vertx-platform/src/main/java/org/vertx/java/platform/impl/cli/Starter.java

[10:24:27] <SLedunois> purplefox: Yes. But I clone a git repo

[10:24:31] <SLedunois> It works on Linux

[10:24:35] <SLedunois> But not on Windows

[10:26:43] <SLedunois> purplefox: When I looked your link, it's the same class name?

[11:44:27] <purplefox> pmlopes: cescoffier temporalfox: one thing I don't really get about asset pipelines, I would have thought it would be more efficient to create minified JS and concatenate resources during build time, not run time….

[11:44:46] <temporalfox> there are two schools :-)

[11:44:53] <cescoffier> purplefox: yes there are two shools

[11:45:03] <temporalfox> I think in java we dont have efficient tools for asset pipelines so it's more runtime-ish

[11:45:06] <purplefox> SLedunois: no your fully qualified classname is wrong it's “platform” not “plateform”

[11:45:13] <temporalfox> and in js on the contrary it's more ahead of time

[11:45:25] <temporalfox> also in Ruby on rails where you have hot reload

[11:45:31] <temporalfox> there is no notion of “ahead” of time

[11:45:39] <cescoffier> in my opinion most of the stuff can be done offline at package time - so here the task is about documenting the integration with how they build their vert.x app

[11:45:58] <cescoffier> however some stuff cannot be done offline (ETAG) this requires runtime support

[11:46:07] <pmlopes> yes i agree with concatenating at compile time

[11:47:00] <pmlopes> at runtime imo i prefer to see the original so if there are bugs i can see what is going wrong

[11:47:12] <purplefox> with a high performance webserver it's usually more efficient to serve a file from sick (e.g. bypassing kernel altogether using sendfile) than trying to serve it dynamically from a stream

[11:47:18] <purplefox> s/sick/disk

[11:47:20] <purplefox> lol

[11:47:42] <purplefox> i can see the advantage during development so you don't have to rebuild all the time

[11:47:45] <purplefox> but.. production?

[11:49:05] <SLedunois> purplefox: Yes. Sorry. I write it, but I french so I write it as a “french” version

[11:49:17] <SLedunois> purplefox: My error is with plaTform

[11:49:45] <cescoffier> for production, if you have lots of static file with lots of traffic, apache or nginx would be much more efficient

[11:49:51] <purplefox> SLedunois: which version of Vert.x are you using and how are you running it?

[11:50:49] <purplefox> cescoffier: yeah, or just use a CDN :)

[11:51:05] <purplefox> (actually Vert.x is not much slower than nginx for static :) )

[11:51:18] <cescoffier> purplefox: CDN does not work for everything (CORS), but for javascript libs, definitely

[11:51:38] <cescoffier> (actually, I'm sruprise no one has ask for webjar support)

[11:51:43] <SLedunois> purplefox: 2.1.1

[11:52:29] <SLedunois> purplefox: And i run it with : vertx runMod org…. 1.13.1 -conf conf-file

[11:52:31] <purplefox> SLedunois: that's pretty old. the latest production Vert.x is 3.0 and the latest on the 2.x branch is 2.1.6

[11:54:06] <aesteve> hi everyone :)

[11:55:21] <purplefox> SLedunois: i recommend upgrading to 2.1.6, if the problem continues post a message on the google group. make sure you follow the install instructions for windows

[11:56:39] <SLedunois> purplefox: I already upgrade to 2.1.6 but i still got the error

[11:56:54] <purplefox> you just said you were using 2.1.1…

[11:57:56] <purplefox> ok (assuming you are using 2.1.6 not 2.1.1)

[11:58:00] <purplefox> edit the vertx.bat script

[11:58:15] <purplefox> after this line:

[11:58:15] <purplefox> set CLASSPATH=%CLASSPATH%;%VERTX_HOME%\conf;%VERTX_HOME%\lib\*

[11:58:25] <purplefox> echo the value of CLASSPATH

[11:58:32] <purplefox> can you tell me what it says?

[11:59:44] <cescoffier> purplefox: about the file resolver PR, can you confirm that two commits were already merged (from another PR) ?

[12:00:14] <cescoffier> purplefox: in other world, am I becoming completely crazy ?

[12:00:33] <purplefox> ah bollocks. no you're not crazy. i created the other pr branch from the previous one not master

[12:00:38] <purplefox> so it contains the other commits

[12:00:46] <purplefox> and since the second PR has been merged first…

[12:01:48] <cescoffier> ourf….

[12:01:52] <cescoffier> :-)

[12:02:00] <cescoffier> ok, so reviewing only the new code

[12:03:23] <SLedunois> purplefox: it says le path to vertx conf folder an vertx lib folder

[12:04:24] <purplefox> which jdk version are you using?

[12:04:49] <purplefox> can you paste the classpath here?

[12:15:21] <purplefox> cescoffier: actually there is an argument that we should ban sys props altogether and have everything configurable programmatically from the options classes

[12:15:39] <purplefox> sys props are kind of ugly coz they're global so they “leak” between vert.x instances

[12:16:02] <cescoffier> it's only useful if you use the Starter class

[12:16:24] <SLedunois> purplefox: It's the 1.7

[12:16:25] <purplefox> well.. in starter we provide an automatic mapping between sys prop and options

[12:16:34] <purplefox> SLedunois: which exact version?

[12:16:40] <SLedunois> purplefox: and in my JDK, I got : C:\developpement\OPEN-ENT-NG\gradle-1.6\bin\;C:\developpement\OPEN-ENT-NG\MongoDB\Server\3.0\bin\;C:\developpement\OPEN-ENT-NG\vert.x-2.1.1\bin\;C:\developpement\OPEN-ENT-NG\apache-maven-3.3.3\bin\;C:\Program Files (x86)\Git\cmd\

[12:16:47] <cescoffier> so in this case, we can get rid of the system property to just use the option

[12:17:05] <purplefox> possibly, but we'll have to do this in several places, so it's a bit of work

[12:17:06] <SLedunois> purplefox: 1.7.0_79

[12:17:30] <SLedunois> purplefox: JAVA SE Environement build 1.7.1_79-b15

[12:17:49] <purplefox> can you just paste the output from java -version?

[12:18:17] <purplefox> SLedunois: also, what is the path that you just pasted above?

[12:18:38] <purplefox> is that the output from echoing the classpath?

[12:19:12] <SLedunois> purplefox: java version “1.7.0_79” Java(TM) SE Runtime Environment (build 1.7.0_79-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)

[12:19:33] <purplefox> can you please also post the output from echoing the classpath from the script?

[12:23:24] <SLedunois> purplefox: C:\developpement\OPEN-ENT-NG\vert.x-2.1.1\bin>vertx.bat ;C:\developpement\OPEN-ENT-NG\vert.x-2.1.1\bin\..\conf;C:\developpement\OPEN-ENT -NG\vert.x-2.1.1\bin\..\lib\*

[12:23:46] <SLedunois> purplefox: the first line is the execution of the .bat

[12:24:32] <purplefox> so you're executing vert.x from inside the bin directory of the vert.x install?

[12:24:37] <purplefox> that's a bit strange

[12:25:13] <purplefox> did you add the Vert.x bin directory to your PATH environment variable?

[12:25:14] <SLedunois> purplefox: no. But when I run it in my project, classpath dosen't appear

[12:25:54] <purplefox> ok make sure you have added vert.x to your path

[12:26:25] <SLedunois> purplefox: MY path is : C:\developpement\OPEN-ENT-NG\gradle-1.6\bin\;C:\developpement\OPEN-ENT-NG\MongoDB\Server\3.0\bin\;C:\developpement\OPEN-ENT-NG\vert.x-2.1.1\bin\;C:\developpement\OPEN-ENT-NG\apache-maven-3.3.3\bin\;C:\Program Files (x86)\Git\cmd\

[12:27:23] <purplefox> ok, so go to another directory (not the vert.x bin install directory) and type:

[12:27:29] <purplefox> vertx run foo

[12:27:38] <purplefox> and tell me what the echoed classpath says this time

[12:28:00] <purplefox> btw… you are still running 2.1.1. please upgrade to 2.1.6 first :)

[12:31:15] <SLedunois> purplefox: I got an error : Failed in deploying verticle java.lang.ClassNotFoundException : foo

[12:31:36] <purplefox> ok, but what does the echoed classpath say?

[12:35:05] <purplefox> if you edited the script it will be output the classpath before attempting to run the verticle

[12:35:59] <purplefox> SLedunois: ^

[12:36:45] <purplefox> SLedunois: if you do not see any output before it says “Failed in deploying verticle java.lang.ClassNotFoundException : foo” that implies either a) you didn't edit the script b) it's running a different version of the script

[12:36:58] <purplefox> if b) then check your path you don't have another version of vert.x installed

[13:02:32] <AlexLehm> SLedunois: if you have problems with the vertx.bat script, you could set DEBUG=1 to turn logging on

[13:03:06] <AlexLehm> I can run vertx.bat version with a 2.1.1 dist I just downloaded

[14:26:57] <cescoffier> pmlopes: do you have a link about json interop ?

[14:27:31] <pmlopes> https://www.tbray.org/ongoing/When/201x/2015/03/23/i-json

[14:28:39] <cescoffier> thanks

[15:06:09] <aesteve> purplefox: I saw you were talking about pipeline / reload earlier, still want some enlightenment ? or you're seeing the point already ?

[15:56:02] <cescoffier> aesteve: it was mentioned (maybe by you) on the 3.1 wish list

[15:56:19] <cescoffier> so we start discussing how this can be done, without reinventing the wheel

[15:57:20] <aesteve> someone else mentionned it, I just picked up on it

[15:57:43] <aesteve> but I like the idea of a “plugin” API for static resources indeed

[15:58:06] <aesteve> if someone want to build an SASS plugin, he just could, etc.

[15:59:17] <cescoffier> the question is whether we should provide such pipelining or show how to use gulp, grub or something else

[15:59:42] <aesteve> grub ? grunt ?

[16:00:14] <cescoffier> yes :-)

[16:00:18] <aesteve> gulp/grunt could be pipelines actually

[16:00:39] <aesteve> thing is, you can't do a better job than gulp/grunt/webpack do

[16:00:52] <cescoffier> because the number of processor / pre-processor / polyfill is so high, we cannot really support them all

[16:01:22] <cescoffier> that's why reusing something existing is interesting

[16:01:42] <aesteve> it is

[16:01:45] <cescoffier> while at the same time we should not be tied to one single tool, but just document how to use it

[16:01:55] <aesteve> i disagree

[16:02:16] <aesteve> in fact, using the tools is the developper problem, I agree on that

[16:02:31] <aesteve> but what Vert.x could do is handling “environments”

[16:02:58] <cescoffier> con you explain ?

[16:03:02] <cescoffier> can

[16:04:04] <aesteve> in some environments (local, dev) you'll want your static resources to be evaluated everytime a request is made

[16:04:41] <aesteve> in some, you'll want your resources to be built at startup

[16:04:47] <cescoffier> so you would like a runtime management

[16:04:51] <aesteve> in production, you'll rely on already-built resources

[16:05:50] <aesteve> the idea of a pipeline API is to allow the developer, for a matching resource (i.e. extension, ….) to act depending on the environment

[16:06:04] <aesteve> let's take SCSS files as an example

[16:07:05] <aesteve> if I want to build an SCSS plugin relying on the SCSS compiler, I'd need 3 extensions for the staticHandler

[16:07:15] <cescoffier> well this can be provided by a `watch` mode processing resources

[16:07:34] <cescoffier> without any runtime support - except cache deactivation

[16:08:01] <aesteve> not sure I understand actually :\

[16:10:34] <cescoffier> image a processing that everytime you save your SCSS file it generates the CSS file in the directory served by your vert.x application

[16:10:58] <aesteve> this could work this way, too

[16:10:58] <cescoffier> this is of course a 'dev' environment, because in prod your resources will have been prepared

[16:12:02] <cescoffier> so, in this case the only runtime (in vert.x) requirement is the cache deactivation (ETAG + Cache-Control) to be sure to use the latest generated resoruce

[16:13:43] <aesteve> I understand Vert.x tries to stay agnostic of other tools

[16:13:52] <cescoffier> I looks to me that this solution can be implemented using gulp or grub

[16:15:38] <aesteve> actually, watchify / browerify

[16:15:41] <aesteve> but anyway

[16:16:12] <aesteve> what I'm trying to explain is, when you're building a whole webapp (front + back) and not a simple example

[16:16:25] <aesteve> it's painful to deal with a lot of different tools

[16:17:14] <aesteve> at build-time, for example, Gradle, Maven, … will be responsible for : creating the server jar + building the front stuff. It's OK

[16:18:25] <aesteve> but in a pure development mode, you have a lot of different tools to manage, launch, relaunch, etc. it's simply painful

[16:19:43] <aesteve> if you've ever tried to use webpack / nodejs you'll see what I mean : you simply run one command and everything runs fine, bot front/back resources are managed

[16:20:07] <aesteve> this is a _major_ adoption feature for web developers

[16:20:33] <aesteve> and I think simply embedding node as a worker verticle would allow Vert.x to have the same kind of features

[16:22:27] <cescoffier> what you are describing is more a rails like framework (as wisdom for vert.x 2)

[16:40:48] <aesteve> well, maybe I guess… But asynchronous

[16:42:00] <cescoffier> yes, obviously

[16:46:14] <aesteve> well I guess it's a lost cause anyway since I don't manage to explain the needs properly, nevermind

[17:32:20] <millrossjez> @aesteve, I agree with you, currently we have to do a maven rebuild/redploy (via bower) when we change web resources, which slows down our front end dev quite a lot

[17:33:43] <aesteve> yes millrossjez I just can't find a proper way to explain it. I already tried with Tim and I'm just not sounding crystal clear

[17:34:24] <aesteve> I guess as long as you haven't face this issue in a developer environment, you just can't understand what I mean (in the way I exaplain it), that's really frustrating :(

[19:05:52] <temporalfox> good week end everyone :-)