[meaty]

Spot on post.

Last year replaced a maven shitfest with an old fashioned Makefile which calls javac and manual dependencies. The whole port process took about 2 hours.

Integration and test run time has gone from 7 minutes (to drag all the maven plugins and dependencies down) to just over two minutes.

This saves us a fortune on build agent capacity as well (we use TeamCity).

[tonetheman]

Exactly. I am not sure what maven people are looking at. I too have gone out of my way to not use maven.

I am really good at make and reasonable at ant. If you cant build a java project with those then you are the problem not the build system.

[brown9-2]

The problem isn't capability, it's not wanting to deal with dozens of projects with slightly different Ant build files and commands.

[jomohke]

It shouldn't need to download plugins and dependencies every time you build, only the first time. Had you disabled the use of a local cache?

[jamieb]

That's my favorite. "Maven is taking too long. It must be shit. I'll write my own!"

Question: Maven is taking too long and downloading plugins and dependencies everytime. What should I do?

Answer:

1. Its shit! Write my own!

2. Well, that seem suboptimal. Would the smart people who wrote it have made it download all this stuff everytime it builds? Surely that is wrong. Maybe I could google that?

[meaty]

Yes we have disabled the local cache. Our build machines are not stateful - the environment is wiped before each build intentionally. We have had problems where maven caches are poisoned and the builds start failing randomly which cost us a lot of time half way through a major release.

[edwinnathaniel]

You can always run maven offline.

[frugalmail]

As part of your build were you wiping out your local repo ( ~/.m2 ) for some reason? It would only need to check if you don't already have the version specified in your pom in your local repo.

[meaty]

Yes - all our builds are done from zero state i.e. and empty directory. We even deploy a new JVM each time (as we have to test against 3 different JVMs).

[frugalmail]

Either make your 3rd party librariers part of an OS snapshot, or make it part of your source repository. The flaw seems like it's in your build as opposed to the build system. I'm all for wiping away intermediate work products, but you don't need to test the ability to download 3rd party librariers each time. You could use the md5 or sha1 files that get published to the standard maven repo. and that would be a miniscule download, and once you have it, you could just compare it to the existing files.