4 ms·

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

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, …).

skrebbel 12y ago
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.

skrebbel 12y ago

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.