https://gradle.com/ logo
Join Slack
Powered by
Morning everybody. Is there a good replacement fo...
# plugin-development
m
Morning everybody. Is there a good replacement for whenObjectAdded on a dependency set that works with dependency collectors?
v
Please take a step back and describe the use-case you have that you try to solve.
m
I need to register a task when the user adds a specific dependency. I used to do this by attaching a whenObjectAdded listener to the configuration. Check if it is the right GAV and then add the task to the task container. This works fine, with the exception of one case: • Create DependencyCollector • Add DependencyCollector to configuration • Then add dependency to collector
The result is that the dependency added to the collector (after the registration of the collector to the configuration), are not actually added to the collector
Most likely because the provider is resolved
The reason for this, is because I need to generate the actual dependency, by patching and modifying the jar. I tried artifact transforms, but no IDE that I tried can really use those when they try for example to resolve sources. So this was currently my best attempt at mimicking the behaviour, while also being compatible with the IDEs and Gradles compile setup
I tried replacing it with a combination of configureEach and withDependencies which we do at work, and there it works reliably because we do not lazily add dependencies, (no versions toml file) but once that gets involved it gets really difficult to get properly notified when a used modifies the list
Actually in 8.7 it even crashes which I guess might be fineish.....
Allthough the JVM-Test Suite system allows adding dependencies that way
v
But that really sounds like you should use an artifact transform. If IDE really does not work properly with that, you could be really evil and check for the system property 
idea.sync.active
and in that case make an identity transform and only transform it when not syncing to IDE. But for me, it works fine. I just tried and opened a class from a transformed artifact and got the proper source displayed.
m
Are you sure? The last time I tried that, I get the default decompiled artifact shown by the IDE (Which we generate), which really does not work when debugging through it. Causing misalligned bytecode, which will get you a broken debugging environment in any IDE, because the places you put the breakpoint is not the place that works in the bytecode.
That said, I can try it again
Let me check
v
Well, you of course would get the original sources, not sources that match the bytecode if you rewrite the bytecode and especially change line numbers in the bytecode or something like that.
I just tried with an artifact where the extra module info Gradle plugin added a manifest entry to the transformed jar.
Since some versions IntelliJ does not fetch the sources by default anymore if you sync a Gradle project so save time when syncing, maybe that is what you hit? 🤷‍♂️
m
Nah I just tested. We decompile and patch the source jar then recompile the entire thing. Resulting in massive line number differences. We currently basically do this in a more or less hacky way: We create a local maven repo, relative to the project. Using whenObjectAdded / withDependencies we monitor for a dependency of our interest (it is always a top level module) and if we find it, we add our tasks to the taskcontainer (since we need to know the version that the user wants). And wire up the output of a task as a dependency to that configuration. This all works fine
And we even got it to work to the point where DependencyCollectors work
By replacing whenObjectAdded with withDependencies
And all of that works perfectly fine
But we simply don't get notified that a user added us as a dependency lazily then (when done via a version.toml file)
So we seem to be stuck between a rock and a hardplace
Where on the one hand, we can lock all DependencyCollectors in a final state as soon as they are added to any configuration Or we can not get notified when a user adds us laziliy, because grade does not resolve or notify anybody of that dependency even being added at all
And there does not seem to be any middle ground
I can't seem to support both lazy systems reliably
v
What do you mean with "both lazy systems"? A version catalog entry itself does not add any dependency to anything. Only if you use the entry. And if you use it, I think it should result in the same result than when using them in the build script directly.
2 Views
Open in Slack
PreviousNext
Powered by