Hacker News Reader

Pretty much everything you mention simplifies to "choose a phase, then add an exec plugin declaration".

Have you looked at http://maven.apache.org/guides/introduction/introduction-to-...?

Maven is particularly good at generating code for later compilation and processing. Your custom code generator just needs to put code into src/generated and it will be picked up.

Given that Maven is used to organize and build some pretty large projects out there in the real world, you might want to amend your statement from "Maven scales astoundingly poorly" to "I am astoundingly poor at scaling Maven".

It's not all wine and roses in the land of Maven, but it gets a whole lot of the job done, and done well.

You can add pretty much anything to do with CORBA to your list. Yes there are plugins for it, but they only work in the most trivial of cases.

The original article was helpful to clarifying for me why I have such a low opinion of maven - the project I was working on when Maven came out was a large complex codebase and we'd built lots of interesting things into our Ant build files. I could not work out how to ever do those sorts of things in Maven.

Badly written programs are far from an inevitable outcome with contextual tools. That is more a symptom of Maven's choice of a rather narrow context that has limited its appeal (that and all the ways it sucks ;-).

>- submitting code to a code review site like Gerrit.

Why would you want your build tool to do that?

>- generating code (for example, a parsed SNMP MIB that you want as a Java class so you can refer to it easily).

There are plenty of plugins to do that. If you want one that doesn't exist, write your own. It's not hard, and means this operation will be encapsulated in a structured, testable, reusable way. If you're generating code in an ad-hoc, specific-to-a-single-project way, you're doing it wrong.

>- integration with a tool like Sonar (yes, there's a Maven plugin. You ever used it?).

Yep, I've used it. It works fine.

>- code coverage analysis (yes, there's a Maven plugin. You ever used it?).

Yep, I've used it. It works fine.

>- FindBugs style analysis (yes, there's a Maven plugin. You ever used it?).

Yep, I've used it, it works fine.

>- interesting dependencies on external libraries (to pick an example from Ruby, the json gem was horribly broken at 1.4.2 and generations of projects have varying requirements for json < 1.4.2, json > 1.4.2, and many other worse things.

Huh? You can depend on a specific version, a range of versions, or a range with gaps in. You can't depend on two versions of the same library because it's impossible to set the classpath up like that, but that's a limitation of Java, not maven.

>- C code (through JNI or anything else, a perfectly reasonable thing to want to do).

There are ways to do this, I'll agree it's not pretty. If you want to use another build tool for those projects that include C code that's fair - it should be a minotiry of your projects.

>- deployment.

Not the appropriate tool for it.

I thought Maven was a build tool, shouldn't your continuous integration system put code into Gerrit?

We use Maven and it just works. We play with the idea to move to Gradle, but the effort is non trivial and the real benefits not clear.

We use Sonar. We use Clover for code coverage. We use PMD. We use Checkstyle. We use FindBugs.

- cross-platform C/C++ code and JNI libraries work just fine using the NAR plugin (was developed at CERN for this use case, IIRC). I've used this extensively over the last year to integrate legacy C++ libraries with our Hadoop jobs.

- code coverage / findbugs etc. are better done using something like Sonar. Again, this works just fine for us. You can also set up Sonar & Jenkins on your desktop in minutes and have a working analysis suite + web interface without centralising your builds.

And I assert that you're wrong on the IDE integration - Intellij appears to shell out to Maven for some things, but M2E in Eclipse is a completely different beast (and has some rough edges as a result, but can work well).

"interesting dependencies on external libraries (to pick an example from Ruby, the json gem was horribly broken at 1.4.2 and generations of projects have varying requirements for json < 1.4.2, json > 1.4.2, and many other worse things."

This seems like a java problem more than a maven problem. In fact, I don't really know what you could do about this. Maybe OSGi has a solution.

Um... his example is a Ruby library. It's a totally language-independant problem.

"The only thing your IDE actually needs to get from the Maven POM is to understand where your source code is, what you depend on and where it is, and how to run your tests."

And how does it get that from ant? That seems such a small thing. "Everything else they do...." must be so important. I don't think it is. I think the most important thing is that when developing in the IDE I have a reasonable certainty that when it builds on the CI server that its going to do the same thing. The next most important thing is that our team can develop using the IDE each prefers (or vim if they want). Maven is the only "project description" that is understood by every IDE and also runs from the command line.

"Everything else they do with command line calls, just like Ant".

Not so. For example, both eclipse and IntelliJ, when faced with a merge-war project, will set up a project definition that provides the same behavior as running maven, but without running maven. Modifying a resource in the common war project causes that file to be deployed to any running targets. Its instantaneous and automatic. Its the difference between an Integrated Development Environment and a text editor.

Everything else, don't use maven. Maven is a tool for building java.

Our tools for deployment make maven look like "hello world". I wouldn't use maven to deploy. Likewise for submitting code to anything. I use maven to build deployable targets from java and to upload them to a repo. End of story.

Basically, if it hurts when you do that, don't do that. I use bash on my build server. Somewhere in the middle, bash runs maven.

So how would I handle generating some code from another format? Depends what it is. One fellow said reading from a database for example. Well before I ran maven, I'd run the program that generated the java files, and then I'd check those files into source control so that we know what exactly got built. Then I'd run maven. If it was generating java from a text file, I'd probably have it as an Ant task in my IDE, and whatever got generated, I'd check that in too. Sometimes I've gone as far as to write an IDE plugin that builds the file automatically.

Checking in generated files? Isn't that an excuse? Well, no, not if you want to guarantee to be able to build it in 18 months time. I've worked at a place where they couldn't even build an 18 month old product to support a customer because the build system itself wasn't versioned!

A correction I should note; the broken json gem was 1.4.3.