----- 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. > > * 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 > _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra