Catalog generator cache does not work in gradle 7.6

[trohr]

Using gradle 7.6.4, the cacheEnabled = true declaration does not create the build/version-catalogs directory nor anything in it. Using gradle 8.8, it works.

[austinarbor]

@trohr cacheEnabled = true seems to be working fine for me with Gradle 7.6.4. Do you have a reproducer I can look at?

As an aside, can you let me know what your use case for the caching is? I am trying to determine if the feature is worth keeping around because it's a little hacky. Unfortunately Gradle does not support incremental build logic when working with settings plugins the same way it does project plugins so the logic is home grown

[trohr]

Hi. I did not prepare reproduction of the issue. When it did not work, I have upgraded gradle to 8.8 and it works there.

My use case was firstly to see what really gets generated so that I know what dependencies get created in the catalog so that I can declare their usage correctly.

Furthermore I wanted to leave the cache enabled because we use gitlab CI/CD and each task gets executed separately - and if using the cache would save a few seconds, it would be benefitial.

If you say this feature is problematic, I should heed your guideline and not use caching.

However if caching shall not be supported (as problematic or not really usefull), I would like to ask you to prepare a way to see what items are in the generated catalog. (maybe by using a separate helper task or at least logger.debug / info during the generation process.

I am trying to move away from io.spring.dependency-management plugin as it has some problems but it is so hard. Thank you for your work.

[austinarbor]

sorry, I don't think the feature is problematic , I am just doubtful of the usefulness. After the first time the catalog is fetched it will be cached in the local gradle repository, so regenerating should only be a matter of milliseconds. AFAIK, in between task invocations on the same machine should not cause the catalog to be regenerated. However, if the tasks are run on separate runners, then it would get regenerated for every task. That being said, the catalog generation process should only be in the millisecond range (after the remote BOM file is downloaded).

I agree that the ability to validate the generated catalog would be a useful feature, maybe I will build something separate for that (or repurpose the caching functionality as just a printing functionality).

For now the caching isn't going anywhere so you don't have to worry about using it - it should work as expected, let me know if you encounter any issues. If I do remove it I will try and let you know here, and I also wouldn't do so without a major version bump.

Moving away from the spring dependency management plugin was the exact reason I built this to begin with and is the perfect tool for the job - good luck!

[trohr]

AFAIK, in between task invocations on the same machine should not cause the catalog to be regenerated. However, if the tasks are run on separate runners, then it would get regenerated for every task. That being said, the catalog generation process should only be in the millisecond range (after the remote BOM file is downloaded).

Well we use the 'default' way of using Docker images for running of the Gitlab CI/CD jobs. Each job gets executed in a newly created docker container with the repo cloned there. It has also some caching functionality where the cache gets copied to the next job, but basically each job is a separate environment. 'Luckily' I have already made a cache for local gradle cache (local gradle repo). Your explanation means that I don't need to use your cache explicitly.

I agree that the ability to validate the generated catalog would be a useful feature, maybe I will build something separate for that (or repurpose the caching functionality as just a printing functionality).

For now the caching isn't going anywhere so you don't have to worry about using it - it should work as expected, let me know if you encounter any issues. If I do remove it I will try and let you know here, and I also wouldn't do so without a major version bump.

I will now continue to use the caching feature to see what gets generated and how to address it.

If you ever create some other way of debugging the generated catalogs, let me know here please and I will disable caching and adjust our usage docs.

Moving away from the spring dependency management plugin was the exact reason I built this to begin with and is the perfect tool for the job - good luck!

Thank you very much. Really.

I plan on using your plugin for the next generation of our projects (gradle 8, spring-boot 3,...). I am really glad there is someone who put the effort into integrating boms into the new way of handling dependency versions in gradle. Dependency management in gradle is hard as f**k; it ought to be improved to be easier to do correclty.

[austinarbor]

going to close this out for now, feel free to open a new issue if you experience any problems!