My First Maven Plugin: A Unit Test Packager

I've just written my first Maven 1.0.x plugin. It's a monumentally simple affair but does what it needs to do quite elegantly; that is to take the Unit tests for your project and zip them up (along with your project's dependencies, the required Junit jars and some auto generated shell scripts) so you can run them anywhere. I don't have any personal hosted space to provide the actual plugin jar but here's the jelly code as a starter:

There's only one configurable (and that's because I ran out of time). You need to set the following property: suite.class.name= [the name of your test suite class]

[BTW, If anyone out there wants to offer me some place to host this I'd be dead greatful. Its a tiny litte jar. Tiny.]

Read More

EJB 3.0 Outside the Container, Inside the JVM - Part 3: Wrapping the Model

Welcome to part three of my blog on using EJB3.0 / JPA and Derby inside the JVM. The previous parts can be found here and here.

We're almost ready to go. However, we still need to wrap our domain model with a facade in order to manage interactions with it and prevent any JPA specific code creeping outside the model boundaries. We can do this by placing a session bean in front of our Claim POJO. (Why a session bean when we're not really going to use this within a Java EE container? Aha! Maybe something will come along in a later posting...)

We'll start by creating a new POJO class called ExpensesTrackerService. To make it a Stateless Session bean we simply the @Stateless annotation. We also need to add the following dependency to the project so that we can get the imports needed:

Now we need to provide a means to address and manage the Claim entity. In JPA this is via the EntityManager which we obtain via an EntityManagerFactory


Now that we have an EntityManager we can use it within our CRUD methods. Here:

Here:

And here:

Now all we have to do is build our maven project (run the jar:install maven goal) which will also copy the resulting jar containing our wrapped model to the repository. In the next entry we'll use it from within our Swing client

Read More

EJB 3.0 Outside the Container, Inside the JVM - Part 2: Configuring JPA Declaratively

Welcome to part two of this blog entry introducing using EJB3.0 inside the JVM. Click here to view the first part.

As we've seen, JPA can use our annotated POJO model to create a database for us, but first we need to give it some information on how to do it. We provide this information in a file called persistence.xml. Let's create a blank file with this name in {PROJECT_HOME_DIR}/expenses-tracker-model/
resources/META-INF/. We also need to let maven know where this is so we add the following to our project.xml file:


This entry ensures that this file will be included on the build classpath.

Now lets add the content to persistence.xml. We'll start at the top:


The persistence-unit tag tells JPA about our (future) database. A single persistence.xml file can have mulitple persistence units but we will keep things simple and just stick to one. Attributes to this tag provide the persistence unit name (which we'll use to refer to it later in code) and the transaction-type. (We have the default). We'll only need the former as we'll see later on.

Enclosed within this top level is the tag which tells JPA which implementation will provide the actual persistence functionality - the "provider" tag. Our example uses the Toplink ORM tool but we could swap this to something like Hibernate simply by changing the contents of this tag.

Finally there is the tag where we declare our new entity class - "class". This tells JPA that we want it to be considered as part of this persistence unit. (Note: if you find JPA doing things you don't expect, check that you have listed all the classes you wish it to be aware of here. It can't work with what it has no idea about!)

Ignore the commented out tags. If you really want to know what they do then just google or yahoo! them.

This is all well and good but clearly my file is a little more complicated. Toplink will need some additional information in order to do its job and we can put this in this file as well. These go within the "properties" tags. You can see below that we use these to tell Toplink the driver class to use, the url for the database connection and well get to the third piece of magic later.

Read More

EJB 3.0 Outside the Container and Inside the JVM - Part 1: The POJO Model

NOTE: This is a more truncated version of an entry I started previously. The aim is to keep it simpler and to actually finish this it...

ANOTHER NOTE: I use Netbeans. It's not popular but I like it. If you don't have Netbeans you'll still be able to follow this series but won't be able to drag and drop a Swing UI in part 4 using Matisse. My heart bleeds...

EJB 3.0 and JPA 1.0 have made it easy for people like me (RDBMS-phobics) to persist our O-O domain models. What's more, Derby (aka JavaDB) has made it easy to have within-JVM RDBMS persistence that is transparent to the user of your thick client application. What follows is a simple example application I wrote to learn some of the basic concepts (and also track my expenses claims)

Step 0: Setting up my project.

I like Maven; Maven 1.0.x to be precise. Before anything else I set up a basic maven project called "expenses-tracker-model" in the standard fashion:


You'll also need to manually get hold of the JPA and Derby Jars (toplink-essentials.jar, derby-10.1.jar and javaee-9.jar) and place them in your repository wherever you see fit.

Step 1: Coding the Domain Model

I like to model in OO land. My model is very simple - a single, serializable POJO class called "Claim" - which will eventually map to a single Derby table called "CLAIM". I create my java class and add attributes as follows:

private Long id;
private String refNumber;
private String projectCode;
private String description;
private Date dateFrom;
private Date dateTo;
private String status;
private Date submitDate;
private Date paidDate;
private Long totalClaimed;
private Long totalFromCurrentAccount;

I now need to add the annotations which will allow JPA to work its magic. First I tell the class that it is an entity (i.e. will be represented in the RDBMS) with the following annotation:

import javax.persistence.Entity;
...
@Entity
public class Claim implements Serializable {
...

The compiler is now clever enough to know that, unless told otherwise, the attributes on this class will be represented as columns in our table. That's how EJB 3.0 works. It assumes the default unless you tell it different. Very handy.

The observant amongst you will realise that we most likely need a primary key. You're right. We need to declare which will be our primary key field and how we will work with it. This is done with the @Id annotation. The @GeneratedValue annotation tells JPA that we'dlike the RDBMS to auto generate our PKs for us (which makes things even easier at our O-O end):

import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
...
/** Unique, datastore generated id */
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
...

Finally, because we have java.util.Date fields, we need to provide some extra information about these for JPA also:

import javax.persistence.Temporal;
import javax.persistence.TemporalType;
...
@Temporal(TemporalType.TIMESTAMP)
private Date dateFrom;

We're nearly there. Another quick IDE aided step to encapsulate our attributes with some getters and setters and we're ready to go. You should now have something like this:

package com.andrewharmellaw.exptracker.model;

import java.io.Serializable;
import java.util.Date;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;

@Entity
public class Claim implements Serializable {

/** Unique, datastore generated id */
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;

private String refNumber;

private String projectCode;

private String description;

@Temporal(TemporalType.TIMESTAMP)
private Date dateFrom;

@Temporal(TemporalType.TIMESTAMP)
private Date dateTo;

private String status;

@Temporal(TemporalType.TIMESTAMP)
private Date submitDate;

@Temporal(TemporalType.TIMESTAMP)
private Date paidDate;

private Long totalClaimed;

private Long totalFromCurrentAccount;

/** Creates a new instance of Claim */
public Claim() {

}

public Long getId() {
return id;
}

public void setId(Long id) {
this.id = id;
}

public String getRefNumber() {
return refNumber;
}

public void setRefNumber(String refNumber) {
this.refNumber = refNumber;
}

public String getProjectCode() {
return projectCode;
}

public void setProjectCode(String projectCode) {
this.projectCode = projectCode;
}

public String getDescription() {
return description;
}

public void setDescription(String description) {
this.description = description;
}

public Date getDateFrom() {
return dateFrom;
}

public void setDateFrom(Date dateFrom) {
this.dateFrom = dateFrom;
}

public Date getDateTo() {
return dateTo;
}

public void setDateTo(Date dateTo) {
this.dateTo = dateTo;
}

public String getStatus() {
return status;
}

public void setStatus(String status) {
this.status = status;
}

public Date getSubmitDate() {
return submitDate;
}

public void setSubmitDate(Date submitDate) {
this.submitDate = submitDate;
}

public Date getPaidDate() {
return paidDate;
}

public void setPaidDate(Date paidDate) {
this.paidDate = paidDate;
}

public Long getTotalClaimed() {
return totalClaimed;
}

public void setTotalClaimed(Long totalClaimed) {
this.totalClaimed = totalClaimed;
}

public Long getTotalFromCurrentAccount() {
return totalFromCurrentAccount;
}

public void setTotalFromCurrentAccount(Long totalFromCurrentAccount) {
this.totalFromCurrentAccount = totalFromCurrentAccount;
}
}

Right, that's the dull part done. Now we can get to the fun part - using this POJO to auto-create our database. That's in the next post in this series...

Read More

Kill Your Computer

I mean it. Kill it. It's probably on its last legs anyway. Then get a new one and see how much you've lost. Didn't I tell you to backup before you wielded the sledgehammer? Sorry.

My laptop died yesterday. What with a previous entry about how great life was with all your stuff online now was the time to test it out. Job 1: Dowload Firefox. Job 2: Get Google Browser Synch up and running. Job 3: Get my favourite extensions and I'm up and running.

Its interesting to me to see what else I felt I had to install to be productive. For me this was the following:

• Java 5 JDK
  
• Thinking Rock - A GTD To Do List Manager
• Netbeans - IDE of Choice plus the VWP extension and the MevenIDE modules
• Maven - All my Java Projects use it
• Subversion
• Tortoise SVN
• AVS DVD Player - I work away and have to watch my LoveFilm picks somehow
• iTunes - Aaaaaargh. Where have all my podcast subscriptions gone!?
  

I was up and going in 2 hours (Slight aside: If I had Eclipse rather than Netbeans how long would this have taken? A lot longer). Now at th emoment I think that's pretty cool. What would really make my day would be if Google Browser Synch remembered which of my bookmarks were on my toolbar and what firefox extensions I used. Oh, and a web based version of Thinking Rock would be great too. I can but hope...

NOTE: If you want to kind of feel like what its like to lose everything just run Windows Cleanup - I lost loads of old files which MSFT deemed no longer important. :-( That'll teach me.

Read More

Running my Java 5 App on MacOS X

I've written a simple app for my wife in Java (using Netbeans Matisse). I've got an XP laptop which I use to develop on. Running it was simple within the IDE and I created a simple zip file containing my jar, the required libraries and the derby database files and a .bat file to make running it a double click affair. How hard could it be to move it to her Mac?

Being quite simplistic about it and having worked at Sun in the past (Unix is Unix right?) I thought I could create a simple .sh equivalent of the .bat file to protect my beloved from the intricacies of the "java" command. Before this I thought I'd just try out the command at the terminal to check it worked. Best practice you see...

Wrong. I kept getting errors about my jar files (all of them) not being excutable ("cannot execute binary file"). My first thought was that it was a Windows / Mac newline thing... nope. Corrupted JAR files?.. Nope. Then I found a blog entry about how my problem was common and you needed to wrap things in a shell script. I did, and then started getting all manner of even wierder errors (most likely due to my terrible korn shell skills rather than anything else). I was stuck but had the distinct feeling that there was a very simple solution.

There was. I had my classpath seperated with ";"'s. Macs don't like that (I'd forgetten that other unixes don't either - so much for my Solaris skills) and need ":"'s instead. Dammit. Now she runs like a dream (and looks sweet too with the default MacOS X liquid look and feel...

Read More

MI6 Mashup

I saw Casino Royale last night and was very impressed; impressed in many ways (especially the Treasury Rep. - anyone who has worked (with)in the British Civil Service knows how close to reality this sometimes seems). But that's not what stuck me.

I was amazed at my reaction to the sequence when Bond has broken into M's apartment to salvage some information from a SIM card he has salvaged. When he plugs it in and some technical wizardry provides him with the location of the last SMS message sent (a suitably exotic Bahamas), the app providing the information had to me the feel of a nice looking mashup combining yahoo maps and some backdoor-access telco data. I even wondered if I could go home and do the same for myself. It reminded me of the (again just ahead of reality) "I know this it's UNIX" bit in Jurassic Park.

The future (as they say) is now. Or maybe a few months away. I wonder if they're really mashing things up down there next to the Thames...

Read More