Hi Carsten One hand there's the runtime classloader, there the sling classloader might be used. Independent from this is the compiler classpath which in scala is different ans not a standard java-classloader.
I'm not sure what the advantages of the sling-classloader is compared with the standard osgi-methods (including dynamic-import). Also I don't know if the sling classpath can easily be used independently of sling. My goal was to implement something without any framework dependency. Cheers, reto On Tue, Jun 1, 2010 at 8:48 AM, Carsten Ziegeler <cziege...@apache.org> wrote: > 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 >
