In my attempt to generate a Maven repository with all the dependencies required to compile a Gradle project, I’ve bumped into a problem which is explained in this post on the old Gradle forum.
Nowadays with the new Artifacts Query API we are able to obtain the POM for each dependency. The problem is that I’m not able to obtain the dependencies which were declared in a parent POM.
Let me show you what I mean by showing you some code. If I do the following:
The set of results will not contain any parent POM. What is more surprising is that those POM file which originally contained a reference to a parent POM, will also be generated with this reference, as follows:
Yeah, it’s exactly that with the single exception that I’d prefer to have a Maven repository instead. I actually found this plugin on http://plugins.gradle.org but didn’t really considered it due to the aforementioned detail.
I’ll give it a try since the path of generating POMs with Gradle doesn’t seem to be easy. Thanks @Lance_Java.
I haven’t used ivypot myself but the pattern(s) used to store the artifacts is configurable. So if it’s not a maven compatible location by default, you can configure it to save in a maven compatible location.
The problem is that even if you use maven layout, it will still store ivy.xml files, rather than pom files. ISSUE #15 is open, with the aim to address that. There is a link to a Gist in there, which might be useful to you.
Yeah, @bmuschko was kind enough to make that gist when I asked him about this slide in a talk he gave at the Gradle Summit 2015.
For simple Maven repos without parent POM dependencies it works well, but when you have some dependency that references a parent POM it doesn’t.
So I ended up creating my own gradle plugin to generate a Maven repository. It relies on mvn's maven-dependency-plugin:copy-dependencies to do the job of generating the Maven repository once I had the list of all dependencies required by all gradle projects. The problem with this, apart from depending on an external tool, is that it’s very fragile (in particular when projects depend on multiple versions of a certain library).