When inspecting the dummy configurations task dependencies, it knows it is supposed to run the generateMdkJar task from our project, but it just never runs it during the resolve. Am I missing something that would trigger that? Or is that simply not possible?

Please do not split topics across several threads. This makes following the conversation in the threads view very hard as the context of the other messages is missing. If you have additional information either edit the original message or post to its thread. Regarding the problem, can you maybe provide an MCVE that demoes the situation?

Sure sorry I will keep it to one message. And yes I can provide you with a minimal viable reproduction, but the plugin is not small so it will take me a bit to build.

putting the message in the thread, but then also sending to channel kind of defeats the purpose, no? 😉

It does. I forgot that if you do not uncheck the damn checkbox in slack it does not do that

oh, it remembers that state, I wasn't even aware 😱 that's quite annoying indeed

Here you go: <https://github.com/marchermans/config-included-build-reproduction> Simply running the Targetbuild task from the project root indicates our problem. The target project here needs some information from a jar that is generated by a task in the master project. The dependency is properly resolved as can be seen from the outputted error message (FileNotFoundException targetting the normal location where the .jar file would be generated in the build/libs directory of the master project). But the task that actually generates it, is not ran.

Did you maybe forget to commit and / or push?

No

There is no

includeBuild

anywhere. There are three builds that are not interconnected. If I go to

target

and do

build

it only does

buildEnvironment

.

I am not sure why it did that

you're eagerly resolving the artifact during the configuration phase:

$ ./gradlew :target:build --dry-run --stacktrace 

> Configure project :target
Resolved greeting artifact to: /usr/local/git/github/thirdparty/config-included-build-reproduction/master/build/libs/greeting.jar

Yes on purpose

I'm trying to wrap my head around this setup. My instinct is that you should probably not publish this metadata as a jar, but I'm not certain I've fully grasped the problem just yet, so bear with me 🙂

When we originally envisioned that we did not have much of an other option

Why does `plugin`have to declare a dependency for

target

and resolve it? Can't

plugin

simply depend on

master

?

Because in reality the thing the json defines is a decompiler structure

so just to clarify in my head: the json file is the recipe for a toolkit capable of building plugins using your MDK, right?

Yes

I think it would make sense to build a plugin tightly coupled to your mdk and just release it alongside

But that would tie a given plugin version hardcoded to a given mdk right?

you could even make a settings plugin that wraps both your MDK and the related plugin and configures both in one of those plugin projects of your users

Hmm

the settings plugin would manage both the mdk dependencies and the toolkit that's capable of building a plugin using that mdk version

Okey, but how would that circumvent me needing to download the configuration for the tasks?

it's baked into the plugin at build time?

So I would need to publish a hardcoded plugin for every build we do....

you could do dynamic resolution in your settings plugin, I suppose, which would indeed shift the build over to an earlier phase, if I'm not mistaken

But that then again would not really work would it

I'm not sure, to be honest. It's a bit too abstract to keep the full picture in my head. I would probably give it a try by creating a settings plugin that does the work of your current

TargetExtension

while also configuring the project dependency to a specific MDK (which would be part of the settings plugin configuration). That way the build of your settings plugin is still independent of the specific MDK (given the recipe doesn't change), but you get resolution of the recipe at application time of the settings plugin.

I will try