[hansgru]

> Maven is broken by design

It might be, but it still has it's merits. It was one of the first, and many other improved tools can't work without it's repositories.

I still like the IDE support for MVN: e.g. IntelliJ draws a nice dependency diagram that I find useful, even if I don't use Maven for something else in a project.

Maybe it's biggest mistake was that dependencies are global by default, and not local (like Node's NPM). If the dependency structure would have been local to a project, than many of the pain points I encountered with MVN in the past wouldn't have even existed.

[mercurial]

> Maybe it's biggest mistake was that dependencies are global by default, and not local (like Node's NPM). If the dependency structure would have been local to a project, than many of the pain points I encountered with MVN in the past wouldn't have even existed.

I don't understand the local vs global dependency thing. What does NPM do differently from Maven?

[hansgru]

> I don't understand the local vs global dependency thing. What does NPM do differently from Maven?

As others have pointed out, NPM as a default is using "local" dependencies, (something I couldn't achieve with Maven easily).

"Local" means that the dependencies are in a sub-directory of the project, and that the transient dependencies are in sub-sub-directories too if needed.

With NPM, for us some of the implications of this are the following:

- being "self contained" I can check in a VCS and tag it "completely" or just zip it and send somewhere else, where it can be built "as it is", even on CI machines or production machines that have no Internet connection, nor do require a company internal Maven server.

- bugs and issues with building are reproducible. The "it builds on my machine" doesn't happen anymore. (Just search the different Apache mailing lists of how often this happened even in those open source projects). We had this problem very very often - to the point where several projects were migrated to ANT again.

- the availability of public Maven Repos, their mirrors and their sync is just bad (sometimes it's the corporate firewall/proxy the problem), so builds just fail all to often. Many companies don't use internal Maven Repo Mirror

- none where I worked had one, nor could we convince the management to finance one.

- very often (even visible in open source projects that build with Maven), there are some dependencies (maybe not from the start of the project, or maybe only temporarily) that are not available in the official repos, so need to be manually added. Doing this in a sub-directory is much easier, and it needs to be done only once, so others will just use it.

These are just a few issues that NPM seems to have been solved nicely (or just not having them because of of the "local" defaults).

Of course, there are also disadvantages of this "local" approach (like the redundant disk space usage - where the global one is very efficient), but from my experience all these disadvantages pale compared to the problems and frustration Maven brought in many projects that adopted it.

[16bytes]

Maven stores all of the artifacts that it retrieves in one big local cache so that you don't have to pull the same dependency down.

NPM, by default, will store the artifacts into a directory local to your project.

The maven way sounds nice, but it's easy to possible to screw things up between different projects. (Especially if you have mvn 2 and mvn 3 projects, ugh).

With NPM, everything is nice and separated.

Ivy is like a mix of the two (a global local cache, but pulls down to the local project), which IMHO, has the benefit of neither while getting the drawbacks of both.

[chinpokomon]

How is it easy to screw things up? You specify the version of a dependency when you write each POM file. If there are two projects, each with different dependency versions, they only get the dependency version they requested. Only if you have two different dependencies that report themselves as having the same Maven coordinate, that is to say the same Group Id, Artifact Id, and Version number, will you have any problems. But then that isn't a "Maven" problem insomuch as it is a bad dependency.

[delluminatus]

NPM stores dependencies in a node_modules folder within the project directory, i.e. "locally." It does have a command-line flag to store something globally, though -- useful for dependencies with executables.

I'm not a Java developer but it sounds like Maven stores all its dependencies globally (like in /usr/share/java). I'm not sure why that would be a "pain point" except making it hard to do different versions of the same library.

[mercurial]

Maven stores dependencies in ~/.m2/repository (so "globally" per user). However, it can and does store parallel versions of the same library without issue. It's not much of an issue unless you need to copy your source folder elsewhere, in which case you either need to copy your .m2 (with stuff from all your various projects) or wait until maven re-downloads everything.

[chinpokomon]

Except that you request the dependency version you need for each module. Since the classloader can't load different versions of a dependency, it makes sense to unify the version across the application, and that is easily done with a Parent POM. If you are using OSGI to keep modules isolated when the classloader loads them, then you can request whatever version you want for a particular module.

[brown9-2]

The local repository cache is in ~/.m2/repository and each artifact is versioned, so you would have

  ~/.m2/repository/com/foo/bar/1.0/bar.jar

  ~/.m2/repository/com/foo/bar/1.1/bar.jar

etc., which prevents you from pulling in version 1.0 when you intend 1.1.

[chii]

i might be mis-interpreting your local vs global dependencies, but if you are wary of the network nature of maven, you can always check into your scm the maven repository (and perhaps, pre-fill it with just the deps needed).