Running scala-library in the IDE

674 views
Skip to first unread message

Simon Schäfer

unread,
Jul 10, 2014, 7:03:47 AM7/10/14
to scala-...@googlegroups.com
After adding scala-reflect and scala-compiler as OSGi bundles to the IDE and starting it up, I got the following error message:

sbt.InvalidScalaInstance: Scala instance doesn't exist or is invalid:
    version 2.11.2.-20140706-234733-75ac225015, library jar: /home/antoras/Software/scala-eclipse/plugins/org.scala-lang.scala-library_2.11.2.v20140706-234733-75ac225015.jar, compiler jar: /home/antoras/dev/scala/scala/src/eclipse/scala-compiler
    at sbt.ScalaInstance$.slowActualVersion(ScalaInstance.scala:122)

However, the expected library exists on the shown path. I got the OSGi bundles by doing:

cp ~/Software/scala-eclipse/plugins/org.scala-lang.scala-reflect_2.11.2.v20140706-234733-75ac225015.jar .
jar xf org.scala-lang.scala-reflect_2.11.2.v20140706-234733-75ac225015.jar
cp -r META-INF ~/dev/scala/scala/src/eclipse/reflect/.

And similar for scala-compiler. I also had to add some dependencies that are somewhere in scala/build. Doing the same for scala-library leads to the error message (this time it is already a build path error, I don't need to startup the IDE to get it):

scala.reflect.internal.Types$TypeError: bad symbolic reference to scala.concurrent.forkjoin encountered in class file 'DrainableForkJoinPool.class'.
Cannot access term forkjoin in package scala.concurrent. The current classpath may be
missing a definition for scala.concurrent.forkjoin, or DrainableForkJoinPool.class may have been compiled against a version that's
incompatible with the one found on the current classpath.

But adding scala/build/libs/forkjoin.jar didn't help. Any ideas what is the problem?

François Garillot

unread,
Jul 10, 2014, 8:33:19 AM7/10/14
to scala-...@googlegroups.com
On Thu, Jul 10, 2014 at 1:03 PM, Simon Schäfer <ma...@antoras.de> wrote:
> After adding scala-reflect and scala-compiler as OSGi bundles to the IDE and
> starting it up, I got the following error message:
>
> sbt.InvalidScalaInstance: Scala instance doesn't exist or is invalid:
> version 2.11.2.-20140706-234733-75ac225015, library jar:
> /home/antoras/Software/scala-eclipse/plugins/org.scala-lang.scala-library_2.11.2.v20140706-234733-75ac225015.jar,
> compiler jar: /home/antoras/dev/scala/scala/src/eclipse/scala-compiler
> at sbt.ScalaInstance$.slowActualVersion(ScalaInstance.scala:122)

Is this error message truncated ? If not, why is a message supposed to
display a path to a jar displaying a path to a directory ?

> However, the expected library exists on the shown path. I got the OSGi
> bundles by doing:
>
> cp
> ~/Software/scala-eclipse/plugins/org.scala-lang.scala-reflect_2.11.2.v20140706-234733-75ac225015.jar

What's the second argument to cp ?

> jar xf org.scala-lang.scala-reflect_2.11.2.v20140706-234733-75ac225015.jar
> cp -r META-INF ~/dev/scala/scala/src/eclipse/reflect/.

Because the '-r' argument is superfluous (since the copy source is a
file), it's unclear whether the command above reflects what you meant
to show.

> And similar for scala-compiler. I also had to add some dependencies that are
> somewhere in scala/build. Doing the same for scala-library leads to the
> error message (this time it is already a build path error, I don't need to
> startup the IDE to get it):

By 'build path error', you mean that the Host eclipse you are running
interprets this as an error over the test IDE's eclipse project
configuration ?

FYI If you just want to run a custom version of Scala in your test IDE
(though not necessarily build on it), PR #731 lets you do that easily,
with a GUI and all the niceties.

--
François Garillot

iulian dragos

unread,
Jul 10, 2014, 8:38:41 AM7/10/14
to scala-ide-dev
On Thu, Jul 10, 2014 at 1:03 PM, Simon Schäfer <ma...@antoras.de> wrote:
After adding scala-reflect and scala-compiler as OSGi bundles to the IDE and starting it up, I got the following error message:

sbt.InvalidScalaInstance: Scala instance doesn't exist or is invalid:
    version 2.11.2.-20140706-234733-75ac225015, library jar: /home/antoras/Software/scala-eclipse/plugins/org.scala-lang.scala-library_2.11.2.v20140706-234733-75ac225015.jar, compiler jar: /home/antoras/dev/scala/scala/src/eclipse/scala-compiler
    at sbt.ScalaInstance$.slowActualVersion(ScalaInstance.scala:122)

Looking at the Sbt source code (where the exception originates), gives:

private def slowActualVersion(scalaLoader: ClassLoader)(label: String) =
{
val v = try { Class.forName("scala.tools.nsc.Properties", true, scalaLoader).getMethod("versionString").invoke(null).toString }
catch { case cause: Exception => throw new InvalidScalaInstance("Scala instance doesn't exist or is invalid: " + label, cause) }
if(v.startsWith(VersionPrefix)) v.substring(VersionPrefix.length) else v
}

I'm surprised there's no stack trace after the error message ("cause"). It might be that Sbt needs a jar file in order to build, and you're using a local build of Scala (which is a directory). Or, maybe, `scala.tools.nsc.Properties` doesn't exist?




However, the expected library exists on the shown path. I got the OSGi bundles by doing:

cp ~/Software/scala-eclipse/plugins/org.scala-lang.scala-reflect_2.11.2.v20140706-234733-75ac225015.jar .
jar xf org.scala-lang.scala-reflect_2.11.2.v20140706-234733-75ac225015.jar
cp -r META-INF ~/dev/scala/scala/src/eclipse/reflect/.

And similar for scala-compiler. I also had to add some dependencies that are somewhere in scala/build. Doing the same for scala-library leads to the error message (this time it is already a build path error, I don't need to startup the IDE to get it):

scala.reflect.internal.Types$TypeError: bad symbolic reference to scala.concurrent.forkjoin encountered in class file 'DrainableForkJoinPool.class'.
Cannot access term forkjoin in package scala.concurrent. The current classpath may be
missing a definition for scala.concurrent.forkjoin, or DrainableForkJoinPool.class may have been compiled against a version that's
incompatible with the one found on the current classpath.

But adding scala/build/libs/forkjoin.jar didn't help. Any ideas what is the problem?

--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/53BE7311.7070202%40antoras.de.
For more options, visit https://groups.google.com/d/optout.



--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

Simon Schäfer

unread,
Jul 10, 2014, 9:02:40 AM7/10/14
to scala-...@googlegroups.com

On 07/10/2014 02:32 PM, François Garillot wrote:
On Thu, Jul 10, 2014 at 1:03 PM, Simon Schäfer <ma...@antoras.de> wrote:

After adding scala-reflect and scala-compiler as OSGi bundles to the IDE and
starting it up, I got the following error message:

sbt.InvalidScalaInstance: Scala instance doesn't exist or is invalid:
    version 2.11.2.-20140706-234733-75ac225015, library jar:
/home/antoras/Software/scala-eclipse/plugins/org.scala-lang.scala-library_2.11.2.v20140706-234733-75ac225015.jar,
compiler jar: /home/antoras/dev/scala/scala/src/eclipse/scala-compiler
    at sbt.ScalaInstance$.slowActualVersion(ScalaInstance.scala:122)

Is this error message truncated ? If not, why is a message supposed to
display a path to a jar displaying a path to a directory ?
Oh, yes sorry, it is truncated. The full one is

sbt.InvalidScalaInstance: Scala instance doesn't exist or is invalid:
    version 2.11.2.-20140706-234733-75ac225015, library jar: /home/antoras/Software/scala-eclipse/plugins/org.scala-lang.scala-library_2.11.2.v20140706-234733-75ac225015.jar, compiler jar: /home/antoras/dev/scala/scala/src/eclipse/scala-compiler
    at sbt.ScalaInstance$.slowActualVersion(ScalaInstance.scala:122)
    at sbt.ScalaInstance$.sbt$ScalaInstance$$actualVersion(ScalaInstance.scala:119)
    at sbt.ScalaInstance$$anonfun$actualVersion$1.apply(ScalaInstance.scala:32)
    at sbt.ScalaInstance$$anonfun$actualVersion$1.apply(ScalaInstance.scala:32)
    at scala.Option.getOrElse(Option.scala:120)
    at sbt.ScalaInstance.actualVersion$lzycompute(ScalaInstance.scala:32)
    at sbt.ScalaInstance.actualVersion(ScalaInstance.scala:32)
    at sbt.compiler.AggressiveCompile.apply(AggressiveCompile.scala:45)
    at org.scalaide.core.internal.builder.zinc.EclipseSbtBuildManager.aggressiveCompile(EclipseSbtBuildManager.scala:254)
    at org.scalaide.core.internal.builder.zinc.EclipseSbtBuildManager.runCompiler(EclipseSbtBuildManager.scala:150)
    at org.scalaide.core.internal.builder.zinc.EclipseSbtBuildManager.update(EclipseSbtBuildManager.scala:141)
    at org.scalaide.core.internal.builder.zinc.EclipseSbtBuildManager.build(EclipseSbtBuildManager.scala:195)
    at org.scalaide.core.internal.project.ScalaProject.build(ScalaProject.scala:697)
    at org.scalaide.core.internal.builder.ScalaBuilder.build(ScalaBuilder.scala:125)
    at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:733)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
    at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
    at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
    at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
    at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
    at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Caused by: java.lang.ClassNotFoundException: scala.tools.nsc.Properties
    at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:270)
    ... 26 more

Seems like the real issue is that scala.tools.nsc.Properties could not be found.



However, the expected library exists on the shown path. I got the OSGi
bundles by doing:

cp
~/Software/scala-eclipse/plugins/org.scala-lang.scala-reflect_2.11.2.v20140706-234733-75ac225015.jar

What's the second argument to cp ?
It is . (the current directory).



jar xf org.scala-lang.scala-reflect_2.11.2.v20140706-234733-75ac225015.jar
cp -r META-INF ~/dev/scala/scala/src/eclipse/reflect/.

Because the '-r' argument is superfluous (since the copy source is a
file), it's unclear whether the command above reflects what you meant
to show.
-r means recursive and META-INF is a directory containing at least the manifest file.



And similar for scala-compiler. I also had to add some dependencies that are
somewhere in scala/build. Doing the same for scala-library leads to the
error message (this time it is already a build path error, I don't need to
startup the IDE to get it):

By 'build path error', you mean that the Host eclipse you are running
interprets this as an error over the test IDE's eclipse project
configuration ?
Yes


FYI If you just want to run a custom version of Scala in your test IDE
(though not necessarily build on it), PR #731 lets you do that easily,
with a GUI and all the niceties.
No, I want to run it on the sources in order to hack them.

Simon Schäfer

unread,
Jul 10, 2014, 9:04:27 AM7/10/14
to scala-...@googlegroups.com

On 07/10/2014 02:38 PM, iulian dragos wrote:



On Thu, Jul 10, 2014 at 1:03 PM, Simon Schäfer <ma...@antoras.de> wrote:
After adding scala-reflect and scala-compiler as OSGi bundles to the IDE and starting it up, I got the following error message:

sbt.InvalidScalaInstance: Scala instance doesn't exist or is invalid:
    version 2.11.2.-20140706-234733-75ac225015, library jar: /home/antoras/Software/scala-eclipse/plugins/org.scala-lang.scala-library_2.11.2.v20140706-234733-75ac225015.jar, compiler jar: /home/antoras/dev/scala/scala/src/eclipse/scala-compiler
    at sbt.ScalaInstance$.slowActualVersion(ScalaInstance.scala:122)

Looking at the Sbt source code (where the exception originates), gives:

private def slowActualVersion(scalaLoader: ClassLoader)(label: String) =
{
val v = try { Class.forName("scala.tools.nsc.Properties", true, scalaLoader).getMethod("versionString").invoke(null).toString }
catch { case cause: Exception => throw new InvalidScalaInstance("Scala instance doesn't exist or is invalid: " + label, cause) }
if(v.startsWith(VersionPrefix)) v.substring(VersionPrefix.length) else v
}

I'm surprised there's no stack trace after the error message ("cause"). It might be that Sbt needs a jar file in order to build, and you're using a local build of Scala (which is a directory). Or, maybe, `scala.tools.nsc.Properties` doesn't exist?
My mistake, there is a longer stacktrace, see the other mail.




However, the expected library exists on the shown path. I got the OSGi bundles by doing:

cp ~/Software/scala-eclipse/plugins/org.scala-lang.scala-reflect_2.11.2.v20140706-234733-75ac225015.jar .
jar xf org.scala-lang.scala-reflect_2.11.2.v20140706-234733-75ac225015.jar
cp -r META-INF ~/dev/scala/scala/src/eclipse/reflect/.

And similar for scala-compiler. I also had to add some dependencies that are somewhere in scala/build. Doing the same for scala-library leads to the error message (this time it is already a build path error, I don't need to startup the IDE to get it):

scala.reflect.internal.Types$TypeError: bad symbolic reference to scala.concurrent.forkjoin encountered in class file 'DrainableForkJoinPool.class'.
Cannot access term forkjoin in package scala.concurrent. The current classpath may be
missing a definition for scala.concurrent.forkjoin, or DrainableForkJoinPool.class may have been compiled against a version that's
incompatible with the one found on the current classpath.

But adding scala/build/libs/forkjoin.jar didn't help. Any ideas what is the problem?
--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/53BE7311.7070202%40antoras.de.
For more options, visit https://groups.google.com/d/optout.



--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.

iulian dragos

unread,
Jul 10, 2014, 9:17:45 AM7/10/14
to scala-ide-dev
On Thu, Jul 10, 2014 at 3:04 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/10/2014 02:38 PM, iulian dragos wrote:



On Thu, Jul 10, 2014 at 1:03 PM, Simon Schäfer <ma...@antoras.de> wrote:
After adding scala-reflect and scala-compiler as OSGi bundles to the IDE and starting it up, I got the following error message:

sbt.InvalidScalaInstance: Scala instance doesn't exist or is invalid:
    version 2.11.2.-20140706-234733-75ac225015, library jar: /home/antoras/Software/scala-eclipse/plugins/org.scala-lang.scala-library_2.11.2.v20140706-234733-75ac225015.jar, compiler jar: /home/antoras/dev/scala/scala/src/eclipse/scala-compiler
    at sbt.ScalaInstance$.slowActualVersion(ScalaInstance.scala:122)

Looking at the Sbt source code (where the exception originates), gives:

private def slowActualVersion(scalaLoader: ClassLoader)(label: String) =
{
val v = try { Class.forName("scala.tools.nsc.Properties", true, scalaLoader).getMethod("versionString").invoke(null).toString }
catch { case cause: Exception => throw new InvalidScalaInstance("Scala instance doesn't exist or is invalid: " + label, cause) }
if(v.startsWith(VersionPrefix)) v.substring(VersionPrefix.length) else v
}

I'm surprised there's no stack trace after the error message ("cause"). It might be that Sbt needs a jar file in order to build, and you're using a local build of Scala (which is a directory). Or, maybe, `scala.tools.nsc.Properties` doesn't exist?
My mistake, there is a longer stacktrace, see the other mail.

So, why is there no `scala.tools.nsc.Properties`? I definitely have that file under src/compiler.
 

For more options, visit https://groups.google.com/d/optout.

François Garillot

unread,
Jul 10, 2014, 9:22:52 AM7/10/14
to scala-...@googlegroups.com
On Thu, Jul 10, 2014 at 3:02 PM, Simon Schäfer <ma...@antoras.de> wrote:
>
>
> Oh, yes sorry, it is truncated. The full one is
>
> sbt.InvalidScalaInstance: Scala instance doesn't exist or is invalid:
> version 2.11.2.-20140706-234733-75ac225015, library jar:
> /home/antoras/Software/scala-eclipse/plugins/org.scala-lang.scala-library_2.11.2.v20140706-234733-75ac225015.jar,
> compiler jar: /home/antoras/dev/scala/scala/src/eclipse/scala-compiler

Have you tried putting this directory
('/home/antoras/dev/scala/scala/src/eclipse/scala-compiler') into a
jar ?


--
François Garillot

Simon Schäfer

unread,
Jul 10, 2014, 9:27:45 AM7/10/14
to scala-...@googlegroups.com

On 07/10/2014 03:17 PM, iulian dragos wrote:



On Thu, Jul 10, 2014 at 3:04 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/10/2014 02:38 PM, iulian dragos wrote:



On Thu, Jul 10, 2014 at 1:03 PM, Simon Schäfer <ma...@antoras.de> wrote:
After adding scala-reflect and scala-compiler as OSGi bundles to the IDE and starting it up, I got the following error message:

sbt.InvalidScalaInstance: Scala instance doesn't exist or is invalid:
    version 2.11.2.-20140706-234733-75ac225015, library jar: /home/antoras/Software/scala-eclipse/plugins/org.scala-lang.scala-library_2.11.2.v20140706-234733-75ac225015.jar, compiler jar: /home/antoras/dev/scala/scala/src/eclipse/scala-compiler
    at sbt.ScalaInstance$.slowActualVersion(ScalaInstance.scala:122)

Looking at the Sbt source code (where the exception originates), gives:

private def slowActualVersion(scalaLoader: ClassLoader)(label: String) =
{
val v = try { Class.forName("scala.tools.nsc.Properties", true, scalaLoader).getMethod("versionString").invoke(null).toString }
catch { case cause: Exception => throw new InvalidScalaInstance("Scala instance doesn't exist or is invalid: " + label, cause) }
if(v.startsWith(VersionPrefix)) v.substring(VersionPrefix.length) else v
}

I'm surprised there's no stack trace after the error message ("cause"). It might be that Sbt needs a jar file in order to build, and you're using a local build of Scala (which is a directory). Or, maybe, `scala.tools.nsc.Properties` doesn't exist?
My mistake, there is a longer stacktrace, see the other mail.

So, why is there no `scala.tools.nsc.Properties`? I definitely have that file under src/compiler.
If I would know that, I wouldn't have asked. I can see the file and git doesn't find any changes either.

Simon Schäfer

unread,
Jul 15, 2014, 6:00:40 PM7/15/14
to scala-...@googlegroups.com
This became even more ridiculous while I tried to fix it. Now I get a

java.lang.NoClassDefFoundError:
org/scalaide/logging/StreamRedirect$$anonfun$2$$anonfun$apply$2

(this time without the library, just with reflect and the compiler).
There occurred probably another exception, which can't be shown because
of this broken StreamRedirect thing. I'm really wondering how that could
happen - maybe an error occurred before the Scala IDE bundle is started
(but then I would wonder how the error message could be redirected to
the IDE).

Has someone a nightly scala compiler running in an IDE nightly and would
like to share their configuration?

Full error message (don't know if the NPE is important):

!ENTRY org.eclipse.ui 4 0 2014-07-15 23:47:02.232
!MESSAGE Error occurred during status handling
!STACK 0
java.lang.NullPointerException
at
org.eclipse.ui.internal.statushandlers.StatusHandlerRegistry.<init>(StatusHandlerRegistry.java:61)
at
org.eclipse.ui.internal.statushandlers.StatusHandlerRegistry.getDefault(StatusHandlerRegistry.java:91)
at
org.eclipse.ui.statushandlers.StatusManager.getStatusHandler(StatusManager.java:135)
at
org.eclipse.ui.statushandlers.StatusManager.handle(StatusManager.java:189)
at
org.eclipse.ui.statushandlers.StatusManager.handle(StatusManager.java:231)
at
org.eclipse.ui.statushandlers.StatusManager$StatusManagerLogListener.logging(StatusManager.java:305)
at
org.eclipse.core.internal.runtime.RuntimeLog.logToListeners(RuntimeLog.java:160)
at
org.eclipse.core.internal.runtime.PlatformLogWriter.logged(PlatformLogWriter.java:100)
at
org.eclipse.equinox.log.internal.ExtendedLogReaderServiceFactory.safeLogged(ExtendedLogReaderServiceFactory.java:86)
at
org.eclipse.equinox.log.internal.ExtendedLogReaderServiceFactory.logPrivileged(ExtendedLogReaderServiceFactory.java:205)
at
org.eclipse.equinox.log.internal.ExtendedLogReaderServiceFactory.log(ExtendedLogReaderServiceFactory.java:178)
at
org.eclipse.equinox.log.internal.ExtendedLogServiceFactory.log(ExtendedLogServiceFactory.java:65)
at
org.eclipse.equinox.log.internal.ExtendedLogServiceImpl.log(ExtendedLogServiceImpl.java:87)
at org.eclipse.equinox.log.internal.LoggerImpl.log(LoggerImpl.java:54)
at
org.eclipse.core.internal.runtime.PlatformLogWriter.logging(PlatformLogWriter.java:43)
at org.eclipse.core.internal.runtime.RuntimeLog.log(RuntimeLog.java:96)
at
org.eclipse.core.internal.jobs.JobManager.doShutdown(JobManager.java:606)
at
org.eclipse.core.internal.jobs.JobManager.shutdown(JobManager.java:252)
at
org.eclipse.core.internal.jobs.JobActivator.stop(JobActivator.java:55)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:771)
at java.security.AccessController.doPrivileged(Native Method)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:764)
at
org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:510)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:566)
at
org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1206)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLevelManager.java:592)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:257)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLevelManager.java:215)
at
org.eclipse.osgi.framework.internal.core.InternalSystemBundle.suspend(InternalSystemBundle.java:284)
at
org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:692)
at
org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:600)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.shutdown(EclipseStarter.java:400)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:200)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
!SESSION Tue Jul 15 23:47:02 CEST 2014
-----------------------------------------
!ENTRY org.eclipse.equinox.launcher 4 0 2014-07-15 23:47:02.397
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.lang.NoClassDefFoundError:
org/scalaide/logging/StreamRedirect$$anonfun$2$$anonfun$apply$2
at
org.scalaide.logging.StreamRedirect$$anonfun$2.apply(StreamRedirect.scala:34)
at
org.scalaide.logging.StreamRedirect$$anonfun$2.apply(StreamRedirect.scala:34)
at
org.scalaide.logging.StreamRedirect$Redirect.write(StreamRedirect.scala:60)
at java.io.PrintStream.write(PrintStream.java:480)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
at java.io.PrintStream.write(PrintStream.java:527)
at java.io.PrintStream.print(PrintStream.java:669)
at java.io.PrintStream.println(PrintStream.java:806)
at
org.eclipse.equinox.log.internal.ExtendedLogReaderServiceFactory.safeLogged(ExtendedLogReaderServiceFactory.java:94)
at
org.eclipse.equinox.log.internal.ExtendedLogReaderServiceFactory.logPrivileged(ExtendedLogReaderServiceFactory.java:205)
at
org.eclipse.equinox.log.internal.ExtendedLogReaderServiceFactory.log(ExtendedLogReaderServiceFactory.java:178)
at
org.eclipse.equinox.log.internal.ExtendedLogServiceFactory.log(ExtendedLogServiceFactory.java:65)
at
org.eclipse.equinox.log.internal.ExtendedLogServiceImpl.log(ExtendedLogServiceImpl.java:87)
at org.eclipse.equinox.log.internal.LoggerImpl.log(LoggerImpl.java:54)
at
org.eclipse.core.runtime.internal.adaptor.EclipseLogFactory$1.log(EclipseLogFactory.java:53)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:189)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
at org.eclipse.equinox.launcher.Main.main(Main.java:1426)

François Garillot

unread,
Jul 16, 2014, 8:54:36 AM7/16/14
to scala-...@googlegroups.com

Hi Simon,

This codepath has been removed by the Scala Installations support, and is not in the latest nightly. Have you tried it ?

--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/53C5A47C.3010602%40antoras.de.

Simon Schäfer

unread,
Jul 16, 2014, 10:38:38 AM7/16/14
to scala-...@googlegroups.com

On 07/16/2014 02:54 PM, François Garillot wrote:

Hi Simon,

This codepath has been removed by the Scala Installations support, and is not in the latest nightly. Have you tried it ?

Indeed, that seemed to be the prbolem. After updating everything and killing my test workspace, the compiler+reflect could be loaded correctly. 0f8b07a8d7 is the Scala version of the host platform, therefore I'm using this one now also for the OSGi bundles of the compiler+reflect. But now I get the following error message in a Scala project:


sbt.InvalidScalaInstance: Scala instance doesn't exist or is invalid:
    version 2.11.2.-20140715-230701-0f8b07a8d7, library jar: /home/antoras/Software/scala-eclipse/plugins/org.scala-lang.scala-library_2.11.2.v20140715-230701-0f8b07a8d7.jar, compiler jar: /home/antoras/dev/scala/scala/src/eclipse/scala-compiler

(see full stacktrace below). The problem seems to be that the compiler jar can't be found (because the compiler sources are in scala/src/compiler and not in scala/src/eclipse/scala-compiler. The latter one is the location of the eclipse project).

WDYT, is this a problem due to the latest changes of Scala installations, or may I be able to configure the correct compiler path?

2014-07-16 16:26:14,680 DEBUG [main] - System.out - sbt.InvalidScalaInstance: Scala instance doesn't exist or is invalid:
    version 2.11.2.-20140715-230701-0f8b07a8d7, library jar: /home/antoras/Software/scala-eclipse/plugins/org.scala-lang.scala-library_2.11.2.v20140715-230701-0f8b07a8d7.jar, compiler jar: /home/antoras/dev/scala/scala/src/eclipse/scala-compiler
    at sbt.ScalaInstance$.slowActualVersion(ScalaInstance.scala:122)

    at sbt.ScalaInstance$.sbt$ScalaInstance$$actualVersion(ScalaInstance.scala:119)
    at sbt.ScalaInstance$$anonfun$actualVersion$1.apply(ScalaInstance.scala:32)
    at sbt.ScalaInstance$$anonfun$actualVersion$1.apply(ScalaInstance.scala:32)
    at scala.Option.getOrElse(Option.scala:120)
    at sbt.ScalaInstance.actualVersion$lzycompute(ScalaInstance.scala:32)
    at sbt.ScalaInstance.actualVersion(ScalaInstance.scala:32)
    at sbt.compiler.AnalyzingCompiler$$anonfun$compileSources$1$$anonfun$apply$2$$anonfun$apply$3.apply(AnalyzingCompiler.scala:143)
    at sbt.compiler.AnalyzingCompiler$$anonfun$compileSources$1$$anonfun$apply$2$$anonfun$apply$3.apply(AnalyzingCompiler.scala:143)
    at sbt.Logger$$anon$4.apply(Logger.scala:90)
    at org.scalaide.core.internal.builder.zinc.CompilerInterfaceStore$SbtLogger$$anonfun$info$1.apply(CompilerInterfaceStore.scala:134)
    at org.scalaide.core.internal.builder.zinc.CompilerInterfaceStore$SbtLogger$$anonfun$info$1.apply(CompilerInterfaceStore.scala:134)
    at org.scalaide.logging.log4j.Log4JAdapter.info(Log4JAdapter.scala:22)
    at org.scalaide.core.internal.builder.zinc.CompilerInterfaceStore$SbtLogger.info(CompilerInterfaceStore.scala:134)
    at sbt.Logger$$anon$3.log(Logger.scala:84)
    at sbt.Logger$class.info(Logger.scala:122)
    at sbt.Logger$$anon$3.info(Logger.scala:69)
    at sbt.compiler.AnalyzingCompiler$$anonfun$compileSources$1$$anonfun$apply$2.apply(AnalyzingCompiler.scala:143)
    at sbt.compiler.AnalyzingCompiler$$anonfun$compileSources$1$$anonfun$apply$2.apply(AnalyzingCompiler.scala:142)
    at sbt.IO$.withTemporaryDirectory(IO.scala:285)
    at sbt.compiler.AnalyzingCompiler$$anonfun$compileSources$1.apply(AnalyzingCompiler.scala:142)
    at sbt.compiler.AnalyzingCompiler$$anonfun$compileSources$1.apply(AnalyzingCompiler.scala:139)
    at sbt.IO$.withTemporaryDirectory(IO.scala:285)
    at sbt.compiler.AnalyzingCompiler$.compileSources(AnalyzingCompiler.scala:139)
    at sbt.compiler.IC$.compileInterfaceJar(IncrementalCompiler.scala:33)
    at org.scalaide.core.internal.builder.zinc.CompilerInterfaceStore.buildInterface(CompilerInterfaceStore.scala:99)
    at org.scalaide.core.internal.builder.zinc.CompilerInterfaceStore.compilerInterfaceFor(CompilerInterfaceStore.scala:59)
    at org.scalaide.core.internal.builder.zinc.SbtInputs.compilers(SbtInputs.scala:114)
    at org.scalaide.core.internal.builder.zinc.EclipseSbtBuildManager.aggressiveCompile(EclipseSbtBuildManager.scala:227)

    at org.scalaide.core.internal.builder.zinc.EclipseSbtBuildManager.runCompiler(EclipseSbtBuildManager.scala:150)
    at org.scalaide.core.internal.builder.zinc.EclipseSbtBuildManager.update(EclipseSbtBuildManager.scala:141)
    at org.scalaide.core.internal.builder.zinc.EclipseSbtBuildManager.build(EclipseSbtBuildManager.scala:195)
    at org.scalaide.core.internal.project.ScalaProject.build(ScalaProject.scala:801)

    at org.scalaide.core.internal.builder.ScalaBuilder.build(ScalaBuilder.scala:125)
    at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:733)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
    at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
    at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
    at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
    at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
    at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Caused by: java.lang.ClassNotFoundException: scala.tools.nsc.Properties
    at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:270)
    ... 46 more

To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/CAEg_ZokH9806rQ-kYnKzgDqag8RZ_YGpBmk-H6AMN%3Djdf2rWCQ%40mail.gmail.com.

iulian dragos

unread,
Jul 16, 2014, 11:00:13 AM7/16/14
to scala-ide-dev
On Wed, Jul 16, 2014 at 4:38 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/16/2014 02:54 PM, François Garillot wrote:

Hi Simon,

This codepath has been removed by the Scala Installations support, and is not in the latest nightly. Have you tried it ?

Indeed, that seemed to be the prbolem. After updating everything and killing my test workspace, the compiler+reflect could be loaded correctly. 0f8b07a8d7 is the Scala version of the host platform, therefore I'm using this one now also for the OSGi bundles of the compiler+reflect. But now I get the following error message in a Scala project:


sbt.InvalidScalaInstance: Scala instance doesn't exist or is invalid:
    version 2.11.2.-20140715-230701-0f8b07a8d7, library jar: /home/antoras/Software/scala-eclipse/plugins/org.scala-lang.scala-library_2.11.2.v20140715-230701-0f8b07a8d7.jar, compiler jar: /home/antoras/dev/scala/scala/src/eclipse/scala-compiler

(see full stacktrace below). The problem seems to be that the compiler jar can't be found (because the compiler sources are in scala/src/compiler and not in scala/src/eclipse/scala-compiler. The latter one is the location of the eclipse project).

WDYT, is this a problem due to the latest changes of Scala installations, or may I be able to configure the correct compiler path?

I think yes. Here's roughly what happens:

- you have scala-compiler checked out, and built. The newly launched eclipse uses that directory instead of the compiler bundle
- the newly launched eclipse will detect that the Scala Installation used by your test project is based on the `scala-compiler` project. From now on, I refer to the second instance of eclipse (your test environment)
- when you want to build the test project, the builder realizes it needs to compile a compiler-interface against the Scala version that you're using. This is exactly what Sbt does on the command line, and the Eclipse builder delegates to the Sbt compiler for that
- the sbt incremental compiler uses the concept of a `ScalaInstance`, which holds a classloader containing the classes needed to run the Scala compiler (since now we can support several versions of the compiler, we need classloader separation). If you look at our ScalaInstallations, you'll see that we create a ScalaInstance (and an associated class loader).
- it looks like the classloader we create is not working for directories. Here's the code:

  override def scalaInstance: ScalaInstance = {
    val store = ScalaPlugin.plugin.classLoaderStore
    val scalaLoader = store.getOrUpdate(this)(new URLClassLoader(allJars.map(_.classJar.toFile.toURI.toURL).toArray, ClassLoader.getSystemClassLoader))

    new sbt.ScalaInstance(version.unparse, scalaLoader, library.classJar.toFile, compiler.classJar.toFile, extraJars.map(_.classJar.toFile).toList, None)
  }

The `URLClassLoader` docs say that it works for directories, but they need a trailing `/` (otherwise it assumes it's a jar file). I think you could fix it by making sure we add a trailing slash for directories:

/**
 * This class loader is used to load classes and resources from a search
 * path of URLs referring to both JAR files and directories. Any URL that
 * ends with a '/' is assumed to refer to a directory. Otherwise, the URL
 * is assumed to refer to a JAR file which will be opened as needed.

 This should be relatively easy to test/fix. Let me know if you managed to get it to work again!

cheers,
iulian



For more options, visit https://groups.google.com/d/optout.



--

Simon Schäfer

unread,
Jul 16, 2014, 1:48:30 PM7/16/14
to scala-...@googlegroups.com

On 07/16/2014 04:59 PM, iulian dragos wrote:



On Wed, Jul 16, 2014 at 4:38 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/16/2014 02:54 PM, François Garillot wrote:

Hi Simon,

This codepath has been removed by the Scala Installations support, and is not in the latest nightly. Have you tried it ?

Indeed, that seemed to be the prbolem. After updating everything and killing my test workspace, the compiler+reflect could be loaded correctly. 0f8b07a8d7 is the Scala version of the host platform, therefore I'm using this one now also for the OSGi bundles of the compiler+reflect. But now I get the following error message in a Scala project:


sbt.InvalidScalaInstance: Scala instance doesn't exist or is invalid:
    version 2.11.2.-20140715-230701-0f8b07a8d7, library jar: /home/antoras/Software/scala-eclipse/plugins/org.scala-lang.scala-library_2.11.2.v20140715-230701-0f8b07a8d7.jar, compiler jar: /home/antoras/dev/scala/scala/src/eclipse/scala-compiler

(see full stacktrace below). The problem seems to be that the compiler jar can't be found (because the compiler sources are in scala/src/compiler and not in scala/src/eclipse/scala-compiler. The latter one is the location of the eclipse project).

WDYT, is this a problem due to the latest changes of Scala installations, or may I be able to configure the correct compiler path?

I think yes. Here's roughly what happens:

- you have scala-compiler checked out, and built. The newly launched eclipse uses that directory instead of the compiler bundle
- the newly launched eclipse will detect that the Scala Installation used by your test project is based on the `scala-compiler` project. From now on, I refer to the second instance of eclipse (your test environment)
- when you want to build the test project, the builder realizes it needs to compile a compiler-interface against the Scala version that you're using. This is exactly what Sbt does on the command line, and the Eclipse builder delegates to the Sbt compiler for that
- the sbt incremental compiler uses the concept of a `ScalaInstance`, which holds a classloader containing the classes needed to run the Scala compiler (since now we can support several versions of the compiler, we need classloader separation). If you look at our ScalaInstallations, you'll see that we create a ScalaInstance (and an associated class loader).
- it looks like the classloader we create is not working for directories. Here's the code:

  override def scalaInstance: ScalaInstance = {
    val store = ScalaPlugin.plugin.classLoaderStore
    val scalaLoader = store.getOrUpdate(this)(new URLClassLoader(allJars.map(_.classJar.toFile.toURI.toURL).toArray, ClassLoader.getSystemClassLoader))

    new sbt.ScalaInstance(version.unparse, scalaLoader, library.classJar.toFile, compiler.classJar.toFile, extraJars.map(_.classJar.toFile).toList, None)
  }

The `URLClassLoader` docs say that it works for directories, but they need a trailing `/` (otherwise it assumes it's a jar file).
All strings in this snippet are converted to URL or File objects - they should handle directories correctly. I think the problem is that the location of the project is added to the classpath, but what should be added are its source folders.

iulian dragos

unread,
Jul 17, 2014, 5:15:37 AM7/17/14
to scala-ide-dev
On Wed, Jul 16, 2014 at 7:48 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/16/2014 04:59 PM, iulian dragos wrote:



On Wed, Jul 16, 2014 at 4:38 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/16/2014 02:54 PM, François Garillot wrote:

Hi Simon,

This codepath has been removed by the Scala Installations support, and is not in the latest nightly. Have you tried it ?

Indeed, that seemed to be the prbolem. After updating everything and killing my test workspace, the compiler+reflect could be loaded correctly. 0f8b07a8d7 is the Scala version of the host platform, therefore I'm using this one now also for the OSGi bundles of the compiler+reflect. But now I get the following error message in a Scala project:


sbt.InvalidScalaInstance: Scala instance doesn't exist or is invalid:
    version 2.11.2.-20140715-230701-0f8b07a8d7, library jar: /home/antoras/Software/scala-eclipse/plugins/org.scala-lang.scala-library_2.11.2.v20140715-230701-0f8b07a8d7.jar, compiler jar: /home/antoras/dev/scala/scala/src/eclipse/scala-compiler

(see full stacktrace below). The problem seems to be that the compiler jar can't be found (because the compiler sources are in scala/src/compiler and not in scala/src/eclipse/scala-compiler. The latter one is the location of the eclipse project).

WDYT, is this a problem due to the latest changes of Scala installations, or may I be able to configure the correct compiler path?

I think yes. Here's roughly what happens:

- you have scala-compiler checked out, and built. The newly launched eclipse uses that directory instead of the compiler bundle
- the newly launched eclipse will detect that the Scala Installation used by your test project is based on the `scala-compiler` project. From now on, I refer to the second instance of eclipse (your test environment)
- when you want to build the test project, the builder realizes it needs to compile a compiler-interface against the Scala version that you're using. This is exactly what Sbt does on the command line, and the Eclipse builder delegates to the Sbt compiler for that
- the sbt incremental compiler uses the concept of a `ScalaInstance`, which holds a classloader containing the classes needed to run the Scala compiler (since now we can support several versions of the compiler, we need classloader separation). If you look at our ScalaInstallations, you'll see that we create a ScalaInstance (and an associated class loader).
- it looks like the classloader we create is not working for directories. Here's the code:

  override def scalaInstance: ScalaInstance = {
    val store = ScalaPlugin.plugin.classLoaderStore
    val scalaLoader = store.getOrUpdate(this)(new URLClassLoader(allJars.map(_.classJar.toFile.toURI.toURL).toArray, ClassLoader.getSystemClassLoader))

    new sbt.ScalaInstance(version.unparse, scalaLoader, library.classJar.toFile, compiler.classJar.toFile, extraJars.map(_.classJar.toFile).toList, None)
  }

The `URLClassLoader` docs say that it works for directories, but they need a trailing `/` (otherwise it assumes it's a jar file).
All strings in this snippet are converted to URL or File objects - they should handle directories correctly. I think the problem is that the location of the project is added to the classpath, but what should be added are its source folders.

I don't understand why *sources* play a role in this. It looks like a classfile is needed...
 

I think you could fix it by making sure we add a trailing slash for directories:

/**
 * This class loader is used to load classes and resources from a search
 * path of URLs referring to both JAR files and directories. Any URL that
 * ends with a '/' is assumed to refer to a directory. Otherwise, the URL
 * is assumed to refer to a JAR file which will be opened as needed.

 This should be relatively easy to test/fix. Let me know if you managed to get it to work again!


--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Simon Schäfer

unread,
Jul 17, 2014, 8:49:16 AM7/17/14
to scala-...@googlegroups.com

On 07/17/2014 11:15 AM, iulian dragos wrote:
>
> I don't understand why *sources* play a role in this. It looks like a
> classfile is needed...
Oh, yes, that is what I meant, the corresponding class folders of source
folders.

iulian dragos

unread,
Jul 17, 2014, 12:37:47 PM7/17/14
to scala-ide-dev
That's true.. so our bundle detection should "know" better when it's a jar vs. a project, and act accordingly for building the class loader... Do you want to have a go at this?
 


--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/53C7A0BB.9070909%40antoras.de.

For more options, visit https://groups.google.com/d/optout.

Simon Schäfer

unread,
Jul 17, 2014, 12:40:18 PM7/17/14
to scala-...@googlegroups.com

On 07/17/2014 06:37 PM, iulian dragos wrote:



On Thu, Jul 17, 2014 at 12:08 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/17/2014 11:15 AM, iulian dragos wrote:

I don't understand why *sources* play a role in this. It looks like a classfile is needed...
Oh, yes, that is what I meant, the corresponding class folders of source folders.

That's true.. so our bundle detection should "know" better when it's a jar vs. a project, and act accordingly for building the class loader... Do you want to have a go at this?
Yes! (I already looked into it, but was interrupted so far by other things)
 


--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.



--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/CAOwe9fYE1HME-g5M_%2BO29hucw3B1oDdzOy9Zi8SC7%2BN3rrC%3Dzw%40mail.gmail.com.

Simon Schäfer

unread,
Jul 20, 2014, 5:29:57 PM7/20/14
to scala-...@googlegroups.com

On 07/17/2014 06:37 PM, iulian dragos wrote:



On Thu, Jul 17, 2014 at 12:08 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/17/2014 11:15 AM, iulian dragos wrote:

I don't understand why *sources* play a role in this. It looks like a classfile is needed...
Oh, yes, that is what I meant, the corresponding class folders of source folders.

That's true.. so our bundle detection should "know" better when it's a jar vs. a project, and act accordingly for building the class loader... Do you want to have a go at this?
It turned out that this is more difficult than I thought. While it is relatively easy to check if a given folder contains a project (it needs to contain the file `.project`), I couldn't find an API that allows me to easily access the configuration (the .project and .classpath files) of that project, which contains the information where the source folder are.

Do you remember how it was done before the multi Scala version feature was introduced? Because I'm not very interested in reading these XML files manually...
 


--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.



--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/CAOwe9fYE1HME-g5M_%2BO29hucw3B1oDdzOy9Zi8SC7%2BN3rrC%3Dzw%40mail.gmail.com.

Simon Schäfer

unread,
Jul 20, 2014, 5:34:27 PM7/20/14
to scala-...@googlegroups.com

On 07/20/2014 11:29 PM, Simon Schäfer wrote:

On 07/17/2014 06:37 PM, iulian dragos wrote:



On Thu, Jul 17, 2014 at 12:08 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/17/2014 11:15 AM, iulian dragos wrote:

I don't understand why *sources* play a role in this. It looks like a classfile is needed...
Oh, yes, that is what I meant, the corresponding class folders of source folders.

That's true.. so our bundle detection should "know" better when it's a jar vs. a project, and act accordingly for building the class loader... Do you want to have a go at this?
It turned out that this is more difficult than I thought. While it is relatively easy to check if a given folder contains a project (it needs to contain the file `.project`), I couldn't find an API that allows me to easily access the configuration (the .project and .classpath files) of that project, which contains the information where the source folder are.
s/source folder/class folders/

Do you remember how it was done before the multi Scala version feature was introduced? Because I'm not very interested in reading these XML files manually...
 


--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/53C7A0BB.9070909%40antoras.de.

For more options, visit https://groups.google.com/d/optout.



--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/CAOwe9fYE1HME-g5M_%2BO29hucw3B1oDdzOy9Zi8SC7%2BN3rrC%3Dzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.

François Garillot

unread,
Jul 21, 2014, 4:54:27 AM7/21/14
to scala-...@googlegroups.com
In ClasspathManagement, you can have a look at uses of ScalaClasspath class. Scala installations tweak the contents of the Scala-library (and scala-compiler) classpath container. Those installations should not affect the contents of the .classpath file, which contains only a pointer to this container (they just change how it is resolved).



To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/53CC34D4.6010303%40antoras.de.

For more options, visit https://groups.google.com/d/optout.



--
François Garillot

iulian dragos

unread,
Jul 21, 2014, 6:16:03 AM7/21/14
to scala-ide-dev
On Sun, Jul 20, 2014 at 11:29 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/17/2014 06:37 PM, iulian dragos wrote:



On Thu, Jul 17, 2014 at 12:08 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/17/2014 11:15 AM, iulian dragos wrote:

I don't understand why *sources* play a role in this. It looks like a classfile is needed...
Oh, yes, that is what I meant, the corresponding class folders of source folders.

That's true.. so our bundle detection should "know" better when it's a jar vs. a project, and act accordingly for building the class loader... Do you want to have a go at this?
It turned out that this is more difficult than I thought. While it is relatively easy to check if a given folder contains a project (it needs to contain the file `.project`), I couldn't find an API that allows me to easily access the configuration (the .project and .classpath files) of that project, which contains the information where the source folder are.

Do you remember how it was done before the multi Scala version feature was introduced? Because I'm not very interested in reading these XML files manually...

We didn't create a new classloader, instead we re-used the Eclipse one. However, due to some changes in the Scala compiler, that stopped working (as you reported). OSGi prevented some classes from being visible in the intricate code paths between the compiler, the IDE and the compiler interface. The "solution" was to create a plain class loader (without any OSGi magic), but now the problem is that we only support jars bundles, not project-based bundles.

IMO the best solution would be to go back to reusing the Eclipse classloader (this has non-negligeable performance and memory benefits). It was done in PR 3820, and I think the problem is that an interface is defined in scala-reflect and implemented in scala-compiler. I would try to add a default implementation on the method that wasn't seen

scala.reflect.internal.Reporter.warning(Reporting.scala:81)

(see my email from July 8).
 
iulian
 


--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/53C7A0BB.9070909%40antoras.de.

For more options, visit https://groups.google.com/d/optout.



--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/CAOwe9fYE1HME-g5M_%2BO29hucw3B1oDdzOy9Zi8SC7%2BN3rrC%3Dzw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Adriaan Moors

unread,
Jul 21, 2014, 11:04:32 AM7/21/14
to scala-...@googlegroups.com
To repeat my hallway comment: I'm happy to work around the classloader issue on our side if someone can explain how to rework our Reporter interface to make it OSGi-friendly, or -- better yet -- submit a PR to scala/scala :-)

Simon Schäfer

unread,
Jul 21, 2014, 11:23:59 AM7/21/14
to scala-...@googlegroups.com

On 07/16/2014 02:54 PM, François Garillot wrote:

Hi Simon,

This codepath has been removed by the Scala Installations support, and is not in the latest nightly. Have you tried it ?

This is getting ridiculous. After updating the host to the newest nightly I get:

java.lang.NoSuchMethodError: scala.tools.nsc.Settings.lint()Lscala/tools/nsc/settings/MutableSettings$BooleanSetting;
    at org.scalaide.ui.internal.preferences.IDESettings$.shownSettings(IDESettings.scala:15)
    at org.scalaide.core.internal.project.ScalaProject.shownSettings(ScalaProject.scala:398)
    at org.scalaide.core.internal.project.ScalaProject.initializeCompilerSettings(ScalaProject.scala:449)
    at org.scalaide.core.compiler.ScalaPresentationCompilerProxy.liftedTree1$1(ScalaPresentationCompilerProxy.scala:153)
    at org.scalaide.core.compiler.ScalaPresentationCompilerProxy.create(ScalaPresentationCompilerProxy.scala:151)
    at org.scalaide.core.compiler.ScalaPresentationCompilerProxy.initialize(ScalaPresentationCompilerProxy.scala:109)
    at org.scalaide.core.compiler.ScalaPresentationCompilerProxy.obtainPc$1(ScalaPresentationCompilerProxy.scala:76)
    at org.scalaide.core.compiler.ScalaPresentationCompilerProxy.apply(ScalaPresentationCompilerProxy.scala:95)
    at org.scalaide.core.compiler.InteractiveCompilationUnit$class.withSourceFile(InteractiveCompilationUnit.scala:69)
    at org.scalaide.core.internal.jdt.model.ScalaSourceFile.withSourceFile(ScalaSourceFile.scala:74)
    at org.scalaide.core.internal.decorators.markoccurrences.ScalaOccurrencesFinder.findOccurrences(ScalaOccurrencesFinder.scala:49)
    at org.scalaide.ui.internal.editor.ScalaSourceFileEditor.getAnnotations(ScalaSourceFileEditor.scala:165)
    at org.scalaide.ui.internal.editor.ScalaSourceFileEditor.org$scalaide$ui$internal$editor$ScalaSourceFileEditor$$performOccurrencesUpdate(ScalaSourceFileEditor.scala:156)
    at org.scalaide.ui.internal.editor.ScalaSourceFileEditor$$anonfun$1$$anonfun$apply$2.apply$mcV$sp(ScalaSourceFileEditor.scala:191)
    at org.scalaide.ui.internal.editor.ScalaSourceFileEditor$$anonfun$1$$anonfun$apply$2.apply(ScalaSourceFileEditor.scala:191)
    at org.scalaide.ui.internal.editor.ScalaSourceFileEditor$$anonfun$1$$anonfun$apply$2.apply(ScalaSourceFileEditor.scala:191)
    at org.scalaide.util.internal.Utils$.debugTimed(Utils.scala:26)
    at org.scalaide.ui.internal.editor.ScalaSourceFileEditor$$anonfun$1.apply(ScalaSourceFileEditor.scala:190)
    at org.scalaide.ui.internal.editor.ScalaSourceFileEditor$$anonfun$1.apply(ScalaSourceFileEditor.scala:188)
    at org.scalaide.util.internal.eclipse.EclipseUtils$$anon$1.run(EclipseUtils.scala:91)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

I run the test workspace with the compiler of the host, which is:

Scala IDE version:
        4.0.0.local-2_11-201407211424-5699935
Scala compiler version:
        2.11.2.-20140720-231248-afa96e3be7
Scala library version:
        2.11.2.-20140720-231248-afa96e3be7
Eclipse version:
        4.3.2.v20140221-1700

To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/CAEg_ZokH9806rQ-kYnKzgDqag8RZ_YGpBmk-H6AMN%3Djdf2rWCQ%40mail.gmail.com.

iulian dragos

unread,
Jul 21, 2014, 11:39:03 AM7/21/14
to scala-ide-dev
On Mon, Jul 21, 2014 at 5:23 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/16/2014 02:54 PM, François Garillot wrote:

Hi Simon,

This codepath has been removed by the Scala Installations support, and is not in the latest nightly. Have you tried it ?

This is getting ridiculous. After updating the host to the newest nightly I get:

But you didn't update your IDE build, right? 
 

java.lang.NoSuchMethodError: scala.tools.nsc.Settings.lint()Lscala/tools/nsc/settings/MutableSettings$BooleanSetting;

...

I run the test workspace with the compiler of the host, which is:

Scala IDE version:
        4.0.0.local-2_11-201407211424-5699935

This is a local build of the IDE, which might be compiled against a slightly older compiler?
 

For more options, visit https://groups.google.com/d/optout.



--

Simon Schäfer

unread,
Jul 21, 2014, 11:50:05 AM7/21/14
to scala-...@googlegroups.com

On 07/21/2014 05:38 PM, iulian dragos wrote:



On Mon, Jul 21, 2014 at 5:23 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/16/2014 02:54 PM, François Garillot wrote:

Hi Simon,

This codepath has been removed by the Scala Installations support, and is not in the latest nightly. Have you tried it ?

This is getting ridiculous. After updating the host to the newest nightly I get:

But you didn't update your IDE build, right?
I did.

 

java.lang.NoSuchMethodError: scala.tools.nsc.Settings.lint()Lscala/tools/nsc/settings/MutableSettings$BooleanSetting;

...
I run the test workspace with the compiler of the host, which is:

Scala IDE version:
        4.0.0.local-2_11-201407211424-5699935

This is a local build of the IDE, which might be compiled against a slightly older compiler?
I compiled it with the build-all script, as I always do (./build-all.sh -Pscala-2.11.x,eclipse-kepler clean install -DskipTests) and then installed it in my Eclipse.

Simon Schäfer

unread,
Jul 21, 2014, 11:51:20 AM7/21/14
to scala-...@googlegroups.com

On 07/21/2014 12:15 PM, iulian dragos wrote:

We didn't create a new classloader, instead we re-used the Eclipse one. However, due to some changes in the Scala compiler, that stopped working (as you reported). OSGi prevented some classes from being visible in the intricate code paths between the compiler, the IDE and the compiler interface. The "solution" was to create a plain class loader (without any OSGi magic), but now the problem is that we only support jars bundles, not project-based bundles.

IMO the best solution would be to go back to reusing the Eclipse classloader (this has non-negligeable performance and memory benefits). It was done in PR 3820, and I think the problem is that an interface is defined in scala-reflect and implemented in scala-compiler. I would try to add a default implementation on the method that wasn't seen

scala.reflect.internal.Reporter.warning(Reporting.scala:81)

(see my email from July 8).
After overriding the `scalaInstance` method in MultiBundleScalaInstallation with the previous implementation I could bring the AbstractMethodError back, but only the first time when I tried it. Now I get some other weird error messages (see my other post).

If you have the time to fix this please go on, I should concentrate on other things and fear that I have to spend more time on this than I want to spend.

iulian dragos

unread,
Jul 21, 2014, 12:42:15 PM7/21/14
to scala-ide-dev
So is this error thrown by your "base" IDE (i.e. nothing is usable), or while running the second ("test") IDE instance? I just installed the latest nightly and everything works fine for me.
 

--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Simon Schäfer

unread,
Jul 21, 2014, 1:25:11 PM7/21/14
to scala-...@googlegroups.com

On 07/21/2014 06:41 PM, iulian dragos wrote:

So is this error thrown by your "base" IDE (i.e. nothing is usable), or while running the second ("test") IDE instance? I just installed the latest nightly and everything works fine for me.
It is thrown by the test instance, the base IDE works fine.

For now I did a downgrade to a previous version, which doesn't have the problem.
 
--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/53CD36AC.8040200%40antoras.de.

For more options, visit https://groups.google.com/d/optout.



--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.

iulian dragos

unread,
Jul 21, 2014, 3:25:29 PM7/21/14
to scala-ide-dev
On Mon, Jul 21, 2014 at 7:25 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/21/2014 06:41 PM, iulian dragos wrote:

So is this error thrown by your "base" IDE (i.e. nothing is usable), or while running the second ("test") IDE instance? I just installed the latest nightly and everything works fine for me.
It is thrown by the test instance, the base IDE works fine.

Ok, so it's possible that your test instance wasn't compiled against the right version of the Scala compiler? You'd have the scala-compiler project on the classpath of `sdt.core` (which branch/checkout?) to compile with, and also to run-with? Or you'd run with the "installed" org.scala-lang.scala-compiler bundle (jar)?
 

For now I did a downgrade to a previous version, which doesn't have the problem.
 
--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/53CD36AC.8040200%40antoras.de.

For more options, visit https://groups.google.com/d/optout.



--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/CAOwe9fYA%3DPR5JqJy3m95MN3wnyH-629LpfRr%3DUEn5_a62V2MFQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Simon Schäfer

unread,
Jul 21, 2014, 4:23:16 PM7/21/14
to scala-...@googlegroups.com

On 07/21/2014 09:25 PM, iulian dragos wrote:



On Mon, Jul 21, 2014 at 7:25 PM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/21/2014 06:41 PM, iulian dragos wrote:

So is this error thrown by your "base" IDE (i.e. nothing is usable), or while running the second ("test") IDE instance? I just installed the latest nightly and everything works fine for me.
It is thrown by the test instance, the base IDE works fine.

Ok, so it's possible that your test instance wasn't compiled against the right version of the Scala compiler? You'd have the scala-compiler project on the classpath of `sdt.core` (which branch/checkout?) to compile with, and also to run-with? Or you'd run with the "installed" org.scala-lang.scala-compiler bundle (jar)?
I used the installed scala-compiler from the host IDE and verified that in the run configuration. It could be that some caching of old classfiles was involved but because I cleaned up everything I don't know how that should have happened.

I wait some days and try to update again, maybe the error is gone then. Otherwise, something I can try is to create a new workspace for my main IDE, maybe something is broken there. That could be a reason - I see these weird NoSuchMethodErrors maybe for the last two weeks and can't remember seeing something similar for years (with exception of some misconfigured run configurations).

Simon Schäfer

unread,
Jul 26, 2014, 6:45:29 PM7/26/14
to scala-...@googlegroups.com
Finally, I found out what was the problem to all of this errors. It is a
little bit stupid but at least I know now what was wrong.

My situation is a follows: I have scalac and scala-ide in my workspace,
where the compiler and reflect are available as OSGi bundles. Eclipse
now automatically choses available OSGi bundles in the workspace that
are dependencies of other OSGi bundles as build dependencies, which
meant that scala-ide was built on top of my local compiler.

However, in my run configuration I disabled my local compiler and
reflect because of scala-ide can't handle it anymore, which means that
the bundles of the host are chosen as runtime dependencies. I got the
NoSuchMethodErrors etc. after updating my scala-ide installation of the
host but at the same time not updating my scala checkout to the exact
same version that was used to build the scala-ide.

This means that my local scala-ide was built against one version of the
compiler, but started with a newer version of the compiler and because
there were binary incompatibilities it didn't work.

This means that as long as the bug exists that the scala-ide can't load
local OSGi bundles of the compiler, I have to update my scala checkout
to the same version of the scala-ide installation. I hope to find some
time soon to look again in fixing this bug...

iulian dragos

unread,
Jul 28, 2014, 5:38:26 AM7/28/14
to scala-ide-dev
Thanks for the detailed explanation, I see how things went wrong. I'm looking now at your setup, trying to make OSGi work with a compiler checkout. However, until that works, I don't see why would you like to continue building aginst the checked-out sources for the compiler. Can't you make the IDE project pick up the installed jars for compilation *and* runtime? You could close the compiler project, for instance.. :-)

 


--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/53D42F88.3050201%40antoras.de.

For more options, visit https://groups.google.com/d/optout.

Simon Schäfer

unread,
Jul 28, 2014, 5:59:59 AM7/28/14
to scala-...@googlegroups.com

On 07/28/2014 11:38 AM, iulian dragos wrote:
>
> Thanks for the detailed explanation, I see how things went wrong. I'm
> looking now at your setup, trying to make OSGi work with a compiler
> checkout. However, until that works, I don't see why would you like to
> continue building aginst the checked-out sources for the compiler.
> Can't you make the IDE project pick up the installed jars for
> compilation *and* runtime? You could close the compiler project, for
> instance.. :-)
Yeah, that is what I now do temporarily. I just like the possibility of
being able to change scalac when I have to debug it (custom println
etc.), which happens from time to time.

iulian dragos

unread,
Jul 28, 2014, 6:51:45 AM7/28/14
to scala-ide-dev
Yes, that's a life-saver.
 


--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

iulian dragos

unread,
Jul 28, 2014, 11:40:37 AM7/28/14
to scala-ide-dev
On Mon, Jul 28, 2014 at 12:51 PM, iulian dragos <jagu...@gmail.com> wrote:



On Mon, Jul 28, 2014 at 11:59 AM, Simon Schäfer <ma...@antoras.de> wrote:

On 07/28/2014 11:38 AM, iulian dragos wrote:

Thanks for the detailed explanation, I see how things went wrong. I'm looking now at your setup, trying to make OSGi work with a compiler checkout. However, until that works, I don't see why would you like to continue building aginst the checked-out sources for the compiler. Can't you make the IDE project pick up the installed jars for compilation *and* runtime? You could close the compiler project, for instance.. :-)
Yeah, that is what I now do temporarily. I just like the possibility of being able to change scalac when I have to debug it (custom println etc.), which happens from time to time.

Yes, that's a life-saver.

I mnaged to reverse engineer a few things:

- when Eclipse runs in dev mode, there's an additional `-dev file:/path/to/launch.config/dev.properties` passed on the command line. This file has the classpath for each bundle that comes from the workspace. For example, in my case:

#
#Mon Jul 28 16:11:14 CEST 2014
org.scala-ide.sdt.core=target/classes,target/lib/miglayout-3.7.4.jar,target/lib/log4j-1.2.17.jar
org.scala-lang.scala-reflect=/Volumes/Thunderbolt_SSD/dragos/workspace/scala/build/quick/classes/reflect
@ignoredot@=true
org.scala-lang.scala-compiler=/Volumes/Thunderbolt_SSD/dragos/workspace/scala/build/asm/classes,/Volumes/Thunderbolt_SSD/dragos/workspace/scala/build/quick/classes/compiler


- there's a class called `org.eclipse.core.internal.runtime.DevClassPathHelper` that seems to handle this file

I also noticed that it's not only a *classloader* issue, but also one of classpath: in order for Sbt to build, it needs a compiler-interface compiled against the specific version of Scala compiler. To compile this interface (CompilerInterfaceStore.scala), we use the scaal-compiler and scala-library jar files from a ScalaInstallation. Currently, that fails to compile, because the paths are not pointing to the output folders. Correctly finding them in dev-mode should fix this too.

I think we could probably use this info to retrieve the correct classpath for the compiler when in dev mode. I didn't push it further, but if you have a bit of time, I think this could lead to a fix.

cheers,
iulian

 
 


--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/53D61F1A.7050806%40antoras.de.

For more options, visit https://groups.google.com/d/optout.



--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
Reply all
Reply to author
Forward
0 new messages