Hi,
I’d like to ask for some advise regarding the following problem I’m trying to solve in Gradle.
We have a proprietary Gradle plugin which adds certain native compiliation functionality to a single project. Such projects, which have this plugin applied, have a configuration for the produced binaries as well as another configuration for the binaries’ compilation output. Other projects can depend on these native projects in turn and consume their native binary artifacts.
When publishing a project which has other native projects as dependencies, I’d like to be able to somehow publish the compilation output artifacts for all the projects on which this project depends on.
Ideally though, I’d like to collect all these relevant compilation output artifacts into a single artifact and publish that. The benefit to me with this kind of solution is that I can create a package per application containing all compilation output relevant for that applciation (as opposed to let’s say publishing every native artifact’s compilation output separately which would be difficult to keep track of).
I’m thinking about creating a BuildService into which the plugin which adds native compilation functionality registers its compilation output artifacts and then creating a new plugin which is appied to the leaf project which gets all the registered artifacts from the BuildService and creates a task to package them all in a single artifact as well as a publication to publish them.
When trying naively to register configurations with such a BuildService and then to read them in a different context, Gradle is reporting a “Resolution of the configuration x was attempted from a context different than the project context” warning. So I’m not sure I’m on the right track with this.
This seems a bit involved. Any ideas, suggestions and such would be much appreciated.
Thanks a lot.
I’m not doing native, but what you describe sounds like in the Java world creating a bad-practice fat JAR and publishing that, which is practically never a good idea.
Why would it be difficult if each project publishes its compilation output?
As long as you publish them as proper variants with identifiable attribute set, it should not be a problem to consume them in bulk.
If those variants also have the necessary dependencies declared, you can use a configuration that requests the according attributes and get the according variant of the projects.
Or if not having the dependencies declared on those variants (like how it is for the sources variant in Java land), you can still use an artifact view to get the proper variant for all those projects.
I’ve migrated my plugins to use variants which was very interesting and I’ve upgraded my project to use Gradle 8.14 which includes artifact views.
Now, I’m trying the following:
> The consumer was configured to find attribute 'org.gradle.category' with value 'library', attribute 'org.gradle.usage' with value 'zos-native'. There are several available matching variants of project :model9-zos:model9-zos-jvm-launcher
The only attribute distinguishing these variants is 'org.gradle.libraryelements'. Add this attribute to the consumer's configuration to resolve the ambiguity:
- Value: 'loadModules' selects variant: 'loadModules'
- Value: 'loadModulesListings' selects variant: 'loadModulesListings'
- Value: 'macros' selects variant: 'macros'
- Value: 'objects' selects variant: 'objects'
- Value: 'objectsListings' selects variant: 'objectsListings'
This is expected.
But when I uncomment the last attribute which should distinguish the required variant, the task fails due to:
Unable to find a variant with the requested capabilities: []:
I’m creating the configuration as:
val packageRemote = configurations.create("packageRemote")
Just doing configurations.create actually (for backwards compatibility reasons) creates a configuration with legacy setup, you should either set isResolvable to false, or right away use the convenience helper configurations.consumable(...).
But that’s just a side-note and should not cause the problem.
From what you provided I don’t see what the problem might be.
What is the full error message?
And what does :theProducerProject:outgoingVariants task display?
And I’m afraid that’s most of the error message. Here it is with part of the stacktrace:
Could not determine the dependencies of task ':model9-acd:model9-agent-package:resolveSources'.
> Could not resolve all dependencies for configuration ':model9-acd:model9-agent-package:packageRemote'.
> Unable to find a variant with the requested capabilities: []:
* Try:
> Review the variant matching algorithm at https://docs.gradle.org/8.14/userguide/variant_attributes.html#sec:abm_algorithm.
> Run with --info or --debug option to get more log output.
> Get more help at https://help.gradle.org.
* Exception is:
org.gradle.api.internal.tasks.TaskDependencyResolveException: Could not determine the dependencies of task ':model9-acd:model9-agent-package:resolveSources'.
at org.gradle.api.internal.tasks.CachingTaskDependencyResolveContext.getDependencies(CachingTaskDependencyResolveContext.java:70)
at org.gradle.execution.plan.TaskDependencyResolver.resolveDependenciesFor(TaskDependencyResolver.java:49)
at org.gradle.execution.plan.LocalTaskNode.getDependencies(LocalTaskNode.java:151)
at org.gradle.execution.plan.LocalTaskNode.resolveDependencies(LocalTaskNode.java:125)
at org.gradle.execution.plan.DefaultExecutionPlan.discoverNodeRelationships(DefaultExecutionPlan.java:182)
at org.gradle.execution.plan.DefaultExecutionPlan.doAddEntryNodes(DefaultExecutionPlan.java:154)
at org.gradle.execution.plan.DefaultExecutionPlan.addEntryTasks(DefaultExecutionPlan.java:129)
at org.gradle.execution.plan.DefaultExecutionPlan.addEntryTasks(DefaultExecutionPlan.java:121)
at org.gradle.execution.TaskNameResolvingBuildTaskScheduler.scheduleRequestedTasks(TaskNameResolvingBuildTaskScheduler.java:61)
at org.gradle.execution.DefaultTasksBuildTaskScheduler.scheduleRequestedTasks(DefaultTasksBuildTaskScheduler.java:72)
at org.gradle.initialization.DefaultTaskExecutionPreparer.lambda$scheduleRequestedTasks$0(DefaultTaskExecutionPreparer.java:48)