Maven reality TV shows

Posted on by
1

Tim O’Brien wrote on twitter:

We’re starting a reality TV shows to judge Maven plugins, “Maven’s Worst Documented Plugin” I’m playing the part of a cranky Simon Cowell.

And this got me thinking about reality TV show names and concepts based on existing reality TV shows.

If you are not technical, and don’t know what Maven is: it is what we Java developers use to build software. It is like a workmate: great tool, but every time (once in two years) you want to use it to do a project, you cut your fingers unfolding the workmate (at least I do). Maven is similar in that every time you want to do something different than what you are currently doing, it will cut your fingers. Suffice it to say I have a love/hate relationship with workmates (and Maven).

The list of TV shows I figure will be great hits among Java developers (and Rubyists wanting to make fun of Java developers):

Hardcore pom, based on Hardcore pawn, will feature Jason van Zyl in a shop called Maven Central where project leads stand in line having to argue with Jason about the contents of their pom’s to get them in the central repository.

Keeping up with the Plugins, loosely based on the ‘reality’ soap family the Kardashians, will show the lives of Maven plugin maintainers living under one roof and watch them striving to win the coveted 3 +1′s for their release votes. See their ups and downs as they run the integration tests to prove backwards compatibility.

O’Brien’s Maven Nightmares well known author of Maven books, Tim O’Brien visits Java shops that are on the verge of collapse, analyses what is wrong with the build, pulls out some corpses from the build closets and drills the Java developers with proper Maven procedures. Once he has left the team with a working, pristine Maven build, O’Brien returns 3 months later to see how they have done so far. Viewer discretion is advised due to strong language.

The Fear Reactor, where 4 developers face the dread of all Maven builds: a multi-module reactor build. In each of 3 rounds a developer will be eliminated. The first round is performing some task on a multi module build under time pressure. The developer with the slowest time is eliminated. The second round involves finding an error in a reactor build by having to wade through Maven’s output using mvn –debug level output. The third and final round involves determining what the hell one of the Maven plugins does based on just their documentation (no one has ever passed this round).

Let me know on twitter if you come up with other reality TV shows based on Maven (or Java or C# or Scala or …) Use hashtag #realityshowsincode

Connecting to MongoLabs on heroku

Posted on by
1

For an internal Topicus application I wanted to deploy to Heroku and utilize MongoDB through MongoLabs. The main reason to use MongoLabs: they have a free 240MB database plan, and I wanted to try MongoDB to see how it would work.

Getting it to run on Heroku was kind of a challenge since I want to build a Java/Wicket application, and most documentation relies on Ruby deployments. In order to connect to MongoLabs you need to do the following:

MongoURI mongoURI = new MongoURI(System.getenv("MONGOLAB_URI"));
DB connectedDB = mongoURI.connectDB();
connectedDB.authenticate(mongoURI.getUsername(), mongoURI.getPassword());

What evaded me was that you need to explicitly authenticate using the provided username and password, otherwise you will get authorization errors. The documentation didn’t show this as a required step unfortunately.

Of course you should check if authentication succeeded, and that no error occurred.

OS X Java 6 update 5: how to reconnect the source…

Posted on by
4

With each update of Java on OS X, Apple nukes all the things you have done to ensure a proper ability to peruse the JDK source files. Which is a pita being a Java developer. How do you get the source again in your IDE (in my case Eclipse Indigo):

  • Download and install the javadeveloper_for_mac_os_x_10.6__10m3425.dmg from developer.apple.com (free registration required)
  • Install the client update (comes from the automatic update functionality in OS X), it doesn’t matter in which order you do these two steps)

Next run the following commands in a terminal:

cd /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
sudo ln -s /Library/Java/JavaVirtualMachines/1.6.0_26-b03-384.jdk/Contents/Home/src.jar
sudo ln -s /Library/Java/JavaVirtualMachines/1.6.0_26-b03-384.jdk/Contents/Home/docs.jar

Eclipse will now be able to find the sources for the Java classes.

If you have problems finding the OS X Java developer downloads:

  • Go to: Resources
  • Click on “developer downloads”
  • Click on “Java” in the right side menu

Apple made it impossible to provide a direct link, so you’ll have to navigate the developer website yourself.

(updated with navigation to Java downloads)

EHCache and Quartz phone home during startup

Posted on by
11

One might call EHCache (the Java caching library everybody loves) ET-Cache, since it keeps phoning home during startup. While probably just implemented as a usability feature, I find it quite nefarious, especially since Quartz (the job queuing library everybody loves) does *exactly* the same.

The culprit lies in net.sf.ehcache.util.UpdateChecker and org.quartz.util.UpdateChecker.

Information sent to Terracotta HQ include:

  • a client ID taken from your local IP
  • os.name
  • java.vm.name
  • java.version
  • os.arch
  • QuartzVersion
  • EhCache version
  • something about source
  • uptime-secs
  • patch level from Quartz/EhCache

Needless to say, this is something that should not be enabled by default, and only with a big opt-in questionnaire… This also sparks the question if the cache doesn’t send *more* information home than just the update information? It is after all a product designed to send information across the network—what is one extra node more in the grand scheme of things? Has anybody audited the code for nefarious code?

In any case: to disable phoning home everybody should start their applications with the following command line parameters:

  • -Dnet.sf.ehcache.skipUpdateCheck=true
  • -Dorg.terracotta.quartz.skipUpdateCheck=true

Or you can configure it in your ehcache.xml according to the user manual. Quartz is similarly configurable in the quartz.properties.

According to Alex Miller, a former Terracotta employee, it is not evil and a price we need to pay to use open source software.

I disagree strongly: this undermines the premise of trustworthy open source. The download page doesn’t mention the phoning home, neither does the announcement of ehcache 2.2 (last july), it is summarily mentioned in the configuration part of the manual, which you typically don’t read when you just upgrade your dependency to the latest version and see that everything still works as usual. The same goes for Quartz: it was apparently added in quartz 1.7.3, but no mention of this in the release notes. Neither of the possibility to disable phoning home which was added in quartz 1.8.

In my opinion, this is unacceptable behavior for any open source product, which severely undermines the trust we spent building in the last couple of years making open source a viable alternative to closed software.

SHAME ON YOU TERRACOTTA!