Scala library and/or plug-in issues

On Thu, Feb 04, 2010 at 03:37:21PM -0500, Tim Clendenen wrote:
> However, once I try to test the plug-in there are numerous errors all
> appearing to be because of scala.tools.nsc.Properties$ causing a
> NoClassDefFoundError.

Like I told the last guy, this is from stale class files. (At least on
the compiler side -- I do not know anything about the plugin, so there
could be some deeper problem there.) When a trait signature changes you
will have issues until you blow away the things which need blowing away.

I didn't see anything pertaining to "the last guy", but I'm not sure
what else to do. Is 'ant all.clean' not the proper way to remove
everything? I've tried that as well as 'ant dist.clean' and it still
occurs. This includes building a complete developer distribution of the
plug-in and a brand new eclipse environment.

On 2/4/2010 3:42 PM, Paul Phillips wrote:
> On Thu, Feb 04, 2010 at 03:37:21PM -0500, Tim Clendenen wrote:
>
>> However, once I try to test the plug-in there are numerous errors all
>> appearing to be because of scala.tools.nsc.Properties$ causing a
>> NoClassDefFoundError.
>>
> Like I told the last guy, this is from stale class files. (At least on
> the compiler side -- I do not know anything about the plugin, so there
> could be some deeper problem there.) When a trait signature changes you
> will have issues until you blow away the things which need blowing away.
>
>

On Thu, Feb 04, 2010 at 03:51:38PM -0500, Tim Clendenen wrote:
> I didn't see anything pertaining to "the last guy", but I'm not sure
> what else to do. Is 'ant all.clean' not the proper way to remove
> everything? I've tried that as well as 'ant dist.clean' and it still
> occurs. This includes building a complete developer distribution of
> the plug-in and a brand new eclipse environment.

I know the compiler builds so process of eliminations says plugin. If
you aren't up for tracking this kind of thing down I'd recommend using a
recent snapshot rather than trunk.

The Typers errors are fixed so the compiler and library are building
again. I've tracked down the issue to a NoClassDefFoundError caused by
scala.tools.nsc.Properties$. You say that is caused by stale classes
but did not confirm whether 'ant all.clean" is the proper way to remove
them. I wouldn't be messing around with trunk if I expected everything
to work, but nor do I want to waste anyone's time by creating frivolous
bug tickets when the problem may be of my own creation. So I post to
the mailing list hoping to get some constructive advice. If anyone can
provide that I would be grateful, if not, I have no desire to go back
and forth on this and I apologize for wasting your time.

On 2/4/2010 4:08 PM, Paul Phillips wrote:
> On Thu, Feb 04, 2010 at 03:51:38PM -0500, Tim Clendenen wrote:
>
>> I didn't see anything pertaining to "the last guy", but I'm not sure
>> what else to do. Is 'ant all.clean' not the proper way to remove
>> everything? I've tried that as well as 'ant dist.clean' and it still
>> occurs. This includes building a complete developer distribution of
>> the plug-in and a brand new eclipse environment.
>>
> I know the compiler builds so process of eliminations says plugin. If
> you aren't up for tracking this kind of thing down I'd recommend using a
> recent snapshot rather than trunk.
>
>

On Thu, Feb 4, 2010 at 9:08 PM, Paul Phillips wrote:
> On Thu, Feb 04, 2010 at 03:51:38PM -0500, Tim Clendenen wrote:
>> I didn't see anything pertaining to "the last guy", but I'm not sure
>> what else to do.  Is 'ant all.clean' not the proper way to remove
>> everything?  I've tried that as well as 'ant dist.clean' and it still
>> occurs.  This includes building a complete developer distribution of
>> the plug-in and a brand new eclipse environment.
>
> I know the compiler builds so process of eliminations says plugin.

The IDE build scripts build optimized version of the scala compiler by
default. As of r20797 optimized builds of trunk of the compiler fail
in quick.lib. I think that,

https://lampsvn.epfl.ch/trac/scala/changeset/20794

is most likely responsible.

Cheers,

Miles

On Thu, Feb 4, 2010 at 9:52 PM, Tim Clendenen wrote:
> The Typers errors are fixed so the compiler and library are building again.
>  I've tracked down the issue to a NoClassDefFoundError caused by
> scala.tools.nsc.Properties$.  You say that is caused by stale classes but
> did not confirm whether 'ant all.clean" is the proper way to remove them.

ant all.clean would be the right thing to do, but that's a red herring
here ... it's the compiler that's busted for optimized builds.

> I wouldn't be messing around with trunk if I expected everything to work, but
> nor do I want to waste anyone's time by creating frivolous bug tickets when
> the problem may be of my own creation.  So I post to the mailing list hoping
> to get some constructive advice.  If anyone can provide that I would be
> grateful, if not, I have no desire to go back and forth on this and I
> apologize for wasting your time.

Your efforts are very much appreciated, by me at least.

Cheers,

Miles

Whoa, scalac has command line switches? That explains a lot.

I think -optimise is fixed.

None of the changes so far have helped. I noticed that the nightly
build succeeded so I gave that a try but with the same result. However,
I did notice this time I got two different errors. The first was able
to find scala.tools.nsc.Properties$ but unable to find
scala/reflect/generic/Names. The second could not find
scala.tools.nsc.Properties$, so it would seem at first glance that the
problem is related to class loading. Hope this helps.

Thanks,
Tim

error #1

Error
Thu Feb 04 23:25:41 EST 2010
Problems occurred when invoking code from plug-in: "org.eclipse.jface".

java.lang.NoClassDefFoundError: scala/reflect/generic/Names
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:183)
...
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at scala.tools.nsc.Properties$.pickJarBasedOn(Properties.scala:13)
at scala.util.PropertiesTrait$class.props(Properties.scala:26)
...
Caused by: java.lang.ClassNotFoundException: scala.reflect.generic.Names
at
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:494)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:398)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 122 more

error #2

Error
Thu Feb 04 23:29:33 EST 2010
Unable to create editor ID scala.tools.eclipse.ScalaSourceFileEditor:
Editor could not be initialized.

java.lang.NoClassDefFoundError: Could not initialize class
scala.tools.nsc.Properties$
at scala.tools.nsc.Settings.scalaHome(Settings.scala:47)
at
scala.tools.nsc.Settings.scala$tools$nsc$Settings$$guess(Settings.scala:51)
at scala.tools.nsc.Settings.guessedScalaBootClassPath(Settings.scala:57)
at scala.tools.nsc.Settings.bootclasspathDefault(Settings.scala:31)
at scala.tools.nsc.ScalacSettings$class.$init$(Settings.scala:826)
at scala.tools.nsc.Settings.(Settings.scala:15)

On 2/4/2010 5:32 PM, Miles Sabin wrote:
> On Thu, Feb 4, 2010 at 9:52 PM, Tim Clendenen wrote:
>
>> The Typers errors are fixed so the compiler and library are building again.
>> �I've tracked down the issue to a NoClassDefFoundError caused by
>> scala.tools.nsc.Properties$. �You say that is caused by stale classes but
>> did not confirm whether 'ant all.clean" is the proper way to remove them.
>>
> ant all.clean would be the right thing to do, but that's a red herring
> here ... it's the compiler that's busted for optimized builds.
>
>
>> �I wouldn't be messing around with trunk if I expected everything to work, but
>> nor do I want to waste anyone's time by creating frivolous bug tickets when
>> the problem may be of my own creation. �So I post to the mailing list hoping
>> to get some constructive advice. �If anyone can provide that I would be
>> grateful, if not, I have no desire to go back and forth on this and I
>> apologize for wasting your time.
>>
> Your efforts are very much appreciated, by me at least.
>
> Cheers,
>
>
> Miles
>
>

Le 05/02/2010 06:18, Tim Clendenen a écrit :
> None of the changes so far have helped. I noticed that the nightly
> build succeeded so I gave that a try but with the same result. However,
> I did notice this time I got two different errors. The first was able to
> find scala.tools.nsc.Properties$ but unable to find
> scala/reflect/generic/Names. The second could not find
> scala.tools.nsc.Properties$, so it would seem at first glance that the
> problem is related to class loading. Hope this helps.

Same issue here, with today build (r20799-b20100205020222).
I can't open any Scala file, there is two errors in error log window:

1 ----------------------------------------------------
Problems occurred when invoking code from plug-in: "org.eclipse.jface".
1 ----------------------------------------------------
java.lang.NoClassDefFoundError: scala/reflect/generic/Names
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:183)
......
1 ----------------------------------------------------

2 ----------------------------------------------------
Unable to create editor ID scala.tools.eclipse.ScalaSourceFileEditor:
Editor could not be initialized.
2 ----------------------------------------------------
java.lang.NoClassDefFoundError: Could not initialize class
scala.tools.nsc.Properties$
at scala.tools.nsc.Settings.scalaHome(Settings.scala:47)
at
scala.tools.nsc.Settings.scala$tools$nsc$Settings$$guess(Settings.scala:51)
at scala.tools.nsc.Settings.guessedScalaBootClassPath(Settings.scala:57)
at scala.tools.nsc.Settings.bootclasspathDefault(Settings.scala:31)
at scala.tools.nsc.ScalacSettings$class.$init$(Settings.scala:826)
at scala.tools.nsc.Settings.(Settings.scala:15)
at scala.tools.nsc.Settings.(Settings.scala:16)
at scala.tools.eclipse.ScalaProject$$anon$1.create(ScalaProject.scala:41)
at scala.tools.eclipse.ScalaProject$$anon$1.create(ScalaProject.scala:38)
at scala.tools.eclipse.util.Cached$class.apply(Cached.scala:44)
......
2 ----------------------------------------------------

Hope it helps somehow

Eclipse has a "revert to earlier configuration" feature and I just tried
using it to back out of this situation. It didn't work because (I think) it
couldn't find a previous plugin version at the plugin update site.

Would it be possible to keep a week or two of old plugin versions at the
update site to allow this kind of reversion to a working conmfig?

Keep up the great work.

On Fri, Feb 5, 2010 at 5:18 AM, Tim Clendenen wrote:
> None of the changes so far have helped.  I noticed that the nightly build
> succeeded so I gave that a try but with the same result.  However, I did
> notice this time I got two different errors.  The first was able to find
> scala.tools.nsc.Properties$ but unable to find scala/reflect/generic/Names.
> The second could not find scala.tools.nsc.Properties$, so it would seem at
> first glance that the problem is related to class loading.  Hope this helps.

Should be fixed now ... either try with tomorrows nightly or rebuild from trunk.

Cheers,

Miles

I actively looked into this one myself, but the release process was all based on a bunch of eclipse release tools that are totally outside of my experience.  The learning curve was just too steep for a quick fix & patch

On 5 February 2010 17:01, kaesler <kevin.esler@alum.bu.edu> wrote:

Eclipse has a "revert to earlier configuration" feature and I just tried
using it to back out of this situation. It didn't work because (I think) it
couldn't find a previous plugin version at the plugin update site.

Would it be possible to keep a week or two of old plugin versions at the
update site to allow this kind of reversion to a working conmfig?

Keep up the great work.


--
View this message in context: http://old.nabble.com/-scala-tools--Scala-library-and-or-plug-in-issues-tp27459371p27470803.html
Sent from the Scala - Tools mailing list archive at Nabble.com.

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

That appears to have done it.

Thanks,
Tim

On 2/5/2010 12:08 PM, Miles Sabin wrote:
> On Fri, Feb 5, 2010 at 5:18 AM, Tim Clendenen wrote:
>
>> None of the changes so far have helped. �I noticed that the nightly build
>> succeeded so I gave that a try but with the same result. �However, I did
>> notice this time I got two different errors. �The first was able to find
>> scala.tools.nsc.Properties$ but unable to find scala/reflect/generic/Names.
>> The second could not find scala.tools.nsc.Properties$, so it would seem at
>> first glance that the problem is related to class loading. �Hope this helps.
>>
> Should be fixed now ... either try with tomorrows nightly or rebuild from trunk.
>
> Cheers,
>
>
> Miles
>
>

On Fri, 2010-02-05 at 09:01 -0800, kaesler wrote:
> Eclipse has a "revert to earlier configuration" feature and I just tried
> using it to back out of this situation. It didn't work because (I think) it
> couldn't find a previous plugin version at the plugin update site.
>
> Would it be possible to keep a week or two of old plugin versions at the
> update site to allow this kind of reversion to a working conmfig?

Yes, this would be nice. Last time I had to revert, I built my own
version from a previous SVN revision.

Best,
Ismael

On Fri, Feb 5, 2010 at 5:01 PM, kaesler wrote:
> Eclipse has a "revert to earlier configuration" feature and I just tried
> using it to back out of this situation. It didn't work because (I think) it
> couldn't find a previous plugin version at the plugin update site.
>
> Would it be possible to keep a week or two of old plugin versions at the
> update site to allow this kind of reversion to a working conmfig?

This is something I'm looking into at the moment ... watch this space.

Cheers,

Miles

NEURONSAVER! thanks!

kaesler wrote:
>
> Eclipse has a "revert to earlier configuration" feature and I just tried
> using it to back out of this situation. It didn't work because (I think)
> it couldn't find a previous plugin version at the plugin update site.
>
> Would it be possible to keep a week or two of old plugin versions at the
> update site to allow this kind of reversion to a working conmfig?
>
> Keep up the great work.
>
>
>

-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Me: http://feeds.razie.com/RazvanTech
Playground: http://wiki.homecloud.ca

On Sat, Feb 6, 2010 at 4:01 AM, kaesler wrote:

> Would it be possible to keep a week or two of old plugin versions at the
> update site to allow this kind of reversion to a working conmfig?

+1. Ive blundered into this by updating my SDT build an hour ago, hit
all the same problems, now cant get back easily. Similar situation a
month or so ago.

I know we're on officially unsupported nighties, etc etc, but with
2.7.7 a long way behind, there really isnt any way out of this swamp
but forward. Being able to jump backwards a small step to some more
solid ground would be nice-to-have.

Now, Miles said its should be fixed circa 7 hours
ago. How many hours then til the next nightly build....?

-Ben

You can check here for the status of all builds here:
http://scala-webapps.epfl.ch/hudson/ You will be interested in
scala-nightly-main. And if you are in a bind you can get previous
builds here: http://www.scala-lang.org/node/212/eclipse Of course you
will have to download and install locally.

On 2/5/2010 7:59 PM, Ben Hutchison wrote:
> On Sat, Feb 6, 2010 at 4:01 AM, kaesler wrote:
>
>
>> Would it be possible to keep a week or two of old plugin versions at the
>> update site to allow this kind of reversion to a working conmfig?
>>
> +1. Ive blundered into this by updating my SDT build an hour ago, hit
> all the same problems, now cant get back easily. Similar situation a
> month or so ago.
>
> I know we're on officially unsupported nighties, etc etc, but with
> 2.7.7 a long way behind, there really isnt any way out of this swamp
> but forward. Being able to jump backwards a small step to some more
> solid ground would be nice-to-have.
>
> Now, Miles said its should be fixed circa 7 hours
> ago. How many hours then til the next nightly build....?
>
> -Ben
>
>
>