This message was deleted.
# plugin-developments
Slackbot
10/25/2022, 10:23 PMThis message was deleted.
c
Clayton Walker
10/25/2022, 10:24 PMWe have a plugin that is applied, wrapped in a
Copy code
rootProject.pluginManager.apply(OurPlugin::class)Clayton Walker
10/25/2022, 10:24 PMAnd a guard in the project
Copy code
require(target == target.rootProject)Clayton Walker
10/25/2022, 10:26 PMFrom what I can tell its similar to this issue, https://stackoverflow.com/questions/29807622/gradle-artifactory-plugin-saying-cannot-cast-object-org-jfrog-gradle-plugin-ar but I’m not sure how it happens. We’re not using buildscript, but we’re still getting our plugin loaded in different classloaders?
c
Chris Lee
10/25/2022, 11:03 PMApply is idempotent, Gradle won’t apply the same plug-in class more than once. What does the extension registration code look like?
Chris Lee
10/25/2022, 11:04 PMPossibly some classloader fun. How do the sub projects get the plug-in class?
c
Clayton Walker
10/25/2022, 11:07 PMThat’s what I’m seeing. Unfortunately it is apply the plugin more than once
c
Chris Lee
10/25/2022, 11:09 PMIt will due to classloader - each sub project has a different class instance, tricking the root project into loading the plug-in multiple times. What is the intent here - perhaps there’s a different way to accomplish it.
c
Clayton Walker
10/25/2022, 11:10 PMif one of the plugins in the chain is applied false in the root build gradle, then it seems fine.
c
Chris Lee
10/25/2022, 11:23 PMusing the plugin-id will sidestep this as well.
c
Clayton Walker
10/25/2022, 11:26 PMnot sure the plugin-id would prevent the extension from being loaded in two separate classloaders tho, right?
c
Chris Lee
10/25/2022, 11:27 PMit would force the root project to load the class itself, not use the class provided by the subproject, at which point it would realize the plugin has already been applied. In theory. May be worth reviewing what the overall goal is here, perhaps a more robust approach is possible.
v
Vampire
10/26/2022, 7:29 AMIt would probably be better to just omit the wrapper plugin that applies the real plugin to the root project. Just let people apply the plugin to the root project. Latest when project isolation comes your approach will probably fail, but such cross-project configurations are questionable now already too.
c
Clayton Walker
10/26/2022, 4:09 PMThanks for the input! Basic idea is we have ‘application’ or ‘library’ plugins that each have their own set of defaults for our company. We’d like to aggregate results from these plugins by reporting at the end of the build. For that we’d like to apply a plugin to the root that would make a ‘global’ extension available to all sub-projects.
Clayton Walker
10/26/2022, 4:10 PMFrom what I’m hearing, it might make more sense to require our ‘notify’ plugin to be applied in root, and then in subprojects check to see if the extension is registered and fail gracefully (or warn) if not.
c
Chris Lee
10/26/2022, 4:12 PMsounds good. if you are doing this to aggregate information a shared BuildService may also be appropriate, instead of depending on cross-project dependencies.
c
Clayton Walker
10/26/2022, 4:12 PMAh! That might be a good route.
Clayton Walker
10/26/2022, 4:13 PMPerhaps even output files that represent the build output, then collect that output similar to how normal gradle tasks handle input/output
c
Chris Lee
10/26/2022, 4:15 PMlikely no need to round-trip info through files - call a BuildService method with the info to aggregate and then summarize/output at the right spot.
c
Clayton Walker
10/26/2022, 4:17 PMWould a buildservice still have a problem with being registered in a subproject? Our would we expect the ‘root’ project to be applied?
v
Vampire
10/26/2022, 4:17 PMYou can register it anywhere
Vampire
10/26/2022, 4:18 PMI'd also say that's the way to go