Getting Maven POM parent in Gradle

Old Forum Archive
1

In Gradle, I am trying to copy to my workspace, all dependencies I need for a package in the shape of a local repo. I know I can get all the files with:

configurations."$configName".each { file -> … }

This way I can also resolve all the POMs for each artifact, but if those POMs have parents defined in them, Gradle resolves them to its local repo.

Can I access this list somehow? The files together with their POMs and parent POMs?

2

[…] all dependencies I need for a package in the shape of a local repo

What kind of local repo?

This way I can also resolve all the POMs for each artifact

How? Which Gradle version are you using?

[…] Gradle resolves them to its local repo

Are you referring to the Gradle artifact cache, or something else?

3

Yes, I meant the local cache. I’m using 1.4 And it’s a simple Maven-style local repo that can is mutable in between computers.

4

This way I can also resolve all the POMs for each artifact

How are you doing this?

5

I resolve my initial configuration, get the list of ResolvedArtifacts, and in a new configuration, I add them as dependencies with “@pom”, then resolve that, and copy over the merged set of ResolvedArtifacts to my output directory.

I realize it’s kind of a hack. Maybe you can suggest a better way of doing this?

Collection artifacts = configurations.localRepo.resolvedConfiguration.resolvedArtifacts Collection poms = artifacts*.moduleVersion.id.collect { id ->

“$id.group:$id.name:$id.version@pom” } poms.each { pom -> dependencies.add(configurations.localRepoPoms, pom) } artifacts.addAll(configurations.localRepoPoms.resolvedConfiguration.resolvedArtifacts)

Something like this…

1 Like
6

I wouldn’t call it a hack. It’s more or less what I had in mind, as I’m not aware of a built-in Gradle API for getting a module’s POM. Probably you want to get the configuration’s dependencies though, not its artifacts.

To get at the parent POMs, you’d have to parse the ‘parent’ element of the downloaded POMs and repeat the resolving.

Keep in mind that a genuine Maven repository contains additional metadata files. Depending on your use case, you might want to generate those as well.

In almost all cases where people told me that they need to generate a Maven repo, they would have been better off with a repository manager like Artifactory or Nexus.

7

Thanks for the advice, Peter.

I actually already started parsing POMs, but it got really slow when parents had parents that had parents that had parents… you know.

Anyway, thanks again.

1 Like
8

I’m looking for the same feature, and is a hard requirement in my organizations build.

@Csaba, did you have a final solution for this you could share?

@Peter, has there been any updates in the last year that would change your answer? I’ve implement something close to what Csaba has referenced, but still hitting the issue with needing to parse POMs, etc. Also what is the additional meta-data you referenced?

We use a repo manager, but exporting the entire lib cache is not scalable for us. Obviously the POM resolution code exists inside of Gradle, it would be very useful to have this exposed at the API level.

9

Hi Casey,

We’ve been using the method I’ve mentioned ever since then, constantly. I cannot really share the code, but the idea is the following:

  1. Given a module version identifier, I add it to a configuration and resolve it. 2. For each module among the dependencies, I add a dependency to their POM in another configuration. 3. I resolve that new configuration of POMs.

From here, it’s recursive: 4. Parse all POM XMLs, deduce parent, if any, and add it to another configuration (the name of this is dynamically growing). 5. If there were any new parents added, I resolve the configuration, and from all the new files, I start again (so parents’ parents’ parents… also get resolved). 6. Continue until the new dynamic configuration is empty (i.e. no more parents, or all are already resolved).

Hope this helps. If you need some more, let me know.

Csaba