Unfortunately in a lot of projects this very important topic does not get the appreciation it deserves. On one hand side it's a very sad story of suffering and endurance. On the other hand side we are talking about a lot of wasted money.In my career as software engineer I experienced some different approaches to the project setup and the build process.

It started with something like find . -name '*.java' | xargs javac, which worked quite well for the first weeks of my professional career. But with a couple of software developer working on a project you want something more standardized.

So we went on with make(*). I guess most of the software engineers will know this build tool which still is a standard tool in the Unix/Linux world. make is a very powerful tools but has its peculiarities also. The make grammar is very delicate when it comes to white spaces. I quess quite a few people sat over a broken make build when a TAB char wasted your build script.

In the Java world Apache Ant was the successor to make in my career. The problem with make and the Java world is, that make is not really platform independent. There are make ports for Microsoft Windows but (at least when I made the jump from make to Ant) it does not work very well. So if you have a heterogeneous environment e.g. you develop on Microsoft Windows and you deploy into a Linux based cloud, you want your build to to be platform independent.

A nice story about platform independence. I did some consulting in a project for the Deutsche Bank Italy and a very large (and expensive) consulting company provided the BEA Weblogic build and setup. I am not 100% sure but I guess it was an Apache Ant based build. One major issue was the application server integration integration. To solve it, the complete project was placed and build in the application server which was committed in to the CVS source control management system. The delivery artifact was - of course - delivered without the application server. But this leads to another wish I have when I am using a build. You want the build to credit the current environment. If you are building for your local development environment you may have different requirements concerning the built artifact as when you are creating an artifact that will be deployed on staging or productive environment.

Back on memory lane: Apache Ant worked pretty well for some years and a couple of projects. But one thing that started to annoy me. Every project was using a slightly build setup so in the daily business there were always searching for artifacts or checking library versions.

Some former colleagues introduced me to Apache Maven. I started with Maven 1 which is a quite interesting mixture of Ant with a framework that offered the possibility to manipulate the Ant build file during the runtime. But Apache Maven had some features which I hat to get used to.
An example is the rigid directory structure defined in a Maven build: Why do I have to follow them? I want my special directory names! But nowadays I love this structure which is equal in every project. You find your files so fast now and even in foreign project. That's another thing that you want: You want your builds to follow standards, so you can get familiar with the project in very short time. If you are working in the software business a couple of years, may have already realized that you will see very much projects during a professional career and standard projects and processes will make your life much more easy.

Let's talk about some goodies now which modern build system offer. I will use Apache Maven as example but other systems like rake or buildr offer similar functions.

One thing I love/hate is dependency management. When I started with make or ant, we where committing all libraries into our CVS. Which worked quite well, in most cases you could check our the project, performed the initial build and started to work. But there where lots of minor but very nasty problems. Starting from which library version is really used to incompatibilities of the build tool version.

With the Apache Maven dependency resolution mechanism a new area begun. If you are having one independent project the mechanism is pretty easy to use. You define the libraries you want to use in your pom.xml and maven takes care of the rest. Okay if you want to use libraries which are not in the maven central repository it's a little more complicated

If you are having a multi module/project environment things will get messy pretty easy, but: They would also if you don't use the dependency management mechanism. You ask why? When you don't use this mechanism you'll normally have a huge monolithic project in your SCM system which will get even more difficult to manage or build. So you want to have a transparent dependency management in your build system. With Ivy for example you'll have an add-on which offers the possibility to have an dependency management when you are using Ant.

Another goodie is release management. It's very handy if you start a build to create your release artifact and your tag (or something similar) in the SCM system of your choice. You want your release process embedded in your build system, so you can perform the build when you are creating your release.

Another important topic is testing. You really want your build tool to support your testing facilities. At least when you create your release or deployment artifact you want your build to automatically run your test suite.

I have only one topic left in this post, that is IDE support. Unfortunately most modern IDE like Eclipe, Netbeans or Intellij IDEA offer a IDE specific build. This this very comfortable if you have a small project and what to deal only with your IDE. But you'll grow really beyond this (my experience). But integration into other build tools is sometimes really poor. So you have to check how you can bridge the gap between your IDE and the build tool. E.g. the maven directory structure troubles some IDE
standard configurations. Fortunatly more and more projects provide solutions for this.

So let's have a quick resume. This is what you should want in your build system:

• standardized process
• platform indipendence (if your need it)
• credit current environment
• standardized structures
• dependency management
• embeddable release process (including SCM support)
• support of your test tools
• IDE support

I think this list is not too lang and offers some major improvements for your daily work. So if your build process is missing some items from this list, you maybe should think about your build process. And remember: Your development resources are far to valuable to be wasted in an inefficient build process

. So congratulations from here

But back on topic: One fundamental rule of the Tapestry 5 framework is, that each page has a corresponding class which contains all (java-) logic for this page. This mechanism works sole with convention over configuration and there is no exception to this rule. At least in standard Tapestry 5 ...In the company I used to work we depended on Tapestry pretty heavy. We had created a couple very good solutions using this framework but we also had some challenges to meet. I guess they are pretty common to web based companies.

• We had to use a CMS system (Magnolia CMS in this case) to enable the marketing and non-techical guys to maintain all the content they are creating.
• We had to maintain a couple of so called landing pages. I guess most of the web guys know and hate them These pages are just an empty shell containing nothing more than some sightly different logos and graphics of partner companies. The also provide a nice URL in most cases like: http://www.mycomany.com/tv, /mobile or /unameit. Unfortunately some of these landing pages hade some minor dynamical stuff on it.
• Most of this landing pages require that you are storing some (voucher) code into your application to modifier your check-out process a little bit.

So, now you have a couple of pages, of which you don't know when they appear - and you really don't want to know, because coordinating the timing with the marketing guys is always a mess -, with very similar structure and functionality. As a matter of fact this case should be a text book example for component reuse. but this is a case where Tapestry 5 and the convention-over-configuration thing works against us.

So what do you have to do in classic Tapestry 5? Jepp you allready guessed it, you have to create a page class for each of this landing pages. Okay thanks to inheritance this class will be de-facto empty. But it is annoying to create this class. You'll have to create a version of your web application, do a QA cycle (if you want to play it right), make a deployment. So you have a lots of communication with a bunch of other departments. In a world with perfect processes you might to accept this, but I guess most of the guys out there know the situation where a junior business consultant guy stands right at your desk telling you of the nation wide TV campaign that launches tomorrow and that needs this new landing page. Maybe some of you already tried to say the 'n*' word

A early solution was to introduce some Meta templates in out CMS. They were some simple HTML comments which where evaluated by a service in our web application and re-assembled via simple Tapestry pages and components. This worked quite well but brought us a bunch of issues - like template caching, dynamic contents in templates, etc. - which are already solved in Tapestry. The solution was also pretty limited in when dynamical and statical parts should be joined together. So I took some time to evaluate a different approach:

My first question was: Is it possible to make tapestry work with pages that do not have a class as backup?

I never tried this, because I figured out, that I actually didn't want to do this, and as a matter of fact, it makes the whole exercise a lot easier. What I did was to make Tapestry use a default class for pages tapestry does not know. I call this pages virtual pages. I'll guess you always have some minor data shared between all virtual pages, so you create on page class that Tapestry may use to serve virtual pages.

So how you serve virtual pages with Tapestry 5.1? I was surprised who simple it was (after some month of the wrong track). So this is, how virtual pages may work:

1. Check if the page exists
   A good place to do this is the ComponentClassResolver with its isPageName(..) method. I created a special implementation of the ComponentClassResolver which decorates the Tapestry original.
2. Mark the request
   Mark the request as request to a virtual page. I used a dedicated service with thread scope for this. You also may compute and store some data in this service.
3. Alter page class loading
   Adapt the loading of the component classes to load (and attach) the default class to the page. Another decorated service does the work here too.

And voila you can deliver content for pages with no backing class, astonishing isn't it? You may look at the small prototype/example project at github and you'll realize how simple the solution is. The prototype is a slightly modified Tapestry 5 archetype project which will serve the URL http://localhost:8080/About as virtual page.

So far, so good! But now some last words if this is a good solution at all. First I want to mention that we had an integration ready for the architecture we used, but it went - for several reasons, most non-technical - never productive.

Let's talk about some oddities first:

• The URLs to address the pages do not fully comply the Tapestry behaviour. In Tapstry it does not matter if you request /About or /about, but the prototype only supports a simple template resolution.
• Some Tapestry components/mechanisms won't work properly. Tapestry uses classes to compute links to pages. Always when this mechanism is used, you'll may get problems. Components like <t:pagelink ...> may not work properly because you do not have a class. Keep this in mind.
• Unexpected Runtime and memory behaviour. Tapestry is a very stable and production ready framework. But we are misusing it a little bit. Keep a close eye on memory consumption because every HTML page will now be a tapestry template and will be cached in the memory of your virtual machine. Some of some infrastructure components are also optimized for a (relatively) small amount of page instances.

Why do I want to use Tapstry this way? The first advantage is the simple creation of new pages. You'll create the .tml file and you are done. We used it with a CMS in the background and with some specialized CMS templates the marketing guys where able to create a bunch of landing pages without troubling an IT guy. In addition to the standard page we used some components which contained the major functions of the pages. So we were able to create instance of this virtual pages which behaved sightly different because we passed some parameters using the TML of the virtual page.

Why does not offer Tapestry this mechanism? First: It's a prototype! If you take a closer look you will se how limited it is. This topic as hole comes across the tapestry mailing list regularly and there are lots of pro's and con's. I don't want to discuss any of them in this blog post. But I agree with the Tapestry guys not to introduce it into the core framework.

At the time I was evaluating this prototype I had some very good reasons to do so and only a few are mentioned here. But if you have a big amount of content it is seldom a good idea to generate templates which are interpreted by a dynamic framework. No matter if you use JSP, Tapestry or even PHP.

I hope you'll enjoyed reading this blog post. I learned much about Tapestry 5 preparing it and evaluating my idea. If you have questions of any kind feel free to contact me

To introduce you a little more into the domain. When using a CMS with some other software components you'll have a situation very similar like having a database. You have content which other (non-tech type) people manage and if you change your application sometimes you'll have to change the content - or worse the structure of the content - too. In the database world there is a very nice book regarding the refactoring of databases.

As a solution to this issue the magnolia CMS offer some API related to the info.magnolia.module.ModuleVersionHandler. This API's offers the possibility to define info.magnolia.module.delta.Tasks which may be related to specific module version. So the CMS may discover on startup time which Tasks to execute when migrating e.g. from module version 1.4.2 to 1.4.6. This is very nice because you can load partial XML content dumps or move some content (or configuration) nodes around.

Unfortunately you'll have to do this while program the update procedure in Java in your ModuleVersionHandler. To close this gap we introduced an own domain specific language using XML. I refer to this as DSL because it evolved to be much more like a simple XML config file, I'll hope you'll get the point later on. The inspiration gave a freelance contractor with very deep magnolia know-how. So here is how I did it:

First of all the ModuleVersionHandler has to deliver all the information defined in the XML file, so you'll have to override it. So we subclassed the info.magnolia.module.DefaultModuleVersionHandler to override methods like getExtraInstallTasks(...). This new version handler is responsible for reading the XML file, and converting it into the objects that magnolia handles.

Next step was to define a XML format. It should be an expressive format, nice to read and easy to understand. So waived of standard formats or facilities like the Springframework which also offers facilities to assemble object graphs from XML files. The format we choose looks like:

<updates>
	<version number="1.5.0">
		<description>Changed implementation of header selection</description>
		<updates>
			<load file="config.modules.scoyo.dialogs.pageProperties.xml"/>
			<if-exists repository="WEBSITE" node="/en"><then>
				<set-property node="/de" repository="WEBSITE" property="reportSuiteIdLive"><value>test_en</value></set-property></then>
			</if-exists>

 		</updates>
	</version>
</updates>

which is quite nice to read and you'll have your documentation in the right place. In order to automatically process it using JAX-B you'll have to define a XML-Schema which will be used to generate your Java bindings. Besides this it's always good to have a XML-Schema, I'll give you some further examples later

Our schema looks like this (at least in eclipe)

We defined some elements (as seen on the left hand side). Each of this elements contains some attributes (or inner elements) which are passed to the magnolia Tasks. The clou of this XML-Schema is the Task type and the <task /> element. The <task /> element is an element, which all elements defining a specific task (e.g. <load />) must have as substitution group. Doing this allows on every place where a <task /> may be placed in XML another element of this substitution group may be placed too. In fact you'll never use <task /> but always use a specific element like <load />. The Task XML type covers the XML type part of the <task /> element, when generating the XML bindings the Task XML type will be translated into an abstract super class for all specific types like the Load XML type, which defines the structure of the <load /> element.

To generate the XML binding classes from the XML-Schema we use the Apache Maven 2 plugin from the Codehaus mojos. You may configure it like this:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>jaxb2-maven-plugin</artifactId>
    <version>1.2</version>
    <executions>
        <execution>
        	<id>bootstrap</id>
        	<phase>generate-sources</phase>
            <configuration>
            	<schemaFiles>bootstrap_1_2.xsd</schemaFiles>
                <packageName>...</packageName>
            </configuration>
            <goals>
                <goal>xjc</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
    	<verbose>true</verbose>
        <outputDirectory>${project.build.directory}/generated-sources/java</outputDirectory>
        <clearOutputDir>false</clearOutputDir>
    </configuration>
</plugin>

The JAX-B bindings will produce nice annotated java beans which you can use in the further work. Another nice side effect of using JAX-B is, that it's blazing fast compared to use DOM or XPath processing of your XML files. Another nice effect of having an XML-Schema.

So, after defining the XML-Schema and generating the JAX-B binding the next thing to do is to unmarshal the data from the XML file (or InputStream) which is not more than 20 lines of standard java code. Then you have an object graph representing the XML and the only thing left is to create the objects you (or the Magnolia CMS) need from this object graph. This should be an accomplishable task for a serious developer

I choose to create a generic mapper interface like

interface TaskHandler {
	info.magnolia.module.delta.Task create(T xmlTask);
}

and use a java.util.Map to determine the right TaskHandler instance for a XML task bean instance and voila I had all the info.magnolia.module.delta.Task instances which where defined in XML. Some glue code which does some sorting and other stuff completed my ModuleVersionHandler. A TaskHandler implementation could look like this:

dictionary.put(Load.class, new TaskHandler(Load.class) {
    @Override
    public Task create(Load xmlTask) {
        String name = name(xmlTask, String.format("Load file '%s'.", xmlTask.getFile()));
        String description = description(xmlTask, String.format("Load file '%s' for XML import.", xmlTask.getFile()));
        String resource = String.format("/mgnl-bootstrap/%1$s/%2$s", moduleName, xmlTask.getFile());
        return new BootstrapSingleResource(name, description, resource,
                javax.jcr.ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING);
    }
});

I used an anonymous inner class an add the instance directly to the dictionary mapping all JAX-B types to the TaskHandler. The task handler itself uses the getter from the XML bean to create a new instance of the BootstrapSingleResource task. You will mention that the name of the element (<load />) is more readable. One of the benefits using a specialized domain specific XML file.

I promised to give some more advantages of having an XML-Schema. Another Advantage is that you may validate the XML (quite boring) and when you deploy the XML to a public location (e.g. a web server) you will get auto completion in Eclipse. Which is very nice!

So my resume: Sometimes it's more than only nice to have a solution specific to the problem domain. With very little effort you are able to create this solution using XML-Schema and JAX-B technology stack. The result in this case was a well documented XML format which can handle various content migration scenarios. With some further levels of indirections (which were very simple) I was able to introduce programming language constructs like conditions (e.g. the <if-exists repository="WEBSITE" node="/en" /> element). I guess it's okay to call it a language now, isn't it?

There are many situation where standard soultions like the Springframework (or the SOAP message XML format) are the best choice to quickly assemble an object graph, but when the XML (or the content in general) is object to changes made by humans it's always worth to consider a more human readable variant.

I already made some experiences with the Flying Saucer on another job and it is still a very nice framework for PDF creation. For me, a major advantage of "The Flying Saucer" over other PDF creation frameworks, like XSLT and FOP, in the Web world is the homogenous technology mix.

"The Flying Saucer Project" create PDF from XML/XHTML pages using CSS style sheets. All technologies known to the web designer that gives your web site this pretty look. I guess it's okay when you say, that XSLT and FOP is the more powerful technology mix, but styling pages on this technology mix is not a simple task to do.

So back to the initial topic: A basic ingredient which is needed to create PDFs with the "The Flying Saucer Project" is some XHTML. In our project at scoyo we wanted to use Apache Tapestry to create this XHTML.

After taking a closer look to the Apache Tapestry rendering pipeline I found out, that the PageResponseRenderer is the perfect place to hook up the PDF creation into the rendering process. On the one hand the PageResponseRenderer uses a MarkupWriter to create the (X)HTML content from the current Page instance. On the other hand the PageResponseRenderer is responsible for writing the generated content into the server response.

Using the Apache Tapestry own IoC mechanism it's quite an easy task to decorate the Tapestry PageResponseRenderer implementation. It's a beautiful mechanism when you understood how it works. Okay I guess using the 5.1 version of tapestry it would be better to advice the renderPageResponse(...) method, but I had not enough time to get familiar with it yet.

One real big plus on Apache Tapestry is the implementation. Every function is well encapsulated into separate services. And the service implementing classes are very short and almost always on consistent level of abstraction. So you easily understand how a service works and you are able to copy and extend the service functions. So I extended PageResponseRenderer to determine if a page creates XHTML output which should be transformed to PDF. If no PDF should be created my PageResponseRenderer simply delegates to the original Tapestry instance.

When the page wants to create PDF my PageResponseRenderer buffers the created content and redirects it into the ITextRenderer of the a href="https://xhtmlrenderer.dev.java.net/">"The Flying Saucer". Okay this sounds more nice, than it actually is. The content is stored into a ByteArrayOutputStream and re-parsed by the standard JDK XML parser for further processing by the ITextRenderer. But I guess the we will live with the performance impact until it gets a real issue.

So long explanation short story. The whole thing worked out great! It took me like two to three hours to implement a first prototype. In out web application. This also includes the embedding of custom fonts into the PDF and a nice discovery of pages to render into PDF, via custom annotations using the component model meta-data facilities and a ClassTransformationWorker.

Web development can be so easy when you are using Apache Tapestry. On an earlier project we used a similar architacture with JSP and the "The Flying Saucer". I guess it took us ten times the effort to establish an equal infrastructure using JSF and the Java Servlet API ...

Due to the generosity of Google I got a nice Google wave test account. Now I am looking desperately to some spare time to evaluate the integration of jaev to the wave. One idea is to expand the validation to wave addresses via the wave protocol. Maybe an online validation as wave bot is another exciting idea.

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 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 ...

The second release candidate was built this afternoon. It contains some fixes and some improvements suggested by PMD and Findbugs. Another major focus was to improve the performance of jaev. This was achieved in reducing the number DNS lookups by introducing a cache for DNS MX record resolution.

This may lead to another nifty feature in the next release candidate, final or 1.1 release. I am planning to introduce a domain suggest function. This may be achieved by using a fix/initial suggestion list and the queries against the DNS lookup cache. If everything works out well the i.e. the Tapestry 5 example may offer a suggest function for e-mail addresses.

I'am using log4j for quite a while. I am not sure when the framework was created by Ceki Gülcü, but log4j was the straight edge for java logging in the recent years. Unfortunately it became very quite around the log4j project recently.

Recently I discovered something new about a thing I am using on an every day basis like most of the software engineers. It's about logging. You may ask: "What is so exiting about logging?"
In my opinion logging is one of the underestimated aspects of software development. Everyone uses it, but only very few are using it right.
Logging is the bridge between the development phase and the operational phase in the software life cycle. If you do it right it may provide valuable informations about the inner workings of an application.

I'am using log4j for quite a while. I am not sure when the framework was created by Ceki Gülcü, but log4j was the straight edge for java logging for the recent years. Unfortunately it became very quite around the log4j project recently.

In my new open source project I broke some new grounds. It started with the simple logging for java (slf4j), which I used for logging. The motivation was clear, I wanted to get rid of a dedicated logger implementation and offer the possibility to integrate the output of jaev logging into the application log files (streams).
The sl4j is not the first "meta" logging library. The commons logging framework was one of the first of these frameworks. At least it's the one I came across most. The sl4j framework is quite new. It offers a similar functionality like the commons logging framework, but slf4j uses a static binding against the executing logging framework. It also supports various logger implementations and offers bridges from i.e. the JUL (java.util.logging) logging into the sl4j world. So you can integrate all logging informations in the sl4j infrastructure.

This is quite handy if you are combining frameworks which rely on a specific logger implementation (i.e. facelets which relies on JUL). When you use the JUL to slf4j bridge you may merge all logging streams and handle the events on you logger implementations. The slf4j framework by the way was created by Ceki Gülcü.

One other word to the logger implementation. Durning my first steps with slf4j I used the log4j implementation. Which works pretty well. But in last weeks I stumbled about the logback project, an offspring of Ceki Gülcü too. The logback project is a native implementation of the slf4j API and it offers a state of the art logger implementation. If you are using log4j you feel familiar in no time. But it also offers quite some interesting new features and continues the evolution which stalled at the log4j project for quite some years. Here are some highlights:

• Configuration fully in XML via logback.xml and read automatically on logging initialisation.
• Different configuration files for productive and test environment (logback.xml and logback-test.xml).
• Configuration via JMX possible.
• Quite handy reduction of the logger name length.
• Provides position informations of the caller (class, line, method).
• Shortened stack traces of exceptions

It took not very long to convince me to switch my logging implementation from log4j to logback for the jaev project.

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.