I’ve been trying to get my feet wet writing code for the Eclipse platform. I figured a good first step is to become familiar with Eclipse SWT—the Standard Widget Toolkit, and work my way up from there.

Since I use Maven, I had to struggle a bit finding out how to configure my Maven project properly so that it’ll build an SWT app that’ll run both under Eclipse and from the terminal.

A little Googling brought me to Brice Lambi’s post on Maven SWT builds, but that was a little outdated.

In particular (and only after careful reading), the guide to Deploying SWT apps on Mac OS X says that the -Djava.library.path=.. option is needed for Eclipse 3.2.2 and earlier. Apparently, starting with 3.4 all you need is your OS-specific JAR (see here).

Anyway, after much fiddling about, I was able to get it all working like so: Read the rest of this entry »

Advertisements

David Saff wrote in on Introducing MagicTest, asking why not just instantiate the variable in-line (private Foo foo = new Foo();).

Which brings me to the real reason for coming up with MagicTestActiveTest.

A code sample is worth a thousand words. Suppose we have a Spring JPA data access object:

public class WidgetDao extends JpaDaoSupport {

  @Autowired
  public WidgetDao(final EntityManager entityManager) {
    setEntityManager(entityManager);
  }

  public Widget find(long id) {
    return getJpaTemplate().find(Widget.class, id);
  }

}

WidgetDao needs a JPA EntityManager provided to it at construction time. Normally, to write a unit test for WidgetDao we’d have to create our mock objects and setup our test scaffolding manually.

Using ActiveTest, however, all we need to write is:

public class WidgetDaoTest extends ActiveTest<WidgetDao> {

  private WidgetDao widgetDao;

  @Mock
  private EntityManager em;

  @Test
  public void testFind() {
    widgetDao.find(42);
    Mockito.verify(em).find(Widget.class, 42);
  }

}

I’m lazy like that.
Read the rest of this entry »

Introducing MagicTest

May 28, 2009

If you’ve written enough JUnit 4 tests, then you should be familiar with code that looks like:

public class FooTest {

  private Foo foo;

  @Before
  public void setUp() {
    foo = new Foo();
  }

  @Test
  public void testBar() {
    assertTrue(foo.bar());
  }
}

Now, how often have you wished it were possible to simply go straight to @Test, do not pass setUp(), do not have to new Foo()?

Introducing MagicTest

So I came up with MagicTest, a parameterized base class for JUnit 4 tests that’ll let us do just that. Read the rest of this entry »

Before we begin, I seem to be getting a lot of people visiting this post when searching for “uninstall macports”. Read 2.5 Uninstall from the MacPorts Guide you want to uninstall MacPorts itself.

EDIT: steve k wrote in and opened my eyes to:

sudo port uninstall --follow-dependents portname

So use that instead, and read on only if you like bash.

(I have another script that does the inverse—traverses up the dependency chain removing ‘leaf’ nodes—that is, ports with no further dependencies. Maybe I’ll make a new post on that one—after making sure it’s also not already available as some hidden option. :p )
Read the rest of this entry »

The following code is provided for educational/illustrative purposes only.

This is probably just a clever hack. This is not kosher. To all students of the Java language, please do not start using this in your day-to-day code. Let me be the first to admit that I haven’t used this extensively and I wouldn’t recommend using it for production.

Disclaimers aside, I won’t give any more background into Java generics. For those in need of an introduction, Angelika Langer’s Java Generics FAQ explains a lot of things with more clarity and depth than I ever could.

The basic problem is, given a generic class, we would like to determine the type parameter to that class at run-time..

I’ve found myself needing to do this more than once. The simplest example I can contrive is one when we want the Base class to perform run-time type-checking of some input parameter. Read the rest of this entry »

Spent a good part of today digging through various mailing list and JIRA posts just to get this to work so I figured I’d post about it for other people who might run into the same problems.

The difference between theory and practice…

Google for “jboss derby” and the first link should be SetUpADerbyDatasource [DOC-12234] over at jboss.org.

That is basically the same file under
${JBOSS_HOME}/docs/examples/jca/derby-ds.xml.

Ji-Woong Choi was kind enough to point out some things that were missing, and to cut a long story short I’ll just post the (supposedly) working derby-ds.xml right here:

Read the rest of this entry »

Here’s a quick post for those who a) use Maven 2 and b) need to use Quartz 1.6.0 in their projects.

See now Quartz 1.6.0 has (run-time) dependencies on JTA (if you’re using it stand-alone, outside of a J2EE container) and Commons Collections – unfortunately, the Quartz pom.xml doesn’t specify these as dependencies.

So here’s a pom.xml you can use to base your project’s POM off from.
Read the rest of this entry »