I assume that just like you have a ClassLoader per module you will have a scripting Context per module.
Objects from separate modules may talk via normal API calls, sure. Not sure how to declare a public package and to offer the API, but for a service implementation the fact that it's a JS object should be irrelevant to the API clients. În lun., 19 dec. 2016 la 19:18 Sven Reimers <[email protected]> a scris: > Hi all, > > > > from my point of view I see some major issues to be solved > > > > The classpath for the script is the module dependency list. This needs to > > be passed to the scripting environment. How many scripts belong to one > > environment? Can they interact? Do you just want service decalarations to > > work? Do we need a delegate? Do we need something like js bindings? Do you > > want to use js for lookups registered in the system file system also? > > > > A couple if year back I did a talk about polyglot NetBeans platform, using > > Scala, Clojure, JavaFX Script and Groovy (I think) for implementing > > TopComponents.. The only thing that I could not get to work was JRuby (had > > something to do with how the environment had to be launched..) > > > > Not sure where this is going.. just my 2€c > > > > Sven > > > > > > Am 19.12.2016 15:55 schrieb "Emilian Bold" <[email protected]>: > > > > All of Geertjan's articles are about the module author manually invoking > > the ScriptEngine. > > > > What I want is all of that to be included in the NetBeans Module System. > > > > So you could have pure Javascript modules with no Java at all. > > > > Note that the Javascript code will still be invoked by Nashorn in the Java > > runtime and will have to talk to Java APIs. > > > > So, this is not about replacing Swing with another Javascript UI. Although > > that would be an interesting feat! We could mix Swing with a browser two > > ways: either we embed the browser into the Swing tree (via the JavaFX > > WebView or something better) or we embed Swing into the browser (via an > > applet or something like http://webswing.org/ ). > > > > Anyhow, there are a lot of plugins that don't need an UI or that could call > > Swing from Javascript. > > > > And, of course, one could imagine hybrid modules, where you have Java code > > (perhaps in a wrapped library initially) and Javascript code intermixed. > > > > > > > > --emi > > > > On Mon, Dec 19, 2016 at 4:21 PM, Christian Lenz <[email protected]> > > wrote: > > > > > Sounds great, Geertjan wrote articles, how to create plugins with JS. > > > > > > JavaScript in JavaFX (Has nothing todo with NetBeans yet): > > > https://blogs.oracle.com/geertjan/entry/javafx_in_javascript > > > Combining Nashorn Scripting with JavaFX (Has nothing todo with NetBeans > > > yet): https://blogs.oracle.com/geertjan/entry/combining_ > > > nashorn_scripting_with_javafx > > > Extending NetBeans with Nashorn (Yes possible): > https://blogs.oracle.com/ > > > geertjan/entry/extending_netbeans_with_nashorn > > > > > > so with the last article it is possible to extend NetBeans with JS, I > > > tried a bit but I really need to have a view with XML or HTML, because it > > > is a mess and a pain in the ass to write new Button, new Label, new > > > Everything, inside a JS file. So it has to be possible to create View > > files > > > like MyWindow.xml or MyWindow.html and a js file behind like MyWindow.js > > > and for sure .css too. > > > > > > If this is possible, that would be great. This would be the same as with > > > Electron (http://electron.atom.io) or NativeScript ( > > > https://www.nativescript.org/) > > > But we need more info for this. > > > > > > > > > Cheers > > > > > > Chris > > > > > > > > > > > > Gesendet: Montag, 19. Dezember 2016 um 14:47 Uhr > > > Von: "Emilian Bold" <[email protected]> > > > An: [email protected] > > > Cc: [email protected] > > > Betreff: Scriptable NetBeans Modules > > > Hello, > > > > > > I think it would be useful to provide a bridge for NetBeans modules done > > > with scripting languages. > > > > > > Javascript is the prime candindate since we have Nashorn at JRE level, > but > > > I assume once the hooks are in place more languages will be supported. > > > > > > The way I expect it to work is to use JAR files but in the MANIFEST add > > > > > > OpenIDE-Module-ScriptEngine: nashorn > > > > > > then all class references will be interpreted through the script engine. > > > > > > So, I could have > > > > > > OpenIDE-Module-Install: ro/emilianbold/js/install.js > > > > > > Then in META-INF/services/name.of.Class I could add > > > > > > ro/emilianbold/js/myservice.js > > > > > > For layer .instance file we could have another attribute like > > > > > > <file name="x.instance"> > > > <attr name="instanceScript" > > > stringvalue="ro/emilianbold/js/serviceimpl.js"/> > > > </file> > > > > > > or maybe register the extension and treat .EXT.instance as a script: > > > > > > OpenIDE-Module-ScriptExtension: js > > > <file name="ro-emilianbold-js-serviceimpl.js.instance" /> > > > > > > Were there some prior attempts towards something like this? > > > > > > Does anybody want to help me spec this out and write some prototype? > > > > > > One area that will be sub-optimal is lazy-loading: I believe the module > > > system used reflection to instantiate lazily services. This will not work > > > for scripts as they will have to be loaded and executed. Still, I believe > > > this will be manageable. > > > > > > PS: Also CCing [email protected] > > > > > > --emi > > > > >
