Carsten,
The reason for the current approach has to do with SLING-945 [1]. I
didn't look at the Sling Commons classloader but I suppose it doesn't
fulfill the requirements of the Scala compiler. Proof me wrong, then I'm
happy to fix that... as soon as I'm done with other stuff :)
Michael
https://issues.apache.org/jira/browse/SLING-945
On 1.6.10 8:48, Carsten Ziegeler 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
