One way would be to write the result of A to a file and have it as output file.
Then have an input file in B that gets the output of A wired and can take the result from there.
This is for example helpful if A is expensive and can be cached or can be up-to-date.
If A anyway always needs to run and cannot be up-to-date, then you could e.g. have a Provider<GitInfo> in A that you wire to a Property<GitInfo> in B.
Another way would be to use s shared build service that holds the state that should be shared.
Thank you very much Björn for taking the time to read my post an suggest this options !
The file solution does not feel right in my case, because the calculations are very light weighted and don’t need to be cached.
I read about Providers before, do you have a simple example for that ? I’m only worked with providers
using for example:
abstract Property<String> getProperty()
in my own Tasks which extend DefaultTask.
I dont know how to wire something from taskA to taskB.
My first thought was, that I need somethin like:
in TaskA and then have something like this in TaskB:
I would wire them like my other properties in my plugin where I create these tasks.
But there is nothing like “@Output” … all default outputs are based on files.
Could you clarify or provide a weblink to an example maybe ?
It will not be “output”, as only file-based outputs are supported as you recongized.
But the outputs are only for up-to-date checks and caching anyway.
So if you don’t have inputs / outputs for your taskA, it will always be executed.
So it probably needs @Internal.
For taskB, if it should count as input, you would annotate the properties of GitInfo with according input annotations and annotate the property with @Nested.
But while thinking about it, if this is something you are going to publish, you should maybe consider using the third option instead, unless you really want the users of those tasks to be able to set those values too.
Or you call disallowChanges() after you wired them, but it might still be confusing then to have them in the API.
If this is just private for your build, it probably doesn’t matter much.
I implemented the build-service ! You were right. It fits like “Deckel aufm Topf” perfect solution ! I don’t even need the “GetGitInfo” task anymore, because the service is far more well suited for this.
Now my other tasks, simply get the needed information by this service and it looks much cleaner.
Many thanks for sharing your precious time to help a gradle newbie