I wrote a post about the tragedy of a #Gradle build classpath, with some tips on how to build a better Plugin www.liutikas.net/2025/02/07/T... This was inspired by @autonomousapps.bsky.social's post "When POM files lie" dev.to/autonomousap... - ThreadSky

About ThreadSky

liutikas.net • 19 days ago

I wrote a post about the tragedy of a #Gradle build classpath, with some tips on how to build a better Plugin

https://www.liutikas.net/2025/02/07/Tragedy-Of-Build-Classpath.html

This was inspired by @autonomousapps.bsky.social's post "When POM files lie" https://dev.to/autonomousapps/this-is-why-we-cant-have-nice-things-when-pom-files-lie-3lm5

Comments

mbonnin.net•18 days ago

bitspittle.bsky.social•17 days ago

I was wondering if a pattern we should be recommending for all gradle plugins is to create two modules per plugin -- the API module and the implementation one?

liutikas.net•17 days ago

I think it could be a good approach to have two compile vs runtime different jars for the plugin. Sadly, it is not something Gradle supports at the moment.

bitspittle.bsky.social•17 days ago

I was thinking maybe the impl module could be a minimized fat jar and the API module would have the impl module as its only dependency. We'd then avoid those same library / different version conflicts?

liutikas.net•17 days ago

How would that help version conflicts? Wouldn't runtime still have all of the dependencies of all plugins?

bitspittle.bsky.social•17 days ago

I thought making it a fat jar would sidestep that? Maybe fat jar + relocation?

I guess what I really want is for each plug-in to get its own isolated classpath.

liutikas.net•17 days ago

It doesn't really work with isolated class loaders as plugins interact with each other. E.g. Kotlin Gradle plugin and Android Gradle Plugin expose hooks and connect things together.

Posting Rules

Be respectful to others
No spam or self-promotion
Stay on topic
Follow Bluesky's terms of service

Comments

Posting Rules

Reply