Hi, I haven't looked at the script engine implementation in detail and I don't know much about the scala stuff, but :) it would be much nicer if the script engine (or even the compiler?) would directly use the Sling Commons classloader instead of creating a class path by itself. The commons classloader is used by all other scripting languages we have and provides access to all public stuff comming from bundles. It registers for bundle update/added/removed events and handles all these cases. When using this classloader there is no need for a dynamic import * for the compiler (or script engine) either - as long as this stuff uses the dynamic class loader to load classes.
Regards Carsten Reto Bachmann-Gmuer wrote > Hello > > I've been working on a 2.8.0 based implementation. The current version > provides a service implementing javax.script.ScriptEngineFactory it > doesn't yet implement javax.script.Compilable but caches the classpath > refreshing it only after a bundle-event occurred. ScriptException are > not yet thrown with correct message and line-number (this depends on > an open scala interpreter ticket). > > For now its in the clerezza repository, however it has no dependency > on any other clerezza project so it could easily be move to a more > appropriate place. > > I welcome feedback, the code is here: > http://svn.apache.org/viewvc/incubator/clerezza/trunk/scala-scripting/ > > Cheers, > reto > > On Wed, May 5, 2010 at 12:58 PM, Reto Bachmann-Gmuer > <reto.bachm...@trialox.org> wrote: >> first I was in holidays and the I missed this thread, sorry for the late >> reply. >> >> I favor the variant with Apache Commons, I think this would allow as to do a >> release as soon as we're ready without having to bother about the scala >> process (obviously in the long run it should become just part of scala, but >> till then its perfectly feasible to have a separate osgi and scripting >> wrapper). >> >> The implementation in clerezza does cache precompiled scripts, but initial >> compiling is probably slower than it needs to be. >> >> What are the steps to create a commons-project? what would the project be >> commons-scala, commons-osgi or commons scripting? >> >> Reto >> >> On Mon, Apr 26, 2010 at 6:26 PM, Michael Dürig <michael.due...@day.com> >> wrote: >>> >>> Thanks Bertrand, for pointing this out. I'd see Apache Commons as a viable >>> place. Granting additional persons commit rights to the Scala scripting >>> engine in Sling seems more like an intermediate solution to me if we want to >>> make the script engine easily shareable across otherwise unrelated projects. >>> >>> Michael >>> >>> On 4/26/10 5:55 PM, Bertrand Delacretaz wrote: >>>> >>>> On Mon, Apr 26, 2010 at 3:52 PM, Michael Dürig<michael.due...@day.com> >>>> wrote: >>>>> >>>>> ...I think it might be worthwhile to check whether we could move >>>>> the Scala scripting engine to the Scala incubator [3]. This would make >>>>> it >>>>> much easier for non Sling committers (like me and Reto I suppose) to get >>>>> things done and to use the script engine. Furthermore the scripting >>>>> engine >>>>> would ultimately profit from contributions from users of different >>>>> backgrounds.... >>>> >>>> Alternatives might be to move the scala engine to Apache Commons, or >>>> keep it in Sling but grant commit access to Apache commiiters (like >>>> yourself and Reto) willing to work on it. The Sling PMC can open parts >>>> of its code to committers from other Apache projects (IMO - that would >>>> need a PMC vote of course). >>>> >>>> I'm not saying that's better than your suggestion, just wanted to >>>> point to those alternatives. >>>> >>>> -Bertrand >> >> > -- Carsten Ziegeler cziege...@apache.org
