The news is that I found it after giving up on trying to use regexes to parse what our users think their phone numbers are, and I thought it would be useful for other devs. I don't remember seeing it here, but maybe it was in the back of my mind when I was looking for solutions.
It seems quite strange to me that one should "[m]anually port any changes of the Java code to the JavaScript code" when updating the JavaScript library; the JavaScript version is so heavily Java-fied that there's hardly any point it being written in JavaScript in the first place, so couldn't they just have used GWT?
Pardon me, but that's what I would do. Why does it make you grumpy?
I'd rather not rely on some package server (and whatever provisions they may have in place to allow library authors or DMCA claimers to remove packages) for my build to succeed. I'm pretty sure javac is going to be available in 10 years, but not equally sure about all dependencies. Why take that risk?
Don't forget, the people who made "don't commit binaries" a holy command actually meant "don't commit files generated from other files that are also in this repo".
You can (and should) run you own internal proxying package server that never deletes things. Like you should run your own CI server or SCM server.
So you have a library in your project added as a JAR in your SCM. Everything seems fine. We'll actually you missed the source JAR so debugging is going to suck. You'll have to find the web page from which you downloaded the JAR. Find the matching source JAR add it and configure your IDE. You could have gotten that for free.
At one point you realize that your library is a little old and you wonder what the current version is. So you go to their website check for the current version, download it, hopefully don't forget the source source JAR, update your IDE configuration. You could have found out which of your decencies are outdated and what their current version is on the command line with one command. The rest could have been a one line change in a build file.
And this is the simple case when your dependencies don't have any dependencies themselves. Where you don't have a dozen JARs checked in and you no longer know what is there why.
And if you want other people to use your library they need it in some package server that meets whatever requirements this server may have (source JARs, Javadoc JARs, GPG checksums, metadata, …).
Thanks for answering. Admittedly, it's been a while since I used Java, but what keeps one from using the dependency manager (e.g. Maven) but still committing the jars? Isn't that way simpler than running your own proxy, with effectively the same result?
Maybe my lack of recent Java work is is where I misunderstood. On .NET, all packages, including debug info and docs, go in a folder called "packages" made by NuGet (the .NET package manager). If you simply choose to not .gitignore that folder, you'll always be able to build even without an internet connection. Keeping the packages up to date goes exactly like it would go if you would ignore the "packages" folder.
I'd do it like this with Node.JS too, except that Node's very deep node_modules directory tree hits Windows's (ridiculously screwed up) MAX_PATH length and therefore Git chokes on it once you have more than 0 Windows devs on the team. Which is a bit sad given how deliciously cross-platform Node is.
