3 ms·

Yes, but Maven doesn't support reproducibility (outside of plugins that basically haul in a lockfile). So his whole point is moot (Gradle now does, as an aside

Yes, but Maven doesn't support reproducibility (outside of plugins that basically haul in a lockfile). So his whole point is moot (Gradle now does, as an aside: https://docs.gradle.org/current/userguide/dependency_locking.html https://docs.gradle.org/current/userguide/dependency_locking...) Again - I don't think the author is aware enough of the problem space to be making the sort of claim that he is. He doesn't understand the problem lockfiles are solving, so he doesn't know why they exist and wants them gone... chesterton's fence in action. --- Directly declaring deps is great. It's so great that we'd like to do it for every dependency in many (arguably most) cases. But doing that really sort of sucks when you start getting into even low 10s of deps. Enter... lockfiles and the tooling to auto-resolve them.

oftenwrong 1y ago
>Maven doesn't support reproducibility I don't think that is true: https://maven.apache.org/guides/mini/guide-reproducible-builds.html https://maven.apache.org/guides/mini/guide-reproducible-buil...
- horsawlarway 1y ago
  Caveats from that document, top one basically blows this whole thing up. Maven can't give you reproducible builds with version ranges, because it has no lockfile. --- More Details Reproducible Builds for Maven: Require no version ranges in dependencies, Generally give different results on Windows and Unix because of different newlines. (carriage return linefeed on Windows, linefeed on Unixes) Generally depend on the major version of the JDK used to compile. (Even with source/target defined, each major JDK version changes the generated bytecode) For detailed explanations, see Maven “Reproducible/Verifiable Builds” Wiki page.
  - oftenwrong 1y ago
    I would say that is a reasonable constraint. As you know, version ranges, and other "dynamic" versions in Maven are inherently incompatible with reproducible builds because they are resolved non-deterministically during the build. The most common approach when reproducibility is required is to resolve dynamic dependency versions in source, which is a strategy shared by tools that use lockfiles. I agree that Maven would be better with lockfile support. However, as with any proposed evolution of Maven, I can imagine it would be quite hairy to implement in a way that is compatible with other mechanisms. On the other listead caveats, I would add: - Output line endings are controllable via line.separator, which Maven honors. Input line endings are an important consideration for reproducibility, but also not truly a problem of Maven's reproducibility. - JDK version can be enforced with Maven Enforcer and/or toolchains.

oftenwrong 1y ago

>Maven doesn't support reproducibility I don't think that is true: https://maven.apache.org/guides/mini/guide-reproducible-builds.html https://maven.apache.org/guides/mini/guide-reproducible-buil...

horsawlarway 1y ago
Caveats from that document, top one basically blows this whole thing up. Maven can't give you reproducible builds with version ranges, because it has no lockfile. --- More Details Reproducible Builds for Maven: Require no version ranges in dependencies, Generally give different results on Windows and Unix because of different newlines. (carriage return linefeed on Windows, linefeed on Unixes) Generally depend on the major version of the JDK used to compile. (Even with source/target defined, each major JDK version changes the generated bytecode) For detailed explanations, see Maven “Reproducible/Verifiable Builds” Wiki page.
- oftenwrong 1y ago
  I would say that is a reasonable constraint. As you know, version ranges, and other "dynamic" versions in Maven are inherently incompatible with reproducible builds because they are resolved non-deterministically during the build. The most common approach when reproducibility is required is to resolve dynamic dependency versions in source, which is a strategy shared by tools that use lockfiles. I agree that Maven would be better with lockfile support. However, as with any proposed evolution of Maven, I can imagine it would be quite hairy to implement in a way that is compatible with other mechanisms. On the other listead caveats, I would add: - Output line endings are controllable via line.separator, which Maven honors. Input line endings are an important consideration for reproducibility, but also not truly a problem of Maven's reproducibility. - JDK version can be enforced with Maven Enforcer and/or toolchains.