https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# plugin-development
s
This message was deleted.
c
it should be there if the dependency is 
implementation
or 
api
. 
compileOnly
would not be there and would result in what you are seeing.
k
I am declaring them as 
implementation
, which is why it is so baffling.
v
And how do you apply it? Do you publish it somewhere first? It do you use an included build or 
buildSrc
? Can you show an MCVE that shows the problem?
k
The plugin is (an included build in) its own repo, published to a (private) binary artifact repository. Then the Plugins API is used to apply the plugin.
c
hmmm. it shouldn’t really be both an included build and published. which is it?
k
The plugin is in its own repo, different from the repo containing the project it is being applied to. So as far as the project is aware, it's just a plain old binary package.
The only use of included builds is a detail internal to the repo where the plugin sources are present.
c
perhaps check the published plugin pom / module.json to see if the dependencies are as expected.
also, as @Vampire noted, how you apply it is important. Is it applied in a 
plugins
block or otherwise? Are you referencing it in 
buildscript
?
k
Plugins block only.
c
ok. that’s fine, it should pull in any deps. check the published pom/module.json to ensure deps are listed there.
k
They are listed as 
runtime
in the pom, which is probably the issue.
(Also, running 7.6.1, for the record. If anything changed since then, please let me know.)
c
runtime
is fine, it pulls in those deps to execute it. Doesn’t look like the issue is there. Perhaps there are conflicting libraries between plugins, that can cause ClassNotFound errors. Run a build scan, check the build dependencies, ensure the deps you expect are there at the right version.
k
Unfortunately, build scans are unavailable for me, and this third-party library isn't used anywhere else.
c
huh. There may be other ways of grabbing that info - check out the gradle dependency tasks, you are looking to target the build classpath configuration.
k
It looks like the issue may be in the project the plugin is being applied to, then. Not sure how I can look at the buildscript classpath while the project is in a state where running 
buildEnvironment
would fail. If it makes any difference, I do see this in cases where 
apply(false)
is present and not present in the 
plugins
block.
c
yep. that’s a common cause. apply(false) loads the plugin into the classpath, but doesn’t apply it. if there are multiple subprojects there’s a bunch of classloaders, which can lead to this kind of issue.
k
I see it where 
apply(false)
isn't present as well.
c
if it’s a multi-module project all it takes is one module on that project to trip into this.
its cleanest to avoid apply(false), but if you must, do that on the root project only.
k
It is being applied to the root module of a multi-module project, so I'm not entirely sure of its relevance, but it is true that for the project being applied, the 
apply(false)
is usually present due to its necessity in a supporting script plugin, which does raise this issue. If it's down to that, then it would make sense.
(Currently in an effort to rid the target project of all non-precompiled scripts.)
Odd. Even after moving all the relevant parts to the main 
build.gradle.kts
so that I can apply the plugin without using 
apply(false)
, the problem persists in that the third-party library is still not present in the buildscript classpath. Would the project structure of the plugin repo be a factor? I have, in the plugin repo
Copy code
root/
  library/
    settings.gradle.kts
  plugin/
    settings.gradle.kts
build.gradle.kts
settings.gradle.kts
The 
plugin/settings.gradle.kts
does have 
includeBuild("../library")
, and the root 
settings.gradle.kts
has 
includeBuild("library")
pointing to the same place, mainly so that 
library
and 
plugin
are built and published together.
After a bit more hacking, I did find that, when 
buildEnvironment
can run properly, I get this:
Copy code
+--- my-plugin:my-plugin.gradle-plugin:1.0.0
|    \--- com.mycom:my-plugin:1.0.0
and nothing else - no reference to the library that was declared as 
api
or 
implementation
in the plugin's own 
build.gradle.kts
. That seems odd.
c
If your plugin is doing an includeBuild on the library then the lib isn’t published with it. Is the lib published separately?
k
Yes
If I run 
:publish
in my plugin repo, then both the library and the plugin is published. ie.
Copy code
tasks.register("publish") {
  dependsOn(gradle.includedBuild("library").task(":publish"))
  dependsOn(gradle.includedBuild("plugin").task(":publish"))
}
is in my root build file.
c
and what does the dependency declaration for the library look like?
k
Copy code
dependencies {
  implementation("com.mycom:my-library")
}
No version specified, though that shouldn't be relevant - I see this issue if this was a public third-party dependency like Guava as well.
c
Hmmm. In the POM for the plugin does it then omit the version for the dependent library?
k
Version included (it's being controlled by an internal-use platform, but the internal use platform shows up as "unspecified")
c
Odd. All generally looks OK, right up until the 
buildEnvironment
that shows that things clearly aren’t right. Are you able to further boil this down to a simple reproducer?
k
It might take a bit, but sure.
👍 1
Not sure if this will work, but here goes: I have three included builds in this project - 
library
, 
plugin
, and 
smoke
. Running 
:smoke:buildEnvironment
shows that 
library
and the external dep (Guava) shows up normally, but if I were to publish 
library
and 
plugin
, and have a different project apply 
plugin
, then 
library
and the external dep disappears. I'm still missing the information about publishing externally, of course.
buildscript-cp-reproducer.zip
v
I'm on mobile so cannot check the reproducer right now. But you said you checked the POM. But the POM is not really relevant. I assume GMM is published too, so the POM content is irrelevant and you should check the GMM file.
k
I also did that, there were a few things that raised eyebrows, but didn't know what to look for to confirm my suspicions.
v
Can you show it?
k
Not much to see, but I did notice that I have something like
Copy code
"variants" [{
  "name": "apiElements",
  "attributes": {...},
  "files": [...],
}, {
  "name": "runtimeElements",
  "attributes": {...},
  "dependencies": [{
    "group": "com.kelvSYC",
    "module": "my-library",
    "version": {
      "requires": "1.0.0"
    }
  }],
  "files": [{ ... }]
}]
Nothing out of the ordinary other than something appearing as 
apiElements
because it was declared as an 
api
dependency. And nothing to suggest that applying in shouldn't bring its dependencies into the buildscript classpath.
c
is it possible that, where the plugin is applied, there is also an includeBuild for the library (possibly the same one) referencing an invalid relative path, resulting in it “not existing”?
k
No, the plugin is applied to a different repo, which does not have an include build declaration for the plugin repo. I did notice in the POMs and Gradle Module Metadata that I have this:
Copy code
"dependencies": [{
  "group": "com.kelvSYC.internal",
  "module": "platform",
  "version": {
    "requires": "unspecified"
  },
  "attributes": {
    "org.gradle.category": "platform"
  },
  "endorseStrictVersions": true
}]
ie. traces of an internal-use-only platform used by the plugin repo to align versions. But I thought of it as being irrelevant.
c
hmmm. it’s concerning. should exclude that platform from publishing if its intended to be for internal use.
k
Would the inability to resolve this platform dependency (which is never published) inhibit it from picking up other dependencies (which are later entries in the list)?
c
not entirely sure. published platforms are encoded into the GMM data, so its effectively distributed, but in an odd state.
k
I'm thinking that maybe I have to apply the workaround suggested in https://github.com/gradle/gradle/issues/10861 even for defensive purposes.
👍 1
After testing this a bit, there is some credence to believe the issue that I saw was caused by this internal-only platform being part of the published Gradle Module Metadata, in that the inability to process it means that everything down the list, including the desired transitive dependencies, was effectively ignored and skipped over. Probably Gradle working as designed, but definitely a gotcha for people intending to use internal-only platforms.
👍 1
3 Views
Open in Slack
PreviousNext
Powered by