Can I use the tooling API to determine a project's repositories?

Old Forum
1

Is there a way to use the tooling API to determine a which repositories a project uses? It looks like this information is somehow accessed as the EclipseProject model in the tooling API can download a sources jar and a javadoc jar from some remote repository. Is there any way to access this information?

2

This information isn’t exposed. In the Eclipse case, it relies on Gradle doing the downloading.

What you could do though is use a client side model, if you control the project as well. The only documentation we have on this is the this sample: https://github.com/gradle/gradle/tree/master/subprojects/docs/src/samples/toolingApi/customModel

3

Thanks this seems really useful. One further question: Why does it say that the model “may or may not implement the custom tooling model interface”? Is there a good reason why you would not want to implement the model interface?

4

Here is a bit extended version of Luke’s answer: When you implement your own ToolingModelBuilder it will have access to Project instance and can call http://www.gradle.org/docs/current/javadoc/org/gradle/api/Project.html#getRepositories() and build some response containing information about repositories.

To the ‘may or may not implement …’: as you can see in the example DefaultModel doesn’t implement CustomModel yet when it is obtained in the client with connection.getModel(CustomModel.class) the instance created is converted to an object that is instanceof CustomModel.

5

You loose the compile time check that the implementation does in fact implement the interface, so are there advantages of not implementing the interface that can out-weigh this loss?

6

The main advantage and the reason why it works is that it makes it possible to use toolingApi with a wide range of Gradle versions (both older and newer). Of course you can implement and it is a good way to go if you know the interface and implementation are guaranteed to be compatible.

If you’re interested there can be more details about this at http://gradlesummit.com/conference/santa_clara/2014/06/session?id=31168

7

@Chris: this allows you to evolve the interface in a backwards compatible way. The server (tooling api) and client (build runtime) may have different versions of this interface. The tooling API manages adapting the server side view of the model to the client side implementation dynamically to facilitate this evolution.