Catching Up with Maven 2

Posted by James Kao on Apr 17, 2007 08:45 AM

Community

Java

Topics

Build systems

Tags

Maven ,

Java EE ,

Ant

Maven is a pattern-based build framework for Java and J2EE projects; more than just scripting builds for arbitrary projects, Maven knows about J2EE, Struts, Hibernate, etc. and has a prescribed way of structuring and organizing a project from its moment of creation through testing, packaging, and deployment. The Maven authors (in the book "Better Builds With Maven",) describe their project:

Maven encompasses a set of build standards, an artifact repository model, and a software engine that manages and describes projects. It defines a standard life cycle for building, testing, and deploying project artifacts. It provides a framework that enables easy reuse of common build logic for all projects following Maven's standards. The Maven project at the Apache Software Foundation is an open source community which produces software tools that understand a common declarative Project Object Model (POM).

The Maven folks have an agreement with ibiblio, which hosts all of the files related to supported dependencies, such that a default installation can remotely populate all of the files it needs from a known repository (a mechanism reminiscent of Gem except in a build-centric way). With so much built-in magic, Maven-based projects can be almost deceptively easy to start but have enough going on under the hood to warrant a 292 page book. Given its ambitious scope, Maven has engendered some pretty strong feelings in the past that the development team has worked to address:

Maven's best practices often don't address corporate real world headaches. Even when I agree with them I bump up against the problems inherent with what an existing corporate practise and/or current tool sets.

Just this week, Matt Raible reported on his experience migrating AppFuse from Ant to Maven:

One of the most interesting things about moving to Maven is we were easily able to make AppFuse more like a framework than a project starter kit. We thought this is what most folks wanted - especially the ability to upgrade a project to the latest version of AppFuse. While some folks wanted this, it seems like most folks liked the full-source version that was a pain-in-the-ass to upgrade. I don't blame them.

Of course, the real benefits of moving to Maven are elsewhere. We've seen quite an uptick on the mailing list in the last few months. There's tools cropping up and I've gotten quite a few inquiries about training (yes, I do have a 3-day course on Spring, Hibernate, Ajax, Maven and AppFuse). To me, AppFuse 2.x seems more complicated than 1.x, but it seems the community thinks otherwise. Judging from the increased amount of developer activity on the project, developers seem more interested in a Maven-based system too. Then again, we are making Maven work!

Since the release of Maven 2, updates (up to the recent 2.0.6 release) have consistently provided bug fixes and incremental improvements to the usability of the core engine. The repository is also frequently updated with the most up-to-date support for common dependencies like Spring and Tomcat, as well as less common ones like openid4java and mule. Earlier this year, lead committers Jason Van Zyl and John Casey left Mergere, a leading sponsor and commercial provider of support for Maven, but continue to participate actively in development.

1. Back to top

   Not there yet...

   Apr 17, 2007 5:05 PM by Dominic Mitchell

   Interesting. I've just been playing with Maven yesterday. Summary: fantastic concepts, but the UI needs some serious work. e.g. I love the concept of an archetype, but there's no way in hell I could ever remember the command to make one without looking it up. And the mvn tool doesn't provide any help.

   Reply

2. Back to top

   Re: Not there yet...

   Apr 17, 2007 8:35 PM by Andrew Clifford

   UI? It's command line unless you use the Eclipse plugin or Netbeans.

   Reply

3. Back to top

   Re: Not there yet...

   Apr 18, 2007 2:36 AM by Stuart McCulloch

   Yes, the archetype command can really get cumbersome - which is why I provide a maven plugin along with my OSGi archetypes to provide a simpler interface: Pax-Construct. See the example for how simple maven archetype commands can be, if people provide the right plugins. ( although, like many maven projects, I still need to write more documentation :)

   Reply

4. Back to top

   a simple crash

   Apr 18, 2007 4:47 AM by Shahzad Ismail

   >mvn archetype:create -DgroupId=com.company -DartifactId=my_app -DarchetypeArtifactId=maven-archetype-j2ee-simple my_app>mvn idea:idea CRASH! Reason: first command created a couple of modules except site module but all the modules including site module is defined in top level pom.xml!

   Reply

5. Back to top

   Re: a simple crash

   Apr 18, 2007 5:07 AM by michele michele

   I used Maven2 in some past projects: it was a hell! The idea is very good, but the implementation is bad! I encountered many bugs too. Moreover it is too slow to compile (even if the dependency jars are stored in the local repo and used the appropriate command flags...).

   Reply

6. Back to top

   Re: Not there yet...

   Apr 18, 2007 7:47 AM by Dominic Mitchell

   Yes, the command line is a UI. It might be graphical, but it's still there. In fact, it's often a lot quicker at getting things done than mousing around in an IDE. And the command line interface to Maven2 really sucks in a few important ways.

   • Unhelpful
   • Bad error reporting
   • Too verbose
   • No ability to list installed plugins, or query them for their parameters.

   I've tried the Eclipse plugin, and what it does, it does well. But I couldn't find a way to get it to do archetypes easily.

   Reply

7. Back to top

   Maven1 was good and very promising but Maven 2 came out...

   Apr 18, 2007 9:04 AM by Alexis Midon

   Few months ago Zarar wrote a very good article explaining the pros and cons of Maven. Being myself migrating a multi-component project (more than 30 modules), I couldn't agree more with Zarar: this is a nightmare. Dependency management, conventions, components & co are great idea but the implementation is too bad, so strict. I really think dropping Jelly was their worst idea. Now, with Maven2, the simple copy of a poor file located outside the default layout is nearly impossible except if you're ready to write an ant file and the maven-ant-plugin (Zarar details how great this plugin is...). And this is just an example among many others. Maven does not replace Ant, you will just get: Maven + Ant + the integration pain + custom plugin development. is it worth it? So I think Maven2 suits small, new projects with no legacy constraints, nor peculiarities. Maven1 was far better, a great blend of the Maven concepts and the scripting power/flexibility of Jelly. If you're looking for a build framework, you get Maven and Rake. If you're using Xml, you suffer a lack of concision. If you're talking about scipting and flexibility, you mean Ruby (for instance). And here is the innovative idea of Raven: build your java projects with rake, leveraging Ruby, Rake, gem and so on. Have a look, it's very attractive! ps: Shahzad, in my personal case, compilation was faster with Maven2.

   Reply

8. Back to top

   Re: Not there yet...

   Apr 18, 2007 10:15 AM by Jason van Zyl

   The IDEs are definitely the way to go. The Netbeans and Eclipse Integration have Wizards that collect information and then use Archetype in the background. We are also trying to add some simple interactivity to the command line so make it easier to select Archetypes.

   Reply

9. Back to top

   Re: Maven1 was good and very promising but Maven 2 came out...

   Apr 18, 2007 6:25 PM by Andrew Clifford

   I had to deal with Maven1 only because some Apache projects required it. I would not recommend it over Ant. Maven2 is better where I would recommend it. I have converted over 30 projects in my company's code base to Maven2 with only accolades from developers. I don't use archetypes because the jar and war deployment structures are all I need and its just as easy to copy and edit an exsting pom.xml. I haven't written or run an ant script in months. Converting to the conventions of Maven2 is required and there is a learning curve but the documentation is getting better.

   Reply

10. Back to top

    Re: Maven1 was good and very promising but Maven 2 came out...

    Apr 19, 2007 2:28 AM by Alexis Midon

    Don't get me wrong Andrew. As a developer, I love Maven (1 or 2). It's clear, easy to use, conventions avoid many headaches, etc. I agree with you, but I can't agree when you say "Converting to the conventions of Maven2 is required". Of course you must do your best to respect conventions, but when you have to deal with more global projects (Java or not), when your Maven build (1 or 50 components) is just a tiny part of higher build with dependencies, Maven conventions might clashed with other system conventions/requirements. And this is why exceptions must be easily handled by a build fwk, which is not exactly the case of Maven 2 IMHO.

    Reply

11. Back to top

    Re: Not there yet...

    Apr 19, 2007 9:13 AM by Alexander Shvets

    Hi, yes, maven is not too convenient with archetypes. You need to provide/remember a lot of information as input. I wrote simple beanshell script that does it for you. You can see details on my blog: http://scriptlandia.blogspot.com/2007/03/building-gui-frontend-for-maven2.html It does help for the following archetypes: - standard Maven 2 distribution contains 5 archetypes; - AppFuse 2.0 project; - WebTide; - JPA 101.

    Reply

12. Back to top

    AppFuse, Maven 2, ICEfaces

    Feb 14, 2009 2:06 PM by Rainer Eschen

    Matt did a good job on using Maven 2 with AppFuse. It helped me to add ICEfaces support within two days to one of the archetypes AppFuse delivers (and that are now also part of the Maven 2 plugin for Eclipse): http://icefusion.googlecode.com/ There's one thing left that's really annoying with Maven 2: the online repositories are pretty late with offering new releases of artefacts you use as your project's dependencies. Would be nice if the process for doing such updates would be more straight forward.

    Reply

• Older >