Comment by aaronkaplan | Hacker News Reader

Comment by aaronkaplan | Hacker News Reader

Parent Full thread

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?

Yes it does. A good local repo will cache it. They act as mirrors. Once its cached, and your build is working fine, you can force all your developers to use only your local repo. This solves all non-determinism problems by allowing you to have complete control over all version of all deps and plugins.

Take a look at how to configure settings.xml to force your users to use only your local repo.

As far as <dependencyManagement> tags -- the point of that is to hard-code the version of foo in one spot, like this:

<dependencyManagement> <dependency> <groupId>com.example</groupId> <artifactId>foo</artifacatId> <version>1.1</version> <dependency> </dependencyManagement>

In child pom, you then have this if you need foo:

<dependency> <groupId>com.example</groupId> <artifactId>foo</artifactId> </depdendency>

And if you use something like Archiva, and force your users through it via settings.xml, then the first time someone downloads foo, Archiva gets it from the web, caches it, all other requests for foo go to Archiva. If foo has a transitive dependency, it will also get fetched from the web one time and cached in Archiva. Thus, guaranteeing that your build is deterministic -- unless you explicitly change foo/bar in Archiva yourself.

... 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."

The original complaint was

> the far more likely scenario is your project depends on a specific version of some other project which in turn depends on the LATEST version of some other project, so you still get hosed even when downstream providers do remember to bump versions!

so are you saying this is impossible (non-snapshot artifacts are somehow forbidden from depending on snapshot artifacts, which is not what was claimed), or that every author has to understand this and package their artifacts perfectly to prevent this from becoming an actual problem?

Reply on news.ycombinator.com