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