Check if Dependency is Dynamic or Changing?

Help/Discuss
1

Hi there,

So I’m just trying to add some logic to a build that will fail when the build contains dynamic or changing dependencies (say like the Maven release plugin) … I’m aiming to have this so that my master branch is not allowed changing / dynamic dependencies.

I’ve done this before with SNAPSHOTs using basically the same implementation as this SO post http://stackoverflow.com/questions/29553215/gradle-equivalent-of-maven-enforcers-requirereleasedeps … Now I’m trying to do something where I use unique version numbers for every build rather than SNAPSHOT’s and can see how I could kinda do the same thing using something like version.endsWith('+') but I’m wondering if there is a better way to identify deps as changing/dynamic than string comparison?

2

There’s nothing in the API for this. Essentially, our internal resolution logic is just doing string comparison to make the same determination. For changing modules we interpret anything with a ‘SNAPSHOT’ suffix as changing but you can also set changing = true on the dependency itself. In your logic you should check for both. For dynamic versions its a bit more complex. Technically it’s more than just the ‘+’ character. We also support version ranges ex. [1.0, 2.0).

3

Thanks Mark,

Thats all good, string compares it it is.

Though any pointers to the internal logic doing the resolution? Would be cool if I could reuse some of that stuff.

Thanks again
Steve

4

Here’s our internal implementation if you want to use that as a guide. There’s a pretty gnarly regex to determine if the version number is a range selector.

5

Super thanks for this info Mark

6

Hi @smozely,

Not quite what you were originally after, but have you taken a look at the nebula dependency lock plugin?

We have found it to be a good balance between dynamic and static dependencies. We use it to allow our CI system to integrate everything very early with dynamic dependencies, but at points we can control using jobs that explicitly test new dependency resolutions before committing the updated lock files (developers have the option of committing updated lock files as well, as certain scenarios require it).

If you were to stop committing lock files on your master branch, the dynamic dependencies would be ignored. To me it would make sense that you might still want to fail on SNAPSHOT dependencies, since releasing from master with those might be a bad idea (or for whatever reason you want master stable).