Maven is such a great tool for building java projects taking care especially of the dependencies. It has became a fondamental tool for my working projects. It is so versatile, you don’t have to worry about where to find the jars of the libraries you want but what makes it even better is that you do not have to worry about their dipendencies. These dependencies most of the case will require other dependencies and there are quite frequent situation where jar A requests jar B which will request jar C which would need jar A, the so called circular-dependencies. Maven does all this for you.
Nevertheless I find setting up a maven project somehow. There have been cases where I had to import a project from a collegue of mine while we had to work on the same project or me taking over the collegue. It happened that my collegue settings were not valid for me. Eclipse keept complaining about missing jars, not being able to download them and so forth. I had a lot of headaches trying to clean the apparent mess.
To start understanding maven we should understand its core, we should undersand the anatomy of a pom.xml file. I will use here what I mainly use in my everyday
I will take for granted that you have maven running on your environment and have settings.xml clean and functional as well as you are running on Eclipse with m2eclipse plugin configured.
Let’s start looking how a pom.xml file is structured and my project. When it is first create the pom.xml includes the junit.jar dependency which is needed for unit test.
<name>Maven Quick Start Archetype</name>
- modelVersion This element indicates what version of the object model this POM is using.
- groupId This element indicates the unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization. For example com.myftiu.app is how my domain object are identified .
- artifactId This element indicates the unique base name of the primary artifact being generated by this project. The primary artifact for a project is typically a JAR file. Secondary artifacts like source bundles also use the artifactId as part of their final name. A typical artifact produced by Maven would have the form -.extension (in my case example, myAppName-1.0-SNAPSHOT.jar). Once maven has build the jar can make it accessible as dependency also for other projects.
- packaging This element indicates the package type to be used by this artifact (e.g. JAR, WAR, EAR, etc.). The default value for the packaging element is JAR so you do not have to specify this for most projects.
- version This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the SNAPSHOT designator in a version, which indicates that a project is in a state of development.
- name This is the top-level element in all Maven pom.xml files defines the name of the project which is the same as your Eclipse project.
- url This element indicates where the project’s site can be found.
- description This element provides a basic description of your project.
The next step is to declare the desired dependencies for the project. As mentioned earlier Maven2 implements what is called transitive dependency that is you can declare only the main libraries that you want in the project as project dependency; maven will take care by itself to include also the libraries that the desired libraries need. My webapp will be based in Spring Framework and as ORM will be used MyBatis but I will show as well a possible Hibernate configuration. The Spring configuration can be done via xml file or via annotations. There are pros and cons of chosing the configuration way. I write a post where I will show the both configuration. Here is a basic list of libraries needed for a startup project.
Spring jar and dependencies
- spring-aop: Core Spring AOP interfaces, built on AOP Alliance AOP interoperability interfaces. Any AOP Alliance MethodInterceptor is usable in Spring. Spring AOP also offers:
Spring AOP can be used programmatically or (preferably) integrated with the Spring IoC container.
- Introduction support
- A Pointcut abstraction, supporting “static” pointcuts (class and method-based) and “dynamic” pointcuts (also considering method arguments). There are currently no AOP Alliance interfaces for pointcuts.
- A full range of advice types, including around, before, after returning and throws advice.
- Extensibility allowing arbitrary custom advice types to be plugged in without modifying the core framework.
- spring-beans: contains interfaces and classes for manipulating Java beans. It is used by most other Spring packages. A BeanWrapper object may be used to set and get bean properties, singly or in bulk.
- spring-context: builds on the beans package to add support for message sources and for the Observer design pattern, and the ability for application objects to obtain resources using a consistent API
Here is how these two packages are presented in Spring Framework Documentation:
Two of the most fundamental and important packages in Spring are the org.springframework.beans and org.springframework.context packages. Code in these packages provides the basis for Spring’s Inversion of Control (alternately called Dependency Injection) features. The BeanFactory provides an advanced configuration mechanism capable of managing beans (objects) of any nature, using potentially any kind of storage facility. The ApplicationContext builds on top of the BeanFactory (it’s a subclass) and adds other functionality such as easier integration with Springs AOP features, message resource handling (for use in internationalization), event propagation, declarative mechanisms to create the ApplicationContext and optional parent contexts, and application-layer specific contexts such as the WebApplicationContext, among other enhancements.
In short, the BeanFactory provides the configuration framework and basic functionality, while the ApplicationContext adds enhanced capabilities to it, some of them perhaps more J2EE and enterprise-centric. In general, an ApplicationContext is a complete superset of a BeanFactory, and any description of BeanFactory capabilities and behavior should be considered to apply to ApplicationContexts as well.
- spring-core: provides basic classes for exception handling and version detection, and other core helpers that are not specific to any part of the framework.
- spring-aspects: Spring Data Binding framework, an internal library used by Spring Web Flow
- spring-orm: Root package for Spring’s O/R Mapping integration classes and supporting Hibernate, JPA, JDO, and iBATIS SQL Maps
- spring-web: Spring’s core web support packages, for any kind of web environment. It contains common, generic interfaces that define minimal boundary points between Spring’s web infrastructure and other framework modules
- spring-tx: Spring’s transaction infrastructure. Also includes DAO support and JCA (J2EE Connector Architecture) integration
- spring-webmvc: Spring’s MVC framework in its Servlet API version
Commons jar dependencies
- commons-digester: the package lets you configure an XML -> Java object mapping module
- commons-pool: defines a handful of pooling interfaces and some base classes that may be useful when creating new pool implementations
- commons-dbcp: relies on code in the commons-pool package to provide the underlying object pool mechanisms that it utilizes
- commons-lang: provides a host of helper utilities for the java.lang API, notably String manipulation methods, basic numerical methods, object reflection, concurrency, creation and serialization and System properties. Additionally it contains basic enhancements to java.util.Date and a series of utilities dedicated to help with building methods, such as hashCode, toString and equals
- commons-logging: an ultra-thin bridge between different logging implementations. A library that uses the commons-logging API can be used with any logging implementation at runtime. Commons-logging comes with support for a number of popular logging implementations, and writing adapters for others is a reasonably simple task
- commons-beanutils: component provides easy-to-use wrappers in order to dynamically access to Java object properties (without compiled-in knowledge of the property getter and setter methods to be called) when needed
- commons-collections: provides a large number of classes to aid day to day programming
- commons-el: EL is the JSP 2.0 Expression Language Interpreter from Apache
MyBatisjar and dependencies
- myBatis: main library that includes all the classes that will facilitate the storage and retrive of the object as well as guarantee the data persistence.
- mybatis-spring: helps you integrate your MyBatis code seamlessly with Spring. Using the classes in this library, Spring will load the necessary MyBatis factory and session classes for you. This library also provides an easy way to inject MyBatis data mappers into your service beans. Finally, MyBatis-Spring will handle transactions and translate MyBatis exceptions into Spring DataAccessExceptions.
The version found right now on the repos is 1.0.0 but I had problems with such version when including mappers. It seems that there is a bug in that version which has been resolved on 1.0.1 as stated here.
Hibernate jar and dependencies
- hibernate3: main hibernate module facilitates the storage and retrieval of Java domain objects via Object/Relational Mapping
- hibernate-validator: bean validator
- hibernate-search: it indexes your domain model with the help of a few annotations, takes care of database/index synchronization and brings back regular managed objects from free text queries
- hibernate-annotations: provides annotation-based mapping metadata that governs the transformation of data from one representation to the other
- persistence-api: Java programming language framework managing relational data in applications using Java Platform, Standard Edition and Java Platform, Enterprise Edition.
- cglib: a Spring dependency that has to be explicitally defined because is marked as optional dependency. It is a Code Generation Library, used to extend JAVA classes and implements interfaces at runtime. Spring uses it to generate a class at runtime
- jta : allowes distributed transactions to be done across multiple XA resources in a Java environment
- slf4j-api: spring dependency for logging
To use Spring with ExtJs I will use DWR (Direct Web Remotig). Such frameworks can proxy spring methods to ExtJs.
Maven as stated in the web page is a plugin execution framework; all work is done by plugins. There are plugins for almost everything. In my project I use mostly the plugin’s from Mojo
- dwr 3.0.M1 a strage behaviour happed while I included this library to my pom. I wanted to include the latest version 3.0.RC but there seems to be an invalid link to such version because I did not show up on the maven dependencies link. Such behavior created me a lot of trouble and I lost a lot of time searching for the problems on other direction before I realised that the library was missing. Actually I think it is always a good behaviour controll that all the jars required are present. Quite frequently happens that maven won’t donwload the jars.
<!-- put your configurations here -->
In order to have a better way of controlling versioning I prefer using the centralized versioning rather than declaring version for each jar.