Further to my little project - I have now added a Crash folder which will run a JavaScript file from within the external jar file. The standard rhino.jar file is also required, of course. This is a small demo to allow JavaScript applications (particularly command line) to be 'bundled' within the jar file, no more external files lying around which can be deleted or modified.
http://code.google.com/p/frizione/source/browse/branches/BleedingEdge/Frizione-Rhino Unfortunately, small modifications were required to org.mozilla.javascript.tools.shell.Main and org.mozilla.javascript.tools.shell.Global, but I used the same technique as for Frizione, Helma and YUICompressor - the rhino.jar (aka js.jar) remains unaltered, but there is also a 'special' jar file with the changed classes. The whole application, scripts, images, or other resources, can now be packaged in just two jar files. Norris's excellent shell code already works with URL references to the files, so the actual modifications were quite trivial. John Leach, Verona, Italy On Jul 25, 4:32 pm, Charles Lowell <[EMAIL PROTECTED]> wrote: > From my perspective, these changes would fit the criterion of > "generally useful" > > I took a look at the metaobject patch from Helma, and it seems like it > seeks to accomplish something very similar to what I'm doing with > crosscheck. So, for what it's worth, I would also like to see > something resembling this as part of the core library. > > In order to simulate a browser host environment with custom javascript > code (For several reasons, writing the host environment in javascript > is much easier than doing so in java), I need to have generic get/set/ > delete operations that do not necessarily know the name/index of the > property in advance. > > Thus far, I've been using AspectJ to monkey patch ScriptableObject and > intercept calls to get/set and friends to check for a __do_get__, > __do_set__, __do_remove__ properties. > > I would also like a way to control enumerability from inside > javascript. > > On Jul 23, 8:09 pm, Norris Boyd <[EMAIL PROTECTED]> wrote: > > > > > On Jul 22, 12:58 am, John Leach <[EMAIL PROTECTED]> wrote: > > > > Dear list, > > > > One of the problems I've had in my JavaScript development tools > > > project Frizionehttp://code.google.com/p/frizione > > > is that Helma is using a modified version of Rhino, as does > > > YUICompressor. Unfortunately that means they don't play well together, > > > so I had to launch YUICompressor as a process - which seemed > > > ridiculous. > > > > I've built a little sub project, which you can find > > > here:http://code.google.com/p/frizione/source/browse/branches/BleedingEdge... > > > This uses a clean Rhino codebase, with separate modified Java source > > > files, then compiles to produce two jar files - the unmodified Rhino > > > jar (the purpose is not to do this, just grab the prebuilt jar from > > > mozilla) and a separate jar file which contains the modified Rhino > > > code. > > > > With that done, Just load the modified jar before the standard Rhino > > > jar, and everything works nicely. > > > > Having said that, I'd like your opinion on licensing. Some of the > > > projects are MIT, some BSD, and of course Rhino is tri-license. I've > > > included all the licenses, but I don;t know if that is enough. The > > > second problem is that I have to (necessarily) include the Rhino > > > sources, which I'm not wildly happy about. I suppose I could use Ant > > > CVS to grab the code, which would be better. Any advice greatly > > > appreciated. > > > > FYI, is the build.xml for toolsrc broken? It uses "classes" (lines 79, > > > 81, 87, and 91) and "js.jar" (lines 83 and 90) which I converted to "$ > > > {classes}" and "${dist.dir}/${rhino.jar}" respectively. Works a treat > > > with those changes made. > > > > John Leach > > > Verona, Italy > > > > P.S. for James Burke - I haven't been able to integrate ShrinkSafe. I > > > took a look at the code, but it seems to modify the Rhino Main class, > > > instead of rolling its own. I don;t know enough about ShrinkSafe (nor > > > how it is used) to do the modifications right now. Perhaps the Helma > > > and YUICompressor modifications can help... > > > > John > > > Ideally we'd just incorporate the changes needed by Helma and > > YUICompressor back into Rhino itself, provided they're generally > > useful. Do you know what the nature of the changes to Rhino are? > > > --Norris _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
