Experiences with Maven?

[Lasse Koskela]

I'd like to do a quick poll about how many people in here are using Ant versus Maven, and if you're using Maven, I'd like to know what you think of it?

Somehow, I feel like Maven's features added on top of Ant's are not really too valuable compared to the added complexity of setting up and using Maven?

[Daniel Mayer]

We are using Ant. We looked into using Maven, but it looked like it would have constrained our projects structure in ways we didn't like.

My personal impression was that Maven had a lot of followership working on adding bells and whistles, but not many people interested in making it a solid, flexible solution for "enterprise sized" systems...

[Bear Bibeault]

Ant here. Also decided that Maven was just too complex/constraining.

[David Hibbs]

Ant here too. Too constraining was part, but not the big problem.

The big problem was having to teach all the developers another markup/tool to lay out their projects.

For a managed/scheduled build system with logs, I went with Anthill because it's a lot easier to figure out what to put in a labelled text box than to start writing with an XML editor or text pad and try to get it all right!

If you have a single project that will have a long lifespan, maybe they're nicer since you can add the bells and whistles...

[Lasse Koskela]

Originally posted by David Hibbs:
For a managed/scheduled build system with logs, I went with Anthill because it's a lot easier to figure out what to put in a labelled text box than to start writing with an XML editor or text pad and try to get it all right!

If you're referring to CruiseControl's log file, I hope I can make the world a bit better place along with my CruiseControl tutorial due out in September's issue of the journal

[David Hibbs]

Originally posted by Lasse Koskela:
If you're referring to CruiseControl's log file, I hope I can make the world a bit better place along with my CruiseControl tutorial due out in September's issue of the journal

A pretty good description. I learned of CC via an article in the WSDJ which was very similar. BUT... no, I'm not referring to the log. I'm referring to the actual configuration -- the section in your article headed "Configuring CruiseControl" =)

As you noted in the intro, "AntHill is not as common as CruiseControl, but it is often quoted as being significantly easier to set up and use than CruiseControl."

You can either directly create or edit the XML file or you can use a GUI.

There were several other weaknesses besides the XML setup I didn't like, too. Some of these may have been fixed.
a) Had to do a manual check-out to start the process
b) Had to run multiple copies of CC for multiple projects.
c) Had to manually start CC rather than having it start as a service (i.e. type 'cruisecontrol' at a command prompt)
d) Project dependencies didn't exist/work, because of (b).

The logs and web site are very nice, though, I must admit.

Frankly, I had considered building a web admin interface for the setup. But then I found b-d and AntHill.

For a group of developers that were/(are?) averse to doing extra work to set up a continuous integration loop, AntHill was the hands-down winner in my book.

[Lasse Koskela]

Originally posted by David Hibbs:
a) Had to do a manual check-out to start the process

True, although this shouldn't be too difficult to fix so I'm sure it will get better.

Originally posted by David Hibbs:
b) Had to run multiple copies of CC for multiple projects.

Has been fixed.

Originally posted by David Hibbs:
c) Had to manually start CC rather than having it start as a service (i.e. type 'cruisecontrol' at a command prompt)

True, it's a shame a Windows service installer isn't included in the standard distribution... However, you can do it yourself -- wait for Part 2 of the tutorial

Originally posted by David Hibbs:
d) Project dependencies didn't exist/work, because of (b).

I'm not sure what you mean by project dependencies, but nowadays you can run a build based on whether another project (not necessarily under the same CC instance's control) has done a new successful build. I haven't used the triggering feature myself so I don't know how well it works, though.

Originally posted by David Hibbs:
The logs and web site are very nice, though, I must admit.

I'm not quite sure if I agree here. While I do think the reporting application is worth its salt, it could be a lot better. I've also considered multiple times of making certain small enhancements to the technical implementation and usability of the reporting app. I'm not sure whether I'll ever be able to actually make it happen, of course...

[K Kernes]

Our project has been using Maven for about 6 months now and for the most part we really like it. It allows for quite a bit of flexibility, allows for easier configuration of routine tasks and relatively easy modification of dependencies, etc. The project.xml specification is a bit weak, so there are occasionally problems figuring out how to accomplish some tasks the first time around.
We use multiple project.xml files to manage the independent portions of our project with a master project to build all of the sub projects and run all of the unit tests.

Though there have been some challenges, but overall we've had pretty good luck with Maven. If you're willing to get past your hesitations at learning a new tool and take time to figure out all the rules, it's a great tool.

[Lasse Koskela]

Originally posted by K Kernes:
Though there have been some challenges, but overall we've had pretty good luck with Maven. If you're willing to get past your hesitations at learning a new tool and take time to figure out all the rules, it's a great tool.

Would you happen to have any tips regarding good tutorials or books on the subject? (I guess there aren't many, yet)

[Ilja Preuss]

Originally posted by K Kernes:
Our project has been using Maven for about 6 months now and for the most part we really like it. It allows for quite a bit of flexibility, allows for easier configuration of routine tasks and relatively easy modification of dependencies, etc. The project.xml specification is a bit weak, so there are occasionally problems figuring out how to accomplish some tasks the first time around.
We use multiple project.xml files to manage the independent portions of our project with a master project to build all of the sub projects and run all of the unit tests.

Though there have been some challenges, but overall we've had pretty good luck with Maven. If you're willing to get past your hesitations at learning a new tool and take time to figure out all the rules, it's a great tool.

Interesting report - can you tell us a little bit more about the project? What exactly does Maven do for you?

[David Hibbs]

Originally posted by K Kernes:
If you're willing to get past your hesitations at learning a new tool and take time to figure out all the rules, it's a great tool.

Herein lies the problem -- not in the hesitations, but in figuring out all the rules and then communicating them to all the other developers. We don't have time for every developer to sit and figure out the rules. What it really needs is a simple admin interface.

[K Kernes]

While there aren't many books on Maven, the online documentation is reasonably good. We experimented with the tool a bit before we implemented it for the entire project. Because Maven can be run on a current project without undoing your current build processes, it's pretty easy to use it with no harm until you get up to speed.

Our project consists of multiple independent modules that must be integrated into a whole. As a result, we use Mavens multi-project capabilities and the jar repository to save ourselves work. Also, of particular importance is the site documentation capabilities that allow us to easily post all of our Javadocs, metrics, unit tests, etc. in a simple and consistent manner that is easily accessible by all of the engineering and management team.

One of the other things that is very nice about Maven is the fact that the lower level project.xml files can inherit from higher level ones. In our case we're using a main project.xml for the entire project and then an individual project.xml file for each of the main components of the project. For the most part the only thing the component level files need to describe is the dependencies and resources they require for building and test. It actually simplifies the process a lot and makes it possible to create a template for a new component that is nearly empty and requires only that the developer fill in the descriptions of what their component needs independent of the rest of the project.

[Ilja Preuss]

Originally posted by K Kernes:
One of the other things that is very nice about Maven is the fact that the lower level project.xml files can inherit from higher level ones.

Of course Ant can do that, too...