Is there a way to isolate the classpath of a thirdparty plugin?

afaik, no, you could fork your own jvm for the majority of the work, but the closest you're going to come otherwise is shading your jars to avoid conflicts

The plugin can do to some extend isolate the work it is doing by using the worker API or by doing manual classpath isolation stuff, if you search for this topic here, you should find some recent references to how some projects do it.

right, I'm running into this issue specifically https://github.com/dependency-check/DependencyCheck/issues/3213

hmm... I mean honestly I let github do my security scanning for me along with the help of gradles github action dependency publishing stuff for that. Also about to publish a blog post on auto upgrading dependencies

we're on bitbucket and run the checks on jenkins

ah... no help for that 😉

Also if you have corporate projects, you cannot use GHA or similar, and if you want the results in SonarQube, you also need to run that plugin

although there is other 3rd party tooling. Again... you might run it outside of gradle

they've recently also quit paying for automatic security scans (as part of some service that eludes me :P)

Also if you have corporate projects, you cannot use GHA

? how so... would dependabot stop working?

So yeah, the plugin probably needs to be adapted to use the worker API with classloader isolation (which currently has a leak in Gradle) or process isolation. I don't think you can isolate it without touching the plugin code as you asked in that issue. Only if you do not use the plugin but an own that does call the tool yourself, so practically an own plugin

yeah, that gave me enough ideas to work around it, thanks

? how so... would dependabot stop working?

Yes, sure, if you don't use GitHub. Besides that you might want that exact report by that plugin, or want the data in SonarQube. 🙂

> Yes, sure, if you don't use GitHub. tangent, right but capital one is a huge corporate project and we use github... (not with actions though) doesn't help bernard but as a response to > Also if you have corporate projects, you cannot use GHA maybe you left a word out 😉

Unfortunately there are a number of Gradle plugins that are guilty of pulling in too many dependencies. Most of them can be rewritten to use classpath-isolated workers, but it takes time. Plugins that introduce "fancy" can be at fault two, because services cannot use isolated classpaths. The responsibility lies with the plugin author to think about what they are doing.

Anything a little bit of it is the fault of great old week as Gradle doesn't really document doing that... Like point me to the plug-in documentation where it says loudly that you should consider using delegating to a worker. It's also gradle's fault that they have dependencies that they have decided to shade and make internal so we can't use them either. It's definitely greater's fault that they haven't migrated to jpms yet in order to force the people aren't accidentally ending up with packages that conflict. I wonder how well the worker solution works if you're doing something that needs to work during configuration. So to say that this problem is entirely the fault of the author is a bit much. That of course doesn't mean the author has no responsibility. I would fix education first though which means the Gradle docs should get updated to make this problem and solution prominent. (And to be honest it's Java's fault that jpms decided not to make it so that multiple versions of a library could be on the module path at the same time separated by version alone, it'd be nice if more libraries were like Apache Commons and put it in their package name even if Java doesn't like that)

I wonder how well the worker solution works if you're doing something that needs to work during configuration.

Worker will not, but there you could for example use

javaExec

or if separate process is too much overhead maybe do some classpath isolation yourself. 🤷‍♂️

Fair enough. I'm just waking up but you are correct that is a solution to do a full fork and exit.

Sometimes even worker-api isolation even with process isolation is not enough. If you for example have something that overuses static state like SpotBugs which seems to not really be designed to run "as lib" inside some other program repeatedly. Some years ago the situation was, the if I run SpotBugs in one project, and then run it in a completey different project but in the same Gradle daemon, the first run influenced the second run as things were stored in static state. In the end iirc they used the worker api to achieve parallel execution, but in the worker action additionally use

javaExec

to get the necessary isolation.

I really wish people would stop using mutable static state. You know what really gets my goat? That spring MVC and spring security both have their own static internal States that they mutate. I keep sitting here wondering why they don't use spring core to make those beans instead... 😔

That SpotBugs state is not mutable, that's part of the problem. 😄 It looks up stuff depending on what you have configured and puts that to some static state. The next build will then reuse that state even if the configuration is different. Something like that. That's why even process isolation was not enough. With using it multiple times concurrently in one JVM it would of course even be worse even if the state would get updated.

You keep saying that it put stuff into a static state but that sounds like it mutated the static State at some point. I would argue that a lazy loaded flyweight Singleton is still mutating a state.