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

Vojtech Szocs vszocs at redhat.com
Fri Aug 29 15:16:18 UTC 2014 


----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> Cc: "infra" <infra at ovirt.org>, devel at 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 at redhat.com>
> > To: "Vojtech Szocs" <vszocs at redhat.com>
> > Cc: "Tomas Jelinek" <tjelinek at redhat.com>, "Mooli Tayer"
> > <mtayer at redhat.com>, devel at ovirt.org, "infra"
> > <infra at 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" <sbonazzo at redhat.com>
> > >> To: "Tomas Jelinek" <tjelinek at redhat.com>, "Mooli Tayer"
> > >> <mtayer at redhat.com>
> > >> Cc: devel at 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 at redhat.com>
> > >>>> To: "Greg Sheremeta" <gshereme at redhat.com>
> > >>>> Cc: devel at 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" <vszocs at redhat.com>
> > >>>>>> To: devel at 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
> > >>>>> Devel at ovirt.org
> > >>>>> http://lists.ovirt.org/mailman/listinfo/devel
> > >>>>>
> > >>>> _______________________________________________
> > >>>> Devel mailing list
> > >>>> Devel at ovirt.org
> > >>>> http://lists.ovirt.org/mailman/listinfo/devel
> > >>>>
> > >>> _______________________________________________
> > >>> Devel mailing list
> > >>> Devel at 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 at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>

More information about the Devel mailing list