You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Reto Bachmann-Gmuer <re...@trialox.org> on 2010/05/05 12:58:15 UTC
Re: Scala scripting support (was Re: And another one ;-))
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 <mi...@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<mi...@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
>>
>
Re: Scala scripting support (was Re: And another one ;-))
Posted by Michael Dürig <mi...@day.com>.
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
>> <re...@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<mi...@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<mi...@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
>>>
>>>
>>
>
>
Re: Scala scripting support (was Re: And another one ;-))
Posted by Michael Dürig <mi...@day.com>.
> 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<cz...@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
>>> <re...@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<mi...@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<mi...@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
>> cziegeler@apache.org
>>
Re: Scala scripting support (was Re: And another one ;-))
Posted by Reto Bachmann-Gmuer <re...@trialox.org>.
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 <cz...@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
>> <re...@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 <mi...@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<mi...@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
> cziegeler@apache.org
>
Re: Scala scripting support (was Re: And another one ;-))
Posted by Carsten Ziegeler <cz...@apache.org>.
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
> <re...@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 <mi...@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<mi...@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
cziegeler@apache.org
Re: Scala scripting support (was Re: And another one ;-))
Posted by Michael Dürig <mi...@day.com>.
Reto,
Thanks for providing a link to your work. I'm a bit busy with other
stuff at the moment so I can't promise to look into it right away.
Having work toward Scala 2.8 is great though!
AFAICS the Sling and the Clerezza code bases of the Scala scripting
engine are diverging a bit. It would be great if we could merge the best
of both worlds together on the long run. I think a good approach would
be to do that at the scripting engine's "new home" and then take it from
there for the individual projects. WDYT?
Michael
On 1.6.10 0:15, 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
> <re...@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<mi...@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<mi...@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
>>
>>
Re: Scala scripting support (was Re: And another one ;-))
Posted by Reto Bachmann-Gmuer <re...@trialox.org>.
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
<re...@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 <mi...@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<mi...@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
>
>