new plugin and eclipse 3.4.0 compilation errors

[DavidV]

Hello again,
I updated my scala plugin so that I am now using the most recent
nightly plugin (7/01/08) for my scala/lift code in eclipse. I also
updated to Eclipse 3.4 "Ganymede". This is the URL that I am using
for the plugin:
http://www.scala-lang.org/downloads/distrib/files/nightly/scala.update/

When I try to debug my program I get the following error message:
ERROR - Failed to Boot
java.lang.VerifyError: class liftBasic.gid.model.User$ overrides final
method count.()J
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at bootstrap.liftweb.Boot.boot(Boot.scala:24)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at net.liftweb.util.ClassHelpers$$anonfun$createInvoker
$1.apply(ClassHelpers.scala:343)
at net.liftweb.util.ClassHelpers$$anonfun$createInvoker
$1.apply(ClassHelpers.scala:341)
at net.liftweb.http.DefaultBootstrap$$anonfun$boot
$1.apply(LiftRules.scala:585)
at net.liftweb.http.DefaultBootstrap$$anonfun$boot
$1.apply(LiftRules.scala:585)
at net.liftweb.util.Full.map(Can.scala:264)
at net.liftweb.http.DefaultBootstrap$.boot(LiftRules.scala:585)
at net.liftweb.http.LiftFilter.bootLift(LiftServlet.scala:442)
at net.liftweb.http.LiftFilter.init(LiftServlet.scala:421)
at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:
97)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:
39)
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:
593)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:
1220)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:
513)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:
448)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:
39)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:
130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:
39)
at RunWebApp$.<init>(RunWebApp.scala:16)
at RunWebApp$.<clinit>(RunWebApp.scala)
at RunWebApp.main(RunWebApp.scala)

Eclipse doesn't recognize any problems with the code so it should
build fine, as it used to about a week ago before I updated my plugin
and my eclipse version. When I look at the page on the web browser,
it partially works but where the navigation menu is supposed to be on
the left side, it just says "No Navigation Defined".

Any ideas on how to get around this problem?

Thanks,
David

[David Pollak]

The Scala Eclipse plugin is very closely tied to a particular version of
Scala. If that version is not precisely the same version as lift was
compiled with (2.7.1 final for 0.8, 0.9, and 0.10-SNAPSHOT), you will
see problems like this.

I cannot recommend strongly enough not to use Eclipse for Scala
development. Until the whole plugin mess (which has been ongoing as
long as I've been part of the Scala community) is cleaned up, Eclipse is
just plain a bad choice to do Scala development with.

Sorry.

[Marius]

Please write about this on scala list ... Sean McDirmid will most
likely respond. I also had a problem with Ganymede (couldn't compile
anything due to a NullPOinterException in Scala plugin) and Sean fixed
it over the weekend.

Br's,
Marius

[Tim Perrett]

> I cannot recommend strongly enough not to use Eclipse for Scala
> development. Until the whole plugin mess (which has been ongoing as
> long as I've been part of the Scala community) is cleaned up,
> Eclipse is
> just plain a bad choice to do Scala development with.

Come to think of it, there isnt really any IDE support yet is there?
Im using compiler terminal and Textmate and it works spiffingly

[Andreas W]

The Eclipse plugin is actually very usable. The problem is frequent
compiler changes that break binary compatibility. That in itself
wouldn't even be so bad if there were past, time-worn versions of the
plugin available to revert back to in case of problems with the daily
builds. As it is, updating the plugin is like a box of chocolates: You
never know what you will get. Worse, until just recently, there was no
way to go back. You may find yourself suddenly having to chose between
Eclipse or lift, as happened last week.

Andreas

[csar]

I had the same erro and I looked a bit into the class files.

it seems that methods from the companion object are now exposed to the
instances, the construct

User extends User fails now therefore - I managed in my case renaming
the "companion" and the Error disappeared.

If my analysis is correct and that change will make it into the next
Scala release they'll have a lot of explaining to do....


Carsten

[Jorge Ortiz]

Binary incompatibility strikes again.

Does anyone want to maintain a branch of lift that compiles with Scala
nightlies?

Advantages:
* You can write lift apps with the Eclipse plugin
* lift will be nearly automatically be ready for new Scala releases

Disadvantages:
* You'd have to periodically merge in changes from master, but git
should make that fairly painless
* Scala nightlies might not be the friendliest thing to work with

--j

[Andreas W]

Why does there need to be a branch? You would want the trunk to keep
up with the compiler, so why not compile with Scala nightlies as part
of the regular build/test process? Code breaking Scala changes should
be too rare now for that to be a lot of work, and what work there is
will likely pay off in full when it comes to supporting the next
compiler release.

As a free byproduct, we would get lift nightlies for the adventurous
that are compatible with the Eclipse plugin.

Andreas

On Jul 14, 12:56 pm, "Jorge Ortiz" <jorge.or...@gmail.com> wrote:
> Binary incompatibility strikes again.
>
> Does anyone want to maintain a branch of lift that compiles with Scala
> nightlies?
>
> Advantages:
> * You can write lift apps with the Eclipse plugin
> * lift will be nearly automatically be ready for new Scala releases
>
> Disadvantages:
> * You'd have to periodically merge in changes from master, but git
> should make that fairly painless
> * Scala nightlies might not be the friendliest thing to work with
>
> --j
>

[David Pollak]

On Wed, Jul 16, 2008 at 7:36 AM, Andreas W <wind...@gmail.com> wrote:

Why does there need to be a branch?

Because pre-release versions of Scala are not nearly as stable as pre-release versions of lift and many of us are deploying production apps off lift trunk head.
 

You would want the trunk to keep
up with the compiler, so why not compile with Scala nightlies as part
of the regular build/test process? Code breaking Scala changes should
be too rare now for that to be a lot of work, and what work there is
will likely pay off in full when it comes to supporting the next
compiler release.

As a free byproduct, we would get lift nightlies for the adventurous
that are compatible with the Eclipse plugin.

If we have a branch that's rebased with master, built with Scala nightlys, and somehow hosted on scala-tools.org, I think you'll get what you want.  If DavidB (or another Maven guru) has time to make it happen, I'm all for it.

Do I have a volunteer to do a daily update of lift to make sure that any breaking changes in Scala nightly is corrected in lift?

 

--
lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[Jorge Ortiz]

Can we set up a mailing list for nightly maintainers that Hudson can
e-mail whenever the build breaks? I'd pitch in periodically. And
usually the lift diffs from one Scala point release to another aren't
very big, so the build probably won't break too often.

--j

[Jorge Ortiz]

I've gone ahead and added a git branch "scala-snapshot" to track the
Scala nightlies. It compiles, but can't be tested, as there's no
version of Specs that targets the Scala nightlies.

Eric, is it feasible to keep a branch of Specs tracking the Scala
nightlies? I'll volunteer to help maintain it.

--j

[etorreborre]

That's a very good idea indeed. This way I will also be sure to have
the latest specs version available when a new Scala version is out.

I've just created a new branch for that (still under svn,...):

https://specs.googlecode.com/svn/branches/SPECS-1.3.0_SCALA_NIGHTLY

And added you on the developers list for the specs project.

Please ask me if anything weird happens with testing/compiling using
the nightly version.

Thanks,

Eric.

[Jorge Ortiz]

*growl*

The rabbit hole goes pretty deep, it seems.

I got specs to compile with the Scala nightlies, but again, there are
binary dependencies on scalacheck (and maybe scalatest?), which has no
version compatible with the Scala nightlies, so it throws NoSuchMethod
errors when you try to test it.

I'm kind of pissed right now because I feel like I've wasted an
afternoon, so I'll re-assess the situation tomorrow.

--j

[David Bernard]

When, branches will be ok, I'll could setup hudson to build and deploy
in the snapshot repository, to avoid pbs, I suggest to use a
classifier or a special version number in the pom (lift, and specs),
may by using an property .

/davidB

[David Pollak]

Jorge Ortiz wrote:

*growl*
  

Would a beer, a coffee or a hug help?

Thanks for putting in the effort!

[etorreborre]

Sorry Jorge,

I didn't think about that and had the same issues as you before.

Actually ScalaCheck and Scalatest are optional with specs, if you
don't use them!

But I used ScalaCheck to test Cans if I remember correctly.

Let me send an email to Rickard Nilsson and see if he's willing to
give us a hand here.

Eric.

PS: has someone already described this "open-source domino effect"
somewhere ;-) ?

[Jorge Ortiz]

Neither lift nor Specs need Specs or ScalaCheck (respectively) to
compile, just to test.

Given that, another solution is to make a Scala-nightly-compatible
lift available to people untested. They're already working with Scala
nightlies (unstable) and the new Eclipse plugin (very unstable), so
really, any further instability we add will probably be minimal...
Especially since the same lift code compiles and passes tests under
2.7.1. The odds of a test breaking between 2.7.1 and minimal, and are
equally likely to indicate a bug in the Scala nightlies as they are to
indicate a bug in lift.

</>

In the larger scheme of things, Scala binary compatibility will keep
biting us in the ass.

It generally hasn't been a problem for lift, as lift tends to keep up
with the latest Scala release, as do Specs and ScalaCheck. However,
this means that people -using- lift also have to always use the latest
release of Scala. If they use a previous version of lift, they need to
use the specific version of Scala that that particular lift release
was compiled with. They also need to use binary-compatible versions of
Specs and ScalaCheck.

This has been fine so far... but it becomes a problem as soon as
someone finds a reason to to stick to an old release of something.

Let's say there's a significant change in behavior between Scala 2.7
and Scala 2.8 that makes porting my lift app to Scala 2.8 a
non-trivial effort. It might mean I'm stuck using lift-0.10 (or
whatever the last lift compiled with Scala 2.7 was), even though
lift's latest release is lift-0.15 (or whatever). If I want lift-0.15
features, I have to port the rest of my app to Scala 2.8.

Or suppose there's some change between Scala 2.7 and Scala 2.8 that is
(god forbid) a show-stopper for lift. The rest of Scala-land evolves
to Scala 2.8 compatibility, but lift is stuck with Scala 2.7. Now lets
say there's a major bug found in Specs (also god forbid) fixed in the
latest (2.8 compatible) version of Specs. Unless Specs backports this
fix to their latest Scala 2.7 version, lift's Specs will forever be
buggy.

Now imagine you depend on some Scala library that is no longer being
maintained... If it's open source, you'd better start maintaining it
if you ever hope to upgrade Scala versions. If it's closed source,
you'd better not hope to ever upgrade Scala versions. And if those
libraries have dependencies on -other- Scala libraries and they are
all no longer maintained... Using Scala libraries means risking that
you'll have to maintain the transitive closure Scala libraries.

Scala code projects become hostages to their libraries. At some point
(unless Scala acquires binary compatibility), "well-behaved" libraries
will have to maintain releases for several Scala releases.

lift-0.9-sc2.7.1
lift-0.8-sc2.7.1
lift-0.8-sc2.7.0
lift-0.7-sc2.7.1
lift-0.7-sc2.7.0
lift-0.7-sc2.6.1

My headache grows as O(n^2)

--j

[David Pollak]

Jorge,

This is very good analysis.  The factor that I think you may have missed is the fact that most medium to large organizations will standardize on a particular version of a language and a framework and only change after an extensive evaluation of the new version.  Without forward binary compatibility between Scala versions, it means that we'll have an absurd number of maintenance branches.

I'm cc'ing Martin and Geoffrey on this note so they can have another data point as they decide how much effort to devote to forward binary compatibility.

Thanks,

David