Why Maven?

[Stan Sokolov]

Hype around Maven is getting momentum. All "wise guys" seems to be jumping in Maven camp? Is it really as good as people claim or it is another "I want to be cool" type of technology? Looking at the documents I found that there is no direct compatibility between Ant and Maven. just some weak plugins that do not do much. So any thought why someone who has a working ANT build would go into the Maven camp ? Any benefits except new line in resume ? What about Gradle? Is it dead on arrival or still has a chance ? At least gradle and ANT are friends when Maven is a completely different animal.

[Tim Holloway]

Maven is probably the most-commonly used build system for open-source java projects, although not everyone loves it. Tomcat is built by Ant, IIRC.

Maven's primary advantages are these:

1. Standardized project layout. Whether you like their layout or not, you can depend on knowing where the parts that make up a project are. For open-source projects that have multiple people around the world moving in and out of development and for people who just want to peek at stuff without getting bogged down in details, this can be invaluable.

2. Automated fetching and resolving of dependencies. Ant can't do this unassisted.

3. Version conflict reduction. Since Maven is based on the idea of producing fixed, immutable versions, you don't have issues where people made "just one little change" to the distributed dependencies (for the most part).

Ant is more flexible and there's less "magic". You can look at an Ant build.xml and tell exactly what you can do with it. Maven has goals, and there's no way in Maven 2 to get a definitive list of what goals will work on a given project. On the other hand, the number of goals available "out of the box" or with little additional configuration is pretty large. And, back when I used Ant more regularly, one of my problems was that my different Ant scripts were stuck at different points in time, as I refined them. Maven projects tend to be more stable, since I didn't have to add new build steps - just declarations if/as needed.

[Peter Johnson]

I'll add to Tim's list:

4. Automatic dependency handling. Simply list the immediate dependencies for your code an Maven does the rest. Including downloading them for you and building classpaths. You no longer will have to manually gather the JARs you need to compile or run your code.

5. Automated application of best practices for building xxx. What are the best practices in your shop for creating a JAR or WAR? You can configure all of that into a parent POM and then have every such project automatically use the best practices. You can accomplish a similar think by having a common ant script that other ant scripts include, but the Maven approach is somewhat simpler and yet more powerful.

6. Binary repository. You will need a separate app for this, such as Nexus or Artifactory. But by setting one up you can place all of your artifacts (WARs, JARs, EARs) into your repository and share those among your teams in much the same way the open source community uses the maven Central repository to share open source JARs.

[Stan Sokolov]

As much as I look at Maven the more it stinks to me
1. All definitions are extremely bulky. To bulky to be able to understand a flow of events. This is not the worst problem

2. Worst problem is that there is no clear flow of events. Declarations are convoluted. One type of declaration overwritten by another type (pluginManagement overwrites plugin). There is no way to determine in 5-10 minutes an entire flow of steps that will be performed for the project build. Again see item 1

3. Eclipse plugin sucks. Even worse, newer versions suck more than old ones. Idiots in charge of development and there is no competition - one plugin m2e. Take it or leave it. If you don't like idiotic "features" like
maven-dependency-plugin (goals "copy-dependencies", "unpack") is not supported by m2e.
then you better kill yourself. Why plugin developers even dare to decide which maven plugins they are supporting or not. There is nothing like this for ANT builds.

4. Too much stupid XML. I hate programming using XML. XML is not for programming. Less XML = Easy to read. Maven is all about creating monstrous XML files that is hard to read and hard to understand.

This technology will be dead in trash in 2-3 years. I remember as idiots were praising EJB. It took industry 5 years to realize how crappy EJB was until than idiots were claiming it the way to go. Maven is an EJB number 2. Than will be Agile.

P.S. I would not complain but I have to use this crap for my new project. Sitting and crying.

[Tim Holloway]

I can sympathise with you. I resisted Maven for years. Now, almost everything I build uses Maven. I have lots of complex projects these days, and the annoyances of Maven are well-compensated by its ability to maintain ( or was that coerce?) uniformity of project layouts and the fact that it handles dependencies so well.

You cannot see the build flow in Maven. Maven is "magic". I don't like magic. On the other hand, what Maven is all about is the process of producing one single component per project. Most components - JARs, WARs, EARS, have essentially the same build process, so as long as there's a Maven mojo for the target object, you no more concern yourself with the "how" of the build than you would worry about where the plumbing runs inside your coffeemaker. The build becomes a commodity, rather than a one-off process like makefiles and Ant scripts. I WOULD like to be able to enumerate what types of build goals you could use, the way Maven 1 did, but the philosophy for Maven 2+ seems to be you can build any goal that makes sense for the project - although it may require additional config in the POM.

Maven POMs can get unwieldy, but so can Ant scripts. Most of the average Maven POM, however, is dependencies. Most large-scale projects, which is what Maven excels at, have tons of dependencies, and dependencies on the dependencies, multiple levels. If you manually included all these JARs in a project, it would be a lot bigger and messier, keeping the JARs up-to-date would be harder, and you'd be more likely to experience the JAR equivalent of DLL hell.

XML isn't everyone's cup of tea. But Maven isn't a programmed build tool, it's a specification-driven build tool. Of the more common specification file formats, XML does hierarchical arrangements better than most. But the m2eclipse plugin really isn't that bad. You can do most of your POM editing using the various dialogs. I only tap into the raw XML when I'm doing copy-and-paste from other POMs.

[Peter Johnson]

You cannot see the build flow in Maven.

Actually, if you are using Maven 3.0.x, then if you run with the -X option, one of the things printed out is the build plan - look for "PROJECT BUILD PLAN" in the output. Of course, it gets lost in all the other stuff output, and the build still runs. I submitted an enhancement request to provide an abbreviated build plan report (along with some code we use in my shop to generate that report) to the Maven team.

Personally, I like the integration of m2eclipse with Eclipse, and it gets better with each release. But then I NEVER build within Eclipse - I always use the command line. (Official builds are done via Jenkins which doesn't build via Eclipse, so why should I?) Search this forum and you will find countless posts where Eclipse (or Netbeans) was being "helpful" and thus screwed up an Ant or Maven build.

But Maven is scary when you first encounter it. My recommendation is to read the two Maven docs available online:
http://monkproject.org/MONK.wiki/attachments/17620/1332
http://www.sonatype.com/books/mvnref-book/reference/
And when you are done, write a plugin. When I wrote my first plugin, a lot of Maven's idiosyncrasies suddenly made sense and the world was a beautiful place.

[Stan Sokolov]

Peter Johnson wrote:

You cannot see the build flow in Maven.

Actually, if you are using Maven 3.0.x, then if you run with the -X option, one of the things printed out is the build plan - look for "PROJECT BUILD PLAN" in the output. Of course, it gets lost in all the other stuff output, and the build still runs. I submitted an enhancement request to provide an abbreviated build plan report (along with some code we use in my shop to generate that report) to the Maven team.

Personally, I like the integration of m2eclipse with Eclipse, and it gets better with each release. But then I NEVER build within Eclipse - I always use the command line. (Official builds are done via Jenkins which doesn't build via Eclipse, so why should I?) Search this forum and you will find countless posts where Eclipse (or Netbeans) was being "helpful" and thus screwed up an Ant or Maven build.

But Maven is scary when you first encounter it. My recommendation is to read the two Maven docs available online:
http://monkproject.org/MONK.wiki/attachments/17620/1332
http://www.sonatype.com/books/mvnref-book/reference/
And when you are done, write a plugin. When I wrote my first plugin, a lot of Maven's idiosyncrasies suddenly made sense and the world was a beautiful place.

Maven is a great example of over-engineering. Simplicity of ANT is gone. Benefits ?
1. Downloading dependencies. Why ? Why dependencies have to be downloaded ? Dependencies are part of every project runtime, developers add/remove check them in SCM as need arises. Why every time build is made a time (a lot of time) should be wasted to download dependencies ? It should be done once when a new feature is added that requires dependencies and upgraded as problem detected.

2. Standardization of project structure ? Project structure for J2EE application has been standardized 10 years ago. Worked as charm in every IDE ... well until Maven was invented. Now structure of Maven project has nothing to do with the structure of WAR archive. Please look at Maven build script to figure out how files are going do be deployed. Now we need bunch of plugins to let our IDE deploy maven projects. And you know what ? forget about it. No more deployment trough IDE - straight deployment of applications to the server after waiting 30 minutes for maven build to complete. It is too hard to configure eclipse to understand structure of the large maven projects and perform a deployment. So no more testing on a local server trough the eclipse. You think that it is probably a joke? No, it is how 5000 people IT organization where I am currently employed ended up after having adopted Maven. Too bad but the architect is happy - he has a line in his resume.

3. Magic ? Maven does some magic! ... The only "magic" Maven does is transforms project structure from its own standard into J2EE standard. But why do we need Maven standard on top of J2EE standard ?

4. Separate folder for tests sources. Ohh it was so hard to exclude com.company.project.test folder from the build by using ANT. Just because somebody did not know how to configure WAR task for exclusion the whole ANT process had to be replaced.

There are 3 things I hate the most from new technologies: Maven, RESTful WS and Agile. I can talk and talk about how stupid these things are....

P.S. I started reading the book about Maven that you guys recommended. Thank you for this. The fact that book exists it is already funny. You have to learn 290 pages of text to figure out how other people manage do things that can be explained in 3 lines of text
generate code based on metadata if have any
compile the code
create war file

290 pages of text. People just have a lot of time ...

[Tim Holloway]

I could write an equally fat book on Ant. In fact, Ant already HAS a nice fat book. But I can definitely state I've seen dozens of different ways to layout webapp projects using Ant, including 4 or 5 I worked up myself over the years. The finished product has a definite layout, yes. But when something gets dumped on you with a deadline, knowing where in the project the inputs are counts too.

The advantage of Maven is that when you have lots of libraries, you don't have to replicate them in each project. Instead, you have a master cache and they only get copied into the build. A related bonus I enjoyed was the day when I ran into a wall using OpenJPA and was able to convert the project to Hibernate in 30 minutes jist by changing a few lines in a JPA config file and about 3 dependency statements in the POM.

When I say "magic", I don't mean like in wonderful things. I mean like in "stuff happens, but it isn't obvious how or why". Not a complement. However, while I don't blindly love everything in Maven, I know the costs and the benefits, and for most of what I do, the benefits greatly outweigh the costs.

[Peter Johnson]

1. You place JARs into SCM? Oh my. How many copies of commons-logging do you have in there wasting space? Also, once the initial set of artifacts is downloaded, they are used from the local repository. They are not downloaded time and time again, like you implied.

2. There has never been a standard for J2EE project structure. There is a standard for EAR, WAR, etc, contents but not for the project's source code.

3. Maven builds more than just J2EE projects.

4. I much prefer organizing my work into clearly-defined directory structures rather than having a mishmash of junk all in one directory. And includes/excludes are not the answer - every time you add a new file you have to go back and revisit the includes/excludes to make sure the new file falls into the right bucket. I am so glad I no longer have to deal with this issue; it was really a pain in the @$$.

Re. the new technologies you hate. I guess this explains it all. It seems that rather than learning new ways of doing things and perhaps incorporating the best practices from the past with new ideas, you would rather go on doing things in the same old way. Well, that is really fine if you want to limit your growth.

[Stan Sokolov]

Peter Johnson wrote:

You cannot see the build flow in Maven.

But Maven is scary when you first encounter it. My recommendation is to read the two Maven docs available online:
http://monkproject.org/MONK.wiki/attachments/17620/1332
http://www.sonatype.com/books/mvnref-book/reference/
And when you are done, write a plugin. When I wrote my first plugin, a lot of Maven's idiosyncrasies suddenly made sense and the world was a beautiful place.

Almost finished reading the first book (only last chapter left). I migrated two of my projects to maven and created one pretty useful maven plugin of my own. It was easy because I had already got an experience with creating custom ANT tasks. So far, so good. Thanks a lot for the book links. It really helped me big time. I am still very confused about doing things that are not in the book. For example finding reference information of properties that are available for Maven plugin is a struggle. My plugin generates sources and some resources. It works - code compiles, jar file generated , but generated files are not removed once jar artifact is created. Big question why. Nobody really needs them. So it is is big mystery how to let Maven know to remove generated code after compilation is over.

And the most scary part that stays in front of me is web.application deployment. My next step is to migrate one complex Web. application (Struts,Spring,Hibernate, AJAX libraries) to maven and see how Cargo/Jetty deployment procedure can handle hot updates. Something tells me that it is not going to be too easy to make it works.

Another right thing for me to do was to migrate to IntelliJ 10.5. Working with Maven projects in Eclipse was a torture. IntelliJ 9.5 seems to be unable deal with Maven at all. But IntelliJ 10.5 has a very very good support for Maven projects. I was impressed how easy it become to deal with Maven projects in IntelliJ 10.5. Sure it is not free IDE as Eclipse and community edition sucks but commercial version is very nice.

[Nam Ha]

Thanks guys for sharing your experience on Maven.

I prefer using Ant for my small to medium projects. I wanted to move to Maven, however I stopped at first place when reading Maven tutorials, as I did not understand what the document says. It seems that learning Maven is harder then Ant.

Will Maven replace Ant or both are still living together?

[Stan Sokolov]

Nam Ha wrote:Thanks guys for sharing your experience on Maven.

I prefer using Ant for my small to medium projects. I wanted to move to Maven, however I stopped at first place when reading Maven tutorials, as I did not understand what the document says. It seems that learning Maven is harder then Ant.

Will Maven replace Ant or both are still living together?

Maven is doing the same what ANT is doing but in a different way. Unlike ANT that has no dependencies on external resources, Maven depends on repository where all build files are stored. This repository stores not only your builds but also builds done by other developers. So you connect Maven to repository to let it download and upload jar files that are required as dependencies for your prokects. Ant does not have anything like this. It loads dependencies from local folders as configured.

Second difference is that ANT does not care how you structure your projects, but Maven does. You need to read a lot of manuals to learn how to comply with Maven standards. The good things other developers do the same. Once all comply it becomes easy to learn (theoretically not practically) how other projects are designed. In reality it is very far from being true.

Third difference Maven has prearranged build scripts where there are around 20 phases (clean, generate-sources, compile etc). You could not change order of these phases. You only allowed to say which tasks you can execute on every phase. So build script is always the same from perspective of how phases are going after each other. Compile always go to after generate-source etc. You free to define which tasks have to be performed for every phase. You do it by connecting plugins. Plugin is basically a task that I mentioned before that is something to bind to a phase. .

Trust me it is hard to read maven scripts and understand what and how is going to happen in which order because there are so many things that are configured not by you but by plugin developers. Every plugin is bind to a phase automatically as plugin developer decided. For example JI wrote a plugin that generate hibernate mapping for DB tables and it is bind to generate-source phase. You have no way to know about it because it is not written anywhere. Unless you know somehow, you have no clue what and how my plugin is doing. I mean in case if you just a developer who has to make sense on somebody's else maven script.

In practice in my opinion Maven is over-engineered product that can be used but requires huge initial investment of time to go trough the manuals. Hopefully it will be replaced soon but something else, but unlikely it takes less than 5 years considering a current hype around this technolgy.

[Peter Johnson]

@Stas: wow, I am impressed! It looks like you have really tackled Maven and gained a very good understanding of how it works. I know that the early going is tough, but it does reap rewards later on, especially is you start to think about all of the things you can do with the dependency handling that Maven provides. Let us know if you have specific questions and we will be more that happy to help you with them (might be best of ask individual question in a new post though).

All the best to you!

[Warren Dew]

Peter Johnson wrote:1. You place JARs into SCM? Oh my. How many copies of commons-logging do you have in there wasting space?

This is hardly fixed by Maven. On my only previous major maven project before the current one, the architect and build people's fix to the random maven induced build breakages included our own maven repo, something which I think is mandatory for any serious commercial use of maven. Then, guess what, our maven repo was checked in to our version control system.

Disk space is cheap. Checking binaries in to a version control system is not a problem in this day and age.

[Tim Holloway]

Warren Dew wrote:

Peter Johnson wrote:1. You place JARs into SCM? Oh my. How many copies of commons-logging do you have in there wasting space?

This is hardly fixed by Maven. On my only previous major maven project before the current one, the architect and build people's fix to the random maven induced build breakages included our own maven repo, something which I think is mandatory for any serious commercial use of maven. Then, guess what, our maven repo was checked in to our version control system.

Disk space is cheap. Checking binaries in to a version control system is not a problem in this day and age.

You can certainly check a Maven repository into a VCS if you want. But it's not particularly productive.

VCS systems are - as their name implies - VERSION control systems. They track the differences between generations of resources.

Maven repositories don't have generations of resources. Each version of a resource is a separate and distinct object. In fact, one of the primary benefits of Maven is that if I pull your project source code and do a Maven build on it, the target will be for all intents and purposes identical to anyone else doing a build on it, today, tomorrow, and 10 years from today. So a simple backup of the repo and a VCS archiving of the repo are going to be functionally the same thing. Although from a sysadmin point of view, putting the one into the other cuts the number of backups in half.

[Warren Dew]

Versions of artifacts selected for a maven build can depend on what's available in the repository. This can result in a build breaking unexpectedly when the repository is updated. For that reason, it can be useful to have a history of what was in a repository at a given point in time. That's what I think the justification was in that project.

Granted adequate specification of version numbers in pom files alleviates that issue.

[Tim Holloway]

Warren Dew wrote:Versions of artifacts selected for a maven build can depend on what's available in the repository. This can result in a build breaking unexpectedly when the repository is updated. For that reason, it can be useful to have a history of what was in a repository at a given point in time. That's what I think the justification was in that project.

Granted adequate specification of version numbers in pom files alleviates that issue.

With the exception of snapshot versions, each and every object in a maven repository should be immutable for all time. A version number is not an optional attribute, it's an integral part of the product ID. And for a given version number of a given product, any copy of that product should be 100% functionally identical, once, now, and forever. This is pretty much Rule #1 in Maven. All builds must be reproducible. There's no technical reason to even backup artefacts such as org.drools/drools-core/5.0.0.CR1, since any copy from any repo anywhere in the world will do. There are practical reasons for backing it up - such as not needing an Internet connection to fill the cache. But not technical ones.

If it is not, proper Maven discipline and protocols are not being followed. And if not, might as well chuck Maven and use a build system that's less confining and less trouble.

Yes, snapshot builds are mutable, but they're not something you normally should be tapping long-term and NEVER for production, and near-term, I would hope that some sort of continuous-integration discipline is in effect such that a given snapshot can be re-created via checkout/mvn clean package commands.

So, to reiterate, the primary purpose of Version Control Systems is to record change. The primary purpose of Maven repositories is to hold things that DON'T change. So, while for administrative reasons an IT shop might find it useful to archive Maven repos, any shop that absolutely has to keep Maven repos under version control is not using Maven the way it's designed to be used and is very likely in big trouble, although they may not realize it. Yet.

[Warren Dew]

In an ideal world, things would work as you describe. In the real world, they don't, quite. I'll give you two examples:

1. Maven's own repository has removed older versions of artifacts. This has resulted in unexpected build breakages for organizations that didn't keep their own repository when the newer version was incompatible with their build. Reason enough to have your own organizational repo, to back it up, and perhaps even to keep it under version control if you ever change it, such as by removing old versions of artifacts or adding new versions. The artifacts themselves don't change, but the repo does.

2. The Maven team is notorious for releasing bug fixes in their own plugins in snapshots. That has often meant that people had to use snapshots. They seem to be doing better on this recently, but again, in the real world, sometimes one may have to compromise on strict version specification.

If the Maven team itself can't maintain perfect discipline, why should anyone else be expected to? Sometimes people have to do the practical things needed to work in the real world.