Scala + IDE (looking for the holy grail)

This post is going to touch one of the most religious topics in coding: the IDE.

It doesn’t matter if it’s Eclipse vs Netbeans or Idea vs all of them, a developer loves and defends his IDE (most of them).

For a long time I have been a true follower of the Eclipse way of things. I loved its extensibility and the amount of available plugins. I really liked doing RCP projects and to work with Eclipse.

But since I started working with Scala I also wanted to take a look at the different IDEs out there.

I gave them all a little rundown. These are the results.

What I wanted to do

I already did some stuff with Scala and SBT and decided to start a small pet project.

Nothing too fancy. Some jMonkeyEngine flavor, playing with actors and reimplementing some algorithms.

After some playing around with jEdit, Git and SBT I started playing with the big three Java-IDEs.

Chapter 1: Eclipse

Naturally I started out using Eclipse.

Sure, I already knew the m2eclipse plugin was crap.

Crap like in

• I can’t believe I got caught in the endless cycle of recompile again.
• Dammit, it compiles on the cmdl but gives error warnings in the IDE?
• Why, what, … ahhhhh it crashed again

I could continue for hours ranting about this abomination but it’s not the topic of this post. In the end I ended up uninstalling it and using the maven eclipse plugin like everybody else.

The next thing I tried was Eclipses Git support. The plugin looks very solid and didn’t give me any problems.

Finally I got to Eclipses Scala support. Eclipse features set of plugins (http://www.scala-ide.org/) to integrate Scala.

Sadly the state of these plugins is rather discouraging. Right now Eclipse (3.6 Helios in my case) will frequently hang while working on Scala files. Autocomplete looks more like guesswork and often misses some entries. Several times my whole Eclipse crashed while either refreshing a file I just had edited or trying to autocomplete.

Ah, and not to forget about the popup warnings.

A message to developers: If there is a problem that doesn’t crash your app or causes your project to spontaneously go up in flames don’t show a popup warning and make me click on a button. This makes the whole thing completely unusable for an impatient person like me.

Sadly, there is no other option for Eclipse. Right now I’d consider this thing an absolute no go.

The good news is that the Martin Odersky (creator of Scala) just joined the eclipse scala-ide which will hopefully lead to a way better IDE.

Chapter 2: Netbeans

Some history about my relationship to Netbeans.

I started out doing java in vi, then I switched to JBuilder. For a brief time I used Netbeans. I hated it.

It was horrendous experience. It was slow, a memory hog and slow. Did I mention it was slow.

So, after battling a full week against my mixed feelings towards Netbeans I downloaded and installed it (for this I tried both, 6.9 and 7.0 Beta 2).

…

I loved it. Netbeans allowed me to use the same shortcuts as Eclipse (relearning shortcuts is something I really wanted to avoid). The interface is clean and feels snappy. It comes with maven integration out of the box. And the maven support actually works.

So, things looked good on that front.

Next thing I tried was git support. From my limited testing I would say things look pretty solid. No crashes, no problems. But again: I just did very basic things there.

Note: Right now Oracle is developing an official plugin for Git.

And finally I tested the scala support.

Sadly Netbeans Scala support is as bas as Eclipses.

It crashes, it hangs, it doesn’t do auto complete most of the time and things sometimes get outright weird.

And again a message to developers: If there is a problem that doesn’t crash your app or causes your project to spontaneously go up in flames don’t show a popup warning and make me click on a button. This makes the whole thing completely unusable for an impatient person like me.

Chapter 3: IntelliJ IDEA

I haven’t payed for a Java IDE since JBuilder and I want to keep it that way. Luckily IntelliJ decided to change the way they do things and since IDEA 9 there is a free version. I got IDEA 10, the most current version as of this writing.

IDEA comes with maven support out of the box, just like Netbeans. Things simply work and I don’t have to perform black magic when importing a project, a big plus compared to Eclipse.

Git also worked without any problems.

Now for the scary part: Scala support.

It works.

Yes, autocompletion needs some work as sometimes not all options show up but it doesn’t crash and doesn’t force me to click on a damn pop-ups everytime something goes wrong.

It even comes with SBT support and decent syntax highlighting. There is still some work needed but it does a lot of the things I wanted and all I needed.

Wrapping up

Eclipse:

Git support is the only thing out of my list of requirements that did its job.

Maven support is utterly broken and the Scala IDE causes way more pain than is justifiable.

Netbeans:

Great Maven integration, Git worked without any problems. Scala support is broken.

I still really like the IDE and I am hoping to get back to it at some point.

IntelliJ Idea:

The clear winner.

Flawless Maven support. Working Git integration. A Scala plugin that solves more problems than it causes.

That’s it for now.

I am going to revisit the whole thing in a few months.

Advertisement

Me, OSGi and Maven

I don’t like Maven. That’s just how it is. And I whine a lot about it (probably unnerving some of my colleagues).
But I have to admit it’s usefulness. As long as there is no other tool that gives me all the nifty things I will have to stick with it (and abandon it the moment something better shows up).
I love OSGi. I like the things you can do with it. Right now there’s a chance to use it in one of our projects.
The only problem: OSGi and Maven don’ really play nice together.
At least that’s what I thought.
After writing this post and looking back at what I had tried in the past weeks I have to rethink my opinion on that.
There are several different approaches for getting Maven to build OSGi-apps, it’s just that you really need to know what you want to do.
I want to use this post to give a brief introduction to the different approaches and show their weaknesses and strengths.
Here we go.

Maven and a MANIFEST-generator

 

Tools like BND (created by Peter Kriens, the well known OSGi-evangelist) and Bundlor (created by the spring project) are used
to:

• turn exisiting jars into bundles

• package the results of a build process as a bundle

Both tools analyze the classes to figure out their imports and exports and generate a MANIFEST.MF from this information.
They take commandline arguments and can be configured via config-files to deal with special cases.
The Maven/Ant integration they provide is good and easy to use.
Looking at their capabilities and intend I would say they are best suited for the following scenarios:

• OSGifying an existing build process. You won’t have to make changes to your build process to add bundle information to your libraries.
• Projects that are ment to be deployed into an OSGi-enabled framework, like a web application.

Often enough that’s already enough.
Just be aware of the problems this approach may cause.
The biggest being dependencies not being available as a bundle.
Maven has no idea what a bundle is. It will satisfy the build dependencies for your bundle from Maven repositories which in turn can’t guarantee that a downloaded jar is a bundle.
Still today I come jars containing a valid bundle manifest which references libraries that are simply not available as a bundle.
Here it starts to get really painful as I will have to handle these dependencies manually by either converting existing jars into bundles or downloading them manually from an OBR.
This is ok for small projects but can become a very tedious task the bigger it gets.
The second problem is that sometimes it’s unavoidable to duplicate dependency information between the maven dependencies and the MANIFEST-generator. Duplicating information is never a good thing.

Pax-Construct

 

The whole pax suite is something I would recommend to everyone getting started with OSGi. It provides a lot of good tools for handling and learning OSGi.
Right now I want to focus on pax-construct, a nice collection of helper scripts for Maven-OSGi-integration.
Pax does everything from creating the basic OSGi-maven project to adding dependencies and maintaining OBRs.
It’s even possible to deploy created bundles directly into an OSGi-framework of your choice.
Actually, it does such a good job it made it into Sonatypes Maven-handbook.
But I am still not 100% happy with it.
Pax does everything right and gets the maximum out of Maven that is currently possible. There are just some things Pax can’t fix without actually changing Maven.
Once again it’s dependency management.
Pax does a good job in hiding duplicated dependency entries through its scripts.
But I still won’t get around handling dependencies manually. A lot easier than it is with plain Maven, but it’s still a manual process.
It provides an easy way for converting jars into bundles and helps downloading dependencies from an OBR . The downloaded bundles are added to a local repository and integrated into the pom. I still have to search for them but at least it’s easier to integrate them.
Pax also provides everything for maintaining my own OBR, again reducing the amount of manual work.
All in all I think ot doesn’t get any better with OSGi and Maven 2. Anything more would require some work in the intestines of Maven. Believe me, I’ve been there. That’s a road you don’t want to go.
Currently I am using Pax for all my Maven/OSGi needs.

Tycho

Taking a peek into the future, the next tool I tried out was Tycho.
Tycho is being built to allow automated builds of Eclipse applications. As Eclipse apps happen to be completely OSGi-based we also get a pretty good OSGi-build tool.
Based on Maven 3 it supports the whole range of OSGi meta data and can use p2 repositories to resolve OSGi dependencies.
Sadly it doesn’t support OBR, but it shouldn’t be too hard to add support for it (I don’t like p2, something I might explore in another post).
The combination of Maven 3 and OSGi is quite sexy and simply works. It’s exactly what I expect from a build tool.

• no duplication of dependency information
• can use OSGi meta information

This time my problems are not technology but maturity problems.
Maven 3 is currently only available as an alpha version and I don’t really know when the final release is about to appear. When it appears it will probably take quite some time until I will be able to use it in a production environment.
That aside, Tycho is the project to keep a close look on.

Sigil

Sigil is a tool I came across just recently.
It was originally created at Paremus as a tool they used for their own projects, facing the same problems I face.
Instead of fighting Maven they decided to do their own build tool and started the Sigil project.
The result is a very slick and lightweight tool with a nice (Eclipse-only) UI integration .
Compared to Tycho it sticks a little closer to OSGi by using OBRs for dependency resolution.
It manages the creation and maintenance of OBRs.
The tool has been donated to the Felix project a while ago and is currently close to finishing the restructuring process.
There is no downloadable available while I am writing this but it is very easy to get the source and build it (it actually just requires running a script).
Being a completely new tool and lacking the Maven ecosystem I currently don’t see a chance for getting it into our build process.
Nevertheless, It’s a great tool and I am using it for my personal projects.

Conclusion

After getting burnt using Maven 2 and OSGi together I started working on this without any expectations.
Now that I am done I have to admit: things look better than I thought.
Not really good but not bad either.
There are quite a lot of hacks involved to make Maven play along nicely with OSGi. Tools like pax do a great job hiding these hacks.
To be really satisfied I will have to wait for the next generation of build tools.
Hopefully Tycho and Sigil start gaining more attention.
Soon.

Cheers,

Jochen