Use the dependency resolution mechanism in Gradle as a library

Old Forum
1

Hi.

The application I am developing manages resources which we plan on hosting on a repository on the internet. The resources include jars with dependencies to other jars. Since managing and fetching dependencies is part of what Gradle does I am considering using the dependency part of Gradle as the engine. The form of the Gradle dsl is a bit too immutable for my needs, and oriented towards building a Project. I would like to be able to query the engine for the dependencies of a single artifact, both transitive and not, and for the engine to download what is not there in the background while my application is doing other work.

Since I have yet to find this library I am considering making it.

If somebody could point me in the right direction as to what internal classes to use, documentation to read and which modifications to make it would help me a lot.

Also I would appreciate any input from others with a similar need since I would like the result to be useful to others. I would be happy to contribute what I have made back to the community if it turns out to be a good idea.

Thanks Espen Brekke dbWatch

2

Since gradle understands maven why not (Eclipse-) Aether ? And since aether is the gist of repository resolvers I’d just look for Ivy support for Aether or write your own if you need that. Maybe this helps?

Let me know if you need more details.

Toni Menzel rebaze GmbH

3

Thanks. This is exactly what I need.

4

Hi,

I want to upvote this idea for different reasons. In Groovy, we have the @Grab annotation which currently relies on Ivy. In Grails, they switched from Ivy to Aether. Both Ivy and Aether have problems that the Gradle dependency resolution engine fixed.

In december 2013, we had a Groovy DevCon meeting where Luke Daley was present and he suggested that instead of migrating @Grab to Aether, we pushed the idea of Gradleware splitting the dependency resolution engine into its own, lightweight, library so that we can use it in both Groovy and Grails. That would allow us to support multiple backends, including, but not limited to, Ivy and Aether.

It is in particular important because Spring Boot, for example, started to fork @Grab to use Aether instead of Ivy. For Groovy, we don’t want that, but we would definitely switch to Gradle Dependency Engine (whatever its name) if it is made available.

2 Likes