Best practices for IntelliJ IDEA Scala Development?

[Ashley Aitken]

Howdy All,

I've just started using IntelliJ IDEA with the Scala plugin for Scala development (with Akka) and I'm experiencing some problems (e.g. tests not getting compiled; compiler errors in IntelliJ, which aren't there in SBT; missing classes when running code in IntelliJ, which aren't there in SBT). 

I am not asking for specific solutions to these problems but just what is the best practice for Scala development with IntelliJ IDEA and the Scala and SBT Plugins.

Is it best to import a project or generate the IDEA configuration using SBT?  Is it best to use IntelliJ IDEA exclusively once the project is within IntelliJ or to continue using SBT with IntelliJ?  Are there still basic problems with Scala development on IntelliJ IDEA?  What are best tips and hints?

How do you get the best out of IntelliJ IDEA with the Scala and/or SBT Plugins?  

Is Eclipse with the Scala Plugin better?

Thanks for your thoughts.

Cheers,

Ashley.

[Vlad Patryshev]

My (maybe limited) experience is this:

- yes, generate idea project from sbt;

- you can use sbt for full builds, for running all tests, etc; but for getting into details, for refactoring, and in general for handling the code IDEA is ideal;

- seems like every time one starts on a new project with IDEA and Sbt, one has such troubles that you describe; but then the dust settles.

One trick is to make sure, from time to time, to "invalidate caches" in IDEA, and to recompile. Can't explain. Also, synchronize.

I do have a couple of problems with IDEA/SBT interop (someone creates a parasitic module, I have to kill it manually; and also sbt files are not properly recognized by IDEA); but somehow I live with it.

Thanks,
-Vlad

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Will Sargent]

I've found that IDEA's import project still lacks compared to sbt-idea, because it doesn't link the source code correctly somehow.

What I typically do:

1) create a project/sbt-idea.sbt file and put addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.6.0") in there.
2) sbt gen-idea
3) Open intellij idea and tell it to ignore the build.sbt file (otherwise IDEA will eat CPU every time you touch build.sbt)

From then on, I do all my compiles and runs inside of an sbt / activator session from iTerm2, and I write all the code in IDEA.  If I touch anything in build.sbt, I re-run gen-idea and then restart IDEA and reload the project.

I have been having problems with IntelliJ IDEA 14, where libraries which are in the project are not showing up in the editor view as resolvable.

Moving back to Intellij IDEA 13 solved this for me. 

Will Sargent

Consultant, Professional Services

Typesafe, the company behind Play Framework, Akka and Scala

[Dennis Haupt]

i am running into problems if i use both sbt and intellij idea for compilation. it all is fine if i don't compile using idea and use sbt for compilation (on a separate console, or using the sbt console plugin)

 

Gesendet: Freitag, 07. November 2014 um 19:34 Uhr
Von: "Vlad Patryshev" <vpatr...@gmail.com>
An: "Ashley Aitken" <amai...@gmail.com>
Cc: scala-user <scala...@googlegroups.com>
Betreff: Re: [scala-user] Best practices for IntelliJ IDEA Scala Development?

[Jason Nerothin]

If you're not on version 14, I recommend using it. 

There is a fair amount of "scala churn" version to version, but my initial impressions are positive for the newest edition (+scala plugin).

[Dennis Haupt]

ah yes, my coworker uses intellij13, i always use the 14 eaps - they are significantly better

 

Gesendet: Freitag, 07. November 2014 um 20:45 Uhr
Von: "Jason Nerothin" <jasonn...@gmail.com>
An: "Dennis Haupt" <h-s...@gmx.de>
Cc: "Vlad Patryshev" <vpatr...@gmail.com>, "Ashley Aitken" <amai...@gmail.com>, scala-user <scala...@googlegroups.com>
Betreff: Re: Re: [scala-user] Best practices for IntelliJ IDEA Scala Development?

[Ashley Aitken]

Thank you everyone for sharing your experiences and approaches to working with Scala in IntelliJ IDEA with the Scala plugin and SBT.

I must say though I'm a little dismayed and disappointed that a professional IDE for Scala development is still somewhat problematic.

Is Scala IDE for Eclipse a more solid alternative?

Thanks,

Ashley.

[Andreas Joseph Krogh]

I'm curious; What is it that IntelliJ-IDEA 14 release doesn't do for you, which makes Scala development problematic?

 

--

Andreas Joseph Krogh

CTO / Partner - Visena AS

Mobile: +47 909 56 963

and...@visena.com

www.visena.com

 

[Ashley Aitken]

Hi Andreas,

On Saturday, 8 November 2014 21:55:33 UTC+8, andreak wrote:

I'm curious; What is it that IntelliJ-IDEA 14 release doesn't do for you, which makes Scala development problematic?

 

To be honest, I have just moved to IntelliJ-IDEA 14 (from 13) and haven't full tested it out. I indicated in my original post what sort of problems I was having and it seems others have experienced these as well.  

I find it difficult to work in an environment where I don't know if problems are caused by what I do (usually the case) or the environment.  I was also hoping that once the project was in IntelliJ I wouldn't need to directly use SBT again.

I am not an experienced Scala developer or IntelliJ IDEA user.  

Cheers,

Ashley.

[Simon Ochsenreither]

Hey Ashley!

> Is Scala IDE for Eclipse a more solid alternative?

I think people are completely split on this. Some love IntelliJ + Scala plugin and consider Scala IDE to be terrible, for some it's exactly the opposite.

Best thing is to use SBT, generate project files for both IDEs and then just try and compare both IDEs to make up your own mind.

Bye,

Simon

[Ashley Aitken]

Hey Simon,

Thanks for your reply to my post. 

I understand these sort of discussions can come down to personal preferences (vi vs emacs anyone?) but my question was more about which environment works better (i.e. without bugs, compilation issues etc.) as opposed to overall functionality and features.

I will try out Scala IDE for Eclipse as you suggest.  

Cheers,

Ashley.

[Andreas Joseph Krogh]

På lørdag 08. november 2014 kl. 15:49:15, skrev Ashley Aitken <amai...@gmail.com>:

 

Hey Simon,

 

Thanks for your reply to my post. 

 

I understand these sort of discussions can come down to personal preferences (vi vs emacs anyone?) but my question was more about which environment works better (i.e. without bugs, compilation issues etc.) as opposed to overall functionality and features.

 

I will try out Scala IDE for Eclipse as you suggest. 

 

This is exactly what causes the split; The definition of "works better" varies greatly, with good reason. People have different needs.

[Simon Ochsenreither]

I understand these sort of discussions can come down to personal preferences (vi vs emacs anyone?) but my question was more about which environment works better (i.e. without bugs, compilation issues etc.) as opposed to overall functionality and features.

No, it's not really personal preferences. It's really just whether Eclipse decides to hate that person or not (which seems to depend on celestial alignment). Eclipse hates me, but I endure it because I want to use the original scalac typechecker, and not IntelliJ's homegrown one. My recommended tactic is just to never touch anything in Eclipse except the editor and let SBT create the project files, so that don't give Eclipse the chance to mess stuff up.

Your mileage may vary.

[Ashley Aitken]

I get the impression this is one approach to using IntelliJ IDEA as well: never touch anything in IntelliJ except the editor and let SBT create the project files, so don't give IntelliJ the chance to mess stuff up.

I'm not used to this approach to using an IDE.

[Andreas Joseph Krogh]

På lørdag 08. november 2014 kl. 19:21:08, skrev Ashley Aitken <amai...@gmail.com>:

 

I get the impression this is one approach to using IntelliJ IDEA as well: never touch anything in IntelliJ except the editor and let SBT create the project files, so don't give IntelliJ the chance to mess stuff up.

 

I'm not used to this approach to using an IDE.

 

If the leading IDEs have such a difficult time getting SBT-integration right one might wonder if SBT really is a Simple Build Tool.

I still use Maven and have no problems with neither command-line builds nor IDE-integration.

[Dennis Haupt]

intellij uses sbt to generate project files for it. the problem starts when i use both intellij and an external sbt for compilation. but i never investigated anything and just went with intellij = editor/refactoring, sbt = compile

 

Gesendet: Samstag, 08. November 2014 um 20:50 Uhr
Von: "Andreas Joseph Krogh" <and...@visena.com>
An: scala...@googlegroups.com
Betreff: Sv: [scala-user] Re: Best practices for IntelliJ IDEA Scala Development?

--

[Peter Chapin]

On Sat, 8 Nov 2014, Andreas Joseph Krogh wrote:

> If the leading IDEs have such a difficult time getting SBT-integration
> right one might wonder if SBT really is a Simple Build Tool. I still use
> Maven and have no problems with neither command-line builds nor
> IDE-integration.

I've never used SBT. I've heard quite a few nightmare-ish stories about it
here and elsewhere so I stay away from it. It sure seems like the tool
creates more problems than it solves!

Peter

[Jason Zaugg]

On Sun, Nov 9, 2014 at 8:03 AM, Dennis Haupt <h-s...@gmx.de> wrote:

intellij uses sbt to generate project files for it. the problem starts when i use both intellij and an external sbt for compilation. but i never investigated anything and just went with intellij = editor/refactoring, sbt = compile

The SBT team is working on this problem and have been talking to JetBrains about what SBT can provide to make things smoother.

More details: https://github.com/sbt/sbt/wiki/Client-server-split

-jason

[ericacm]

Intellij works great with Maven and Scala.  It's a really nice integration.  If you tweak the pom file, say to add a dependency or change a version, Intellij automatically notices, downloading jars and updating its internal model.

SBT support is very new, so it will probably take a while for it to be as smooth as with Maven.  I've imported a few projects using build.sbt and the small projects imported ok.  For large projects (for example Akka), it was pretty slow, and the Intellij internal model did not get built 100% correctly.  For example, some modules didn't know where other module's classes were defined.  At some point I may try to manually fix everything up in my Akka project.  If I get time. :)

sbt gen-idea works well, the only drawback is having to re-gen as the build evolves.  But even then with Akka it's not 100%.  To me the gold standard of sbt IDE integrations would be to seamlessly import Akka.

I'm looking forward to the sbt server architecture that Jason mentioned.

[kcwill]

I use SBT and IDEA in the following way: create an SBT project with IDEA and manage the project using sbt only. I compile and package from the sbt console window. I just use the sbt plug in to sync IDEA for presentation and debug/run purposes only. This has worked reasonably well even for multi-project projects with many dependencies. On rare occasion I have to refresh the project or invalidate caches but I am happy with it.

[kcwill]

I use idea and SBT in the following way:

I create projects using IDEA's SBT template, but I configure and manage the project using SBT only. I let the SBT plug in sync IDEA for presentation and run/debug purposes but I do everything else through either editing sbt files or sbt commands from the sbt console plugin. 

This has worked well for me even with relatively large multi-module projects with many dependencies. 

[Peter Chapin]

I'm a fairly heavy Emacs user also. Perhaps an Emacs+SBT work flow would
be effective. Maybe I should look into that at some point.

Peter

On Sun, 9 Nov 2014, kcwill wrote:

> I used to feel the same way, but I kept hearing people talk about how powerful SBT is. I
> eventually broke down and invested a little time into learning it. What ended up converting me
> was how cleanly SBT let me manage multi-module projects. Then I needed to wire a
> code-generator into my build pipeline. Once I saw how elegantly SBT supported this, I was
> hooked.
>
> I think the main drawback of SBT is that it is not as accessible as the IDE at first. But it
> offers far more power once you learn the basics.

[Simon Ochsenreither]

I've never used SBT. I've heard quite a few nightmare-ish stories about it
here and elsewhere so I stay away from it. It sure seems like the tool
creates more problems than it solves!

I think all build tools share the trait that they are terrible.
SBT is the least terrible of all build systems I know, additionally, it has a lot of places where it just amazes me, unlike most other build tools.

[Haoyi Li]

> SBT is the least terrible of all build systems I know, additionally, it has a lot of places where it just amazes me, unlike most other build tools.

+1 to this. 

On the other hand, every nightmarish story you've heard about SBT is true. Bash scripts, maven POMs and Ant files all have the same "the designers didn't know any better, it was a while ago" feel to them. SBT is in a unique in showing you such incredible genius that your brain explodes on a regular basis, and not in a good way.

What other build system has fishbones as an un-documented (like all the others) operator? 

<++=

--

[Peter Wolf]

Hello, I am also very happy using IntelliJ and Scala.  

I also do not use SBT.  Our projects use both Java and Scala, and we use Maven.  IntelliJ imports the pom.xml to create a project.  It all works fine.

However, I definitely recommend you upgrade to IntelliJ 14.  The new IntelliJ is significantly faster, and the error highlighting works better.  

I found the files generated by Slick CodeGen drove IntelliJ 13 to its knees.  It became impossibly slow.  IntelliJ 14 fixes this.

P

[Dmitry Grigoriev]

Hi. Looks I'm a bit too late. Anyway: I use scala + sbt + gen-idea + IDEA for a pretty long time for now (since the very beginning actually, which was 2.7.x for me AFAIR). I must say it's very far from good, but alternatives are even worse.

What is bad in my current setup:

1) IDEA colors all my macros in red!!! :( It does not understand quasiquotes, so in (val x = q"...") it colors q in read and also infers its type as Any so everything that uses that x below gets type errors colored in red too. It does not handle path dependent types correctly so if I create macro helper like this (val mh = new MacroHelper[c.type](c), where c is Context) and then call its method it always says that mh.c.type != c.type.

2) When I tried to migrate from scala 2.10.3 to 2.11.x about 0.5 year ago I just could not find gen-idea version which would work with scala 2.11. This is not the only reason I'm stuck in 2.10 (also my macros weirdly broke apart), so I'm not even going to try again until... well, I heard there's ongoing work of completely rewriting macro framework; that's going to be a good reason.

Why alternatives are worse for me:

1) Eclipse platform itself: this would look like a good old holywar, but speaking of usability, configurability, etc. I would not even try to compare it to IDEA. Totally different levels.

2) Scala-IDE: last time I tried it about a year ago. It crashed almost instantly. "How familiar" - I recalled my experience of one more year ago, and with a sad sigh returned to IDEA. For now I don't have neither time nor reasons to try again, so I'll skip this year's attempt.

3) To happy ones whose Scala-IDE does not crash: its background compilation was really slow on large multi-module projects. Screw red colors in macro source, but everywhere else IDEA is 1-2 orders more responsive to changes in code. This is by its own a very serious reason to throw Eclipse away because it was nothing but asspain: turn on background compilation - everything terribly lags; turn off - get blind.

4) When I failed to run gen-idea with 2.11, I tried IDEA's new sbt project importer. It hanged. "Damn, boy, aren't you lucky?" I was already tired of that fight and didn't try to find how to give it more memory maybe or anything else. High configurability has its backside: settings are well structured about IDEA's own stuff (code formatting & coloring, etc.) but when it comes to configuring external tools integration, I swear gentoo text configs are simpler to understand. (Well, actually Eclipse is not better in this matter. I have a long story to tell here but it's not actually related to Scala.)

So in two words, the good old principle of choosing lesser evil. And on this very positive note, let's finish. :)


Once in about a year I'm trying to migrate to scala-ide. Last time (0.5 ... 1 years ago

[Dmitry Grigoriev]

I forgot one more problem about IDEA + macros: if macro annotation adds fields/methods to class/object, IDEA obviously won't see those added fields/methods. So for macros (both development and even usage), full blown compilation performed by Scala-IDE is needed.

[Jaap Taal]

Hi Dimitry,

IntelliJ has improved a lot since version 14. I'm not using sbt gen-idea any more, but import the directory and select SBT while importing. It works better than gen-idea. It's quite fast and compiles the SBT project dir quickly. The first time might be very slow if you have a lot of dependency's and when you're using macros, it needs to compile the compiler library...

About the macros, we're using quite a couple of Blackbox macros and have no problems with them. If you're using whitebox macros, it's not a real surprise that IntelliJ doesn't understand them. I believe Eclipse may do a better job regarding Whitebox macros. When scala meta (http://scalameta.org/) gets developed further there is a good change we will see improved scala support.

Cheers!

Jaap

[Jaap Taal]

I use the console to compile code and run tests, this works well.

If you use the SBT import in IntelliJ I believe it should use sb'ts compiler when you Make the project, but I don't use this. Using the commandline really helps out imho.

[Dmitry Grigoriev]

Ops, I remember visiting jetbrains site pretty recently, but they already managed to release v14 since then. =) Thanks for info, I'll try it out.

I also build projects in console. I have two tabs in Konsole: one runs interactive sbt where I do nothing but press up&enter to issue last command which is always "deploy-local" (my own stuff which performs incremental jar copying / ssh uploading), in second tab I restart console app which contains embedded jetty and all reflectionary stuff precompiled with macros, so it restarts by ctrl+c&up&enter in less than a second (unavoidable JVM startup overhead). So edit-and-try works for me almost as fast as if it was not compiled Scala but PHP. :)

[Jaap Taal]

Why not run with built in netty? Just sbt run, works really well for us...

--
You received this message because you are subscribed to a topic in the Google Groups "scala-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-user/V1iD92Wyzjg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-user+...@googlegroups.com.

[Jaap Taal]

Hi Dimitry,

It looks like you've thought this through. What I mean by sbt run, I was assuming you use playframework, but I guess you're not. Maybe you should let look into that sometime, sorry for the confusion! The run command in your project, if any, will probably not do what you want...

Jaap

On Nov 14, 2014 3:32 PM, "Dmitry Grigoriev" <ma...@dimgel.ru> wrote:

On Friday, November 14, 2014 1:50:49 AM UTC+3, Jaap Taal wrote:

Why not run with built in netty? Just sbt run, works really well for us...

1. Because this is the first time I've heard of it. (Maybe not the first at all but the first time someone points _me_ to it.)

2. Little googling found me this: http://stackoverflow.com/a/8639995/4247442  So while I'm happy with jetty (and I'm really happy with its speed and easy programmatic XML-less configuration) there's no reason to switch away.

3. Don't understand "just sbt run" but if you mean it would require sbt on production then that's too bad. And if you mean it's just easy to start it on dev machine under sbt, then AFAIR jetty had some sbt plugin too but I don't want it at all: during app startup I perform syncrhonous DB migrations, spawn thread for long-running asynchronous DB migrations, setup two socket servers for internal RPC API besides HTTP server, etc. Pretty lot of stuff. So I prefer having full control of what, when and how initializes in my Main. BTW I recall I had an idea of terminating/restarting my console app from under my local-deployer, but don't want to spend efforts for it now.