[Feedback needed] Gradle Module Metadata

(Cédric Champeau) #1

Hi folks,

I’m starting this thread to gather feedback about Gradle Module Metadata, which ships 1.0 in Gradle 5.3.

We’re looking for early adopters, both on the library authors side (you build a library, and you’d like to publish Gradle Module Metadata) and as a consumer of module metadata.

Feel free to ask questions here, this thread might be split into specific discussions as needed.

Thanks a lot!

(Ingmar Steiner) #2

Looks like a very nice feature that would also help with managing elaborate custom details about published artifacts at the dependency management level!

However, I’m afraid I need a leg up on how to try this out. In a data project, I did this:

  1. I upgrade my Gradle wrapper to 5.3-rc-3
  2. I appended enableFeaturePreview("GRADLE_METADATA") to my settings.gradle
  3. I ran ./gradlew publish, but could not find any *.module files in the target repository

Inspecting this further, I ran ./gradlew generatePomFileForMavenPublication and see this output:

> Task :generateMetadataFileForMavenPublication SKIPPED
Maven publication 'maven' isn't attached to a component. Gradle metadata only supports publications with software components (e.g. from component.java)

My project only uses the ‘base’ and ‘maven-publish’ plugins, and the ‘default’ artifact is just a Zip task:

task packageRefPitch(type: Zip) {
    from extractData.refDir
    classifier 'reference'
}

artifacts {
    'default' packageRefPitch
}

publishing {
    publications {
        maven(MavenPublication) {
            artifact packageRefPitch
        }
    }
    repositories {
        maven {
            url "$buildDir/repo"
        }
    }
}

How can I publish a Gradle .module file with some custom metadata? If that doesn’t work directly, how can I register the ‘default’ artifact of my data project as a component?

(Cédric Champeau) #3

The error message says it all:

Maven publication 'maven' isn't attached to a component. Gradle metadata only supports publications with software components (e.g. from component.java)

You must have a software component, so that Gradle understands the semantics of your module (that’s what Gradle Module Metadata is about). So you need something like:

from components.java

adhoc artifacts are by definition out of context :slight_smile:

(Ingmar Steiner) #4

Is it planned to support ad-hoc artifacts? Or do I have to find a way to register my custom artifact as a component? (I tried that some time ago, but gave up without finding a solution. Any pointers would be much appreciated!)

(Cédric Champeau) #5

The whole idea is that there are no adhoc artifacts. Artifacts are attached to variants. And yes there’s an API for that, using SoftwareComponentFactory. The Java plugins uses this API to declare custom components.

(Ingmar Steiner) #6

Thanks very much for the prompt and helpful replies! I’ll see what I can come with and open a different discussion if necessary.

(Igor Melnichenko) #7

Is there a public API to create (and hopefully publish) the metadata outside build scripts?

My use case: I develop a Gradle plugin that facilitates software development for an environment that includes a lot of JARs not available in any repositories by default. So the plugin must be able to publish artifacts in a repository without making corresponding publications part of a project it applied to.

Currently I use org.eclipse.aether to publish these artifacts along with Maven POM metadata but Gradle Metadata looks much more suitable for this (considering complex relationships between the artifacts) so I’d like to try it.

(Cédric Champeau) #8

No, currently only Gradle is capable of generating and publishing Gradle Module Metadata. One reason being that we generate it from our model (components.java, …) so we don’t need this, but it would be worth extracting a library from the writer.

(Ross Goldberg) #9

org.gradle.jvm.version

Only allows a minimum java version.

It should support a more verbose version syntax, presumably the one used by build scripts for dependencies.

That would be useful for modules that don’t yet support newer versions of java (as many projects don’t yet support 9, 10, 11, or 12), and for ones that use APIs / features that have been removed from newer or future versions of java.

This would help devs quickly determine the latest java they can use, and help pinpoint roadblock projects.

(Cédric Champeau) #10

The org.gradle.jvm.version is NOT a version constraint. The only thing it says is “if you try to use it on a VM that doesn’t support this version, this is going to fail”. You can have different variants with higher levels, but it’s not mandatory. All you explain is that if you have different variants, Gradle can choose the most appropriate (closest match).

(Ross Goldberg) #11

It would be useful if org.gradle.jvm.version was changed to be a version constraint.