Having versioned, pre-built tools (ex python interp, a linter, swig) participate in dependency resolution?


(Dave Smith) #1

So I’m pretty sure this is doable, I’m just having a hard time finding the right set of things to search for to find who ahs done it or described it… if anyone can point me in the right direction I’d be appreciative.

I want to be able to have all parts of tool chain, configuration, and other non-source inputs partipate in the dependency resolution process. So, for example, I want a python project to be able to actually declare a dependency on python 3.6 and have that interpreter pulled down as a versioned package and available to the gradle plugin that is driving a python build.

Python is just one example, one can imagine any number of tools that might not be present on the machine doing the building which could be fetched as versioned dependencies. Maven doesn’t seem appropriate for this, how would you all approach this? Or are there docs for how to do it, somewhere?

I’m learning gradle and consider this a learning exercise as well as a practical matter, so I’m prepared to write custom plugins or custom dep resolvers etc if necessary. :slight_smile:


(Stefan Oehme) #2

Well written tasks (including your own) allow you to supply the path to the tool to be used (or the classpath in case of Java based tools). How you get the tool depends on where and what it is.

If it’s a jar in a Maven repository, you can create a Configuration and set that as the classpath of the task. Gradle will resolve it before the task gets excuted. An example of that is Gradle’s Checkstyle plugin that can be configured to fetch any version of Checkstyle.

If it’s a binary that can be downloaded via http, you can write a simple task that fetches it with Files.copy. Then you let the tasks that need it depend on that download task.