nebula-plugins / gradle-dependency-lock-plugin

A plugin to allow people using dynamic dependency versions to lock them to specific versions.
Apache License 2.0
292 stars 42 forks source link

Add example(s) of use #47

Open grodin opened 9 years ago

grodin commented 9 years ago

It's probably just me, but I'm finding it hard to understand exactly what this plugin does. I think it might help with a particular problem I've got, but right now, I don't understand enough to be able to decide. A crystal clear, quite explicit example would really help.

The problem I'm dealing with is a dependency which is currently under development, so all the releases have version 2.0-SNAPSHOT. I want to fix on a particular snapshot release, i.e. a release on a particular day, so that I won't constantly have gradle downloading the most recent snapshot and breaking things. There are obviously other ways of doing this, but I found the dependency-lock plugin, and it seems like maybe it does what I want. Am I barking up the wrong tree?

bmuschko commented 9 years ago

It's probably just me, but I'm finding it hard to understand exactly what this plugin does. I think it might help with a particular problem I've got, but right now, I don't understand enough to be able to decide. A crystal clear, quite explicit example would really help.

Improving the documentation would certainly be helpful.

I want to fix on a particular snapshot release, i.e. a release on a particular day, so that I won't constantly have gradle downloading the most recent snapshot and breaking things.

Using a timestamped SNAPSHOT version is only possible with Gradle >= 2.4. Currently, the plugin doesn't work with 2.4 yet. Once the plugin is compatible with 2.4, you'd be able to solve your use case with the plugin.

benvandenberg commented 8 years ago

We have a fairly complex multi-project Gradle build and have noticed that after 2.2.2, the plugin does not generate complete global.lock files, even after specifying the configurations we use in a

dependencyLock {
  configurationNames = [ 'list', 'of', 'configuration', 'names' ]
}

block.

We would like to see multi-project examples to see how the plugin is successfully used internally at Netflix. Given the size of our project, it is difficult for us to upload failing examples as it isn't always clear what is causing the plugin to fail for us, since the plugin's logging is fairly sparse.

nadavc commented 8 years ago

Hey @benvandenberg - thanks for your comments. Could you please describe this in a bit more detail? What is missing, exactly? Is it specific to certain projects or configurations?

benvandenberg commented 8 years ago

This line (in configureGlobalLockTask, DependencyLockPlugin.groovy), which was added in 2.2.3, causes the global.lock file to be nearly empty.

project.allprojects.each { it.configurations.add(conf) }

When it is removed, the global.lock file is populated again. We declare all of our "lockable" dependencies using the compile configuration, and would expect them to show up.

So I was hoping to see some examples of how the dependency lock plugin should be used, and should not be used, in a multi-project build in order to understand what we could do differently. An explanation of what that line is supposed to do would also help.

nadavc commented 8 years ago

Writing more comprehensive documentation is definitely on our list. Until that happens, you can find many working examples in our integration tests.

Having said that, if you could provide a working sample, we'd be happy to look into it and provide feedback as to expected behavior. Alternatively, join us on Gitter for a quick chat.

ftclausen commented 8 years ago

As @benvandenberg mentioned above merely adding that empty (in our case) detached configuration seems to nuke the "compile" configuration for all our projects. The resultant lock file only contains project dependencies and some a few testing related configurations. By commenting out project.allprojects.each { it.configurations.add(conf) } a complete lock file is generated. I think this detached configuration confuses nebula.plugin.dependencylock.tasks.GenerateLockTask some how.

We're still working on putting together a small test multi-project to demo this issue but any more info on what that (seemingly empty) detached configuration does would be much appreciated.