Hello,

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/

Regards,
Vojtech
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel

Reply via email to