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

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

> > 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).

> > 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