Publishing artifacts does not put non-jar <type> in the dependencies block

[ducrohet]

When publishing an artifact that has dependencies that are not jar (aar in our case), the dependency block in the pom file does not contain any type information.

The pom should looks like this:

<project ...> 
   <modelVersion>4.0.0</modelVersion> 
    <groupId>com.android.support</groupId> 
    <artifactId>leanback-v17</artifactId> 
    <version>21.0.0-rc1</version> 
    <packaging>aar</packaging> 
    <dependencies> 
       <dependency> 
         <groupId>com.android.support</groupId> 
         <artifactId>recyclerview-v7</artifactId> 
         <version>21.0.0-rc1</version> 
         <scope>compile</scope> 
         <type>aar</type>     <---- this s the part that's missing
      </dependency> 
  </dependencies> 
</project> 

<type>aar</type> is missing from the dependency section.

Note that Gradle handles this properly, but Maven does not. The fact that the dependency's own pom has <packaging>aar</packaging> does not seem to help, as I would have expected.

[liutikas]

Could we get an update on this bug? It has been over 8 months without any response.

[marcphilipp]

@ducrohet @liutikas Thanks for the ping! Are you using the maven plugin or the maven-publish plugin? Could you please provide a small sample project?

[liutikas]

We are using maven plugin.

MavenPublish.zip

1. Download the project
2. Run ./gradlew uploadArchives
3. Check path/to/project/mylib/repo/net/liutikas/myLibrary/1.0.0/myLibrary-1.0.0.pom

Observe that pom file dependencies say:

  <dependencies>
    <dependency>
      <groupId>com.android.support</groupId>
      <artifactId>appcompat-v7</artifactId>
      <version>27.1.1</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>

and it is missing <type> tag even though this artifact is aar type.

[liutikas]

Are you able to reproduce this issue?

[liutikas]

Note this issue is also true for dependencies on projects within the same settings.gradle.

For example, if I have a project A and project B, both of them are aars and A depends on B, pom file will not have build type in the pom file.

We have to add some pretty hacky code to work around that:
https://android.googlesource.com/platform/frameworks/support/+/refs/heads/support-library-27.1.1/buildSrc/src/main/kotlin/android/support/MavenUploadHelper.kt#99

[marcphilipp]

@gradle/dependency-management Is the packaging from the POM of a dependency currently available in our internal data structures?

[liutikas]

Any updates on this?

[ljacomet]

@marcphilipp Yes it is available, and so is the type of a Maven dependency. And the type is properly published with both the maven and maven-publish plugins when explicit set in the dependency declaration.

This means that issue probably is about plugin interactions.

@liutikas I can't give you any timeline for getting this fixed.

[liutikas]

@ljacomet could you point me on where the type is available of a Maven dependency? I looked at org.gradle.api.artifacts.ModuleDependency which has getArtifacts(), but sadly the set is empty unless the dependency explicitly adds the type foo:bar:1.0@aar.

[mathjeff]

Any ideas about things that we as users could do to help get this fixed sooner?

(The need for projects to specify "@aar" in dependencies seems to make it more likely for #5174 (or perhaps #7594 ) to occur)

[liutikas]

Could we get an update on this? It would be great to have this resolved. Alternatively, it would be nice to get a response to:

@ljacomet could you point me on where the type is available of a Maven dependency? I looked at org.gradle.api.artifacts.ModuleDependency which has getArtifacts(), but sadly the set is empty unless the dependency explicitly adds the type foo:bar:1.0@aar.

[juanchosaravia]

Any updates on this? I'm having the same issue

[jjohannes]

Unfortunately the issue persists. But there are some updates with Gradle 6 (RC1 available now):

• We now fully migrated to the new mave-publish plugin. So we can think about solutions in that plugin.
• With Gradle 6, you also publish Gradle Module Metadata, which does not suffer from this issue. So if you are only concerned about Gradle consumers the effect of the issue goes away because the dependency/module information is taken from the module and not the pom files.
• Solving this issue in maven-publish for pom should be possible but it still requires some design decisions. The problem is that we would have to look into the dependencies to determine their packaging. But, normally, for publishing we do not even resolve the dependencies. However, you can now publish resolved versions - in that case we resolve and know the target modules, and could take the information from them. But it would be good if we find a solution that also works if you publish the declared versions. Probably as an opt-in, where we still do the resolution, but do use the original versions.

For now, I would recommend the following workaround for maven-publish:

• Do not change anything in the dependency declarations to work around this. That could also screw up your module metadata (i.e. I would not recommend the @aar workaround anymore).
• Instead, use withPom in your publication declaration to "fix" the necessary dependencies. E.g.:

pom.withXml {
    val dependencies = asNode().children().find { it is Node && it.name().toString().endsWith("dependencies") } as Node?
    dependencies?.children()?.forEach { dep ->
        if (dep is Node) {
            val groupId = dep.children().first { it is Node && it.name().toString().endsWith("groupId") } as Node
            val artifactId = dep.children().first { it is Node && it.name().toString().endsWith("artifactId") } as Node
            if (isAarDependency(groupId.children()[0] as String, artifactId.children()[0] as String)) {
                dep.appendNode("type", "aar")
            }
        }
    }
}

Where isAarDependency(group, name) has the knowledge if a dependency needs the aar type or not.

[liutikas]

Any updates here? It would be great to be able to resolve this issue without having to work around it. It is especially problematic now due to configuration caching, as that means you can no longer access project within pom.withXml

[Hanmac]

Any plan on fixing this after 5 years? it still causes problems with maven projects

[daymxn]

Friendly bump, we're still suffering from this over at Firebase :')

[jvandort]

We are looking into this. In general, you should not need to resort to re-writing XML in order to publish proper component metadata (as is necessary to resolve this issue)