Since the @JavaScript notation was not working for sub-components to the main JS we reference (all sub parts like CSS, other JS and image files that are dynamically loaded by the main JS referenced get rejected as not having been published), we tried the app:// reference to serve it all from the VAADIN folder.
We found that using app://VAADIN/addons/CKEditorForVaadin7/ckeditor/ckeditor.js worked, but prevented the Eclipse Vaadin plug-in to fail to export the JAR since it apears that /VAADIN/addons/ has special meaning.
So, we put it in app://VAADIN/addon-js/CKEditorForVaadin7/ckeditor/ckeditor.js instead, and this also worked, and would allow us to use the Eclipse plug-in to generate the JAR (though it didn’t auto-select WebContent/VAADIN/add-ons, so we had to select it on export).
But, when we brought it into a project that has its own JSPs and images and such so that the Vaadin Servlet is mapped to only use /VAADIN/* and /ui/* instead of the default /*, the app:// scheme was now trying to load the JS from /WEBAPPNAME/ui/VAADIN/add-ons/… instead of /WEBAPPNAME/VAADIN/add-ons… It seems that the app:// should root itself at the webapp’s context. Relative URLs are generally tricky and it’s best that it root itself at the webapp’s deployment context when it’s trying to find a specific location like the /VAADIN/ folder which cannot be deployed elsewhere.
Also, the default UI created by the Eclipse plug-in set up a default VaadinServlet and used annotations to configure it. This caused problems when that add-on was then used in another project because it took the annotations from the add-on’s JAR instead of our web.xml. The solution was to revert the add-on to remove the annotations for VaadinServlet and use its web.xml instead.
Hope this can be resolved. Maybe 7.1’s vaadin:// scheme will resolve this rather than using app:// Anyway, just an FYI on what we’ve found that keeps us from moving forward with a JS-based add-on.