Live data from Hacker News

Maven builds are an infinite cycle of despair

kent.spillner.org

21–30 of 51 posts

Re: Maven builds are an infinite cycle of despair

#21

> Automatically downloading unresolved dependencies makes your build process nondeterministic! This. You need to be able to check in your build tools, and use them as they were to precisely repeat any build you've ever done, or you're risking bit rot. Ant is sort of painful but it works for this. And if I want my dependencies to be preinstalled rather than checked in and bundled, I'd rather use yum so the rest of the…

This. You need to be able to check in your build tools, and use them as they were to precisely repeat any build you've ever done, or you're risking bit rot.

It's not non-deterministic if your dependencies include an explicit version. You should not be using unversioned -SNAPSHOT dependencies for release builds.

And if I want my dependencies to be preinstalled rather than checked in and bundled, I'd rather use yum so the rest of the world can reuse them too. Does Maven even support dependencies upon native (non-JVM) apps and libraries which are available for a given platform?

No. Maven is intended to support easy-to-use bundled code dependencies, not to operate as a complete replacement UNIX packaging system.

Re: Maven builds are an infinite cycle of despair

#22
post #5

I am doing solo part time development (1 day/week) on a very large orphaned enterprise system. The builds are done using maven. The build takes about 15 minutes because maven is going off to various sites looking for no longer supported versions. I removed the dependencies; not much improvement. I tried mvn -o and the build dropped to 3 minutes. But war file was broken in mysterious ways. The currently irreducible st…

You don't need to toss out maven, you need to spend the effort learning a system with which you're unfamiliar to actually understand why your build is misconfigured and failing.

Re: Maven builds are an infinite cycle of despair

#23
The java build world is perverse. Maven and Ant are imperative, highly limited, domain specific languages using XML for syntax.

If that doesn't set off just about every warning bell in your head, consider that Ant performs character set decoding and re-encoding when copying files. By default it will decode every file with your system's default character encoding and then re-encode it with the very same format. As far as I can tell all this can possibly do is introduce errors. When copying a binary file the best-case scenario is that your JVM throws a runtime error, but it's more likely that ant will silently corrupt the copy.

The Ant team's solution for this problem? You might reasonably expect that they would provide an option for binary files which does a byte by byte copy. Instead they suggest that you change an environment variable to an encoding which "does not seem to contain illegal character sequences."

Re: Maven builds are an infinite cycle of despair

#24
post #23

The java build world is perverse. Maven and Ant are imperative, highly limited, domain specific languages using XML for syntax. If that doesn't set off just about every warning bell in your head, consider that Ant performs character set decoding and re-encoding when copying files. By default it will decode every file with your system's default character encoding and then re-encode it with the very same format. As far…

The java build world is perverse. Maven and Ant are imperative, highly limited, domain specific languages using XML for syntax.

Maven is declarative, not imperative.

Ant is broken in many respects, but your provided example is not true. Ant only attempts re-encoding of a file if you specify text filters (aka variable/string replacement). It shouldn't be a surprise to anyone that string replacement breaks on binary files.

Re: Maven builds are an infinite cycle of despair

#25
Sure it not perfect

- very handy when starting new projects - easy to generate project files for Idea, Eclipse etc.

I used ant in the past, maybe it is more flexible, but also requires more work to set up initial build file. I find Maven just easier to use.

What I liked the most is consistency across project files, project structure.

Re: Maven builds are an infinite cycle of despair

#26

Maven sucks and everyone hates it, but uses it anyway because tragically there is no better alternative for large projects. For me, the M2 plugin for Eclipse seals the deal as it makes the build files double as the IDE project files. One place for dependencies, one build cycle, this is how things should be. I hate Maven with a passion, and use Ant any chance I get, but for very large multi-module projects, the strong…

buildr combines the advantages of maven with the advantages of being built on top of rake and scales to managing multiple projects. Groovy's Grails build system and Scala's sbt also both look good to me, although I have not yet taken the time to try them. The only reason I can think of why systems like buildr aren't more popular than maven is that most Java developers appear too unwilling to learn a separate programming language and would instead rather torture themselves coding in painful XML-based DSL's like Maven.

Re: Maven builds are an infinite cycle of despair

#27

Yes, Maven sucks, but for large projects the dependency management is rather nice. Java as a language is terribly dependency crazy, and being able to add three lines to your pom and get a new library in along with all its dependencies is a good thing. Though I'll now get flamed for not fully understanding every library dependency I'm importing in, which is fair, but hasn't been an issue for me for the three years I'v…

As I mentioned elsewhere in the thread, buildr manages dependencies just like maven, including the ability to download sources and javadocs, and also has an ant integration library that works really well. Finally, buildr supports generating eclipse .classpath and .project files for eclipse, though the IDE integration obviously isn't as good because the project is younger and has less community support.

Re: Maven builds are an infinite cycle of despair

#29
post #26

Maven sucks and everyone hates it, but uses it anyway because tragically there is no better alternative for large projects. For me, the M2 plugin for Eclipse seals the deal as it makes the build files double as the IDE project files. One place for dependencies, one build cycle, this is how things should be. I hate Maven with a passion, and use Ant any chance I get, but for very large multi-module projects, the strong…

buildr combines the advantages of maven with the advantages of being built on top of rake and scales to managing multiple projects. Groovy's Grails build system and Scala's sbt also both look good to me, although I have not yet taken the time to try them. The only reason I can think of why systems like buildr aren't more popular than maven is that most Java developers appear too unwilling to learn a separate programm…

I'm sorry to disagree with you but some people would rather invest their time to learn how to use Maven more effectively than to learn another programming language _and_ a new build system altogether.

Breadth vs Depth I suppose.

Re: Maven builds are an infinite cycle of despair

#30

Seems like the typical reaction seen over and over. People love to hate maven. It always goes like this: 1) try maven but don't bother to RTFM 2) run away with your hair on fire and back to cave-man tools like Make, Rake & Ant 3) ignore dependency management 4) re-invent the build script for _EVERY_ project you start. 5) ??? 6) profit!!! You only ever hear rants like this from people who don't spend the time to learn…

It sounds like the author has had quite a bit of experience with Maven and most likely has RTFM.
Post reply on HN