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