4 ms·

Missing: all of the other software on the host (including maven) and the OS itself.

pmontra 9y ago
Yes, maybe it doesn't apply to Java but I've been unable to setup projects on a new machine because library versions changed, external programs became hard to build themselves, some sw is impossible to find anymore (I remember a customer with a prehistoric MySQL, we had to find the oldest available bug compatible version and hope - they had no tests), etc. A Vagrantfile or a Dockerfile are not enough. You need the actual images.
- rtpg 9y ago
  Or in your docker file you specify versions of things to install, check in repos to use, etc etc. It's versions all the way down
  - ris 9y ago
    You're assuming that all those repos are still around 5 years later.
    - rtpg 9y ago
      Definitely true. Not sure I am a fan of having every git repo having a copy of everything over and over and over, for "ecological" reasons... But it's probably the best way to endure that your builds will work.
    - manyxcxi 9y ago
      They are if you mirror the Docker registry. We use Sonatype Nexus and get the added benefit of having our own private Docker, NPM, Maven, etc. repositories on top of automatically caching dependencies we use. So now we don’t have to worry about them disappearing AND we don’t have to leave the network to get them... assuming we don’t screw up our server.
      - pmontra 9y ago
        We own our registry. That's why we have the images for one project. We install from there. What we don't do yet is storing a pristine a VirtualBox image for another project. We should start doing that because sometimes building those images requires a surprising amount of work. Bitrot, etc.
jermo 9y ago
It recommends using the Maven wrapper to fix Maven's version.
ris 9y ago
So this is why I create Nix files for all of my projects and do all builds from within a nix-shell. You then get to decide to what extent you want to freeze your exact dependencies or leave them abstract to some degree.
- Phlogistique 9y ago
  And do you freeze the nixpkgs version as well?
  - ris 9y ago
    Again, depends. It's a tradeoff. As much as you want reproducibility, you never really want to be wed to security bugs. I tend not to but generally consider myself on the fence about that one.
  - chriswarbo 9y ago
    I hard-code ("freeze") known-good versions of dependencies (including nixpkgs) in my derivations; but I also check to see if an override has been given in NIX_PATH (using `builtins.tryEval <foo>`). This way, I can override things if needed; and in particular I have continuous integration (Hydra) building both a "stable" (all fixed versions) and "unstable" (all latest versions). This way I always have a known-good build I can use, but I can still spot impending breakages and bit-rot in CI. In the case of nixpkgs I don't actually track the very latest commit, since it updates so often. Instead I just `git pull` into a fork every now and again.

Yes, maybe it doesn't apply to Java but I've been unable to setup projects on a new machine because library versions changed, external programs became hard to build themselves, some sw is impossible to find anymore (I remember a customer with a prehistoric MySQL, we had to find the oldest available bug compatible version and hope - they had no tests), etc. A Vagrantfile or a Dockerfile are not enough. You need the actual images.

rtpg 9y ago
Or in your docker file you specify versions of things to install, check in repos to use, etc etc. It's versions all the way down
- ris 9y ago
  You're assuming that all those repos are still around 5 years later.
  - rtpg 9y ago
    Definitely true. Not sure I am a fan of having every git repo having a copy of everything over and over and over, for "ecological" reasons... But it's probably the best way to endure that your builds will work.
  - manyxcxi 9y ago
    They are if you mirror the Docker registry. We use Sonatype Nexus and get the added benefit of having our own private Docker, NPM, Maven, etc. repositories on top of automatically caching dependencies we use. So now we don’t have to worry about them disappearing AND we don’t have to leave the network to get them... assuming we don’t screw up our server.
    - pmontra 9y ago
      We own our registry. That's why we have the images for one project. We install from there. What we don't do yet is storing a pristine a VirtualBox image for another project. We should start doing that because sometimes building those images requires a surprising amount of work. Bitrot, etc.

jermo 9y ago

It recommends using the Maven wrapper to fix Maven's version.

ris 9y ago

So this is why I create Nix files for all of my projects and do all builds from within a nix-shell. You then get to decide to what extent you want to freeze your exact dependencies or leave them abstract to some degree.

Phlogistique 9y ago
And do you freeze the nixpkgs version as well?
- ris 9y ago
  Again, depends. It's a tradeoff. As much as you want reproducibility, you never really want to be wed to security bugs. I tend not to but generally consider myself on the fence about that one.
- chriswarbo 9y ago
  I hard-code ("freeze") known-good versions of dependencies (including nixpkgs) in my derivations; but I also check to see if an override has been given in NIX_PATH (using `builtins.tryEval <foo>`). This way, I can override things if needed; and in particular I have continuous integration (Hydra) building both a "stable" (all fixed versions) and "unstable" (all latest versions). This way I always have a known-good build I can use, but I can still spot impending breakages and bit-rot in CI. In the case of nixpkgs I don't actually track the very latest commit, since it updates so often. Instead I just `git pull` into a fork every now and again.