IzPack – Open Source Java installer engine

Old post from Feb 11th, 2010


Recently we faced the need for an installer for a Java tool. Nothing too refined, just select the path, select the packages to install and create some shortcuts.

First I googled for the obvious query and found many alternatives, some free and some commercial, and then we do a preliminary testing to some of them (OpenInstaller, Advanced Installer, install4j) and finally we knew of IzPack.

In this post I would to highlight some of the characteristics of IzPack and why we decided to use it, and then show you how to make a simple yet powerful installer.

Continue reading “IzPack – Open Source Java installer engine”


Architecture Rules 3.0.0 goes RC1

Old post from Dec 11th, 2009


After some months evaluating Architecture Rules (AR for sort, web http://wiki.architecturerules.org/index.php?title=Main_Page) for serious use, and fiddling in a hate-love relationship with this tool (very good idea, not so well documented, some extrange behaviours that almost makes you resign), I found in their SVN and Maven repository that they have posted there the RC1 (release candidate) of the new 3.0.0 release.

For those that do not know about AR, this tool builds on top of JDepend to analyze the architecture, understood as module relationships and valid dependencies, of a Java project.

JDepend calculates OO metrics (Afferent, Efferent couplings, Instability, Abstractness, Distance) and also checks for circular dependencies between Java packages. JDepend is very fine, produces reports, has a fine GUI and there is an Eclipse plug-in available for your convenient use, but it is not easy to do validations in automated builds and continuous integration.

AR offers that. You can automate your architecture validation as an Ant task, Maven plug-in or, as it is most interesting to me, as a JUnit test case.

Thus, why this post? AR can be frustrating. You can easily get lost in dependencies, not found files and folders and different behaviours in unit tests if executed from Eclipse or from Maven. And this is why I would like to share some of my findings.

First, consider how to run it in an automated way. The Ant task or Maven plug-in have a disadvantage, they break the build if the architecture validation does not pass. It can be good for you but in my opinion I just want to know whether rules are being followed and continue with the rest of the build process, eventually running Sonar and publishing my results in Sonar dashboard.

So I finally decided to go for the JUnit test case. I can give you details on running in Ant and Maven but in this post from now on I will focus on JUnit and I will split the rest of the contents in these areas:

1. Dependencies.

2. Configuration.

3. Writing the test case.

4. Running.

Continue reading “Architecture Rules 3.0.0 goes RC1”

Testing Java Swing components with Fest

entrada antigua del 28/3/2011 – old post from 3/28/2011


While exploring into new ways of writing automated unit test cases in Java, I discovered the Fest framework.

Besides some nice tools for mocking and wrapping calls to reflection, Fest has a convenient API to automate unit tests for Swing components leveraging the AWT Robot, which is too low-level as to be of real use for massive unit testing.

Of course, this is valid for integrated/assembly tests, not real unit tests, because Fest launches a Swing frame or dialog and then reproduces user gestures in the application (go to that field, enter that text, select that on the combo, press this button and so on). I find it useful because, especially in Swing, a thorough unit test suite is not enough to ensure proper user experience and bug-free deliveries. You need to test integrated, all the Swing widgets, event handlers and even business logic.

Results have been very good. Fest has some bugs but even with that I was able to write a good quantity of unit tests in a decent time. I will show some examples in this post.

Continue reading “Testing Java Swing components with Fest”

Using EasyMock to enable response text based testing of Java Servlets

entrada antigua del 23/3/2011 – old post from 3/23/2011


Behind this long title, today I would like to show an easy but powerful technique to unit test Java Servlets.

This method focuses in the fact that most of the Java Servlets are just returning plain text contents, usually HTML or XML.

For a proper unit test on the Java Servlet to run outside a web container, we need to mock the HttpServletRequest and HttpServletResponse objects. Mock, in short, is a term to refer to a double object, that is, an object that exists solely for the purpose of testing the unit at hand, with the same interface that an actual runtime object but with a different behavior, based on expectations.

It is not the purpose of this post to talk about mocks and other unit testing techniques. If you feel curious you can get more on the subject on this excellent paper from Martin Fowler (yes, ‘that’ Fowler guy): Mocks aren’t Stubs, by Martin Fowler.

With that being said, let’s go to the point. What we want to achieve is to test the output of a Java Servlet in different situations, asserting that this output contains certain strings of text. We will need to mock the request and response objects.

Continue reading “Using EasyMock to enable response text based testing of Java Servlets”

hola blog / hello blog

después de mucho tiempo dándole vueltas a la idea de crear un blog público (ya mantengo uno interno en el trabajo), al final me he decidido. un lugar donde contar cosas, supongo que principalmente sobre java y otras cosas que me gusten o me llamen la atención. un lugar donde dar cabida a pensamientos más largos de los que “caben” en facebook. el tiempo nos dirá a dónde llegamos.


after a long time thinking in creating a public blog (I already have one, internal at work), finally I have decided to do so. a place where to tell things, specially on java and others things that I like or simply caught my attention, I suppose. a place to put ideas and thoughts, longer than those that “fit” on facebook. only time will tell.