You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Bertrand Delacretaz (JIRA)" <ji...@apache.org> on 2008/06/20 11:19:45 UTC
[jira] Created: (SLING-549) Scala interpreter should use the
current ClassLoader instead of rebuilding its own classpath
Scala interpreter should use the current ClassLoader instead of rebuilding its own classpath
--------------------------------------------------------------------------------------------
Key: SLING-549
URL: https://issues.apache.org/jira/browse/SLING-549
Project: Sling
Issue Type: Bug
Components: Scripting
Reporter: Bertrand Delacretaz
Priority: Minor
As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
We should find a way for it to use the current classloader instead.
Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
[1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
[2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-549) Scala interpreter should use the
current ClassLoader instead of rebuilding its own classpath
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662354#action_12662354 ]
Michael Dürig commented on SLING-549:
-------------------------------------
> 1 Is there a reason to have two projects instead of one single project ?
Separation of the Scala and the Java parts. Having mixed Scala and Java sources in a single project does not work well with the maven-scala-plugin and with the Scala Eclipse plugin ATM. We might fix this when the tools catch up.
> 2 Is there a reason to exclude the imports of Sling packages in the ScriptEngine project ?
You mean !org.apache.tools.ant.*,!org.apache.sling.jcr.api.*,!org.apache.sling.scripting.api.* ?
I could not get the bundle to install without excluding these:
!! org.apache.sling.jcr.api,version=2.0.3.incubator-SNAPSHOT from -- Cannot be resolved
and so on.
3 and 4 are inherited from when I took over the GSoC code base. Should be easy to fix.
> Scala interpreter should use the current ClassLoader instead of rebuilding its own classpath
> --------------------------------------------------------------------------------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-549) Scala interpreter should use the
current ClassLoader instead of rebuilding its own classpath
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606703#action_12606703 ]
Bertrand Delacretaz commented on SLING-549:
-------------------------------------------
Asked on scala-user, see http://www.nabble.com/How-to-compile-Scala-code-from-java-using-the-current-ClassLoader-instead-of-a-string-based-classpath--tt18026672.html
> Scala interpreter should use the current ClassLoader instead of rebuilding its own classpath
> --------------------------------------------------------------------------------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Priority: Minor
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-549) Scala interpreter should use the
current ClassLoader instead of rebuilding its own classpath
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dürig updated SLING-549:
--------------------------------
Attachment: SLING-549.patch
This patch implements a Scala scripting engine:
- Scala compiler 2.7.2 (most recent stable version)
- Scripts are compiled into /var/classes by default (configurable)
- Recompilation of scripts as needed
- Supports dynamic package import
- Pre-build binaries are available from the interim project page at http://code.google.com/p/sling-scala/ (revision 129)
Possible improvements/changes
- Add configuration settings for compiler options
- Make the script wrapper more flexible
- Instead of rolling an own script wrapper, make Scripts implement the Servlet interface
> Scala interpreter should use the current ClassLoader instead of rebuilding its own classpath
> --------------------------------------------------------------------------------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-549) Scala script engine
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bertrand Delacretaz updated SLING-549:
--------------------------------------
Summary: Scala script engine (was: Scala interpreter should use the current ClassLoader instead of rebuilding its own classpath)
Renaming the issue as Michael's lates patch provides complete Scala scripting engine
> Scala script engine
> -------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: SLING-549-2.patch, SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-549) Scala script engine
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669723#action_12669723 ]
Michael Dürig commented on SLING-549:
-------------------------------------
ok everything seems to work fine. The only thing I noticed is that the Scala scripting engine is not buildable from sling\scripting\scala. If I try to do so Maven fails with
[INFO] Project 'org.apache.sling:org.apache.sling.scripting.scala' is duplicated in the reactor
If this is not easy to fix, I suggest to remove the reactor pom from that location.
I'll follow up on the integration test later this week.
> Scala script engine
> -------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Assignee: Felix Meschberger
> Priority: Minor
> Attachments: SLING-549-2.patch, SLING-549-3.patch, SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-549) Scala script engine
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700220#action_12700220 ]
Michael Dürig commented on SLING-549:
-------------------------------------
I created SLING-928 for the missing integration test and added a patch there.
So I think this issue can be closed.
> Scala script engine
> -------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Assignee: Felix Meschberger
> Priority: Minor
> Attachments: SLING-549-2.patch, SLING-549-3.patch, SLING-549-integration-test.patch, SLING-549-integration-test.patch, SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-549) Scala interpreter should use the
current ClassLoader instead of rebuilding its own classpath
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610818#action_12610818 ]
Bertrand Delacretaz commented on SLING-549:
-------------------------------------------
In the scala eclipse plugin [1], the intializePaths() method sets the classpath for the scala compiler. That plugin looks like a good example of using the compiler, but it also uses a list of strings for the classpath (which makes sense in an IDE context).
[1] http://lampsvn.epfl.ch/svn-repos/scala/scala-plugin/trunk/src/scala/tools/eclipse/ScalaPlugin.scala
> Scala interpreter should use the current ClassLoader instead of rebuilding its own classpath
> --------------------------------------------------------------------------------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Priority: Minor
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-549) Scala script engine
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669581#action_12669581 ]
Bertrand Delacretaz commented on SLING-549:
-------------------------------------------
Thanks Felix for taking care of this.
> Could you please verify that everything works alright and then close this issue ?
Michael, while you're at it, could you add an integration test for this module in the launchpad/testing module?
A smoke test similar to [1] would be good already, just something that proves that the Scala engine is basically working. This would also require adding the required sling/scala modules to launchpad/testing/pom.xml
[1]
launchpad/testing/src/test/resources/integration-test/rendering-test.jsp
and
launchpad/testing/src/test/java/org/apache/sling/launchpad/webapp/integrationtest/JspScriptingTest.java
> Scala script engine
> -------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Assignee: Felix Meschberger
> Priority: Minor
> Attachments: SLING-549-2.patch, SLING-549-3.patch, SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-549) Scala script engine
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675944#action_12675944 ]
Bertrand Delacretaz commented on SLING-549:
-------------------------------------------
SLING-865 means integration tests will need to be moved to contrib/launchpad/testing. I'm fine with doing that, just making a note here to remember it.
> Scala script engine
> -------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Assignee: Felix Meschberger
> Priority: Minor
> Attachments: SLING-549-2.patch, SLING-549-3.patch, SLING-549-integration-test.patch, SLING-549-integration-test.patch, SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-549) Scala interpreter should use the
current ClassLoader instead of rebuilding its own classpath
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662363#action_12662363 ]
Felix Meschberger commented on SLING-549:
-----------------------------------------
1. ok then
2. resolution issue: This might be caused by your environment ;-) If you don't really depend SNAPSHOT API functionality, you might as well declare the released version dependencies (2.0.2-incubator).
> Scala interpreter should use the current ClassLoader instead of rebuilding its own classpath
> --------------------------------------------------------------------------------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-549) Scala script engine
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dürig updated SLING-549:
--------------------------------
Attachment: SLING-549-3.patch
Updated patch:
- Upgraded to Scala 2.7.3
- Fixed problem with boot delegation and system packages not found by the Scala compiler
- Added better string representation of file system abstraction of bundle content
> Scala script engine
> -------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: SLING-549-2.patch, SLING-549-3.patch, SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-549) Scala interpreter should use the
current ClassLoader instead of rebuilding its own classpath
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662271#action_12662271 ]
Felix Meschberger commented on SLING-549:
-----------------------------------------
Thanks for supplying this patch
I have the following remarks:
1 Is there a reason to have two projects instead of one single project ?
2 Is there a reason to exclude the imports of Sling packages in the ScriptEngine project ?
3 Source files miss the ASL license headers.
4 Please explicitly state the versions in the dependency elements for the
sling artifacts. Using variables won't work in the long run. And also refer to
released artifacts unless you require functionality from SNAPSHOTs
I think, we can fix the third and fourth issue when applying the patch.
> Scala interpreter should use the current ClassLoader instead of rebuilding its own classpath
> --------------------------------------------------------------------------------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-549) Scala script engine
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger resolved SLING-549.
-------------------------------------
Resolution: Fixed
Thanks for supplying (and maintaining) the patch. I have applied it in Rev. 739973 with some modifications:
* Removed the META-INF/services/javax.script:ScriptEngineFactory file since the ScriptEngineFactory
is registered as an OSGi service
* Fixed the README.txt, LICENSE, NOTICE and DISCLAIMER files
* Set the version to 0.9.0-incubator-SNAPSHOT, assuming an initial 1.0.0 version
* Fixed dependencies
* Fixed bundle generation to not require compile scope dependencies
AFAICT this makes a usable OSGi bundle, but since I don't know any Scala, I could not really verify.
Could you please verify that everything works alright and then close this issue ? Thanks.
> Scala script engine
> -------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Assignee: Felix Meschberger
> Priority: Minor
> Attachments: SLING-549-2.patch, SLING-549-3.patch, SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-549) Scala script engine
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger reassigned SLING-549:
---------------------------------------
Assignee: Felix Meschberger
> Scala script engine
> -------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Assignee: Felix Meschberger
> Priority: Minor
> Attachments: SLING-549-2.patch, SLING-549-3.patch, SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-549) Scala script engine
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dürig updated SLING-549:
--------------------------------
Attachment: SLING-549-integration-test.patch
Same patch as before but with correct ASF license settings for the Attachment
> Scala script engine
> -------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Assignee: Felix Meschberger
> Priority: Minor
> Attachments: SLING-549-2.patch, SLING-549-3.patch, SLING-549-integration-test.patch, SLING-549-integration-test.patch, SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-549) Scala script engine
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dürig updated SLING-549:
--------------------------------
Attachment: SLING-549-integration-test.patch
Smoke test as suggested by Bertrand
> Scala script engine
> -------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Assignee: Felix Meschberger
> Priority: Minor
> Attachments: SLING-549-2.patch, SLING-549-3.patch, SLING-549-integration-test.patch, SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-549) Scala script engine
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669894#action_12669894 ]
Felix Meschberger commented on SLING-549:
-----------------------------------------
Oops, the reactor used the same artifactId as the ScriptEngine project. I fixed this to be ...reactor now in Rev. 740242. Also in this revision I modified the root reactor POM to refer to the scala reactor instead of the projects directly.
> Scala script engine
> -------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Assignee: Felix Meschberger
> Priority: Minor
> Attachments: SLING-549-2.patch, SLING-549-3.patch, SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-549) Scala interpreter should use the
current ClassLoader instead of rebuilding its own classpath
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dürig updated SLING-549:
--------------------------------
Attachment: SLING-549-2.patch
Updated patch:
- No more snapshot dependencies
- No more exclusion of Sling packages
- Added license information and headers
> Scala interpreter should use the current ClassLoader instead of rebuilding its own classpath
> --------------------------------------------------------------------------------------------
>
> Key: SLING-549
> URL: https://issues.apache.org/jira/browse/SLING-549
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: SLING-549-2.patch, SLING-549.patch
>
>
> As the code at [1] demonstrates, the scala interpreter rebuilds its own classpath from the current JVM classpath and user-supplied additions.
> We should find a way for it to use the current classloader instead.
> Note that the almost same test [2] works when run with "mvn test" without setting the classpath explicitly, probably because in this case the JVM classpath includes the scala jars.
> [1] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/main/java/org/apache/sling/scripting/scala/minbundle/ScalaCompileServlet.java
> [2] http://code.google.com/p/sling-scala/source/browse/trunk/scala-min-bundle/src/test/java/org/apache/sling/scripting/scala/minbundle/ScalaCompilerTest.java?r=38
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.