Equivalent to Gemfile.lock in Maven and gradle

Question

How Maven (client) and IvyResolver (used by Gradle) Bundler solves the dependencies of libraries that were declared in the configuration file (Gemfile for bundler). However, after that, the Bundler saves dependency resolution on Gemfile.lock. This allows other developers to use the same libraries.

For example, Maven uses a determinist, using an obscure way to resolve conflicts when resolving dependencies. For example, specifying the version as ...

<version>1.0.1</version> 

does not guarantee that the version will be used. And specifying the version as ...

 <version>[1.0.0,2.0.0)</version> 

give us almost no guarantee.

Yes, I can manually write all the versions listed

 mvn dependency:resolve 

But is there any automatic way to do this?

To be very clear: is there any equivalent of Gemfile.lock in Maven or Gradle?

---

Java developers, if you are not familiar with Gemfile.lock, Bundler, check:

http://bundler.io/v1.3/rationale.html

The important part that I copy below:

Code Verification in Version Control

After developing the application, check the Gemfile and Gemfile.lock snapshot for a while. Now, your repository has a record of the exact versions of all the gems that you used the last time you knew that the application worked. Keep in mind that although your Gemfile contains only three gems (with varying degrees of severity), your application depends on dozens of gems as soon as you take into account all the implicit requirements of the gems you depend on.

This is important: Gemfile.lock makes your application one package of your own code and third-party code, it has been running the last time when you know for sure that everything works. Specifying the exact version of the third-party code in which you depend on your Gemfile will not provide the same guarantee, because gems usually declare a range of versions for their dependencies.

The next time you run the installation of the package on the same computer, the provider will have it already have all the dependencies that you need and skip the installation process.

"You are wrong. Maven can guarantee the version."

Yes, right. If you have a version declared in pom.xml itself, maven uses it. But, if it were announced in the parent pump, this guarantee would disappear.

Dependency matching - this determines which version of the dependency will be used when multiple versions of the artifact are detected. Currently, Maven 2.0 only supports “nearest definition”, which means that it will use the version of the closest dependency on your project in the dependency tree. You can always guarantee a version by declaring it explicitly in your POM project. Please note: if two versions of the dependencies are at the same depth in the dependency tree, until Maven 2.0.8 decides which one will be defeated, but since Maven 2.0.9 is the order in the ad that counts: the first ad wins .

“nearest definition” means that the version used will be closest to your project in the dependency tree, for example. if the dependencies for A, B and C are defined as A → B → C → D 2.0 and A → E → D 1.0, then D 1.0 will be used to construct A, since the path from A to D via E is shorter. You can explicitly add the dependency to D 2.0 in A to force D 2.0

Oh, it looks like it's the opposite of the DRY principle.

Answer 1

The nebula.gradle-dependency-lock plugin does just that.

PS: Gradle no longer uses Ivy (if that's what you mean by IvyResolver).

Answer 2

The solution for blocking dependencies is to use the <dependencyManagement> section of the current pom or its parent and never declare a <version> in the <dependencies> section of your pom.

You can apply this behavior with the Pedanic Pom Enforcer plugin (so only the parent project can declare dependency versions). You can also use the plugin to completely ban all transitive dependencies or various subsets (I don’t even think that gradle or package have this level of configurability). Some people really like this behavior, as you can make it so that you declare every addiction that makes you aware of how much your application / library can be inflated / connected.

Yes, it’s not like DRY, because you basically have to declare the package twice (once in dependencyManagement and second time without version in dependencies ). This is even worse if you decide to ban all transits. You can reduce the DRY problem by using import (i.e. Bom: pom material file) and / or parent posts. Some company, such as mine, has a main parent pom with each dependency that each project uses (hence, blocking the version of libraries in projects). Remember that a parent or imported pom may also be a version!

As for the behavior of the gem lock file, nothing like that exists ... err it just isn't like KISS there (which, as I said, I burned Gem.lock badly and prefer the maven / gradle way ... everyone has their merits). You can write a plugin, although it is based on the maven dependency plugin (i.e., upload the analyzed dependencies to a file).

Answer 3

You are wrong here. If you explicitly specify

 <version>1.0.1</version> 

in your pom, it is guaranteed that this version will be used over transitive dependencies that can use another version.