Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Everyone Eventually Hates or Leaves Maven

nealford.com

Post reply on HN
Print view View original

91–100 of 168 posts

Re: Why Everyone Eventually Hates or Leaves Maven

#91

Post by krickle »

laureny wrote: post #55
dasil003 wrote: 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…

> not using verbose Java-like languages that require IDEs for the all the boilerplate and rote refactoring. You probably need to revisit your opinion on IDE's, they haven't been used for boiler plate code since the late 90's with Visual Studio. Java IDE's make your more productive and they help you keep your code base in a healthy state with very little technical debt. Not using them would be like preferring a screwd…

No, IDEs make you more productive. It's like declaring that your blue screwdriver is better than their red screwdriver.

Re: Why Everyone Eventually Hates or Leaves Maven

#92

Post by gchpaco »

gizmo686 wrote: post #88
laureny wrote: post #55

Earlier quoted context omitted.

> not using verbose Java-like languages that require IDEs for the all the boilerplate and rote refactoring. You probably need to revisit your opinion on IDE's, they haven't been used for boiler plate code since the late 90's with Visual Studio. Java IDE's make your more productive and they help you keep your code base in a healthy state with very little technical debt. Not using them would be like preferring a screwd…

My understanding of dasil003's point is that it is not a complaint about IDEs, but rather about languages that are designed in such a way as to require IDEs. For example, in Java, if you want to sort a List by a given field (using the Native Collections.sort method), you would need to do something like: Collections.sort(myList, new new Comparator () { public int compare(E o1, E o2) { return 01.val-02.val } } (You cou…

Another way of looking at this is how much code you have to read. This is one of the reasons I hate wizard generated code in a way that I don't hate InterfaceBuilder or similar serialized object trees. If I'm gonna have to read the code eventually, the fact that your IDE makes it easy to draw a button is cold comfort to me when it takes 100 lines of cryptic C to do it (actually pretty common in early Windows programs or Xaw hacks, but mercifully diminished in frequency in these more enlightened days).

Code generation can cause people to neglect library design; the reason why the MFC wizards spat out volumes of code instead of calling a library method is because you might need to rewrite some or all of that. You are not expected to modify InterfaceBuilder output, nor should you have to any more than you would have to regularly rewrite bits of Xlib to customize them appropriately.

Re: Why Everyone Eventually Hates or Leaves Maven

#93

Post by rossjudson »

chii wrote: post #73
spullara wrote: post #63

Earlier quoted context omitted.

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 o…

I used to be really annoyed by that too, but I'm not any more. It's _really important_ in commercial software development to understand where your code comes from. Having a local repository act as a gatekeeper does a nice job of that. It's a good idea to always have builds run where maven settings force use of a local repository. You can then easily track everything that's going into builds, and scale that up over larger numbers of projects.

You can also push libraries into the repository that aren't open source, and know that you've done so.

Running a maven repository doesn't take much. Sonatype's basic offerings are fine and quite effective.

Re: Why Everyone Eventually Hates or Leaves Maven

#94

Post by rossjudson »

gchpaco wrote: post #89
chii wrote: post #77

Earlier quoted context omitted.

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

Building java libraries isn't really all that difficult. Not is packaging them. Damned if it doesn't take 30 lines of XML to do it in maven, but these kinds of see-spot-run situations are pretty easy. Extremely difficult in maven and five minutes work in make or ant is things like "running LaTeX to generate a PDF of some of your documentation, because it is math laden and HTML isn't suitable". This is not theoretical…

Or you could use org.codehaus.mojo:latex-maven-plugin, stick your latex and graphics in src/main/latex/, and watch it 'just work', like I do.

I agree that not every maven plugin does exactly what you want it to, but a lot of them get pretty damn close, and as the authors iterate them, they gain a lot of flexibility.

Re: Why Everyone Eventually Hates or Leaves Maven

#95

Post by jamieb »

gchpaco wrote: post #65
jamieb wrote: 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…

"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!

Re: Why Everyone Eventually Hates or Leaves Maven

#96

Post by frugalmail »

jshen wrote: post #82
jamieb wrote: post #79

Earlier quoted context omitted.

One is reproducible. One isn't. YMMV.

Well in ruby you could use bundler and it becomes gem 'gem-name' # in Gemfile $ bundle install

Until you want to do it on a system you just want binaries.

Or until you need to guarentee the version of the library you're bundling

Or you want to run on something other than a MAC-in-crap, like Linux.

RVM has the same problems.

In my opinion, one is for play, and one is for work. If you just want to fuck around and spew code in one long controller that looks like spaghetti, and you don't want to worry about reproducability or quality guarantees or modularity then Ruby build tools are fine to use.

It's incredibly frustrating to hear about people complaining about how tool X doesn't do task Y. They could just STFU and write the plugin.

There is really only one type of plugin that wouldn't work well in Maven, and it's when for some reason you're task doesn't fit into it's "life cycle" pattern. For example, you want something running in the background when you edit SASS, LESS, TypeScript files and you want some processor to just run and deploy in the background continuously. In this scenario, you could keep the Mojo API, but you would have to lose the Maven Framework.

Each tool for it's job.

Re: Why Everyone Eventually Hates or Leaves Maven

#97

Post by mceachen »

cageface wrote: post #78
dasil003 wrote: 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.

This is exactly how I approach new tools.

My brain-stem knows what to type when I want to go to the end of the line. If the tool doesn't do what I expect when I hit that keystroke, I update the keymapping. In about 1 hour of coding/retraining, the keymap works quite well.

Re: Why Everyone Eventually Hates or Leaves Maven

#98

Post by frugalmail »

ap22213 wrote: post #4

It's a trade-off, right? As most things in software are. Recently, I inherited a project that had 10,000s of lines of ant scripts. Resource constrained, I didn't have anyone to maintain that build process. So, I took a few hours and converted those projects to several hundred lines of maven 'scripts'. Now, it works way better than the previous system, because now I can have a person focused on coding features, rather…

Gradle doesn't have the library of plugins Maven has.

Do you really need stupidly concise code in a build process that gets updated .01% of the time compared to the rest of a project? I'd rather have the verbosity and formality (Maven plugin vs. customized groovy)

Re: Why Everyone Eventually Hates or Leaves Maven

#99

Post by frugalmail »

chii wrote: post #73
spullara wrote: post #63

Earlier quoted context omitted.

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 o…

I think that's an interesting concern, but you might be in a different enviornment than I am.

If "network dependence" is an issue for you, you could check in your ~/.m2 directory iff you don't want to run a repository server and you're deploying to many machines that have access to source control (which you probably do if you're running maven on that machine) and you don't have access to the internet. Then it's almost like a Ant 'lib' directory type of build, but with version information, docs, and sources all available if you want it and easily refreshed when you do have network access.

Re: Why Everyone Eventually Hates or Leaves Maven

#100

Post by frugalmail »

berlinbrown wrote: post #51
mcherm wrote: post #3

I don't hate Maven, and I haven't left it yet. But he is absolutely correct about the key observation: a basic tool with "plugins" is simply NOT the way to create a build tool. A built tool should allow (when needed) the full flexibility of a Turing complete programming language. Because eventually your project is probably going to need it.

I think developers are dogmatic and stick to a particular religion. I don't mind mind maven but I hate when I see an example piece of code and the only way to get it to work is complicated maven(pom) script. Then I have to spend a hour trying to figure out what is in the maven script. And you end up with only 2 or 3 jars (log4j and commons-logging junit and some other jar). Why don't you just give me the version I ne…

Not sure what you're complaining about specifically, but maven has the ability to generate bundled jars when the app author includes the assembly plugin ( http://maven.apache.org/plugins/maven-assembly-plugin/ ).

Then you would just type mvn assembly:assemble

Post reply on HN