On Mon, Jun 16, 2008 at 9:14 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am not 100% clear, whether I understand the issue (and my Scala
> knowledge is close to NIL).
>
> But if Scala really needs an explicit class path (with Strings not
> URLs !), I would say, this is a real problem and virtually prevents
> Scala from being used in a truly embedded way.
>
> I tend to think, this a fundamental shortcomming of this whole
> stuff ....
>
> Maybe Bertrand has more insight...
>
>
> Of course, there could be a solution to this problem, but to be honest,
> I really do NOT like it and would more like consider it a "short-term
> workaround to get this thing running" solution and would oppose to any
> release of such a thing.
>
> Having said this, here is the solution: Copy the required library to
> some filesystem location at runtime and refer to it with the filesystem
> path:
Another (just as ugly but maybe less resource intensive) workaround
could be to register a URLHandlerService with the framework for a
magic protocol (like e.g. scala-sling://). The implementation of the
handler would then just delegate to the bundle.getResource method.
I agree that the correct thing to do is to figure out how to make
scala use something else then a string classpath.
regards,
Karl
> BundleContext context = BundleContext of Scala
> ScriptEngineFactory bundle
> URL resource = bundle.getEntry("name of scala library");
> File file =
> context.getDataFile("someFolder/scala.lib.name.jar");
> // copy resource to file
> // add file.getAbsolutePath() to class path
>
> This could could be run at bundle start time. While at bundle stop time,
> I suggest to cleanup the filesystem again and remove the library file.
> Alternatively you could copy the interpreter file to the file system on
> request instead at bundle start time.
>
> But, to repeat myself: The correct solution would be to get Scala to
> operate on a ClassLoader and NOT on some class path based on
> String-ified URLs
>
> Regards
> Felix
>
>
> Am Montag, den 16.06.2008, 00:40 +0530 schrieb janandith jayawardena:
>> Hi,
>>
>> The report is a bit different this week because my intention was to load the
>> scala Interpreter in sling.
>>
>> I tried to fix the scala interpreter loading problem this week. This is the
>> most important thing in sling-scala.
>>
>> In doing so I found that the Scala Interpreter is a special case of the
>> compiler.[1]
>> That means a wrapper to the compiler.
>> The compiler has to be notified the classpath location to the
>> scala-library-2.7.1.jar or other scala-library jar version.
>>
>> This should be done by passing it using the scala.tools.nsc.Settings object.
>> If the classpath is not specified Interpreter will look in the paths it
>> guesses as in [2].
>>
>>
>> I tried the following and different variations of them but failed,
>>
>> 1. Inside the engine I tried the solution suggested by Felix using
>> ClassLoader.currentTheread().
>>
>> 2. loading "scala.tools.nsc.Interpreter" using
>> ClassLoader.loadClass("scala.tools.nsc.Interpreter") which returns null.
>>
>> 3. Reading the URL of the parent class loaders which doesn't go beyond
>> "felix://extensions/" I passed this to the Settings.
>>
>> 4. Using the <Import-package> and <Private-Package> directives in maven.
>> These help compiling but doesn't include the scala-library to the current
>> class path.
>>
>> 5. The "maven-scala-plugin" is only able to compile and run scala code using
>> the "compile" , "testcompile". There is no "install" goal. This requires
>> .scala files. Even though java code can be run in scala I think scala byte
>> code cannot be run in the jvm. Although I tried to change the extension
>> there were syntax errors because the plugin expects scala syntax for
>> methods.
>>
>> 6. Tried to write a dummy class in scala which creates the interpreter and
>> passes it the Setting without absolute path and pass it the script string
>> within eval method.
>>
>> As the bundle ID reads I have tried these a 184 times.
>>
>>
>> My suggested solution,
>>
>> 1. While compiling in maven copy the
>> "m2/repository/org/scala-lang/scala-library/2.7.1/scala-library-2.7.1.jar"
>> in to a directory in target/lib and create a plain file with the version.
>> Then possible to give the classpath as "/lib/scala-library"+ version +
>> "jar".
>>
>> I don't know whether it's possible in maven or how it's done if possible.
>>
>>
>> 2. Create an osgi bundle using the existing maven dependancy "scala-library"
>> in repository to include it in "apache felix". This might help in solving
>> the problem but I don't know the correct way to do it. According to what I
>> found in google it's possible to create osgi bundles in scala code and
>> compile using the "maven-scala-plugin" but what I want is to wrap the
>> scla-library as a bundle to load in sling while building using maven..
>>
>> 3. Setting an environment variable to the maven repository and get the
>> classpath using
>> "org/scala-lang/scala-library/2.7.1/scala-library-2.7.1.jar".
>>
>>
>>
>> I'm currently confused with this problem. I can write tests for the current
>> code but even though all other code is completed using
>>
>> "Settings.classpath().value_$eq("/home/janandith/.m2/repository/org/scala-lang/scala-library/2.7.1/scala-library-2.7.1.jar");"
>> temporarily it would leave with the same problem of avoiding path setting in
>> the completed project.
>>
>> What are your suggesstions ?. How can I move forward in solving this issue.
>>
>>
>> [1]
>> https://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/compiler/scala/tools/nsc/Interpreter.scala
>> [2]
>> https://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/compiler/scala/tools/nsc/Settings.scala
>
>
--
Karl Pauls
[EMAIL PROTECTED]
