https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# plugin-development
s
This message was deleted.
l
Hello, If this did not get resolved since then, can you share a bit more about the plugin itself? Like its coordinates. When the Gradle plugin portal is not aware of an artifact, it fully delegates to JCenter. There is no intermediary caching. So if the artifact can be resolved against JCenter in an isolated test, something else is going on. What you describe looks a lot like a partial download in the local maven repo, which, if declared as a Gradle repo, will break things. If you want to move forward with publishing existing plugin to the portal, please reach out to plugin-portal-support@gradle.com
t
Hey, the plugin id is 
co.touchlab.skie
and it's currently in Maven Central only. I wanted to publish the plugin to the portal, but I couldn't figure out how to publish all of our artifacts to the Gradle Plugin repository, not just the plugin one. What I meant by caching was the JCenter caching or a local cache. I'm not sure which one is it and it's not really reproducible. But it has happened to many of our users, all over the globe. And they didn't have mavenLocal as a plugin repository configured, so that shouldn't be it.
Hey @Louis Jacomet, any ideas why we're seeing this behavior? Do you think that publishing into Gradle Plugin Portal will alleviate it?
l
Hey, Without understanding the root cause, I don’t think that publishing to the portal will fix what users experience unfortunately.
t
So this isn't something you experienced/got reported before? Could it be caused by having multiple artifacts while also using Gradle variants?
I'll admit that I'm struggling to think of a way to find the root cause, or even where to start. So far all our efforts to isolate it only "fixed" the issue locally so that we couldn't really find what was happening
So I did some more digging and my current hypothesis is: 1. Gradle accesses Plugin Portal 2. Plugin Portal doesn't have the artifact, so it asks JCenter which then asks Maven Central 3. For some reason the 
.pom
file artifact is returned, but the 
.module
returns 404. 4. Even though the 
.pom
file contains the 
<!-- do_not_remove: published-with-gradle-metadata -->
, Gradle ignores the fact that it couldn't find the 
.module
and resolves just the 
.pom
. 5. Because of this the variant is not resolved correctly and a basically empty (metadata) 
.jar
file is loaded on classpath Running Gradle again does nothing, because Gradle has already cached that the 
.module
doesn't exist. The only way for a user to get it working is running Gradle with 
--refresh-dependencies
. Is this an expected behavior? It seems a little weird that Gradle ignores the missing 
.module
without even a warning. Or is it some misconfiguration on our side? Thanks!
l
To be precise: when the portal does not have a file, it redirects to JCenter (which internally might ask Maven Central) What you describe is possible but should only ever happen shortly after a new release and only for a couple attempts until the file is returned. After that, no one should still see a 404. Does what I say here make sense?
Aside from that, what you share about how Gradle behaves is correct. When a POM contains the GMM redirect marker, Gradle will ignore a missing GMM file indeed. Checking if we log something in that case.
t
Yeah that makes sense but it doesn’t explain why so many people have seen the issue with various times after the release
Is there a way to force Gradle to find the .module or fail?
I tried deleting the 
.jar
file in the "root" artifact (where the 
.module
is to tell Gradle about the variants) and I'd say the error is slightly better - erroring out that it can't find the 
.jar
. Honestly it'd be best if we could force Gradle to fail when it can't find the 
.module
, because now the behavior is really weird. I also noticed that Gradle will cache the "non-existence" of even the 
.jar
artifact, so when I've put it back in the repository, it still says "not found" until I run 
--refresh-dependencies
. Is that also expected?
I also noticed in this post https://blog.gradle.org/plugins-jcenter that Gradle Plugin Portal doesn't go to JCenter directly but instead to Gradle hosted mirror of JCenter. That could be another reason for missing artifacts
l
Hey, Gradle will indeed cache 
404
. Without that, declaring multiple repositories would be a serious performance issue as Gradle would have to retry repositories where an artifact is not every time. That blog post has outdated information, the plugin portal currently redirects directly to JCenter. Regarding the setup and mandating the use of the 
module
file. You can do it, at the cost of complicating a bit the repository declaration. By combining content filtering and metadata sources, you can make sure that artifacts that you know have a 
module
file are sourced from a repo that ignores the 
pom
. Something like (did not test it):
Copy code
repositories {
    maven {
        url = uri("<https://repo.mycompany.com/repo>")
        metadataSources {
            gradleMetadata()
        }
        content {
            includeGroup("my.company")
        }
    }
    maven {
        url = uri("<https://repo.mycompany.com/repo>")
        metadataSources {
            mavenPom()
        }
        content {
            excludeGroup("my.company")
        }
    }
}
t
But that would require our users to change their settings.gradle.kts to always include:
Copy code
pluginManagement {
  repositories {
    gradlePluginPortal {
      metadataSources {
         ...
...
l
Correct
t
Yeah, that's not something we can be doing, we need to figure out something better.
Is it possible to deploy all the artifacts we need on 
classpath
to Gradle Plugin Portal?
l
Let’s have that conversation over email, I just replied to you
t
Perfect, thanks!
2 Views
Open in Slack
PreviousNext
Powered by