Wednesday 20 June 2007

Centralize surefire reports from multiple maven modules

For a long time I have been cursing the maven-site-plugin for not giving me the opportunity to assemble and centralize all surefire reports from my submodules.

One could argue (and I agree) that a benefit of using maven is that it urges you to split your code into logical reusable artifacts (submodules). But at the same time as you don't have the tool to combine reports from the submodules you could easily be loosing the big picture of any errors and failures in your testcases.

Up until now I have either ignored the fact that I couldn't get the big picture (yes, I'm ashamed :-) or implemented a solution using the maven-antrun-plugin and a simple Ant script.
But then my colleague Per showed me the fairly new dashboard-maven-plugin from codehaus and that does exactly what I have been missing for quite some time.

As they say: "The basic purpose of "Maven Dashboard Report Plugin" is to centralize and share all quality informations generated by other Maven report plugins..."

Finally, home grown Ant solutions seem to be history!

Still thinking on this project I worked on last year together with my good friend and colleague Claus, that could benefit from moving to the dashboard-plugin and throw away the ant solution we implemented.

Monday 18 June 2007

Keep learning without your computer

My vacation is moving closer and closer and I am actually looking forward to the annual three weeks completely offline.

As the past two years we are driving to the southern Europe which means I am going to spend many ours behind the wheel.
Time that I usually spend listening to music on the local radio.
As podcasting is getting more and more popular I thought it could be worth looking through the internet for interesting subjects.

I found a couple that I will definitely download:
- Google
- Ajaxian
- Devcasting

Many others are available but I am not sure about the quality.
So let me know if you can recommend any other podcast.

Now only one thing stands between me and my offline knowledge transfer - my girlfriend!
Still thinking on how I can convince her that technology podcasting is so much more interesting for her than listening to the radio :-)

Friday 15 June 2007

Tip: How to depend on non maven artifacts in a maven build

Have you ever wanted to depend on some jar file that is not located in any public maven repository you probably ended up copying the dependency to your local repository and creating pom and md5 files by your self. Maybe you didn't even create the md5 files as it is not necessary and 'only' generates a warning in your maven build lifecycle.

Instead of doing all the hard work, you could use the install-file goal maven-install-plugin.

The install-file goal installs the artifact into your local repository. It can aslo create the nessesary pom.xml and checksum files.

A simple example of use:

$ mvn install:install-file -Dfile=pzfilereader-3.0.0.jar -DgroupId=net.sf.flatpack -DartifactId=pzfilereader -Dversion=3.0.0 -Dpackaging=jar -DgeneratePom=true -DcreateChecksum=true

The preferred csv parser for java?

My project needs to parse a csv file.
Of course I could write "yet-another-csv-parser", but this time I looked a bit further - past my own code to see if someone else had created the preferred csv java api.

My requirements seemed fair:

  • Open source:
    • I would like to see the code and have the ability to extend where needed
    • If the code is available from a maven repository it is easy to download and add to my favorite IDE (intellij idea)
    • Distributed to ibiblio with sourcecode would be great as it eases my work even more.
  • Some kind of error reporting
    It would be nice if the parser could report a more specific error than just an IOException with now details. It would be nice if the error could tell something about what line that couldn't be parsed.

I found a couple of api's that I took a closer look at:

http://www.csvreader.com/
- Seemed easy to use, but not available from ibiblio (or any other repository I could find)
- Binary was available from sourceforge as was the sourcecode
- No error reporting besides IOException

http://www.mvnrepository.com/artifact/genjava/gj-csv
- Binary and source available from ibiblio.
- No error reporting besides IOException

http://www.mvnrepository.com/artifact/net.sf.opencsv/opencsv
- Only binary available from ibiblio.
- No error reporting besides IOException

Looked at some other apis as well but my general observation was that non of the api's had a focus on error reporting or validation of the document.

Why doesn't the java community have a preferred api for csv parsing?
One explanation could be that every project implements its own as parsing a csv file seems as a trivial operation.
Another explanation could be that this kind of work suffer from the Not invented here syndrome? :-)

Please let me know that I am missing the implementation - it simply must be out there.

Thursday 14 June 2007

Flex/flash could learn from Java and Maven

Yesterday I told my colleague how much I loved the tight integration between flex components and XML.
Pretty much any UI flex component can use a xml document as a dataprovider and you can dynamically use attributes or nodes in your component.
That really brings your application up to speed in a hurry.

Just as I had declared my affection for the integration I ran into a bug best demonstrated by this small example:

<?xml version="1.0"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" initialize="init()">
<mx:Script>
<![CDATA[
import mx.controls.Alert;
import mx.events.*;
import flash.events.*;

private var work:String = "<tmps><tmp att=\"abc\"><dummy/></tmp></tmps>";
private var wontWork:String = "<tmps><tmp att=\"abc\" /></tmps>";

private function init() : void {
result.text = work;
}

private function clickHandler(event:ItemClickEvent):void {
if (event.label == "OK") {
result.text = work;
} else {
result.text = wontWork;
}
}

private function printResult(event:MouseEvent):void {
var list :XMLList = XML(result.text).tmp;
Alert.show(list[0]); // should print first element in the list - the tmp element
}
]]>
</mx:Script>
<mx:Panel title="Flex bug example" height="100%" width="100%">
<mx:ButtonBar itemClick="clickHandler(event);">
<mx:dataProvider>
<mx:Array>
<mx:String>OK</mx:String>
<mx:String>not OK</mx:String>
</mx:Array>
</mx:dataProvider>
</mx:ButtonBar>
<mx:TextArea id="result" editable="false" height="100" width="100%"/>
<mx:Button id="evaluate" label="evaluate result" click="printResult(event)"/>
</mx:Panel>
</mx:Application>
The compiled version:








I want to get the first element of my "tmps" xml document. Casting the string to a XML document and work on it as a XMLList prevents me from getting the first element in the XMLList as long as the element doesn't contain a child! That simply must be a bug.

I admit it is not the largest bug in the world, but the consequence of a bug like this seems larger than I first thought.
As the xml and ui components both are a part of the platform, the solution seems to be an upgrade of the flashplayer as Adobe fixes the bug. Upgrading the flashplayer is something the enduser as to do.

As I am working on a internal flash/flex application that has to run in a closed environment, where ugrades of the flashplayer are something that is out of the hands of the enduser, an upgrade of the flashplayer may not be a trivial process.

A "watercooler talk" led to a interesting suggestion to how Adobe could structure the platform to lower the impact on the end user.
What if the xml api was some kind of versioned module that your flex application dependend on?
Then you (as a developer) just had to change your internal dependencies as bugfixes and new features was available.
Adobe could have something like a centralized repository existing of original (signed) modules.

The local machine running the flex application could have some local repository for downloaded dependencies. Each dependency could be resolved at runtime and downloaded as needed.
That would lower the time it takes for adobe to release a bugfix, as it doesn't involve a complete new flashplayer release and the issue where endusers doesn't have the privilege to upgrade a plugin is gone as well.

If the idea looks like the java/maven dependency architecture it's not a coincidence :-) Maybe flex /flash could learn from the java world in this case.

Sunday 10 June 2007

Tapestry Bayeux 2.0.0 released - Improved download an image streaming functionality

I have just released the final version of Tapestry Bayeux 2.0.0.

Maven:
As with 2.0.0-beta2 the new 2.0.0 will be available from ibiblio in a couple of days.

Then you will be able to depend on Bayeux by adding the following dependency snippet to your pom.xml

<dependency>
<groupId>com.nordija.tapestry.bayeux</groupId>
<artifactId>tapestry-bayeux</artifactId>
<version>2.0.0</version>
</dependency>
Tapestry version:
The last version 2.0.0-snapshot was compiled and tested against Tapestry 4.1, but because of some issues with Tapestry 4.1 and Java 1.4 I decided to upgrade to Tapestry 4.1.1.

New Features:
A few extra features has been added since 2.0.0 beta-2:
  • StreamLink: A updated an renamed version of the DownloadLink. This StreamLink works together with the StreamService to get access to a StreamResource defined by the user.
    The StreamService is capable of streaming all kinds of data, hence the StreamLink is useful when a tapestry application is to provide some kind of download facility.
  • StreamAsset: As the StreamLink this asset works together with the StreamService. The StreamAsset is useful for streaming images that is not a static asset.
    That could be streaming of a JFreeChart (something that Bayeux provides special StreamResource implementations for)
  • RequiredValidationDelegate: A simple extension of the default ValidationDelegate provided by tapestry. The RequiredValidationDelegate uses css instead of hard coded font color values.
    But the most nifty feature is the integration with the input fields and any associated RequiredValidator. Every input field with an requiredvalidator is marked with a *, hence you don't have to keep your required fields in sync with your validators.

Enjoy!

Thursday 7 June 2007

Flex: ISO-8859-1 vs. UTF-8

Hint:
In a flex/flash project we encoded our files using iso-8859-1 encoding resulting in the danish characters like æ, ø etc. not being encoded correct.

The adobe flex compiler seems to interpret all files not containing a Byte Order Mark (BOM) as utf-8 even though we specified the -compiler.actionscript-file-encoding option.
Changing our files to utf-8 encoding solved the problem and no -compiler.actionscript-file-encoding option was needed.

And luckily for that as the israfil maven flex plugin that we use doesn't support the -compiler.actionscript-file-encoding option in the latest available version (1.0).