I've gotta take beef with the deployment comment, we use Java at my job and the deployment is quite specifically awesome. There is a single package management system, maven repositories, and multiple build options using that management system.

But the reason deployment is awesome is because of the nature of shipping an assembled pile of bytecode. You can build an assembly that statically links in all the code you depend on, and bang: You have one jar (or war) file, can run java -cp myjar.jar MyClassName and all of your dependencies have been packed into the jar for you. It's so easy. No management of which dependencies have been installed where.

I think it helps to look at the scope of the analogies being presented. For instance, the friction of installing & configuring Postgres is compared unfavorably to MySQL. Objectively speaking, those are pretty minor differences (i.e. installing Postgres is easy). However, the point that was being made was that even minor increases in "friction" can negatively impact adoption.

No-one is saying Maven / Gradle / Ant are terrible package management systems. However, when compared against tools used in other popular languages (ruby gems, pip, NPM), it's fair to argue that other language's package management systems are more fluid - in that neither of them require prior configuration and work quite well outside of an IDE.

Maybe these other systems are more fluid, but their are also a lot weaker in what their platform gives them. What I mean by this is that the Java world never needed the extra rvm, virtualenv, etc.

The complexity of dependency management doesn't come from declaring dependencies, but from managing conflicts over time and being able to create isolated environment.

Even if many call it the "jar nightmare", I don't know other systems that offer better isolation.

I think you've misunderstood the point I was making, which makes sense in context of the video in the OP. I'm not arguing NPM > Maven. I'm arguing NPM is conceptually simpler and easier for a newcomer to use than Maven.

Namely, the speaker made reference to "weaker" DB technologies being used due simply to a frictionless barrier to entry. Mongo was cited as one example. The use of MySQL over Postgres was another. This is basically taken verbatim from the presentation in the video.

This isn't about which systems are "better" or "worse", but which are simpler to get up and running with. Mongo is super duper simple to install and configure. So is NPM. Managing complexity is a real and valid concern, but also not what we're talking about here.

What I wanted to suggest is that: at the tool level npm, gem, pip are simpler to get started. But I don't think that's the case at the env level where you'll need more tools.

So while I've used some wrong words in my comment, I was still (trying at least) referring to simplicity vs complexity.

PS: I've never been very fond of other complexities introduced by the maven approach, but that's a different (and probably longer) story.

Yeah, that's what I'm disagreeing with.

Maven doesn't require an IDE and uses a convention over configuration based approach where it will run against the public repo with zero config.

Moreover, it's significantly 'more fluid' due to the ability to ship assembled fat binaries that have all of their dependencies packaged with them. No need to worry about which version of what is installed on this machine.

I think you glossed over the 'configuration' that adds friction to Maven adoption. Namely, the pom.xml file. You could argue that its complexity is typically overstated, but the fact remains that it exists and most developers will have to interact with it at some point or another. That's simply not the case in many other systems.

> No need to worry about which version of what is installed on this machine.

That's not a concern when using NPM (out of the box), and when using virtualenv it's not a concern when using pip (which most Python devs do).

> the fact remains that it [Maven] exists and most developers will have to interact with it at some point or another. That's simply not the case in many other systems.

Are you saying that when developing in Node, you don't have to interact with npm or other build & deployment utilities? End-users of packaged Java applications don't have to interact with Maven any more than end users of packaged C applications have to interact with Make.

I was probably not clear. 'It' refers quite specifically to pom.xml, not Maven as a whole.

Thus :

> the fact remains that it [pom.xml] exists and most developers will have to interact with it at some point or another. That's simply not the case in many other systems.

Again, I would like to highlight that this entire discussion should be viewed through the lens of friction vs. frictionless tools, and what that means for community adoption.

A big part of the ease of use of package managers comes from implicit trust in the maintainers of the repositories. Convention over configuration dictates you as a node dev trust the NPM repos. Ditto for ruby gems.

Like most things java related maven is very extensible from an env perspective. People complain about java programs/tools being over engineered but in this case it's a good thing.

One of the great things about maven is that you can trivially point it to a repo you control that is shared across a team or even an entire corporation. This allows whitelisting of packages, confirmed trusted versions, and consistency across different applications (my app and you app both use library X and we know its the same jar).

How many of you actually verify the origin of the modules and libraries you use as dependencies?

I think you got it backwards. Maven doesn't support any form of authentication or verification for packages. So you better trust the network you're on, the core network, and the remote repository.

Maven central and other repositories contain a lot of software, under many different licenses. So unlike, say, apt-get or rpm, you can't always be sure that what you're getting is free/open source software. Be careful with the licenses!

Going back a step, Java itself is just download, unzip. Oracle actually made it even easier than Sun, by doing the "agree" on the website. But they do lose by not having it in ubuntu/debian.

It's not so easy in the corporate world because you need Administrator access to install Java.

If you specify the right options in the manifest (or configure the maven assembly plugin appropriately) you can reduce it to java -jar myjar.jar.

But these megajars have other issues when you need to run in slightly more advanced scenarios, e.g. hosted Akka or Play. It's not hard to end up with multiple versions of the same library on the classpath, and the wrong ones getting chosen.

I use SBT-Assembly with Akka to generate megajars and I haven't had any issues with multiple dependent libraries getting packaged with conflicting versions. SBT-Assembly has a pretty straightforward system for handling conflicts, allowing you to define merge strategies for different files or patterns.

The problem with something like Akka Microkernel is that you get multiple megajars for different actors, living in the same JVM, with conflicts in the libraries in the separate megajars.

I listened to it as well and your summary is a good one. If I were a Java developer in the audience I'd feel reassured, but not too excited.

> The talk mostly deals with Java the language, not so much the JVM

Have yet to watch the video, but my biggest problem with Java was THE language and swing.