Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add example(s) of use #47

Open
grodin opened this issue Feb 24, 2015 · 6 comments
Open

Add example(s) of use #47

grodin opened this issue Feb 24, 2015 · 6 comments
Labels

Comments

@grodin
Copy link

grodin commented Feb 24, 2015

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
Copy link
Contributor

bmuschko commented Jun 9, 2015

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
Copy link

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
Copy link
Contributor

nadavc commented Oct 23, 2015

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
Copy link

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
Copy link
Contributor

nadavc commented Oct 24, 2015

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants