Book Review: Maven: The Definitive Guide

Sonatype recently released its 0.5 version of its Maven Book - Maven: The Definitive Guide.The print edition published by O'Reilly, the printable PDF published by Sonatype is available as a free download! I went thorough the book quickly and here is my first hand impression. The books is also available for online reading.

Cool!

I have been using Maven now for quite sometime, and I was very happy to read the book. The book is a fit-for-all, who wants to use maven in someway or other.

It starts with as simple as downloading and installing maven, to explaining the core basics of maven, its dependency management, plugins etc, to optimizing plugins and POMS. It serves as a tutorial as well as a reference guide for Maven.
The book explains concept with ample examples. It also covers to explain some of the most useful plugins in depth. It explains the maven build cycle in depth, build profiles, maven assemblies, site generation and maven repositories, m2eclipse and nexus at depth. It also explains customizing plugins and also on writing our own plugins.

How to use the book

An extract:

This book is divided into three parts: Introductory Material, Part I, “Maven by Example”, and Part II, “Maven Reference”. The introductory material consists of two chapters: Chapter 1, Introducing Apache Maven and Chapter 2, Installing and Running Maven. Part I, “Maven by Example” introduces Maven by developing some real examples and walking you through the structure of those examples providing motivation and explanation along the way. If you are new to Maven, start with Part I, “Maven by Example”. Part II, “Maven Reference” is less introduction than reference, each chapter in Part II, “Maven Reference” deals with a focused topic and dives into as much detail as possible about each topic. For example, the Chapter 17, Writing Plugins chapter in Part II, “Maven Reference” deals with writing plugins by providing a few examples and a series of lists and tables.

While both Part I, “Maven by Example” and Part II, “Maven Reference” provide explanation, each part takes a different strategy. Where Part I, “Maven by Example” focuses on the context of a Maven project, Part II, “Maven Reference” focuses on a single topic. You can skip around in the book, Part I, “Maven by Example” is by no means a prerequisite for Part II, “Maven Reference”, but you'll have a better appreciation for Part II, “Maven Reference” if you read through Part I, “Maven by Example”. Maven is best learned by example, but once you've gone through the examples, you are going to need a good reference to start customizing Maven for your own environment.

Kudos

The work is excellent and what makes it even better is the fact that the company and the authors do not consider it complete yet! Its a beta 0.5. This is what they have to say on it:

If this book moves out of Beta, we're essentially saying that there is no more content to add and nothing is going to change. I've always thought that good books evolve over time and that they live beyond the confines of the chapters and sections that define them. A good book is an ongoing conversation and a series of interactions not just between authors and readers, but of lateral interactions between readers. That was a fancy way of saying that the book is a community.

Sonatype and the book authors have done an excellent job. I would recommend the book to anyone who uses Maven.

Flex Clients for OSGi apps

As I continued to work on OSGi based web apps, there was rising demands from our clients and partners about supporting Flex clients in future. I took a lead to evaluate our existing architecture consisting mainly of POJOs, supported with Spring and OSGi.

Thanks to the documentation at BlazeDS site and the refcard at DZone for helping me out. I am almost ignorant of Flex programming, but still I could make out few things. Here is my first-cut evaluation.

Flex and Java with POJO

I was happy to learn that with Spring's hailed paradigm of programming with interfaces and POJOs would make integration with Flex very simple, and would hardly require any change in how we program and architect our application.

Flex has strong ties to Java. Its server BlazeDS is based on Java remoting. Good news that with Spring BlazeDS, we can reuse our interfaces and its POJO implementations.

Spring BlazeDS as described by SpringSource:

Spring BlazeDS Integration is a new addition to the Spring portfolio, and a component of the complete Spring Web stack. This project's purpose is to make it easier to build Spring-powered Rich Internet Applications using Adobe Flex as the front-end client. It aims to achieve this purpose by providing first-class support for using the open source Adobe BlazeDS project and its powerful remoting and messaging facilities in combination with the familiar Spring programming model.

Blaze DS is based on Java remoting and web messaging from Adobe. Its primary purpose of existence is easier integration of Adobe Flex/Adobe AIR with existing Java code to create Rich Internet Applications (RIA). Spring BlazeDS leverages more on this end by its dependency injection, and simpler integration platform.

Blaze DS can be set to run on any web container such as Tomcat. It listens to a particular URL for client requests and processes them. Flex clients connect to the Blaze DS server and executes Java methods. The base transport protocol will be HTTP.

The regular client calls with Blaze DS is usually handled by a Servlet from Blaze DS. However, when Spring Blaze DS comes into picture, this is replaced by the Spring's Spring MVC Servlet, so that Spring can intercept those client calls.

Flex works on the concept of message broker. A class that will can handle client calls. The clients calls will be routed to the message broker through additional configuration specific to Blaze DS. We should be happy to expose our interfaces and its implementation classes to work as message brokers.

A sample Spring's application-context.xml file

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:flex="http://www.springframework.org/schema/flex"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/flex
http://www.springframework.org/schema/flex/spring-flex-1.0.xsd">
<!-- Spring Beans's -->
<bean id="myService" class="MyServiceImpl" />
<!-- Simplest possible message broker -->
<flex:message-broker />
<!-- exposes myService as BlazeDS destination -->
<flex:remote-service ref="myService" />
</beans>

The point to be noted above is that myService can be given any reference, including a reference to any OSGi service.

Another notable point about Spring BlazeDS Integration is that Flex can support authentication, that can easily plug in with Spring Security.

Kudos

Spring BlazeDS has not yet had its final release, but indeed a great work from Spring guys to help lift existing POJO based applications to work with Flex clients in most non-intrusive manner.

Guice getting into Java SE?

One day I may use @javax.inject.Inject as my regular Java annotation! Yes, dependency injection with annotations might become a standard Java API. Google Guice and SpringSource have partnered to standardize a proven, non-controversial set of annotations that make injectable classes portable across frameworks. The JSR has been proposed.

Read more about this at the official Google Code Blog.