Possible to implement custom RepositoryHandler etc so other sources can participate in dep resolution process?

Help/Discuss
1

(Sorry if this is not clear or if I’m missing something simple–I’m new to gradle–but I think what I might be looking for is really just some good documentation or write-up of how this can be made to work, or decent working examples.)

I want to figure out how to get other repositoires, like python PyPI to participate in Gradle’s dependency resolution process as an equal participant to Ivy/Maven. I saw that the PyGradle plugin requires you to move everything out of PyPI into Ivy, but with Gradle’s super-extensibility it seems like it should be possible to supply a custom type to "repositories in the same list as, say, mavenCentral(), so that declared dependencies can be resolved in the same dep resolution process, but under-the-hood could use PyPI.

I don’t mind implementing a lot of code in the right places if Gradle has the right abstractions in place, but those relationships don’t seem very well documented and there seem to be a lot of “hard-coded” assumptions. For example, Project.RepositoryHandler (which is ostensibly not java-specific) seems very hard-coded to be able to work with specific types of only java repositories, and it manages ArtifactRepository objects which only have get/setName methods… there are no generic/polymorphic dependency resolution methods on those types, so I am very confused how gradle ever knows how to use those ArtifactRepository objects to actually resolve or retrieve anything. (What data types own the logic to do that part of the work? And what is the logical path to that code from ArtifactRepository?)

Can anyone point me to anything to will help me understand this? I really want us to be able to use gradle for some new multi-language build infrastructure and workspace tooling, but I’m starting to worry that it has a nice facade on top of a lot of assumptions due to its java origins.

2

Having attempted it, all I can say it is not easy task. This is definitely one area where the Gradle folks know some more public APIs are needed, but there a remore important things to take care of at present and the respotiory handling strategy has to be thought through.

Having said that, in the JRuby-Gradle project we have kludhed in a little daemon that runs inside GRadle that presents the rubygems repository as a maven-like repo. It is not ideal, but it solves the problem for now.

3

I’m totally unfamiliar with PyPi, is it possible to write an http front end adapter for it that uses the maven rest interface? Perhaps you could even start/stop jetty embedded in a gradle plugin and configure the localhost http maven repository adapter

4

I’m sure we could shim an interface in front of it in one form or another (as Schalk did, above, as well). But that’s just another layer of potential points of failure between the build and the artifact repositories that it depends on. I’d love to be able to make gradle talk directly to the repositories in their native languages through well-tested, strongly typed things

I’m more and more concerned about the fact that projects have only a list of ArtifactRepository objects. Unless I’m misreading the API docs, something in the gradle core codebase must be explicitly casting those ArtifactRepository objects to a java-specific data type that has useful methods on it–I haven’t had time to dig that far yet.

5

Thanks, Schalk. Not what I was hoping to hear, but it seems like a feasible path at least.