Thursday, June 24, 2010

Preview of Maven 3 feature's

Maven 3 is promising to be the most significant upgrade since the release of Maven 2. While maintaining backward compatibility with existing Maven 2 projects, it introduces a number of powerful and compelling new features, such as a complete rewrite of the internal architecture, OSGi support and multi-language pom files.

One exciting new feature in Maven 3 is it's ability to work with pom files written in non-XML notations. The Maven core now provides an underlying DSL to access the Maven internals, and write POM files in the language of your choice. This currently includes scripting languages like Groovy, Ruby, and others.

With Maven 3, you can use a Groovy DSL that maps directly to the XML pom format. So, instead of

<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.5</version>
<scope>test</scope>
</dependency>



you could write:

dependencies {
dependency { groupId 'junit'; artifactId 'junit'; version '4.7'; scope 'test' }
}


If you're familiar with the XML pom files, this will read pretty easily - it's essentially an XML pom file without the noise generated by the XML tags. Although it's an obvious improvement, some of the transcribed Groovy DSL code might still seem a bit wordy to some. For example, a set of project dependencies might look like this:

dependencies {
dependency {
groupId 'junit'
artifactId 'junit'
version '4.7'
scope 'test'
}
dependency {
groupId 'org.hamcrest'
artifactId 'hamcrest-all'
version '1.1'
}
dependency {
groupId 'log4j'
artifactId 'log4j'
version '1.2.12'
}
}
However, you can make this more concise simply by using semi-colons to separate the dependency elements:

dependencies {
dependency { groupId 'junit'; artifactId 'junit'; version '4.7'; scope 'test' }
dependency { groupId 'org.hamcrest'; artifactId 'hamcrest-all'; version '1.1' }
dependency { groupId 'log4j'; artifactId 'log4j'; version '1.2.12' }
}

This is certainly more concise and more readable, and goes with the general tendancy of moving away from XML as a build scripting language in favour of more lightweight notations. But the real power of this is that it is effectively an interface to the Maven 3 core, that gives you full access to all of the Maven features. The Maven 3 core is rock solid, and you can leverage all the existing features and plugins from the Maven 2 ecosphere.

Maven 3 is fully backward-compatible with your existing Maven 2 projects. Here's some good sites to get more information about Maven 3.

http://stackoverflow.com/questions/1414618/good-learning-resources-for-maven-3-mercury

Wednesday, June 2, 2010

EJB3 & EJB 3.1 and Spring Framework

In this article i;m trying to compare what EJB 3.1 and spring framework have in common, if at all? and whether Sun did a mistake by releasing EJB 3.0 spec? So the real question is if application are using EJb 2.1, should they migrate to EJb 3 or EJB 3.1? Or remove ejb's and use Spring framework to do everything...

well, It turned out, that both components models are surprisingly similar. You could migrate an EJB 3.1 based application, almost without any additional effort to Spring (search and replace for annotations). It is even possible to run an EJB 3.1 applications without ANY modification just tweaking Spring a bit.

Although both technologies are almost identical from the programming model perspective - the philosophy is totally different. Spring "is not just a framework", rather than complete solution - the full stack. Spring was architected as a layer above the actual application server. The idea: you can upgrade your APIs updating Spring and not touching the application server. The DI model is just a tiny part of spring framework, and now REST support in Spring MVC and so n so forth..

The philosophy of EJB 3.1 is exactly the opposite. It is not a complete solution, rather than "only" a component model for transactional, serverside applications. It comes with a set of suitable conventions, so you don't have to configure anything an rely on the existing conventions.Neither annotations (except @Stateless), nor XML-configuration is needed. The EJB infrastructure has to be available at the application server - so you only have to deploy your application - without the EJB-"framework" (Glassfish EJB 3 container is about 700kB) bits. The DI are not as sophisticated as Spring's, JSR-299 or JSR-330