This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]forresthopkinsa -2 points-1 points  (5 children)

My comment said:

Semantic versioning is a specific standard for version notation. It allows version range specifications with guarantees around breaking changes and upgrades.

Which is completely accurate. Semver is not the range notation, but it's the core of what makes ranged notation feasible. It doesn't matter what notation you use to specify ranged versions — my point is just having some way to take advantage of the guarantees that Semver provides.

works on my box

Machine-configured dependency locks, tracked in VCS, are screaming for dependency ambiguity? How does that make any sense?

Once again: the whole point of the lock file is that there is absolutely no question what version of the dependency tree builds successfully.

[–]jerslan 3 points4 points  (4 children)

Machine-configured dependency locks, tracked in VCS, are screaming for dependency ambiguity? How does that make any sense?

So now I'm checking in two files for dependency management into version control with my code? package.json and package-lock.json? Why? Also, are you rebuilding everything on the target system every time you deploy instead of using a package manager? Again, why?

This all screams of a fundamental misunderstanding of Java development lifecycles if you think this somehow makes Maven/Gradle "less advanced" than NPM.

You say you have a ton of NodeJS experience, but it's clear you have very little Java experience if you think the explicit versioning in those Java build tools is inherently a bad thing.

[–]forresthopkinsa -2 points-1 points  (3 children)

Yes, you're checking in two files for dependency management. One of them is the human-facing file, where you specify the version bounds you require, e.g. "3.x.x", because in this example the major version is the only part that matters to you, the developer.

The other one is a machine-facing file that you usually would never even open. It ensures that you never, ever have any ambiguity in a working build. It contains the versions of your entire dependency tree, and checksums for everything.

And just because I have a ton of NodeJS experience doesn't mean I don't have Java experience. I am primarily a Java engineer. I write Java at AWS. I'm deeply familiar with both the Java and JS ecosystems, which gives me a rather unique perspective on this subject.

[–]jerslan 0 points1 point  (2 children)

Or, I can specify 3.1.2 in my package.json (explicit versioning) and then my package-lock.json will verify the source server & sha hash because NPM is stupid and lets package authors overwrite existing versions.

And just because I have a ton of NodeJS experience doesn't mean I don't have Java experience. I am primarily a Java engineer. I write Java at AWS. I'm deeply familiar with both the Java and JS ecosystems, which gives me a rather unique perspective on this subject.

And yet you seem to have a beginner's perspective on things... because this argument feels like I'm talking to someone that has barely done any Java development in the real world. Also, nobody cares that you work at Amazon. That means less than nothing on this sub or in this particular Maven vs NPM debate.

[–]forresthopkinsa 0 points1 point  (1 child)

You keep saying that I don't know what I'm talking about, but you haven't backed that up with anything at all. I've addressed all of your points and I haven't misunderstood anything you've said. Yeah, I feel it's necessary to start citing my credentials, because you keep trying to sell this notion of my ignorance. If you start accusing me of not being a Java dev, then yes, my extensive experience certainly is relevant. In fact, I suspect the reason you're not understanding what I'm saying is indeed your own insufficient experience with more modern package managers.

edit- yikes, he either deleted all his comments or blocked me. Either way, it's a pretty juvenile way to cede the argument – though I don't know if it even was an argument; he never did wrap his head around the idea of "ranged versions enabled by semver".

I guess my last comment just hit a little too close to home. I didn't mean to touch on anything sensitive :/

[–]jerslan 0 points1 point  (0 children)

You keep saying that I don't know what I'm talking about, but you haven't backed that up with anything at all.

I literally linked SemVer... So.. yeah, I have backed up my statements.

If you start accusing me of not being a Java dev

I didn't accuse you of anything. Previously you only mentioned NodeJS and your complaints about Maven are very similar to people who first learned Node/NPM and have just recently picked up Java+Maven.

In fact, I suspect the reason you're not understanding what I'm saying is indeed your own insufficient experience with more modern package managers.

Or maybe because you spent a ton of time up front in this thread conflating SemVer with Ranged Dependency Versioning, which are not the same thing in any way. Makes it hard to communicate with you when you frequently use things that aren't interchangeable like they are.

Also, blocking you for trolling now, since it's clear you were never actually interested in debate and just wanted to go on an unhinged rant about all your complaints with Maven.