Il 29/08/2014 17:16, Vojtech Szocs ha scritto: > > > ----- Original Message ----- >> From: "Vojtech Szocs" <vsz...@redhat.com> >> To: "Sandro Bonazzola" <sbona...@redhat.com> >> Cc: "infra" <infra@ovirt.org>, de...@ovirt.org >> Sent: Friday, August 29, 2014 4:43:44 PM >> Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js project >> >> >> >> ----- Original Message ----- >>> From: "Sandro Bonazzola" <sbona...@redhat.com> >>> To: "Vojtech Szocs" <vsz...@redhat.com> >>> Cc: "Tomas Jelinek" <tjeli...@redhat.com>, "Mooli Tayer" >>> <mta...@redhat.com>, de...@ovirt.org, "infra" >>> <infra@ovirt.org> >>> Sent: Friday, August 29, 2014 8:05:58 AM >>> Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js >>> project >>> >>> Il 28/08/2014 21:00, Vojtech Szocs ha scritto: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Sandro Bonazzola" <sbona...@redhat.com> >>>>> To: "Tomas Jelinek" <tjeli...@redhat.com>, "Mooli Tayer" >>>>> <mta...@redhat.com> >>>>> Cc: de...@ovirt.org >>>>> Sent: Tuesday, August 26, 2014 12:03:14 PM >>>>> Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js >>>>> project >>>>> >>>>> Il 26/08/2014 09:38, Tomas Jelinek ha scritto: >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Mooli Tayer" <mta...@redhat.com> >>>>>>> To: "Greg Sheremeta" <gsher...@redhat.com> >>>>>>> Cc: de...@ovirt.org >>>>>>> Sent: Tuesday, August 26, 2014 9:17:20 AM >>>>>>> Subject: Re: [ovirt-devel] Tools for developing and building oVirt.js >>>>>>> project >>>>>>> >>>>>>> Are we talking about using node as a development/test/packaging(minify >>>>>>> etc >>>>>>> ) >>>>>>> tool or having a runtime backend (site) on top of node? >>>>>> >>>>>> It is only devel environment (e.g. build dependency), not runtime. >>>>> >>>>> >>>>> If it's build dependency it's not just devel environment. >>>> >>>> Right, I messed up my comment above, sorry. >>>> >>>> Node.js can be (and typically is) used as both devel & build dependency >>>> for JavaScript projects. >>>> >>>>> We must ensure that all required build dependencies are available and >>>>> properly packaged for all supported distributions. >>>> >>>> Yes, fully agreed. >>>> >>>> Fedora already has some packages we could use, for example: >>>> http://koji.fedoraproject.org/koji/packageinfo?packageID=15154 >>>> http://koji.fedoraproject.org/koji/packageinfo?packageID=15356 >>>> >>>> However, there's one complication (as Greg mentioned before): npm (Node >>>> package manager) resolves Node-specific packages (esentially JavaScript >>>> artifacts) via HTTP access, so we'd need some infra to serve these, and >>>> for each such JS module: >>>> - either use existing package for that JS module, if one exists >>>> - or maintain package for that JS module on our own [*] >>>> >>>> [*] I understand that this is not what we want to do in general >>> >>> I would add >>> - Ask supported distributions to provide needed rpms >> >> Well, that ^^ would be ideal. >> >>> >>>> >>>> In other words, there would have to be some infra to support builds for >>>> JavaScript/Node.js projects, similar to existing infra to support builds >>>> for Java/Maven projects: >>>> - package for Node.js + npm >>>> - package for each JS module (likely problematic) >>>> - tool (existing Artifactory that serves Maven artifacts?) to serve >>>> JS modules via HTTP for npm to consume (maybe problematic) >>>> >>> >>> Adding infra for above >>> >>> >>>> In any case, we can proceed with developing oVirt.js without requiring >>>> Node.js as a build dependency. I see two possible solutions here: >>>> >>>> 1, avoid using build tools like Traceur (ES6 -> ES5 transpiler) >>>> and UglifyJS (code compressor/obfuscator), just concatenate >>>> JS source files into resulting JS target file (either via >>>> command in Makefile or via some Maven plugin) >>>> >>>> PROS: no special build requirements >>>> CONS: can't use tools like Traceur >>>> >>>> 2, use build tools like Traceur and UglifyJS, commit resulting >>>> JS target file into source tree, maybe with git commit hook >>>> for this >>>> >>>> PROS: can use tools like Traceur >>>> CONS: storing target JS file in source tree >>>> >>>> 3, (?) >>> >>> Use something simpler to package for compressing / minimizing like >>> http://yui.github.io/yuicompressor/ or any other tool like that at build >>> time >>> (nothing against Node.js at development time). >> >> YUI Compressor is written in Java, we could use it within our Java-based >> Engine build. It seems that YUI Compressor uses Rhino (JS engine written >> in Java) with some custom Rhino extensions/tweaks. >> >> I didn't find Fedora package for YUI Compressor, but I found this: >> >> http://davidb.github.io/yuicompressor-maven-plugin/ >> >> And luckily, this Maven plugin is also in JBoss Maven repo: >> >> >> https://repository.jboss.org/nexus/service/local/repositories/central/content/net/alchim31/maven/yuicompressor-maven-plugin/1.4.0/yuicompressor-maven-plugin-1.4.0.pom >> >> OK, now some bad news. According to this: >> >> http://www.yuiblog.com/blog/2012/10/16/state-of-yui-compressor/ >> >> development on YUI Compressor continues through JavaScript (surprise!) >> project yUglify (it's based on UglifyJS which I proposed way above): >> >> https://github.com/yui/yuglify >> >> And, not surprisingly, yUglify is Node.js module. Here we go :) >> >> As everyone can see, all popular tools for JavaScript development >> are pretty much centered around Node.js, that is not coincidence. >> Avoiding Node.js for JavaScript development complicates the whole >> development and build process (from developer's perspective). >> >> OK, now what we can do. I suggest to use wro4j (Java-based): >> >> https://code.google.com/p/wro4j/ >> >> wro4j uses Rhino to execute most of its "processors", including >> UglifyJsProcessor. As I wrote before, wro4j bundles JS tools >> (like UglifyJS) that are developed against Node.js runtime, and >> runs them via Rhino. As a result, you can invoke JS development >> tools from within Java environment. >> >> It's available in JBoss Maven repo: >> >> >> https://repository.jboss.org/nexus/service/local/repositories/central/content/ro/isdc/wro4j/wro4j-maven-plugin/1.7.6/wro4j-maven-plugin-1.7.6.pom >> >> Conclusion: >> >> * can we use wro4j-maven-plugin for now? >> (OK to add new Maven plugin dependency?) > > Additionally, we could pull JS dependencies (such as Lo-Dash) > as webjars through Maven, for example: > > > https://repository.jboss.org/nexus/service/local/repositories/central/content/org/webjars/lodash/2.4.1-4/lodash-2.4.1-4.pom > > As for Traceur, I guess that we could just use it "on-the-fly" > (compilation happens during page load) as described here: > > https://code.google.com/p/traceur-compiler/wiki/GettingStarted > > Overall, assuming we can introduce some new Maven (plugin/JAR) > dependencies into Engine build, we can avoid Node.js runtime > required for the build; Node.js would be purely a devel/test > env. dependency.
Are all of the above maven dependencies already available in Fedora? > >> >> * in the long term, supporting Node.js within our build infra >> (still) seems needed, assuming we're in agreement about >> modularizing (currently monolithic) GWT UI, with JavaScript >> becoming the common base UI technology >> >>> >>> >>>> >>>> What do you think? >>>> >>>> Note that this might work for small projects in short term. >>>> >>>> If we agree that JavaScript is the common base technology for >>>> oVirt frontend, not having well-established build environment >>>> (such as Node.js) will make it very hard to develop and maintain >>>> bigger JavaScript projects in the long term. >>>> >>>>> >>>>> >>>>>> >>>>>> I'd just like to point out that one thing is the development of the >>>>>> ovirt.js itself >>>>>> which is not going to be a big project and I can imagine also using >>>>>> less >>>>>> ideal (slower) tools for it's development. >>>>>> >>>>>> A completely different story will be when (if) we decide to use >>>>>> ovirt.js >>>>>> to >>>>>> develop some parts of the webadmin/userportal >>>>>> in javascript instead of GWT (or even rewrite the whole FE to JS) which >>>>>> will be a big project (set of projects). >>>>>> >>>>>> If we want to be effective in that effort, we will need good tools. >>>>>> >>>>>>> >>>>>>> From my perspective I can't stress enough how important is the >>>>>>> separation >>>>>>> of ovirt UI part from the backend. I agree to everything Vojtech said >>>>>>> about >>>>>>> developing to the browser with java. >>>>>>> >>>>>>> Mooli. >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Vojtech Szocs" <vsz...@redhat.com> >>>>>>>>> To: de...@ovirt.org >>>>>>>>> Sent: Monday, August 25, 2014 11:13:38 AM >>>>>>>>> Subject: [ovirt-devel] Tools for developing and building oVirt.js >>>>>>>>> project >>>>>>>>> >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> last week, we had "oVirt.js PoC" session and I mentioned the >>>>>>>>> possibility >>>>>>>>> of using Node.js and related tools like npm to develop & build >>>>>>>>> oVirt.js >>>>>>>>> project. >>>>>>>>> >>>>>>>>> I'd like to hear your opinion - what do you think about using >>>>>>>>> Node.js >>>>>>>>> in >>>>>>>>> context of developing & building JavaScript projects? (oVirt.js >>>>>>>>> etc.) >>>>>>>>> >>>>>>>>> Obviously, I'm strongly biased towards Node.js because of its >>>>>>>>> popularity >>>>>>>>> and therefore availability of various tools (npm packages) for >>>>>>>>> JavaScript, >>>>>>>>> for example: grunt (task runner), jslint/hint (code analyzer), >>>>>>>>> uglifyjs >>>>>>>>> (minify/compress), karma (both one-time & continuous test runner), >>>>>>>>> traceur >>>>>>>>> (es6 -> es5 compiler), etc. >>>>>>>>> >>>>>>>>> My understanding is that any special-purpose JavaScript development >>>>>>>>> tool >>>>>>>>> is typically implemented as module for Node.js (due to its >>>>>>>>> popularity), >>>>>>>>> so I think it makes sense to use Node.js as a platform for >>>>>>>>> JavaScript >>>>>>>>> development. >>>>>>>>> >>>>>>>>> There are also Java-based projects for JavaScript (post)processing >>>>>>>>> like >>>>>>>>> wro4j, however these tend to be implemented by invoking JS tools >>>>>>>>> (like >>>>>>>>> uglifyjs) from Java context via Rhino (JS engine for Java), for >>>>>>>>> example: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://code.google.com/p/wro4j/source/browse/wro4j-extensions/src/main/java/ro/isdc/wro/extensions/processor/support/uglify/UglifyJs.java >>>>>>>>> >>>>>>>>> (To me, developing JavaScript project with Java-centric tooling >>>>>>>>> sounds >>>>>>>>> quite strange in general.) >>>>>>>>> >>>>>>>>> There's also webjars repository for hosting popular web resources >>>>>>>>> for >>>>>>>>> use in Java applications (i.e. Maven artifact for uglifyjs etc.), >>>>>>>>> but >>>>>>>>> this is just for easier dependency management from Java perspective >>>>>>>>> (JAR file as a distribution format for web resources): >>>>>>>>> >>>>>>>>> http://www.webjars.org/ >>>>>>>>> >>>>>>>>> Overall, I'm in favor of using Node.js to manage all tasks related >>>>>>>>> to >>>>>>>>> JavaScript development and build process. If you have any objections >>>>>>>>> or suggestions, I'd like to hear them! >>>>>>>>> >>>>>>>>> (I understand that Node.js essentially means new dependency with all >>>>>>>>> implications, but in this case, I think it's worth it. But this is >>>>>>>>> just me, so please share your opinions.) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vojtech >>>>>>>> >>>>>>>> I think most developers would agree that node.js is the tool of >>>>>>>> choice >>>>>>>> for >>>>>>>> JavaScript development. >>>>>>>> >>>>>>>> The thing we must carefully consider is that node.js uses its own >>>>>>>> package >>>>>>>> manager (npm -- much like maven), and unlike maven, tooling does not >>>>>>>> yet >>>>>>>> exist to deal with npm packages in an rpm environment. >>>>>>>> >>>>>>>> This isn't on the same level as adding a logging library or a >>>>>>>> collections >>>>>>>> library or something. I'd argue that dependencies don't get any >>>>>>>> heavier >>>>>>>> than this one. That is worrisome to me. >>>>>>>> >>>>>>>> Run 'yum list available |grep nodejs' on your machine to see which >>>>>>>> node.js >>>>>>>> packages are available. Note that I don't see karma or uglify >>>>>>>> available >>>>>>>> in >>>>>>>> either Fedora or Red Hat SCL (Software Collections) [1]. >>>>>>>> >>>>>>>> [1] >>>>>>>> https://sochotni.fedorapeople.org/nodejs010-RHSCL-1-RHEL-6/Server/x86_64/os/Packages/ >>>>>>>> >>>>>>>> Greg >>>>>>>> _______________________________________________ >>>>>>>> Devel mailing list >>>>>>>> de...@ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Devel mailing list >>>>>>> de...@ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>> >>>>>> _______________________________________________ >>>>>> Devel mailing list >>>>>> de...@ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>> >>>>> >>>>> >>>>> -- >>>>> Sandro Bonazzola >>>>> Better technology. Faster innovation. Powered by community >>>>> collaboration. >>>>> See how it works at redhat.com >>>>> _______________________________________________ >>>>> Devel mailing list >>>>> de...@ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>> >>> >>> >>> -- >>> Sandro Bonazzola >>> Better technology. Faster innovation. Powered by community collaboration. >>> See how it works at redhat.com >>> >> _______________________________________________ >> Devel mailing list >> de...@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
