P2: How do repositories work inside Gradle?

Help/Discuss
1

The What:
I’m trying to update https://github.com/dhakehurst/net.akehurst.build.gradle/tree/master/net.akehurst.build.gradle.resolver.p2 to work with newer Gradle versions (newer than 2.8). I have lots of problems with that because the implementation of that p2 repository plugin needed lots of internal API…
Where can I find useful documentation that would help me understand how repositories work inside Gradle? so that I could implement the p2 repository support on top of public API?

The Where:
I tried to research this in the Gradle 3.1 Documentation, Sources and on https://gradle.org/why/robust-dependency-management/
There is a link on that page called “Custom & legacy repositories” that leads to nothing.

The Why:
I’m migrating the build of a standalone Java application from ant & checked in jars to Gradle and dependencies on official repositories. Some of the repositories are hosted only in p2 repositories (org.eclipse.swt among them).

Gradle claims “If it’s out there, Gradle can grab it” and https://gradle.org/why/integrates-with-everything/ . So I assume that I didn’t look for the documentation in the correct place yet.

2

The repository API is unfortunately not yet extensible. So far the p2 use case has come up a few times, but we couldn’t find a contributor who wanted to push a public repository API forward. We didn’t get a lot of other requests besides p2, so the feature is relatively low priority compared to the many other ones we are currently building.

There are plugins like Goomph that convert p2 to Maven repositories such that Gradle can consume them. Maybe you can use that as a workaround?

3

I spent quite a bit of time (multiple hours during commute) trying to figure out how repositories work. Without much success. Maybe the complexity of the code turns contributors away here?

Also what about the broken links from the documentation? Were repositories extensible in older Gradle versions?

Goomph looks kinda interesting - but doesn’t support dependency translation, maybe still worth a look tough.

We didn’t get a lot of other requests besides p2,

I searched a bit and it seems like those that build gradle plugins to handle non java projects invent their own dependency specification mechanism. IOW there is demand but it’s easier to reinvent the wheel than to extend Gradle properly.

4

This does not refer to an extensible repository DSL, but to the fact that you can read any kind of other metadata and create plain old file dependencies from that. One example would be reading Eclipse .classpath files and taking the dependency information from there.

It seems to me that doing their own DSL and then just delegating to the underlying tool (like bower) is a very simple and workable approach. So there is no immediate pain to integrate bower into Gradle’s repository infrastructure. Finding a common abstraction for all kinds of repositories and then programming against that abstraction will not make the programming model easier, quite on the contrary. It would make things more performant and probably more consistent for the user, but the development cost of such a solution is high.

If you want to take this topic further, I’d suggest working on a more conceptual level. Think about what the common denominator of Maven, Ivy, Bower, NuGet etc. could be. Do they even agree on the most basic concepts like “components have a name and a version”? Based on this analysis you could propose an API that would allow you to implement different repositories. You could use the types in org.gradle.internal.resolve.resolver as inspiration. You could even write a small mock-up of that API and show how someone would use it to implement p2 support. We could then take that proposal through some design iterations and break it down into actual changes to the Gradle code base. Whether these are done by an outside contributor or the Gradle team is something we would have to figure out at that point. But let’s not worry about that yet, but focus on the design part.

Is that something you’d be interested in?

5

Gradle itself also doesn’t do that to integrate with Ivy or Maven repositories.

No I don’t think it is a good idea to have such a central infrastructure of Gradle changed by an external contributor. I’m working on an application that has like 10 dependencies, modifying Gradle is way out of scope for me.