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

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

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