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.
The compile time classpath is where SLING-945 applies. See my other message.
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.
In the Scala scripting engine of Sling I implemented and abstraction
layer for such cases [1]. That is, the scripting engine itself does not
have any dependency on Sling. There are parametrization classes [2] in
Sling which adapt the scripting engine for Sling. We can put the Sling
classloader to use there. So other implementations wouldn't be affected.
Michael
[1]
http://svn.apache.org/viewvc/sling/trunk/contrib/scripting/scala/script/src/main/scala/org/apache/sling/scripting/scala/ScriptInfo.scala?view=markup
http://svn.apache.org/viewvc/sling/trunk/contrib/scripting/scala/script/src/main/scala/org/apache/sling/scripting/scala/SettingsProvider.scala?view=log
[2]
http://svn.apache.org/viewvc/sling/trunk/contrib/scripting/scala/config/src/main/java/org/apache/sling/scripting/scala/config/
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
