Hacker News Reader

Comment by lmm | Hacker News Reader

It's long been ironic that Java has excellent dependency management in the form of Maven - better than any other tool I've used, for any language - but the typical java project had far fewer dependencies than in ruby or node. Glad to see some smaller libraries emerging (and it's worth noting that even e.g. spring is now released as a collection of smaller modules rather than one giant jar).

View on HN

It's undeniable that maven can do much more things that other dependency managers, like setting IDE configurations for instance, but that does not make it better.

Do you think it's better than the likes of npm, bower, or composer? where you just say: give me all these things, with at least these versions, and could you please run these scripts also --all at once, in about 30 lines

Every time I want to use mvn I need to start for google .. which was the archetype parameter that I needed?

or so let's run this not-so-common target, no problem I have 5 minutes for a coffee while it downloads all the requirements .. then 5 minutes later says "missing parameter"

> Do you think it's better than the likes of npm, bower, or composer? where you just say: give me all these things, with at least these versions, and could you please run these scripts also --all at once, in about 30 lines of plain text.

Yes. "Run these scripts" leads to snowflake builds: every project ends up slightly different from every other, no-one can resist putting a little "magic" in their build that then goes on to confuse future developers. Requiring every build step to be encapsulated as a plugin, so that there's one and only one way of putting the scm version in your build, one and only one way of bundling your app into an executable, and so on, makes everything much more maintainable.

> Every time I want to use mvn I need to start for google .. which was the archetype parameter that I needed?

You don't need archetypes if you find them problematic. Just start with a minimal pom: groupId, applicationId and version. That's not so hard is it?

> or so let's run this not-so-common target, no problem I have 5 minutes for a coffee while it downloads all the requirements .. then 5 minutes later says "missing parameter"

Either you share your build steps, which means downloading them sometimes, or you copy/paste them everywhere. I know which I prefer. Maven caches quite aggressively (if anything too aggressively), I'm not sure what more it could do.

Running scripts doesn't imply "snowflake builds" - one can just as easily write duplicate plugins that are a mess, and one can also just as easily write encapsulated scripts that do one job and do it well.

It's all about the quality of the developers.

It's not "just as easy". A maven plugin is necessarily a maven module, a first-class module like any of your libraries; unless you go out of your way to make it not, it has versioning, tagging and the like. Even more importantly, since the plugin itself is built with maven, it naturally has dependencies and unit tests, arranged in the same familiar structure as the rest of your code. Everything guides you towards good development practice; of course you could manage your scripts in the same way, but you'd have to do so by hand, and with the best of intentions I've never seen any team that used scripts have the discipline to manage them properly.

Good developers can make good things with bad tools and bad developers can make bad things with good tools yes, but even so, tooling and defaults are extremely important.

> I've never seen any team that used scripts have the discipline to manage them properly

And I'll throw in my personal experience too, which is the opposite: I've never seen any team that used Maven and had the discipline to manage it properly.

Anecdotes don't really get you too far.

Unfortunately this is pretty much the problem you will get. It doesn't have to be about good or bad developers, even good developers will start to apply their own flavor and smart solutions in the build scripts and you will end up with very different way of doing things.

Anyone remember using Ant with Java? Same thing I would say. Maven is convention over configuration for a reason.

> Do you think it's better than the likes of npm...

"Better" is a word I don't like, but NPM failed to learn lessons from some of the aspects of dependency management that Maven nailed, e.g. support for standard HTTP caching proxies, immutable versioning.

NPM ran for many years before they switched off the ability for module publishers to overwrite an already published version number with new code.

I actually somewhat like the XML configuration of Maven. Smart auto-complete in IntelliJ is fantastic. In many JS tools they use a JSON file for configuration, which means one cannot even add comments in the file. And grunt/gulp is worse than Maven, no way you can do anything without writing a custom script with the help of Google.

I'm dabbling with Java occasionally, and what always stumps me is that dependencies are handled differently in every environment. Learning how to add and use an external library in Android is too painful, and zero of that knowledge transfers to Java desktop applications, and zero of that to JBoss WARs.

At some point I just give up and start copy pasting source files; Java's whole environment is too painful for me to want to spend my free time on it, and too complex to learn it in passing at work. It's a lose-lose situation, and I just end up avoiding Java where I can. (Which imo is a shame, because JBoss e.g. turned out to be surprisingly neat once I wrapped my head around it.)

Well there are a bunch of things that are not really Java and it's best to just avoid them; that's not really Java's fault though. I'm not sure what you're talking about with android versus desktop applications though; in android or a desktop application one adds a library as a maven dependency in exactly the same way. (At least, I do).

> Well there are a bunch of things that are not really Java and it's best to just avoid them

I've only ever heard that of Java and C++, and it seems it's always the stuff I cannot avoid because I need it for work.

Your complaint basically boils down to "I don't know how to do it correctly and don't want to learn it". I have a game I'm working on that uses the same setup for both Android and desktop. JBoss does things a crazy way, but for everything else the same approach can be used.

You're doing a bunch of different things there, but none of this stuff is really a secret. You need to be familiar with java class loading[1] and Maven's dependency scopes[2], which is really it's killer feature.

Beyond that, a container, such as jboss, is free define how its things work. One of my favorite things to come out of the Java ecosystem is OSGi, which does dependency management in a very sane way.

[1] http://docs.oracle.com/javase/8/docs/technotes/tools/finding...

[2] https://maven.apache.org/guides/introduction/introduction-to...

My own experiences with Maven have been kind of nightmarish. It puts so much abstraction in between what you see and the underlying reality of command-line tool invocations that it becomes impossible to debug. It also improperly mixes compiling and downloading dependencies into a single tool - more than once I've checked out a project and started compiling it and immediately hit ^C when I noticed it was downloading software without https.

> It puts so much abstraction in between what you see and the underlying reality of command-line tool invocations that it becomes impossible to debug.

That's not the reality. The reality is plugins which are java code - and if you're developing a java program you ought to be capable of debugging java code.

> It also improperly mixes compiling and downloading dependencies into a single tool

"improper" is like "unprofessional" - it's not a real criticism. Having a single command to build is very valuable.

With maven it's a bit like with sex: the first time is sometimes not that funny, and rather painful. And if you're boy you might have not delivered 100% what was expected.

That's interesting. I'm the person who don't like external libraries and avoids using them unless they are really make me happy. Yet my last small project has 89 libraries in dependencies (including transitive). Is it small number?

If you are using Standard Java EE you have exactly one dependency in your pom file.

Reply on news.ycombinator.com