Menu
As Maven (client) and IvyResolver (used by Gradle) Bundler solves libraries dependencies that was declared on configuration file (Gemfile for bundler). However, after that Bundler saves dependency resolution on Gemfile.lock. It allows other developers use exactly the same libraries.
For instance, Maven use a determinist by not clear way to resolve conflict in dependency resolution. For example, specifying version as ...
<version>1.0.1</version>
is not guarantee that version will be used. And specifying version as ...
<version>[1.0.0,2.0.0)</version>
give us almost no guarantee.
Yes, I could write manually all versions listed by
mvn dependency:resolve
But, is there any automatic way to do that?
To be very clear: is there any equivalent to Gemfile.lock in Maven or Gradle?
Java developers, if you are not familiar with Gemfile.lock, Bundler, please check:
http://bundler.io/v1.3/rationale.html
The important part I copy below:
Checking Your Code into Version Control
After developing your application for a while, check in the application together with the Gemfile and Gemfile.lock snapshot. Now, your repository has a record of the exact versions of all of the gems that you used the last time you know for sure that the application worked. Keep in mind that while your Gemfile lists only three gems (with varying degrees of version strictness), your application depends on dozens of gems, once you take into consideration all of the implicit requirements of the gems you depend on.
This is important: the Gemfile.lock makes your application a single package of both your own code and the third-party code it ran the last time you know for sure that everything worked. Specifying exact versions of the third-party code you depend on in your Gemfile would not provide the same guarantee, because gems usually declare a range of versions for their dependencies.
The next time you run bundle install on the same machine, bundler will see that it already has all of the dependencies you need, and skip the installation process.
Yes, right. If you have a version declared in the very pom.xml, maven uses it. But, if it was declared in parent pom, this garantee is vanished.
Dependency mediation - this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the "nearest definition" which means that it will use the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, until Maven 2.0.8 it was not defined which one would win, but since Maven 2.0.9 it's the order in the declaration that counts: the first declaration wins.
"nearest definition" means that the version used will be the closest one to your project in the tree of dependencies, eg. if 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 when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0
Oh, looks like this is the opposite of DRY principle.
556
The Gemfile. lock allows you to specify the versions of the dependencies that your application needs in the Gemfile , while remembering all of the exact versions of third-party code that your application used when it last worked correctly. By specifying looser dependencies in your Gemfile (such as nokogiri ~> 1.4.
Gradle provides support for importing bill of materials (BOM) files, which are effectively .pom files that use <dependencyManagement> to control the dependency versions of direct and transitive dependencies. The BOM support in Gradle works similar to using <scope>import</scope> when depending on a BOM in Maven.
Gradle is based on a graph of task dependencies – in which tasks are the things that do the work – while Maven is based on a fixed and linear model of phases. With Maven, goals are attached to project phases, and goals serve a similar function to Gradle's tasks, being the “things that do the work.”
Short answer: yes. There's no conflict between having two independent build scripts for the same project, one in Maven and one in Gradle.
The nebula.gradle-dependency-lock plugin does just that.
PS: Gradle doesn't use Ivy anymore (if that's what you mean by IvyResolver).
156
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
