Re: [ovirt-devel] Tools for developing and building oVirt.js project

----- Original Message ----- > From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > To: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; > Cc: "infra" <infra(a)ovirt.org&gt;, devel(a)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" <sbonazzo(a)redhat.com&gt; >> To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; >> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com&gt;, "Mooli Tayer" >> <mtayer(a)redhat.com&gt;, devel(a)ovirt.org, "infra" >> <infra(a)ovirt.org&gt; >> 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" <sbonazzo(a)redhat.com&gt; >>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com&gt;, "Mooli Tayer" >>>> <mtayer(a)redhat.com&gt; >>>> Cc: devel(a)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" <mtayer(a)redhat.com&gt; >>>>>> To: "Greg Sheremeta" <gshereme(a)redhat.com&gt; >>>>>> Cc: devel(a)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/con... > > 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/con... > > 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/con... 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.

> > * 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" <vszocs(a)redhat.com&gt; >>>>>>>> To: devel(a)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/j... >>>>>>>> >>>>>>>> (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/... >>>>>>> >>>>>>> Greg >>>>>>> _______________________________________________ >>>>>>> Devel mailing list >>>>>>> Devel(a)ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>> >>>>>> _______________________________________________ >>>>>> Devel mailing list >>>>>> Devel(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>> >>>>> _______________________________________________ >>>>> Devel mailing list >>>>> Devel(a)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 >>>> Devel(a)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 > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel >