5 ms·

This. You need to be able to check in your build tools, and use them as they were to precisely repeat any build you've ever done, or you're risking bit rot. It

This. You need to be able to check in your build tools, and use them as they were to precisely repeat any build you've ever done, or you're risking bit rot. It's not non-deterministic if your dependencies include an explicit version. You should not be using unversioned -SNAPSHOT dependencies for release builds. And if I want my dependencies to be preinstalled rather than checked in and bundled, I'd rather use yum so the rest of the world can reuse them too. Does Maven even support dependencies upon native (non-JVM) apps and libraries which are available for a given platform? No. Maven is intended to support easy-to-use bundled code dependencies, not to operate as a complete replacement UNIX packaging system.

aaronkaplan 17y ago
I think you're right that in principle one can make a maven build deterministic, but in practice I have yet to see it done. Of course, that could just be a statement about the crowd I hang out with, but I think there are more fundamental problems. Wouldn't you have to specify explicit version numbers for not only your immediate dependencies, but also all transitive dependencies? Not that that's necessarily a bad thing in itself--regardless of what build system you use, if you want a reproducible build, one way or another you have to specify particular versions of all dependencies. But if you have to provide a configuration file that explicitly lists all direct and indirect dependencies, then what's the point of all the sophisticated transitive dependency management functionality we hear so much about? Also, you didn't address the gp's complaint that the build tool will spontaneously update not only the project dependencies, but also itself. Some maven plugin developer out there can release a new version, and a project that compiled fine yesterday suddenly won't compile anymore. I'm sure there's a way to force it to use particular versions of the plugins as well, but by the time you explicitly list every transitive dependency and every plugin used in every phase of the lifecycle, you've got a really big configuration file, especially for a tool whose motto is "convention over configuration." Not to mention that if you accidentally forget to specify a version number for one of these potentially dozens of packages, maven will happily default to using the latest version, which makes your build secretly nondeterministic.
- zenocon 17y ago
  What you're missing here is sort of described in the RTFM. There are a couple very good, free books on maven that describe this, but in essence: 1) You absolutely should have your own local repository (e.g. Archiva). 2) You should use <dependencyManagement> and <pluginManagement> tags to force all projects to have the same versions o all deps and plugins. 3) Don't even try using snapshots unless you know what you are doing.
  - aaronkaplan 17y ago
    A local repository doesn't address the problems I mentioned above, it addresses a separate problem, namely the nondeterminism that comes from relying on external repositories that might not always be available. As for the <dependencyManagement> and <pluginManagement> tags, you didn't address my complaints: (1) if you have to explicitly list every dependency, including indirect ones, doesn't that negate the benefit of maven's transitive dependency management? [Edit: ok, not entirely, because it takes care of downloading the dependencies automatically. But one of the supposed arguments for maven is this: if your project depends on foo, and foo depends on bar and baz, you can just specify foo in the pom, and bar and baz will be pulled in automatically. But that's disingenuous: if you want your build to be deterministic, and of course you do, you still have to specify bar and baz explicitly.] And (2) if you forget to specify a version number for one of the dependencies, doesn't maven just default to the latest version at build time, thus becoming nondeterministic?
    - tentonova 17y ago
      ... if you forget to specify a version number for one of the dependencies, doesn't maven just default to the latest version at build time, thus becoming nondeterministic? No. ... if you want your build to be deterministic, and of course you do, you still have to specify bar and baz explicitly If you declare a dependency on non-snapshot foo, then it will also declare a dependency on non-snapshot bar, ergo, reproducible build. Your comments seem to be the standard "I don't understand Maven, but I hear that it's broken."
prodigal_erik 17y ago
If there's no built-in interoperability, does it become my job to translate my maven dependency on foo:foo:jar:1.2.3 into a spec file dependency on foo-1.2pl3-4.noarch.rpm, and that my maven and rpm repositories each have a package which was built from the same code, and that all foo's dependencies match up in both places (recursively)? How do people actually use this stuff, short of just slopping jars around with rsync and abandoning all automatic management?

aaronkaplan 17y ago

I think you're right that in principle one can make a maven build deterministic, but in practice I have yet to see it done. Of course, that could just be a statement about the crowd I hang out with, but I think there are more fundamental problems. Wouldn't you have to specify explicit version numbers for not only your immediate dependencies, but also all transitive dependencies? Not that that's necessarily a bad thing in itself--regardless of what build system you use, if you want a reproducible build, one way or another you have to specify particular versions of all dependencies. But if you have to provide a configuration file that explicitly lists all direct and indirect dependencies, then what's the point of all the sophisticated transitive dependency management functionality we hear so much about? Also, you didn't address the gp's complaint that the build tool will spontaneously update not only the project dependencies, but also itself. Some maven plugin developer out there can release a new version, and a project that compiled fine yesterday suddenly won't compile anymore. I'm sure there's a way to force it to use particular versions of the plugins as well, but by the time you explicitly list every transitive dependency and every plugin used in every phase of the lifecycle, you've got a really big configuration file, especially for a tool whose motto is "convention over configuration." Not to mention that if you accidentally forget to specify a version number for one of these potentially dozens of packages, maven will happily default to using the latest version, which makes your build secretly nondeterministic.

zenocon 17y ago
What you're missing here is sort of described in the RTFM. There are a couple very good, free books on maven that describe this, but in essence: 1) You absolutely should have your own local repository (e.g. Archiva). 2) You should use <dependencyManagement> and <pluginManagement> tags to force all projects to have the same versions o all deps and plugins. 3) Don't even try using snapshots unless you know what you are doing.
- aaronkaplan 17y ago
  A local repository doesn't address the problems I mentioned above, it addresses a separate problem, namely the nondeterminism that comes from relying on external repositories that might not always be available. As for the <dependencyManagement> and <pluginManagement> tags, you didn't address my complaints: (1) if you have to explicitly list every dependency, including indirect ones, doesn't that negate the benefit of maven's transitive dependency management? [Edit: ok, not entirely, because it takes care of downloading the dependencies automatically. But one of the supposed arguments for maven is this: if your project depends on foo, and foo depends on bar and baz, you can just specify foo in the pom, and bar and baz will be pulled in automatically. But that's disingenuous: if you want your build to be deterministic, and of course you do, you still have to specify bar and baz explicitly.] And (2) if you forget to specify a version number for one of the dependencies, doesn't maven just default to the latest version at build time, thus becoming nondeterministic?
  - tentonova 17y ago
    ... if you forget to specify a version number for one of the dependencies, doesn't maven just default to the latest version at build time, thus becoming nondeterministic? No. ... if you want your build to be deterministic, and of course you do, you still have to specify bar and baz explicitly If you declare a dependency on non-snapshot foo, then it will also declare a dependency on non-snapshot bar, ergo, reproducible build. Your comments seem to be the standard "I don't understand Maven, but I hear that it's broken."

prodigal_erik 17y ago

If there's no built-in interoperability, does it become my job to translate my maven dependency on foo:foo:jar:1.2.3 into a spec file dependency on foo-1.2pl3-4.noarch.rpm, and that my maven and rpm repositories each have a package which was built from the same code, and that all foo's dependencies match up in both places (recursively)? How do people actually use this stuff, short of just slopping jars around with rsync and abandoning all automatic management?