The bottom line is that we have approximately 100 projects build with maven to build our entire platform. You don't need much imagination that we have a couple of challenges to meet.I started with Maven 1 which was a astonishing mixture of Apache Ant and Jelly. But I never really liked the idea of executable XML. In my opinion XML is not a good programming language at all but this would be a blog posting of its own

Back to to the builds. A couple of days ago a read some tweets from the the man behind tapestry to remind me about Apache Buildr. This lead to rethink some experiences I made with Maven2 in the last couple of month...

This lead to certain discoveries what I started to really dislike on Maven2:

1. The XML - The pom.xml which defines the central project object model os getting really cluttered. When you have a small project there is almost no problem but if you have an enterprise scale project (almost evereything after an example project) the pom.xml is getting huge and you don't find the things you need.

   Okay, there are "helpers" to maintain the pom.xml, but e.g. if you use Eclipse with a POM file the XML editor starts to parse it. If the file is no very small - even a small open source project like jaev has an approx. 140 lines pom.xml - it'll make Eclipse somewhat slow. If you use the m2eclipse plugin it will get even worse. The m2eclipse offers some very nice tools for POM handling and it got really good compared to the early versions. But I know a couple of guys who refuse to use it because of the negative impact on your development environment.

2. Reuse by inheritance - The only way (so far I know ) to reuse settings in Maven2 is POM inheritance. This works like prototypic inheritance (like in Javascript). You may define prototypic plugin settings in the parent POM and all POMs which inherit from this parent POM will use this settings as a default.

   So far so good, but in most object oriented programming languages inheritance to reuse code is considered to be a bad design pattern. In Maven2 you may stumble across the same bad issues as e.g. in Java when you use the POM inheritance. As a matter of fact you may only inherit from one parent POM, so your inheritance tree will get cluttered with settings and overrides.

3. Insufficient version and dependency management - The dependency management is one of Maven2 strongpoints, no doubt about it. But if you really start to use it you'll get to it's limits very fast.

   I guess Maven2 did some awesome pioneer work to version handling. Due to the fact that every artifact has a version number. Unfortunately the version numbers in Maven do not have an ordinal structure and admits special indicators like SNAPSHOT, alpha or LATEST which are adding a whole new level of complexity. So maven can't tell if a version is greater than another version, e.g. is 1.4-SNAPSHOT greater than 1.4?. This is very problematic when use version ranges and transitive dependencies. When you'll get a dependency from different sources (e.g. the commmons-lang library) there is always some magic involved which version you'll get. This leads to next next issue:

4. The build does not break early enough. - Maven2 tries to be very clever in some situations like the dependency resolution. If a problem occurs maybe a log message will be provided but the build will continue even if you have contradictory dependency declarations. So the only "hint" you'll get, if the dependency tree is faulty, are compile errors if you're lucky. If you have runtime dependencies you'll get some funny effects in your application
5. No separation of concerns. - The POM includes all concerns of a build like:
   • Dependency management
   • Compiling
   • Tesing
   • Packaging
   • Reporting
   • Deployment

   You'll have different sections in the pom.xml like <build/>, <dependencies/>, <profiles/> or <reporting/> which group the declarations a little bit. But if you take a closer look at the <build/> section you'll soon realize that it works quite different that e.g. the <dependencies/> section. In the <build/> you are more on a programming level to specify the compile and packaging issues of your build. The <dependencies/> is only declarative.

6. Only one file - To make the lack of separation more painful you are not able to break the different concerns into separate files. There are some Maven plugins which use other files like the assembly plugin, but this an exception. It would be really nice if out could include files into your pom.xml. This really could have positive effects on the inheritance issue too.

Okay to straighten this a little bit. I guess the Apache Maven did some of the most innovative work on the build sector in the last few years. And I don't consider to switch to make or Apache Ant. It makes many things a lot easier and most of my critique may be corrected in further versions I already had a peek into the Maven3 source code and I'll guess the Maven/Sonartype guys will level some of this issues. I 'am very curious about Maven3 and I hope it will ease some of my pain related to the Version 2 of Maven.

So, it was great to get some thoughts clear about what is important when you build a project and what are the different facets when you use a build tool. I had a first look on Apache Buildr maybe I get enough stuff together to create a blog entry about it ...

The jaev framework is in productional use at least one installation and no major problems where filed so far. I'm keeping my fingers crossed

I am working already on some new features:

• Caching negative responses of mail servers
  When a mail server refuses communication due to suspected spam, the result will be cached to reduce network traffic.
• Suggest e-mail addresses
  When the validation fails suggest a list e-mail addresses. This algorithm may use the previous request and a default list of domains to compute some suggestions.

If you have any good ideas, file them on the issue tracking system or the google group.

Maybe I am applying for a google wave developer sandbox access to provide a google wave robot for online e-mail suggestion. Bah, that sounds like some work

The last time when I blogged about the Flex mojos I was still quite frustrated and thought I had a better solution. Now some time passed and on April the 3rd the new version (3.1) of the flex mojos was released and me and some of my colleges made some interesting discoveries.

Well, but in the last few weeks I often thought about the meaning and the source of the word mojo. Lets take a closer look at wikipedia.

Mojo (pronounced /ˈmoʊdʒoʊ/) is a term commonly encountered in the African-American folk belief called hoodoo. A mojo is a type of magic charm, often of red flannel cloth and tied with a drawstring, containing botanical, zoological, and/or mineral curios, petition papers, and the like. It is typically worn under clothing.

Okay, hoodoo! That explains quite a lot. Sometimes maven and the flex-mojos are a kind of magic.

But let's get back on topic The boys from the Flex mojos where quite busy and created with the 3.x release very usable platform for flex builds in the maven world. It took us (mainly a freelance colleague) two more weeks to adapt our build process form various ant scripts into a multi-module maven2 build. But now it looks quite nice, the build is even faster and we were able to fix a problem with our Flex Builder configuration.

The platform build process is realized with Apache Maven, which is, in humble my opinion, still the first choice for Java based software projects, but integrating other project types into maven is a kind of challenging due to the nature of Maven. You may summarize this in: If you do it the maven way it's very easy, if you don't it is up to you ...

Luckily there was already an existing build with Ant and a dysfunctional Maven variant with the Maven Flex-mojos plugin. So it stated my journey to insanity an back ...

In the last week the release 1.0 platform release of scoyo came close and we were tying up some loose ends. One of these ends was the integration of the scoyo Flash/Flex portal build process into the platform build process.

The platform build process is realized with Apache Maven, which is, in humble my opinion, still the first choice for Java based software projects, but integrating other project types into maven is a kind of challenging due to the nature of Maven. You may summarize this in: If you do it the maven way it's very easy, if you don't it is up to you ...

Luckily there was already an existing build with Ant and a dysfunctional Maven variant with the Maven Flex-mojos plugin. So it stated my journey to insanity an back.

My first attempts started with reactivating the Flex-mojos maven build. I already had some experience with Flex-mojos when preparing the build for the jaev Flex example. This example Project for the jaev framework also uses the Flex-mojos maven plugin to create the example .swf and uses the infrastructure of maven to assemble the web application with the HTML and the BlazeDS services. Took me some time and a quite nice tutorial from Sébastien Arbogast but finally it worked!

So I thought I was prepared for the task and nothing could stop me. There is no law against being wrong, at least in Germany .

The main problems was finding all the required libraries in various maven repositories. Additionally there were some foul libraries. Some yahoo uploaded HTML files as .pom and .jar file in a repository. It took me quite a moment to realize this. Unfortunately the current Flex SDK 3.3 was not available at all in any maven repository. At least I did not find any.

So after wasting some hours I changed the strategy: My new Idea was to call the Flex Ant tasks provided by Adobe from the maven build using the maven-antrun-plugin. The antrun-plugin is quite nice if you have to perform some tasks not covered by maven. So you can execute some Ant tasks to enrich your build.

But things where going to be worse. A couple of very "unsatisfying" hours later I discovered a bug or incompatibility of the maven maven-antrun-plugin and the Adobe Ant tasks. So it was time to rethink my strategy again. Should I switch back to the Flex-mojo approach? I went for a minor adjustment first: Instead of using the the Ant tasks I went for the compilers (mxmlc for Flex applications and compc for Flex libraries) directly. Calling them with the Ant <exec /> task, which executes a command on the command line. Then use the maven-assembly-plugin to create a ZIP file of the compiled artifact and install/deploy it into the repository.

Let's sum this up:

1. start JVM and execute maven
2. execute the maven-antrun-plugin to execute ant tasks
3. use some Ant tasks to assemble the Flex build path (external and included libraries)
4. use the Ant <exec /> task to execute the flex compiler (let's share a secret: The Flex compilers are written in Java. Welcome back home )
5. use the maven-assembly-plugin

to create a ZIP file

6. install the ZIP file into the local repository
7. (optionally deploy the artifact into a remote repository)

That does not sound like a simple build process. And let me amend something: If you a using shared libraries in the build (yepp we have a couple of them) you may add another step before invoking the maven-antrun plugin. You'll have to use the maven dependency plugin to copy and uncompress the libraries from the local (remote) repository to your build environment, so they can be accessed/found by the build. You'll imagine I was not satisfied at all with this build variant ...

Again my old friend came along, the question:"What to do?"

The Flex-mojo approach obliged my to upload the whole Flex SDK into our local archiva installation which hosts out company maven repository. This includes the minimum 54 libraries supplied by the Flex SDK. Okay most of them are quite common, but when a new Flex SDK is released (which happens on a quite regular basis) you'll have to recheck all dependencies. No thanks ...
The maven/Ant/Flex compiler variant emerged as juggernaut with bad performance and a loads of catches. No improvement at all ...

So I decided to take a closer look at the Flex-mojo plugin itself. Why do I need to have all this dependencies? The major advantages to the Flex-mojo plugin are the special packaging types swf and swc for Flash movies and libraries. Using this packaging types maven will use a special life cycle and offer the possibility to install/deploy the artifacts directly into the repository. To my relief only a quite simple XML file (a plexus component definition) was necessary to achieve this.

So desperate as I was, I decided to write a maven plugin on my own. I must confess it was not my first time. I already wrote a simple maven plugin for the SinnerSchrader commerce framework, a library developed by my former employer. I really do not like to reinvent software on my own. But I was curious and I want to give it a shot. My goal was to combine the two approaches I tried before and use the best of both. So the plugin should be able to manage the swc dependencies, the flex compiler configuration (via -load-config) and the direct deployment of swc and swf artifacts.

The approach was simple:

1. check the maven dependencies for libraries to reference or to include
2. check for a configured compiler configuration
3. create the compiler command line and all options like -load-config, -compile.debug, -compiler.include-libraries or -compiler.external-library-path, etc.
4. invoke the compiler via thejava.lang.ProcessBuilder
5. install the artifact into the local repository

It took me not an hour to build a working proof of concept and only approx. four more hours to mavenize almost the entire build. This was really fun after two days of trying and failing. There are still some minor adjustments to make on monday, but I am really looking forward to finish the build. And if all works out as I want, there might be a 15-20% speed improvements for a complete build. But this also reduces the necessity to perform complete builds, because some shared libraries are rarely changing at all, so we can deploy them into our company maven repository.

As I went to bed last night, I was wondering why the Flex-mojo approach failed and the home-grown maven plugin approach succeeded. Under the shower this morning it was quite obvious to me. The Flex-mojo plugin stores the whole Flex SDK in maven repositories, so you don't even have to download the Flex SDK to compile your Flex application. My home-grown plugin needs the Flex SDK installed on the build computer and the FLEX_HOME environment variable set. But that is okay, because the maven-compiler-plugin does the same. It does not work without the JAVA_HOME set and it does not try to deploy the Java SDK into maven repositories. Maybe the Flex-mojo guys will also realize the difference. It seems to be a quite nice piece of software but with too much unnecessary complexity and very "clustered" documentation.

After tying up this loose end me and a very experienced Flex development colleague already discovered some further TODOs relating to the maven and Flex Builder integration. There is still lots of work to do, so I am exited. My new job is different as I expected but a am very confident that it will offer some exiting further challenges for me ...

What does jaev do? The name jaev is the abbreviation for java (advanced) email validation. So the framework does validate e-mails. Sounds quite boring, isn't it? Of course not!

The name of who/what is jaev? The jaev framework is my first open source project! Jepp, I joined the community and giving something back after years of using the frameworks of other people.

What does jaev do? The name jaev is the abbreviation for java (advanced) email validation. So the framework does validate e-mails. Sounds quite boring, isn't it? Of course not! There are some quite good tools for e-mail validation like the one in the Apache commons validator project (I "borrowed" some test cases there). But the e-mail validation in java was quite shallow. If you want to have a more advanced validation, i.e. of the domain, you'll had to do it yourself. The jaev framework tries to fill this gap.

It provides facilities to validate the syntax of an e-mail address with including addresses with names like Niclas Meier <niclas.meier@example.com> (I confess the handling of comments in e-mail addresses has still some flaws, but it's not so important I guess). This is obligatory but the jaev framework offers quite more.

With the jaev framework you'll may check the domain of the e-mail address. The framework uses a local (or server) copy of the IANA top level domain database (http://data.iana.org/TLD/tlds-alpha-by-domain.txt) to validate the top level domain. If the top level domain is okay the DNS database will be queries if the domain exists and has MX entries. If a domain has no MX entries you'll have to assume that you will could not relay an e-mail message to the e-mail address. The mail server uses the same mechanism.

A very important feature of the jaev framework is: You have the choice! You are receiving a Result object as outcome of the validation process. The Result contains a code, which specifies the details, and a validity level which specifies the level of validity of an e-mail address. I.e. SYNTAX suggests that an e-mail address is syntactically valid but the domain and account may be invalid. The maximum validity is ACCESSIBLE. With ACCESSIBLE validity the jaev framework was able to verify the existence and accessibility of the e-mail address on the MTA of the e-mail domain.

This is the last big feature of the jaev framework. The framework can connect to the MTA specified in the MX entry of the domain and tries to send an e-mail to the e-mail address. If the mail transfer can be initiated the framework will abort the process, no mail will be send, but we can assure that the e-mail account exits.

Around the three step validation mechanism the framework offers quite simple and extendible construction and configuration mechanisms, examples for JSF, Tapestry 5 and Flex & BlazeD and different acceptance strategies. Timeouts may be applied on different levels and operations, so you can assure that you'll get a Result in a defined amount of time.

I think this is quite a handy package. And I spent lots of my spare time the last four weeks to bring this to life. Maybe someone out there agrees with me and uses the framework in his application.

If you encounter some problems or you would like to contribute/request some features you may post them to the google group or to the issue management system. Maybe there is someone out there who is firm in ANTLR which the jeav framework uses for e-mail parsing.

After nine years and five month it wouldn't be nice of me to leave without a notice and there a quite a lot a very nice people. But in a couple of days I have to consider me as alumni. But this has benefits too. On System Administrator Appreciation Day there will be plenty of topics to talk about.

So what to do in the next couple of days? Now I am sitting here at home on my computer and blogging. But this won't last until the 2 February when I am starting my new job at scoyo. I am pretty exited and not even in a mood for a vacation. On top of it, the January in my old job was strange because nobody had real work for me to do. Okay that's not quite correct, but if you are used to have a very full inbox and a very noisy telephone, it is quite strange if the telephone doesn't ring anymore.

So I decided to push things a little bit at a small project which I started a couple of month ago. It's making quite some progress at this moment, and I am pretty confident that I have some stuff for more blog entries.

Parallel I am working on my Actionscript and Flex skills. It's quite nice but I am desperately looking for an example or application which really challenges me. It's quite a little bit academic at the moment.

After nine years and four month at SinnerSchrader I am pretty nervous how this will be. It was my first employment after I graduated at the Fachhochschule Wedel. Hell I will really miss some of the boys and girls! But I am still convinced that this is the time for me to move on.

One of these "new skills" I am preparing is Adobe Flex, which is a framework to create rich clients for the internet based on the Adobe Flashplayer.
Quite an intresting and well designed piece of Software. This is still my first impression I'm pretty sure I will discover some very ugly facets later. I already ran about some bugs with the HTTPService which prevented my from setting the "User-Agent" header on a HTTP GET request. Damn I am demanding I know
But the WoW Armory refused to return pure XML until I pretend to be the Firefox 2.x Browser. WoW Armory is also a pretty interesting piece of software. It offers the facilities to query WoW Characters, Guilds or Items via the Web. If you are using a Firefox browser the WoW Armory returns only a XML which will be rendered with a XSLT style sheet. All the other Browser will get an "interesting" HTML page. Maybe I am blogging about this later.

One last thing left to do for 2009:

Wie man so schön in Deutschland sagt: Einen Guten Rutsch ins neue Jahr!