Tracking change and innovation in the enterprise software development community
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
Defy all
Challenges.
Microsoft®
Visual Studio
2008
Testing Tools to
Support Agile
Software Delivery
Whitepaper
Posted by James Kao on Apr 17, 2007 08:45 AM
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.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.
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!
Agile Development: A Manager’s Roadmap for Success
Tutorial: Expand the capabilities of your Tomcat Web server
Offshore software development: Making it a success with Agile Practices
Lean Software Development Governance, a whitepaper by Per Kroll and Scott Ambler
Webcast: Applying lean thinking to the governance of software development
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.
UI? It's command line unless you use the Eclipse plugin or Netbeans.
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 :)
>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!
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...).
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.
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.
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.
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.
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.
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.
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:
scriptlandia.blogspot.com/2007/03/building-gui-...
It does help for the following archetypes:
- standard Maven 2 distribution contains 5 archetypes;
- AppFuse 2.0 project;
- WebTide;
- JPA 101.
Aptana RadRails: An IDE for Rails Development by Javier Ramírez discusses the latest Aptana RadRails IDE, a development environment for creating Ruby on Rails applications.
Cliff Click discusses how to optimize generated bytecode for running on the JVM. Click analyzes and reports on several JVM languages and shows several places where they could increase performance.
Scott Ambler, Practice Lead for Agile Development at IBM, speaks on the current status of the Agile community and practices having a look at the perspective of the Agile’s future.
Dave Nicolette and Karl Scotland try to introduce non-technical managers to one of the most popular Agile development techniques: Test-Driven Development (TDD).
Smooks is best known for its transformation capabilities, but in this article Tom Fennelly describes how you can also use it for structured event streaming.
Successful architectures evolve over time to meet changing business requirements. Luke Hohmann presents how to collaborate with key members of your business to manage architectural changes.
In this article, Dr. Tobias Komischke explains how colors used in a GUI can influence our interaction with a computer and offers advice on using the appropriate colors for the interface.
In his presentation, recorded at QCon San Francisco, MuleSource architect Dan Diephouse explores ways to use the Atom Publishing Protocol (AtomPub) when building services in a RESTful way.
11 comments
Reply