Tag Archives: Tooling

Developing with Lift in Eclipse

Posted by on October 2, 2010 12 comments

A few weeks back, I wrote a blog entry lamenting the attitude toward IDEs in the Scala community. A few people told me that the tooling situation was better than I’d implied, so I thought I’d spend a bit of time looking at using Scala (and Lift specifically) in Eclipse. I think the situation is still a ways away from the tooling situation for Java, but it is actually quite good, and I wanted to post a quick tutorial for those interested in developing Lift in Eclipse.

Prerequisites

This post assumes that you already have Scala 2.8 final and Eclipse 3.6 on your system. For Eclipse, I recommend upping the Xmx setting if you haven’t already – I had issues when I had multiple Lift projects imported with Xmx set to 386.

Also, this tutorial is going to use Maven, not SBT. SBT may be a better build tool for Scala projects, but I’m not sure how well it works with m2eclipse – I’m going to play with that more later.

I also assume you know how to install plugins into Eclipse – I will create a more in-depth screencast for doing all of this if there is enough interest.

1. Install m2eclipse

Install m2eclipse using the following URL:

http://m2eclipse.sonatype.org/sites/m2e

If you need full instructions, you can go here:

http://m2eclipse.sonatype.org/installing-m2eclipse.html

2. Install the Scala IDE

Get the Scala IDE for Scala 2.8.0 and Eclipse Helios here:

http://download.scala-ide.org/nightly-update-helios-2.8.0.final

3. Install the m2eclipse-scala plugin

There is a configurer for m2eclipse that will setup Scala projects for you. You can install it using the directions here:

http://github.com/sonatype/m2eclipse-scala

The short version of those instructions:

1. Download the latest jar found at this url:

http://github.com/sonatype/m2eclipse-scala/downloads

2. Copy it to the dropins/ directory in your Eclipse installation

3. Restart Eclipse

4. Create a Lift project from an Archetype

Now you can create a new Lift project from the Archetype – this is effectively the same as running the mvn archetype:generate command that the Lift ‘Getting Started’ guide tells you to.

To do this, go to File > New > Other… > Maven > Maven Project

Follow the wizard until you get to the Select an Archetype screen. In the Catalog drop-down, select the Scala-Tools.org Catalog. A list of archetypes will appear below – you can filter down to just the Lift projects by typing ‘lift’ in the Filter box. Select one of the Scala 2.8/Lift 2.1 archetypes – I selected lift-archetype-basic_2.8.0. Click next and fill in the information (group id, artifact id, and version), and then click ‘Finish’.

m2eclipse will spend a few minutes setting up your project, downloading sources, and configuring it in Eclipse.

5. Import an existing Lift project (optional)

If you already have a Maven-based Lift project, you can import it. Just select File > Import.. > Maven > Existing Maven Projects and then follow the wizard to import your project. It will configure everything for you.

6. What you can do

So, now that you have a Maven-based Lift project in Eclipse, what can you do?

– Code complete, syntax highlighting, and real-time compiler errors are available

– Code navigation works quite well – you can CMD/Control + click a class or method to go right to it. Cmd + O will let you navigate the methods and fields in the current class.

– m2eclipse will download sources for you automatically – this is one of my favorite features. If you navigate to a class in the Scala API or Lift itself, you’ll see a rough decompiled view of the class for a second while m2eclips grabs the sources, then it will refresh with the actual source code. This is a really handy feature! It will also download scaladocs for you.

– You can setup an m2eclipse command to run Jetty within the IDE. Right-click on the web project and select ‘Run as…’ > Maven build… You’ll be presented with a screen for creating a new maven runtime configuration. In the Goals box, add jetty:run, then click ‘Run’. This configuration will be saved, so you can run your project in Jetty anytime you want by using the Run button in the menu bar. You can also do this for the mvn scala:cc command if you want.

7. Final thoughts / Feedback

I think the tooling situation for Scala and Lift is pretty good – much better than when I was doing a lot of Lift work last year. A lot of credit goes to Miles Sabin, David Bernard, and others who have done a lot of work to make this possible.

If this post was helpful, please let me know. I’m also interested to know if people are interested in more in this area, specifically:

1) A screencast showing how to do all of this, and what other features are available when working with Scala/Lift projects in Eclipse.

2) A single Eclipse feature that can tie all of the above features together into one easy-to-install package, along with setting up the m2eclipse Run As.. commands automatically for you.

If either of these interest you, or you have any other ideas, please let me know. You can either leave a comment on this post or email me directly (suresk@gmail.com). You may also follow me on Twitter – @suresk.

IDEs are not about code generation

Posted by on September 11, 2010 4 comments

There’s been a lot of interesting topics on Twitter, the JavaPosse Google Group, and various blogs recently about the “complexity” of the Scala language and whether it will be the next Java. This isn’t meant to be a post ripping on Scala – I respect the hard work from the talented individuals it took to create Scala, and I think it is a delightful language.

However, there is more to a language than the language itself, and I think the tooling situation in Scala leaves much to be desired. This is fixable – Miles Sabin and others are doing some excellent work to improve the tooling situation in Scala. What is more worrisome is the attitude that a lot of people in the Scala community seem to have toward IDEs.

Every week or so, someone pops into the Scala or Lift mailing list and asks about the IDE situation with Scala. They are met with a smattering of helpful replies pointing them to the IntelliJ plugin, the Eclipse plugin, someone’s favorite TextMate bundle or whatever. There are also, inevitably, a handful of people questioning the need for an IDE in the first place – “Scala is such an elegant language, why do you need an IDE?” or “Scala requires no code generation like Java does, so why do you need an IDE?” or “You don’t need anything more than emacs” are some common refrains.

Development environments are very personal, often irrational

I’ve been working on developer tools for the last several years, and one of my most memorable experiences was talking to developers about IDE usage a year or two back. I’m a die-hard Eclipse user, and I was talking to a group of equally die-hard IntelliJ users about what they liked about it. I remember walking away shocked, thinking “What the hell are these guys on? Over half the things they liked about IntelliJ are reasons I quit using it!” I’m sure had I shared my reasons for being an Eclipse enthusiast, they’d be thinking the same thing about me.

One of the biggest lessons I’ve learned over the past few years is that developers are often very passionate about their development setup and are loathe to change it. The best development environment is the one you are most productive in – whether that is Eclipse, Netbeans, IntelliJ, TextMate, vi, emacs, dictating your code to an intern, or writing it on a piece of paper and scanning it in. I’m not arguing that people who are happy writing Scala (or any other language) in emacs are idiots and should use a modern IDE, but I am arguing that there are millions of developers who derive significant productivity benefits from using one and we aren’t interested in stopping just because a new language has nicer syntax.

Not just code generation

A common argument against modern IDEs is that people use them largely for code generation, and thus, languages such as Scala that are generally more elegant and terse don’t really benefit from an IDE. This is way off the mark. Code generation is only a tiny part of IDE usage for most people, and Scala benefits from an IDE almost as much as Java does. Let’s look at some uses for a modern IDE such as IntelliJ or Eclipse:

1. Syntax Highlighting

Yes, most text editors do this perfectly well.

2. Debugging

Being able to debug your code from within the same program you are writing it has a lot of benefits.

3. Real-time compilation information

Being able to immediately see when you’ve done something that the compiler doesn’t approve of is a time-saver, and can be especially helpful when you are learning a new language.

4. Auto Complete

Is this a form of code generation? Maybe, but I’d argue it goes well beyond simply saving you a few keystrokes. For one, autocomplete functionality can be pretty useful when you can’t quite recall what the method name is, what parameters it requires, or what it returns – a nice language can’t help you avoid this, this is a problem of being able to instantly recall details about potentially thousands of classes in hundreds of libraries. Second, autocomplete in Eclipse (and other IDEs, I assume) can show you JavaDoc information inline, saving you a context switch out to your browser to view them.

5. Getting useful information about the code you are working with

What calls this method? Where is this variable referenced? What classes implement this interface? What does this class’ inheritance tree look like? All of these are pretty useful things to know, and IDEs make them trivial to discover.

6. Code navigation

Ctl+o in Eclipse opens up a list of methods in the current class, ctl+o again changes the scope to all of its parents – this makes it trivial to navigate to a specific method. Ctl+clicking on a class or method takes me directly to it.

7. Easy access to sources

Being able to jump directly to the source of a library is often useful as well, and this works quite well in current IDEs. M2eclipse will automatically download sources for Maven-based projects, which makes this even easier.

8. Refactoring

One of the benefits of statically typed languages such as Scala is that you can refactor your code with a high level of confidence that you haven’t horribly broken something. IDEs make this task even easier.

9. Version Control integration

It is also nice to be able to interact with a version control system directly from your IDE, without having to switch to another program to checkin your changes, perform merges, get new code, etc.

Final Thoughts

You’ll notice that of the uses for an IDE I’ve pointed out above (which are not a comprehensive list by any means), at least half of them are especially useful for someone learning a new language or framework. Yes, I know Scala has a REPL that is quite useful for when you are initially learning and playing around with the language, but I think an IDE is incredibly helpful for that phase when you’ve been playing with the language for a month or so and are now trying to do something productive with it – the instant feedback and wealth of information that an IDE can provide is incredibly valuable during that time.

This wasn’t intended to be a mean-spirited post and I hope it didn’t come across that way. I’m just trying to point out that IDEs are not crutches for hack programmers who want a tool to write code for them – IDEs are incredibly useful, even for Scala.