Live data from Hacker News

Why Everyone Eventually Hates or Leaves Maven

nealford.com

71–80 of 168 posts

Re: Why Everyone Eventually Hates or Leaves Maven

#71
post #65
post #57

"These abstractions apply to tools and frameworks as well, particularly tools that must scale in their power and sophistication along with projects, like build tools. By hard-won lesson, composable build tools scale (in time, complexity, and usefulness) better than contextual ones." And then the person that wrote them leaves and we're fucked. If maven doesn't do what you need to do, then chances are you don't need to…

If what you need to do can be done in Maven you don't need to do anything very difficult. Ant scales poorly; dependencies are a particular headache. Maven scales astoundingly poorly. Here's a very short list of things that are massively obnoxious to do with Maven, but are perfectly reasonable: - submitting code to a code review site like Gerrit. - generating code (for example, a parsed SNMP MIB that you want as a Jav…

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.

Re: Why Everyone Eventually Hates or Leaves Maven

#72

Earlier quoted context omitted.

Gradle has given me a lot of headaches for small projects. I keep going back to it now and then and run into performance issues with it where builds that take 10 seconds in Maven take 10 min in Gradle. It's something about the dependency resolution mechanism. Something is broken, but I haven't been able to pin-point it yet. It's frustrating because I love Groovy. I write a lot of Groovy and I'd love to use a Groovy-b…

I've used Gradle on a handful of small projects and am very surprised that you're seeing an order of magnitude difference between a Maven build and a Gradle one. Can you provide a little more detail about what the script was doing for 10 minutes?

Last time I used it which was right around when 1.3 was released I turned on debug logging while the project built so I could see what was causing the issues. It was hanging long periods of time around a task I had to make a fat jar. If I remember correctly it was having some real trouble with locks on Ivy caches... I tried clearing out the Gradle caches and that did not resolve the problem. Since that was a small project I was able to replace the build file with a POM and assembly descriptor be done with it.

If I get some more time to play around I might go back and try and collect some more info for a bug report... I have had this issue since the late Gradle betas each time I go back to using Gradle I hope the problem is resolved.

Re: Why Everyone Eventually Hates or Leaves Maven

#73

Earlier quoted context omitted.

The problem is that there is a large overhead associated with writing a plugin. Sometimes the things you need to do are as small as copying a file from one directory or another. Having to write a plugin to do something so small is overkill.

That already exists. Almost everything you would ever need already exists. Stop reinventing the wheel.

agree fully. IF you are doing something remotely common, chances are theres already a maven plugin that does it. It might have bugs, but chances are, the plugin is also opensource, so its no worse than you writing it yourself than having to fix the bug(s) you encounter.

The only reason i don't like maven is not because of its rigidity, but because of its network dependence. To use maven, you really need to run your own repository server, and that comes with huge overheads. I m warming up to the idea of always mandating offline mode in maven, and then check in to the scm a preloaded repository which includes all the libs and plugins for your project, and never have to worry about external repos, or network connectivity.

Re: Why Everyone Eventually Hates or Leaves Maven

#74
post #57

"These abstractions apply to tools and frameworks as well, particularly tools that must scale in their power and sophistication along with projects, like build tools. By hard-won lesson, composable build tools scale (in time, complexity, and usefulness) better than contextual ones." And then the person that wrote them leaves and we're fucked. If maven doesn't do what you need to do, then chances are you don't need to…

You can like maven or hate it, but why can't it be a bit simpler?

e.g. take this selenium install instructions (http://seleniumhq.org/docs/03_webdriver.jsp)

Ruby:

    gem install selenium-webdriver
Java (with Maven):

   
    
        4.0.0
        MySel20Proj
        MySel20Proj
        1.0
        
            
                org.seleniumhq.selenium
                selenium-java
                2.28.0
            
            
                com.opera
                operadriver
            
        
        
            
                
                    com.opera
                    operadriver
                    1.1
                    
                        
                               org.seleniumhq.selenium
                            selenium-remote-driver
                        
                    
                
            
        
   
Then run

   mvn clean install

Re: Why Everyone Eventually Hates or Leaves Maven

#75

I'll take rigid maven any day. Much preferable to some cobbled together build system that is undocumented and hard to reliably reproduce. I'm curious what people are doing with Maven that they manage to get into such a fight with it? Although to be fair, due to issues in its dependency resolution mechanics, it can pull in incorrectly versioned artifacts without ever telling you anything.

I once did an Ant to Maven conversion job on around 10 mature projects I didn't code. So that a large enterprise can move over to Maven and reap the productivity benefits. Various Maven modules were restricted, including Antrun. Because the projects are old and tied to their directory structure of resources, it was more practical to script in Maven rather than follow conventions. Scripting in Maven was quite... chall…

> the problems arising from Maven also stems from the organization's context.

that's just euphemism for not following maven's conventions, which is where most people's complaint about maven stems from. You either do things the maven way, or the highway. Twisting maven to do what _you_ want, but not how maven likes it is just asking for disaster.

Re: Why Everyone Eventually Hates or Leaves Maven

#76

I love the Access analogy. It burned me quite a few times in prior lives, when every project started with, "Let's build an access database." Ultimately it's a tradeoff in abstraction and usability.

i actually doubt the problems with access are really that bad - sure you outgrow it eventually, but you'd be surprised at what its capable of.

Often the real underlying cause is that a business owner with little to no programming knowledge makes something which works ok, but is architectually wrong. For example, bad table structure/relationships. Or after a while, they want to 'put their app online', and asks a poor intern to convert it.

Re: Why Everyone Eventually Hates or Leaves Maven

#77
post #66

TLDR: Maven makes hard things easy and easy things really f hard.

Maven isn't even good at making hard things easy. Trivial things are easy and anything else will take a day of head scratching, minimum .

what would you consider something as trivial, and what is hard?

Re: Why Everyone Eventually Hates or Leaves Maven

#78
post #7

This is very eloquent distillation of the thought process underlying the evolution of my toolset over the last 5 years. After having jumped into Rails and shifting from BBEdit to TextMate as my primary editor overnight back in 2005, when TextMate started withering on the vine I became disillusioned that I had put so much effort into pursuing such a short-lived tool. Reflecting on my history with a UNIX shell going ba…

Is switching tools really so catastrophic? I have emacs keybindings burned into my muscle memory but just about every tool I use supports them.

But if I'd insisted on sticking with Emacs instead of moving in the mainstream (Xcode & IntelliJ for mobile) I would have ultimately been much less productive than I've been after spending a week getting my head around more specialized tools.

Re: Why Everyone Eventually Hates or Leaves Maven

#79
post #57

"These abstractions apply to tools and frameworks as well, particularly tools that must scale in their power and sophistication along with projects, like build tools. By hard-won lesson, composable build tools scale (in time, complexity, and usefulness) better than contextual ones." And then the person that wrote them leaves and we're fucked. If maven doesn't do what you need to do, then chances are you don't need to…

You can like maven or hate it, but why can't it be a bit simpler? e.g. take this selenium install instructions ( http://seleniumhq.org/docs/03_webdriver.jsp ) Ruby: gem install selenium-webdriver Java (with Maven): 4.0.0 MySel20Proj MySel20Proj 1.0 org.seleniumhq.selenium selenium-java 2.28.0 com.opera operadriver com.opera operadriver 1.1 org.seleniumhq.selenium selenium-remote-driver Then run mvn clean install

One is reproducible. One isn't. YMMV.

Re: Why Everyone Eventually Hates or Leaves Maven

#80
post #9

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).

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.

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