Ideas for dependency management

Old Forum Archive
1

Hey Gradlers,

i’m describing a part of my build and hoping to get some ideas for improvement! Our project A that is based on project B. Project B does exist in multiple branches (~8), with multiple versions per branch (~5). So that are approx. 40 versions of B. For each version of B we have an set of artifacts for that version we’re using to setup projectA. This includes the jars of B, specific java files for B, specific config scripts for B, etc. Most of the artifacts stay the same between versions of a branch, only from time to time something changes. Some branches are also almost identical.

Now the way to manage the artifacts right now is: - Have a local repository containing the uniques files (jars, java files, config scripts, etc). - For each version of B we have a folder which can contain a dependencies.gradle file which defines all required files - If no dependencies.gradle is defined, we take that from the upstream version

So this is already not to bad, but the downside is that once one file changes the whole dependency file has to be duplicated in order to change it slightly. Now i’m thinking about a way to only describe for each version: - what has been added - what has been removed - what has been replaced (other version)

Any ideas on that ? best Johannes

2

Thinking about: - having my main gradle script creating an homegrown object - pass that through multiple version-gradle-scripts via ‘apply from’, each version script could modify that object (add or remove stuff from it)

Appreciates any hints on implementation! best Johannes

3

I think you’re on the right track with your reply there.

I’d model your setup with your own classes. Then essentially pass this model through the transformation layers to allow it to be configured/changed. Then at the end I’d apply it to the Gradle model (e.g. actually create the dependencies etc.).

4

Yep, went into this direction, starting to make it a plugin, thanks! Except for the startup speed i really like Gradle!

5

Are you using the Gradle Daemon?

6

Yep using it. Could it be that in case a build is interrupted or fails the daemon is stopped ? Maybe thats the reason for the instability in terms of startup speed i’m experiencing…

7

If you kill the build (e.g. ctrl-c) it will tear down the daemon.

8

Gradle 1.6 has a regression in terms of build script compilation performance, which is fixed in 1.7. Maybe that’s what you are seeing.