This message was deleted.

ext

is practically always bad practice and you should feel dirty every tiem you use it. 😉 And yes it does, especially when changing versions. Because if you have the versions in code, it needs to be recompiled and classpaths change and thus also make things out-of-date that shouldn't be. With version catalog (if defined a TOML that is) the build logic stays the same and only the things where really something changed due to the different version has to be re-executed.

assuming I use configuration caching or not?

Either way

alright great, time to migrate then

alright great, time to migrate then

Not that you got me wrong, CC will not be reused if the TOML changes. But you still save time for the actual configuration that is necessary then.

I have a new project where I added the version in the toml, and subjectively gradle sync times & configuration feels snappy granted my other project with the ext, is 100x the size 😀 so wondering if there are perf gains other than using a standard way of doing things

As I said, at least when changing a version and not changing other build logic, definitvely, especially in more complex builds.

the constants are mostly different api urls based on build variant (different environments) so I found it simple enough to chuck it into a map in a ext

Often it is simple use

ext

but that does not make it any cleaner. 😄 It is usually just a work-around for not making it in some proper way. Or as I said, often even an even simpler local variable would be more appropriate, but ill examples are out there.

yea the constant needs to be available to 3 apps in the build

Might also be a sign that the according logic should instead go into a convention plugin, then you only need the constant there. 🙂

honestly I never understood this suggestion, conv. plugins sure are nice, but are a pain to develop, pain to use locally without uploaing to maven therefore I now need a composite build, which is slower isnt it a overkill?

composite build is trivial to setup, and only built when it changes, so no perf impacts other than when modifying that build. Creating a precompiled script plugin in there is likewise trivial, it’s exposed to your main build w/o requiring maven etc.

how do I distribute the precompiled plugin without maven?

if its in a composite build you don’t need to do anything.

are composite builds really same speed? I read some blogpost some time ago..

it’s all cached - assuming minimal/infrequent changes to plugins etc theres no perf impact.

I mean clean build yea

yea, but who ever really does a clean build locally? That’s a crutch for misconfigured build scripts etc that should properly manage their inputs and outputs.

well.. yea, but its the reality

We live in the reality too and I always use convention plugins in included builds.

ksp breaks config cache every other release.. cant even have that turned on

I even do that for single-project builds

and you disrribute it via internal maven?

No distribution, I said included build

no, its a composite build included in your main build.

Just locally in that build

interesting, guess I have to measure my assumptions

Docs on composite builds w/ plugin

If you do clean builds, then you will have negative impact, yes. But just don't do clean builds, but fix the build that requires it instead, this is not Maven where you always need to include

clean

to get halfway correct builds. 😄

ah, Maven, have almost managed to erase that experience from my memory…

I always managed to avoid it, except when contributing somewhere.

yep, pretty much same here. 🙂