5 ms·

Maven versions are not present in VCS if you use ranges. Wouldn't this cause issues like not know what Library version is being used in production and builds no

Maven versions are not present in VCS if you use ranges. Wouldn't this cause issues like not know what Library version is being used in production and builds not being reproducible?

isbvhodnvemrwvn 5y ago
Not to mention that Maven doesn't have any mechanism for locking in transitive versions, because typically everyone uses hardcoded patch versions and never update them.
- EdwardDiego 5y ago
  How do you mean? You can override versions of transitive dependencies.
  - isbvhodnvemrwvn 5y ago
    In most projects JVM devs don't pin the versions of transitive dependencies, even though in many other languages it's recognized as a basic functionality of the build tool.
    - EdwardDiego 5y ago
      Yeah, that's a fair point about JVM culture. I suggest that there's a few cultural reasons this occurs, based on my experience: 1) JVM libs generally tend to follow semver to the Y level of X.Y.Z. reasonably well. (Spring can FOADIAF in this regard though) 2) Maven and Gradle etc. have very good dependency resolution algorithms 3) When the dependency algorithm struggles, you can provide guidance (e.g., Maven's dependencyManagement element, or the ability to exclude a dependency's dependency so that your pinned version of that dependency is what's used) On that last point, you can use the Enforcer plugin to be very very draconian about transitive dependencies. I worked on a project in the past that would fail the build if you introduced a dependency that had dependencies, and didn't precisely specify the version of each new dependency at the project level. I've done a fair bit of work also with Python, Go, and JS, and doing so made me realise that the dependency management situation in JVM land is the best I've ever encountered (so far). Which surprised me, I had always thought it somewhat over-engineered, but now I think it's sufficiently engineered and those other languages need to steal some ideas. (Especially Python, I love Poetry, especially compared to pipenv, but I would kill for the ability to override a dependency's dependency like I can in Maven and Gradle).
EdwardDiego 5y ago
That's true, but you can export resolved dependency versions at build time if necessary. I've rarely used version ranges because, well, semver rarely occurs, but for Jackson, allowing it for patch releases was a decision to ensure security updates were automatically picked up.
PeterisP 5y ago
You can solve that issue not at the source/VCS level but with artifact management, properly logging, storing and documenting the things that were built from that source. In some places that's tightly integrated with VCS in a single pipeline, in others the source and built artifacts are managed quite separately, especially if you're packaging many different builds for different customers.

Maven versions are not present in VCS if you use ranges. Wouldn't this cause issues like not know what Library version is being used in production and builds not being reproducible?

isbvhodnvemrwvn 5y ago

Not to mention that Maven doesn't have any mechanism for locking in transitive versions, because typically everyone uses hardcoded patch versions and never update them.

EdwardDiego 5y ago
How do you mean? You can override versions of transitive dependencies.
- isbvhodnvemrwvn 5y ago
  In most projects JVM devs don't pin the versions of transitive dependencies, even though in many other languages it's recognized as a basic functionality of the build tool.
  - EdwardDiego 5y ago
    Yeah, that's a fair point about JVM culture. I suggest that there's a few cultural reasons this occurs, based on my experience: 1) JVM libs generally tend to follow semver to the Y level of X.Y.Z. reasonably well. (Spring can FOADIAF in this regard though) 2) Maven and Gradle etc. have very good dependency resolution algorithms 3) When the dependency algorithm struggles, you can provide guidance (e.g., Maven's dependencyManagement element, or the ability to exclude a dependency's dependency so that your pinned version of that dependency is what's used) On that last point, you can use the Enforcer plugin to be very very draconian about transitive dependencies. I worked on a project in the past that would fail the build if you introduced a dependency that had dependencies, and didn't precisely specify the version of each new dependency at the project level. I've done a fair bit of work also with Python, Go, and JS, and doing so made me realise that the dependency management situation in JVM land is the best I've ever encountered (so far). Which surprised me, I had always thought it somewhat over-engineered, but now I think it's sufficiently engineered and those other languages need to steal some ideas. (Especially Python, I love Poetry, especially compared to pipenv, but I would kill for the ability to override a dependency's dependency like I can in Maven and Gradle).

EdwardDiego 5y ago

That's true, but you can export resolved dependency versions at build time if necessary. I've rarely used version ranges because, well, semver rarely occurs, but for Jackson, allowing it for patch releases was a decision to ensure security updates were automatically picked up.

PeterisP 5y ago

You can solve that issue not at the source/VCS level but with artifact management, properly logging, storing and documenting the things that were built from that source. In some places that's tightly integrated with VCS in a single pipeline, in others the source and built artifacts are managed quite separately, especially if you're packaging many different builds for different customers.