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

Fri Aug 29 06:05:58 UTC 2014

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

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