[ovirt-devel] oVirt.js - source control & distribution

Vojtech Szocs vszocs at redhat.com
Tue Jun 17 14:43:51 UTC 2014


I'd like to share my ideas on how to manage oVirt.js source code and
distribution for consumer applications. Please let me know what you
think, nothing is set in stone :)

1, Idea: separate git repo for oVirt.js, example: "ovirt-engine-sdk-js"
   - using Node/Grunt for building oVirt.js distributable package
     - development build: ovirt.js
     - production build: ovirt.min.js
     - source maps for production build: ovirt.min.js.map
     - not sure we really need platform (make/RPM) build here, since
       WebAdmin & UserPortal are planned to have oVirt.js injected
       right into their output (GWT-generated) JavaScript code (no
       need to fetch it at runtime)

2, Idea: contain GWT/Java overlay for oVirt.js in "ovirt-engine" repo
   - overlay = Java facade to oVirt.js which uses JSNI [1] to delegate
     calls to underlying JavaScript (oVirt.js) code
   - for now, WebAdmin & UserPortal are the only GWT applications
     intended to consume oVirt.js, we can extract the overlay into
     different repo later if needed

3, Idea: distribute oVirt.js via Bower [2] for common audience
   - just like any other JavaScript library is distributed
   - this is similar to oVirt _Java_ SDK distributed via Maven Central
     (in that case, common audience = Java developers using Maven)

4, Idea: integrate oVirt.js into Engine Maven build as dependency
   - building oVirt.js would (also) produce ovirt-js-<version>.jar
   - GWT/Java overlay project (essentially GWT module) would depend
     on ovirt-js-<version>.jar, including its content into overlay's
     output JAR
   - WebAdmin & UserPortal would consume ovirt-js-gwt-<version>.jar
     (GWT overlay) as GWT module in their <moduleName>.gwt.xml files

[1] http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsJSNI.html
[2] http://bower.io/


More information about the Devel mailing list