| ▲ | ivan_gammel 7 days ago |
| Well, I‘m not talking about Gradle, right? Sometimes conservative choice is what gets the job done. |
|
| ▲ | demosthanos 7 days ago | parent | next [-] |
| Right, I'm just clarifying for others who may not know the difference that Node doesn't have a monopoly on instability. There are a very small number of projects that specifically make it their goal to be backwards-compatible effectively indefinitely, and Maven is one of those. It's part of what people who hate it hate about it, but for others it's the main selling point. |
|
| ▲ | lowboy 7 days ago | parent | prev [-] |
| Well, the article is about npm, a package manager for node. Vendoring dependencies into source is a choice, albeit one that I don't often reach for. |
| |
| ▲ | cesarb 7 days ago | parent [-] | | > Well, the article is about npm, a package manager for node. And Maven is a package manager for Java. The main difference IMO? The usual way to do things in Maven is to always use exact versions for the dependencies. When I specify I want some dependency at version 1.2.3, Maven will use version 1.2.3 of that dependency even if 1.2.4 or later already exists. | | |
| ▲ | lowboy 6 days ago | parent | next [-] | | Pinning to exact versions has been supported in npm for most, if not all of its life. That’s the usual way to do things in most teams working on app code I’ve been a part of (as opposed to library code where version ranges are preferable). | |
| ▲ | ivan_gammel 7 days ago | parent | prev [-] | | Maven is also stable and requires only JDK to run. You can unzip it to desired location and add to PATH - it will be ready to go in a couple of minutes. It will not build all old projects out of the box, of course. Specific versions of plugins may not be compatible with it or some dependencies may break on modern JDK. But chances of hitting this issue are much lower than in JS/NPM ecosystem. |
|
|
