Quickstart flex development with this maven archetype

Have you considered starting some flex development, but haven´t found out where to start? Or are you already flex'ing but could use some easy way to quickstart new flex projects in java?

I have created a maven archetype called maven-archetype-flex and distributed it to ibiblio for all to use.
It will quickly get you up and running.

Here is how you do it:

1. Download flex sdk
Download the flex sdk from adobe, if you haven't got it already.

1b. Minor change to flex-config.xml
You have to uncomment the following in your flex-config.xml located in:

${flex.home}/frameworks/flex-config.xml

<local-fonts-snapshot>localFonts.ser<local-fonts-snapshot>

Otherwise the compiler will complain as Matt mentions in his comment.

2. Create flex project
Running the following maven command will create a flex project called my-flex having groupId my.group. Feel free you change these to what ever you like:

mvn archetype:create
-DarchetypeArtifactId=maven-archetype-flex
-DarchetypeVersion=1.0
-DarchetypeGroupId=dk.jacobve.maven.archetypes
-DgroupId=my.group
-DartifactId=my-flex
-DpackageName=

Note: it is important that you remember the -DpackageName= as the Main.mxml flex file in the archetype is to be kept in the root of your source dir and not in some subpackage.

3. Set flex.home property
In the newly created project pom.xml you should change the flex.home property to fit your flex.home path.

4. Build flex project
Now you are ready to build the flex project:

mvn install

Running this command inside your project will build the project and create a swf file in the target directory.

Viola! You have just created a simple flash application ready to use.

Where to go from here
To see the result of the work you can do one of the following things:

• Open the flash file with your favorite browser.
  
• Download the standalone player for your operating system ().
• Deploy the swf file to a webserver. Maybe you can get inspiration on how to do it from this maven flex template.
  

Easy syntax highlight embedded code on your blog

For some time I have been looking for a easy way to syntax highlight code snippets on my blog as my default stylesheet seems to do a bad job.

I came across tools like:

• code2html
• star-light
• syntaxhighlighter

But the one I found most interesting is google-code-prettify that Hung Huynh recommended me.

Prettify only requires you to include a small stylesheet and a single javascript file containing the code doing the hard work - see the simple readme
Then you just surround you code with - say <pre class="prettyprint"> and voila! your code is syntax highlighted.

I have updated some of my older posts so you can see the prettifier in action:

• Acegi: How to implement remember me
• Maven defaults is missing something
  
• Acegi: How to implement formbased login

The preferred multidimensional html/css menu

Yesterday I wrote about how friends and family from time to time asks for help when developing some homegrown php project and today was no exception.
I was asked if I could recommend a simple but efficient multi dimensional menu that could fit into a left column of a website.

A couple of years back I remember that I used some menu relying on a homegrown javascript library doing the best to take care of the many different browsers javascript implementation.
The actual menu content was placed inside lots of tables hence it wasn't easy to maintain.

Today many different opensource dropdown menu's are available so the job is more to look up the one that suites you best, than writing a bunch of code and markup - and the one I ended up with is the extended suckerfish dropdown menu.
It is almost a html/css only menu (of course some javascript is nessesary to please IE!) and was very simple to implement.
The menu content is rendered as unordered list items - (ul and li elements) so serverside generation of the menu is easy.

Customize it
The default implementation represents the menu as a normal top menu, so a bit of customization had to be done to make the menu fit as a left site menu.

The following did the trick:

/* set the width of the entire menu */
#nav {
  width: 10em;
}


/* remove this as it aligns the toplevel menu to the left of eachother
#nav li {
  float: left;
  width: 10em;
}
*/

/* add this as it let the first level menu appear to the left of the first level menu */
#nav li ul {
  margin: -1em 0 0 10em;
}

#nav li ul ul {
  margin: -1em 0 0 10em;
}

I must say the menu is very cool and I can indeed recommend it!

Drawback
The only drawback of being a pure html/css implemention is the lack of ability to delay the time it takes to hide submenus.
It will happen instantly as the cursor removes focus from the menu and you will quite often find yourself "loosing" the menu as you tries to navigate down the menu tree.

A badly packaged project will break builds!

I have stumpled across many comments on different blogs bashing maven for being a bad build tool. To me it seems that an era of "hate maven" is rising and many people seems to just blindfolded follow the horde of maven bashers.

It seems to me that people tend to forget what maven brings to a project.

• Convention above configuration.
• Dependency management.
• A bunch of default plugins ready to be used. (You can argue the quality of all opensource plugins, but I really think it is getting better)

A thing like dependency management is one of the greatest benefits. Luckily I have forgot the old days where precious time was spend looking for dependencies need by other dependencies.

Although maven provides many benefits I ran into one of the things that one could call a bad side effect of using maven and its transitive dependency management.

The springframework is distributed in two different ways.
As a single artifact containing the complete spring distribution and as a much more fine grained distribution where each artifact contains a logical spring module.
As it all seems fine and interface21 probably think they are pleasing the broader audience by providing the different distributions, it brings a bigger problem to the surface.

By providing the same code in different artifacts you introduces the risk of a project to unintentionally depend on the same software in different versions.

In my case just adding the acegi 1.0.4 to my maven pom.xml broke our build - and I did not even configure or use any of the acegi code!

Ofcourse I wasn't late to blame maven. As the problem showed up by just modifying my pom.xml the problem couldn't be blamed on anybody else but maven.

Some exercises with the -X option shed some light on my problem:
Acegi 1.0.4 depend on the fine grained distributions of spring 2.0.4 modules, but as it happens I already had a dependency to the full spring 2.0.5 artifact. Dependency resolution interprets the to versions of the same software as different artifacts - and if you stick strictly to the maven dependency resolution rules they sure are different!

A dependency is defined uniquely as follows:
<groupid><artifactId><version><package>

As the version changes, maven takes care of using the latest version. But with different artifactnames containing the same code, you are most likely leaving your users of your library with a classloading issue just around the corner.

Hence the cause of the problem was lying outside maven.

Now you would probably tell me that I should only use the fine grained spring dependencies - but I was probably lazy and sure others out there are lazy too.

My experience sums up to the following rules of thumb:

1. Apply DRY to your artifacts distribution.
   If you repeat yourself in your artifacts you introduce risks (not the same type of risk though) as if you repeat your code.
   
2. Choose your groupId wisely and do not change it again - ever.
   

After blaming Spring I can tell that Spring isn't the only one to break dependency rules of thumb.
Ehcache has changed its groupId between version 1.2.3 to 1.2.4 and bingo! You have to different artifacts from a dependency resolution point of view.

Conclusion
Even with the quirks I just described I still think maven dependency management it is fare better than the good old plain Ant days!

Hints
If you suspect that you have run the same problem as I did, I suggest you run maven with the -X option as it prints the complete dependency resolution tree. From there you can find what transitive dependencies to exclude.
If you prefer Ant you should take look at the dependency management tool Ivy, but that subject is worth its own blogpost...

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.

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!

Bayeux is now tapestry 4.1 compatible

I am a developer of Tapestry Bayeux and is proud to announce the release of Tapestry Bayeux 2.0.0-beta-2 (see: changelog).

The reason why I have decided to name the release beta-2 is because the flow component available in bayeux 1.4.0 isn't included in this release. But that is the only reason and the rest of the components is stable.

What is bayeux?
Tapestry Bayeux is a open source component library for Tapestry and was released for the first time back in 2004.

Bayeux contains various components primarily developed for use in projects that Nordija is involved in. But since our first release we have had numerous downloads and we know for sure that tapestry jumpstart 1.2 uses the "do it once" components.

Actually it was Geoff Callender - the developer of tapestry jumpstart - that inspired me to upgrade tapestry bayeux.

When we first released Bayeux, tapestry 3.0 had only been stable for about half a year.
Since then tapestry has evolved rapidly and the latest stable release at the current time of writing is 4.1.1.
In hope to fit as many active tapestry projects as possible, we have upgraded Bayeux to tapestry 4.1.

Your past will always haunt you...

Recently I was contacted by Geoff Callender, the guy behind the Tapestry Jumpstart application.

He was working on the next Jumpstart version (1.2), that should contain a solution to the famous redirect-after-post paradigm.
As any other developer he must have used Google in his search for inspirationto such a solution and Google must have led him to Tapestry Bayeux.

Bayeux is a Tapestry Component Library containing a small set of components that a couple of my colleagues and I have developed a long time ago - back in the time were Tapestry 3 was on anybodies lips.

Geoff was interested in in the "do it once" components that prevents the user from activating more than one listener by the use of some Javascript. They should be a part of his solution to the previous mentioned redirect-after-post paradigm.

But those components was only Tap 3 compatible, so Geoff had to convert the components to Tap 4 him self if he would like to use this approach in his solution.

And so he did!
I tried to convince him to contribute the source back to Bayeux by giving him developer privileges but some how that wasn't tempting enough. :-)

So now I am "stuck" with the task of bringing Bayeux up to the latest stable version of tapestry - which is 4.1.1 at the current time of writing.
Its funny how software you developed as a part of a solution for some client back in the ages can haunt you down and for a split second make you think "why did I ever make it open-source" :-)


Just started the upgrade of Bayeux made me realize that software development has moved on since then...
CVS > SVN
Maven 1 > Maven 2
etc...

Just more work to be done... :-)