https://gradle.com/ logo
Join Slack
Powered by
What would it take to make convert a Gradle Module...
# community-support
a
What would it take to make convert a Gradle Module Metadata file to an equivalent POM file, so the module can be consumed by Maven? Just looking at the JVM ecosystem. I've found a way to publish Gradle libraries to GitHub, without using GitHub Packages (which is annoying because it requires authentication, and requires users define multiple repos for each library). I want to make it easier to prototype libraries, which would be much easier than setting up Maven Central. Basically: attach the files to GitHub Release assets. It's quite easy to tweak Gradle to process the files but not for Maven, because the files are in a 'flat' directory, and Maven requires files are in the typical 
org/package/version/
directories. To support Maven I think a Maven plugin could make it work, but I'm just curious whether a 
pom.xml
would be necessary, since the GMM contains the same data.
e
wouldn't it be easier to publish to github pages?
github release downloads have rate-limits which you'll run into without cookies or access tokens unfortunately
if you're going to write a plugin to munge the paths anyway, then github container registry can convinced to host arbitrary files without authentication
a
GitHub pages have size limits
my reading of the GitHub assets docs is there's no rate limiting, but I wouldn't expect high usage anyway because Gradle does a good job of caching dependencies
Each file included in a release must be under 2 GiB. There is no limit on the total size of a release, nor bandwidth usage. https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases#storage-and-bandwidth-quotas
v
Why would you want to transform a GMM to a POM? If you release using Gradle, Gradle already creates both accordingly.
e
a
I think that's caused by the API limits, i.e. calls to 
<http://api.github.com|api.github.com>
. Do you think it's also downloading release assets? The URLs are different at least, and don't start with 
<http://api.github.com|api.github.com>
Prior to Kotlin 2 the kotlin-native-prebuilt assets were downloaded from GitHub Assets, and I don't remember seeing rate limit issues when they were downloaded. Do you see rate limit issues when you download the larger files attached to the Kotlin releases? https://github.com/JetBrains/kotlin/releases/tag/v2.1.21
e
it's downloading a binary from releases
maybe it's ok if the URL is hard-coded but you can't check what the latest release is
a
yeah, I think that's fine. Gradle just needs to download the metadata files and the artifacts via Ivy repository patterns. No need for API calls.
e
does GMM work in Ivy repos? I thought it didn't
a
I think so, at least I've got it working locally.
Copy code
ivy(file("../demo-lib/github-release-files")) {
      name = "DemoLibReleaseFiles"
      patternLayout {
        setM2compatible(true)
        artifact("[organisation]/releases/download/v[revision]/[module]-[revision].[ext]")
      }
      metadataSources {
        gradleMetadata()
      }
    }
v
Sure, why should it not work?
If you publish with Gradle to an Ivy repository, you also get the GMM-redirect-comment in the ivy.xml, that you get in the POM when you publish to a Maven repository
Ah, one of the few use-cases where a manual 
artifact(...)
call in the publication is appropriate. If you use an 
Ivy
repository to publish to, but want to also add the POM file.
Copy code
val java by components.getting
val maven by publications.creating(MavenPublication::class) {
    from(java)
}
val ivy by publications.creating(IvyPublication::class) {
    from(java)
    val generatePomFileForMavenPublication by tasks.existing
    artifact(generatePomFileForMavenPublication)
}
repositories {
    ivy {
        //...
    }
}
a
anyway, back to my original question about converting. At least some of it is simple: the group/name/version can be easily converted from GMM to POM equivalents. It's a bit trickier with converting the dependencies, because Gradle's graph/dependency resolution algorithm is quite complicated and afaik there's no standalone version. But I would expect limiting it to JVM dependencies would make it easier. I suppose it would just be a case of reading the GMM file and only converting variants with a 
org.gradle.usage
of 
java-runtime
or 
java-api
, and converting them to dependencies with a 
<scope>
of 
runtime
or 
compile
respectively. Maybe determining the versions gets complicated if there are constraints? What else could make it complicated?
v
back to my original backquestion, what ist he use-case? Why can't you right away let Gradle generate the POM file togehter with the GMM file, why do you need to convert it?
a
> I think so, at least I've got it working locally. Hmm scratch that, it only seems to work for local directories, and not for remote files. Gradle fails with 
Could not resolve all files for configuration. [...] Cannot locate module version for non-maven layout
2 Views
Open in Slack
PreviousNext
Powered by