Basically, I was having trouble uploading files generated by Maven’s site plugin to a host. The URL was specified as follows

<site>scp://server:/some/long/path</site>

In Maven2 this worked out of the box without extra configuration.

In Maven3 this threw the following error during site-deploy:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:2.2:deploy (default-cli) on project $PROJECT_NAME: Unsupported protocol: 'scp': Cannot find wagon which supports the requested protocol: scp: java.util.NoSuchElementException

The trouble was that the Site Plugin apparently doesn’t automatically pull the Apache Wagon SSH implementation. You have to tell it manually to do that like this:

<build>
  ...
   <plugins>
     <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-site-plugin</artifactId>
      <version>2.2</version>
      <dependencies>
        <dependency>
          <groupId>org.apache.maven.wagon</groupId>
          <artifactId>wagon-ssh</artifactId>
          <version>1.0-beta-7</version>
        </dependency>
      </dependencies>
     </plugin>
    </plugins>
  ...
</build>

• compiled
• JavaDoc’d
• unit tested

These things don’t need to be declared and are automatically done by Maven. Maven’s great advantage over Ant is it’s ability to handle the dependencies of your project, ie. the old “Hunt the JAR” game is a thing of the past as Maven will simply download whatever libraries or frameworks you will need. Most of the time your build will run smoothly and Maven will spit out a nice JAR or WAR without problems.

The curious error message

However, if there are build errors they tend to be on the cryptic side. “The artifact has no valid ranges” is one of those. Basically it means that you do have a valid range, however you have defined two (or more) different version ranges of an artifact in a fixed way. Most likely you haven’t defined those dependencies in the same project but through a transitive dependency.

Let’s have an example. Your project my-app, depends on an artifact super-framework at version 1.0, and only 1.0, nothing else. my-app also depends on another of your apps called my-app2. my-app2 has a dependency on super-framework but only for versions 0.5 to 0.9. This means that you have incompatible version ranges and you need to resolve this. You will have to edit my-app or my-app2 and change their version ranges for super-framework.

This took me a little while to figure out myself since the error kinda suggests to look in the wrong place. The range is perfectly valid, it’s just that there is too many of them.

Debugging this message

That is a little tricky. You can try running Maven with the -X flag, which will show a running log of how the version is chosen. Also, sometimes the Maven plugin for Eclipse can give you some clues, but sometimes it is way off.

One word of advice though, it seems to matter in which order you include your dependencies in the the POM file. So, if you include a dependency on

super-framework [0.5,1.5)

it will fetch the latest available version, say 1.1.

If you then have a transitive dependency further down that includes

super-framework [0.5, 1.0)

Maven will generate this misleading error, since it will not select anything other than the 1.1 it already has, even though it could just select 0.9 without producing a version conflict. If you swap the order, weirdly, it works.

I use a MacBook for my development and until recently I have done my Java development in Eclipse. It is a very popular IDE and apparently very flexible and can be made to do absolutely everything. Also, all the Google Java products plugins only worked for Eclipse and that was the main reason for me to not switch.

However, it shortcomings became more and more apparent during the time I wrote my dissertation and became more serious about Java development. I noticed the following things about the OS X variant of Eclipse.

1. It. Is. Slow. It is painful to work with an IDE that locks up every 5 minutes and whenever you open a menu that has so far not been opened. I heard something about the Java-Carbon bindings not being very good and I think performance is better on Windows but this was a real issue for me.
2. Usability is abysmal. There are millions of message areas that pop up all the time, buttons are tiny and appear and disappear seemingly randomly. I know software development is supposed to be difficult but this is just unbearably hostile to the user.
3. It is very much a Windows app. It feels a lot like they wrote the app to fit with the windows UI guidelines, realised that there is Mac developers too and just copied the UI button by button. I know us Mac people are demanding when it comes to OS integration but Eclipse is simply not cutting it.

The conversion

One day I was frustrated enough by how rubbish Eclipse was, that I was ready to switch IDE mid-project. I kept saying to myself that I would give Netbeans a spin at the next project but my patience with Eclipse was wearing thin. I have not looked back.

The main issue I was worried about was the project conversion process and I have to tell you it was the most seamless thing I have ever experienced. Absolutely no errors or incompatibilities turned up. I was impressed. It also turned out that Netbeans is much better at managing your classpath automatically, so conversion even resolved a few issues. The only thing I had to redo was the tomcat configuration but that took about 30 mins.

I didn’t know Java development could be bearable on a Mac

After trying Netbeans out for a few days I have the following things about it.

1. It has a nicer UI. I know this will not get me any cred with the emacs crowd but if an application doesn’t shout “I’M UGLY!” all day long I like using it better than one that does. Call me superficial.
   I also managed to install a dark editor skin which makes Netbeans resemble Textmate a bit more which has also earned some plus points with me.
2. Usability is way better. Buttons are clear and there are fewer of them. Netbeans also gives you more sane default behaviour so you don’t have to poke around in the settings too often.
3. Classpath and lib folder management works. When you put something in the lib folder, it will be put on the classpath and copied into WEB-INF/lib. I couldn’t get Eclipse to do that no matter how hard I tried. I had to enable this for every JAR I downloaded.
4. It’s faster. Not Textmate-fast but fast enough to not annoy me constantly. I like.
5. Mercurial works out of the box. I didn’t install a plugin, I never activated anything. Netbeans just knew I was using it and started marking files as edited. (I guess this works for other SCMs too.)

Netbeans screenshot with Textmate-style dark theme

In retrospect, switching to Netbeans has been a huge boost in terms of productivity for me. I’m wondering why I didn’t try it earlier.

Eclipse squashing lines

Originally uploaded by Lenniboy

I used to have terrible problems with Eclipse on my MacBook running OS X. Editor text was bouncing up and down and all my lines were squashing. Have a look at the photo if you think I’m crazy.

Finally I have managed to find out what has caused this behaviour: It is the font size, which was set to 9.5. I’m not sure if the small size or the .5 bit that is to blame but but as soon as I set it to 11pt everything was fine.

I’m happy I found this because I was very short of changing over to XCode.