Category: Java

OSGi Diaries – A short series

I’m going to be spending some time over the next couple of weeks learning about OSGi – there is an application at work that we want to try and make more modular. In particular, we’d like to be able to share the back tier with more front end clients. The more conventional modularisation techniques, such as EJBs, have been tried and didn’t work fairly well. Simply creating more deployments is prohibitive, due to hardward And before someone asks “why not just stick a web service on it and share that way” – some of the front end clients will be those web services. To cut a long story short, one of the options we want to check out is OSGi.

The only problem is that there isn’t much in the way written up on the web about writing OSGi components – at least not without invoking magic tools (e.g. Maven plugins) that don’t work on any version of any tool developed six months later. Which is odd, because OSGi, as a spec, doesn’t look that hard to write too. So, I thought I’d write up a series describing the initial investigative spikes, starting as close to the metal as possible and working up.
Continue reading “OSGi Diaries – A short series”

Hudson Plugin for Eclipse

Lusting over the Atlassian Connector’s support for Bamboo made me decide to check out what support there was for Hudson in Eclipse. So I checked out the Hudson Eclipse Plugin. My thoughts: not bad, but not great – a lot of potential is there, though.

Continue reading “Hudson Plugin for Eclipse”

Atlassian Connector for Eclipse – Installation issues

I’ve been having a problem installing the Atlassian Connector for Eclipse (which gives integration to a bunch of Atlassian and non-Atlassian tools – mostly I’m after Fisheye and JIRA). The installation constantly failed for me on this error:

Cannot complete the install because one or more required items could not be found.
Software being installed: Atlassian Connector for Eclipse (recommended) 1.1.0.v20090624 (com.atlassian.connector.eclipse.feature.group 1.1.0.v20090624)
Missing requirement: Atlassian Connector for Eclipse (recommended) 1.1.0.v20090624 (com.atlassian.connector.eclipse.feature.group 1.1.0.v20090624) requires ‘org.eclipse.mylyn.jira_feature.feature.group [3.2.0.I20090529,3.3.0)’ but it could not be found

Today I found this issue in Atlassian’s issue system: [#PLE-393] Installation error – Atlassian Projects. What it comes down to is that one of the update sites shipped with Eclipse is disabled in some of the distros (the JavaEE one, in my case).

The issue has the instructions, but for anyone too lazy to follow the link:

The problem seems to be that the Mylyn update sites (which has JIRA) is not enabled in your copies of Eclipse. There is a bug in Eclipse that these sites may not be automatically enabled even though we specify that we require them for installation. To enable this site:

1. open Help > Software Updates…
2. switch to the “Available Software” tab
3. click on “Manage Sites…”
4. look for either the Mylyn Extras update site or a url that looks like: http://download.eclipse.org/tools/mylyn/update/extras and check make sure that it is checked
5. look for either the Mylyn For Eclipse 3.4 update site or a url that looks like: http://download.eclipse.org/tools/mylyn/update/e3.4 and make sure that it is checked
6. try to install the Atlassian Eclipse Connector again

And with that, I get my JIRA integraton to Mylyn working again! Joy and happiness abounds.

M2Eclipse Plugin is not for me

In my previous rant, I bitched about the eclipse:eclipse plugin. I got a fair amount of feedback suggesting I look at the M2Eclipse IDE plugin instead. This plugs directly into Eclipse, introducing in-IDE maven support.

Well, I’ve looked at the M2Eclipse plugin, and decided it’s still not suitable for my personal working style.

For anyone interested, here’s a short list of reasons. Note that I haven’t actually _tried_ the plugin – I’m just going off their FAQ.

  • No real support for separate output folder. I can’t stand having my IDE and my build tools compile to the same folders. With Eclipse, in particular, it’s a different compiler! Compiling to the same folders results in contention, and I don’t do it. The M2Eclipse plugin used to support this as an option, but they took it away in version 0.94. This isn’t hard folks – let Maven compile to one place, and Eclipse compile to the other, and never-the-twain-shall-meet. Strike one.
  • It uses the Maven Embedder. The Maven Embedder is not Maven. It’s a somewhat bastardised version of an unreleased-even-as-beta version of Maven. It doesn’t even use the Maven Embedder that came with 2.1 – instead, it uses a “Embedder component build in May 2008 ” which is “somewhat outdated”. This means it’s got different bugs in it from the command-line Maven. I don’t need to chase down two sources of maven bugs. Strike two. (Okay, you can apparently tell it to use an installed Maven elsewhere – wonder what functionality _that_ breaks; we currently use Maven 2.0.9 because both Maven 2.1 and Maven 2.0.10 broke stuff)
  • It wants to use the JDK associated with the JRE that launched Eclipse. Well, I use a Mac. Due to SWT issues, Eclipse on the Mac has to run under Java 1.5 (though that may change with the upcoming release). But I compile against Java 6, and that what I want to run Maven under. Strike three, and you’re out.

Look, it may be a great plugin. Obviously people like it. But it doesn’t suit me.

This is why Maven gives me the shits…

The Apache Maven project just announced the next version (2.7) of the Maven Eclipse plugin. This is the plugin that generates the .classpath and .project files.

All well and good. Except that version 2.6 introduced at least one new massive bug – it puts the JRE at the end of the project classpath, instead of at the start. This means that, due to some projects out there doing stupid shit liking including JDK classes, you can get code breakages (e.g. you use generic collections, but this bug causes you to compile against the 1.4 Collection API). This bug is rated as ‘CRITICAL’ on their own issue tracker. It was caused by a patch for a ‘MINOR’ issue.

This bug is not fixed in the new 2.7 version.

Why, Maven developers? Why? Why are you releasing any new versions yet? According to your JIRA instance, you have 1 BLOCKER – introduced in 2.6 – and 14 CRITICAL bugs, going back as far as 2.0. In 2.7, you “fixed” one CRITICAL bug – by calling it a duplicate of a bug that was only MAJOR.

I know, I know – it’s open source, it’s free, and you get what you pay for. But there is no excuse for this. Those priority levels are meant to reflect the urgency felt by the project team. If they really feel an issue is a BLOCKER, they shouldn’t release. If they feel an issue is CRITICAL, they shouldn’t be working on trivial issues. If they don’t feel that these issues are CRITICAL, they should change the status.

And, in the meantime, I’m staying on 2.5.1.

Jersey – a review

We’ve been getting more interested in using RESTful web services and AJAX based applications recently. One of the tools we’ve been using with that is Jersey – the JAX-RS (JSR-331) reference implementation. I’ve been using it in anger for about a month now, and thought I’d write up some thoughts I had about it.
Continue reading “Jersey – a review”

RSpec, JRuby and Story Testing Java Code

I’ve long been interested in decent ways of expressing tests in a human-readable format. Not just any humans, but BAs and business reps in particular – the kind of people who will not be interested in slugging through piles of language syntax. I tried Fit sometime ago, and was impressed, but when I came back and revisited it recently, it looked a lot like the community had kind of faded away. Accordingly, I looked around at what else was available, and stumbled across RSpec Now, I want to test Java code, and RSpec is for Ruby (as the R kind of hints), but I was able to get this going under JRuby fairly easily. I couldn’t find any examples of other people doing that, so I thought I’d write it up.

Continue reading “RSpec, JRuby and Story Testing Java Code”

Hibernate Query (Lack Of) Caching

Hibernate has long had a feature known as “query caches” – you can run a query, cache the result, and thus avoid running it repeatedly. The only problem is that it doesn’t do what you think it does.

Continue reading “Hibernate Query (Lack Of) Caching”

… and sometimes they don’t.

I’ve spent most of the last year involved in an intensive project that really drained me – hence the lack of blogging. I want to blog in a positive fashion this year, so I’ll start by getting a lot of gripes off my chest. 🙂 Call it things that suck.

Here’s a short list, before I define what I mean by “suck”:

  • Maven2
  • EJB3 Persistence
  • Hibernate, caches, and the way they can kill your database.
  • Maven2 (it just sucks a lot!)
  • No Java 6 on the Mac
  • No “next/previous word” keyboard navigation in the Mac terminal
  • Mac Firefox, drop-down boxes, and tabbing

and I’m sure that there’s more that will come to me. Today, I’m doing Maven – the rest will come later.

Continue reading “… and sometimes they don’t.”

%d bloggers like this: