Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1435874400 [2017/05/27 13:44] (current)
Line 1: Line 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 :-)