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

Sandro Bonazzola sbonazzo at redhat.com
Mon Sep 1 06:49:34 UTC 2014 

Il 29/08/2014 17:16, Vojtech Szocs ha scritto:
> 
> 
> ----- 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.


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


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

More information about the Infra mailing list