This page is no longer maintained — Please continue to the home page at www.scala-lang.org

ENSIME and scala-library, suggestions?

1 reply
Aemon Cannon
Joined: 2010-03-21,
User offline. Last seen 1 year 24 weeks ago.

I'm trying to come up with a simpler, friendlier behavior for ensime wrt
to finding the scala-library for the active project.

Currently, ensime is very dumb about this. It expects the user
to provide the scala-library via the project's configuration. For sbt
projects the lib is in a known location. For maven, generally the
pom.xml declares a dependency on the lib, and it gets pulled in that
way. For custom projects, the user must include the lib using the
.ensime configuration format.

This all works pretty well. But, there are some nagging issues:

0) If a scala-library is not found on the classpath, the compiler will
die in a nasty way (this could be mitigated, awkwardly..).

1) If the scala-library version is not compatible with the
scala-compiler that ensime is compiled against, things will kerplode.

2) New ensime users often forget to add the scala-library to the
classpath. See 0.

3) For pure-java projects (ensime's java support is improving) it's
unreasonable to expect the user to think about including a scala-library.

Fortunately, ensime ships with its own scala-library. It seems to me the
best solution is to just always use this library. Perhaps also adding a
manual override option to the .ensime format, just in case you want to
specify a customized library.

Any objections to this?

If a user specifies their own scala-library jar via maven or sbt or with
the :compile-jars .ensime option, it should be ignored. This brings me
to an implementation question: if I prepend ensime's default lib to the
project classpath, is that sufficient to override any project-specified
scala-library? Or could having two libs on the project classpath cause a
problem during compilation?

Thanks,
Aemon

Chris Twiner
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: ENSIME and scala-library, suggestions?

Ignoring the technical cp issue I don't see any way to avoid ensime using its library due to all of your above points.

This would be bad if you didn't release as often as you do :-)

Personally I am a very happy user can't thank you enough.

On 11 Feb 2011 08:24, "Aemon Cannon" <aemoncannon [at] gmail [dot] com> wrote:

I'm trying to come up with a simpler, friendlier behavior for ensime wrt to finding the scala-library for the active project.

Currently, ensime is very dumb about this. It expects the user
to provide the scala-library via the project's configuration. For sbt projects the lib is in a known location. For maven, generally the pom.xml declares a dependency on the lib, and it gets pulled in that way. For custom projects, the user must include the lib using the .ensime configuration format.

This all works pretty well. But, there are some nagging issues:

0) If a scala-library is not found on the classpath, the compiler will
die in a nasty way (this could be mitigated, awkwardly..).

1) If the scala-library version is not compatible with the scala-compiler that ensime is compiled against, things will kerplode.

2) New ensime users often forget to add the scala-library to the classpath. See 0.

3) For pure-java projects (ensime's java support is improving) it's unreasonable to expect the user to think about including a scala-library.


Fortunately, ensime ships with its own scala-library. It seems to me the best solution is to just always use this library. Perhaps also adding a manual override option to the .ensime format, just in case you want to specify a customized library.


Any objections to this?


If a user specifies their own scala-library jar via maven or sbt or with
the :compile-jars .ensime option, it should be ignored. This brings me to an implementation question: if I prepend ensime's default lib to the project classpath, is that sufficient to override any project-specified scala-library? Or could having two libs on the project classpath cause a problem during compilation?


Thanks,
Aemon




Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland