This repository has been archived by the owner on Apr 25, 2019. It is now read-only.
Include kat-deps-* modification information when considering changes #16
Comments
arrdem
added a commit
that referenced
this issue
Nov 5, 2018
This patch leverages the manifest prep time across all tools.deps (eg. JVM) backed targets to run some shared initializer code in the JVM extension that reads Katamari's current global default deps.edn data sources. After that step in manifest prep, at rule prep time all the JVM manifests use the version pinning information currently somewhat magically delivered by the deps config to rewrite! their dependencies. This fixes #19 properly, by making the pinned and versioned deps part of the rule as it is content hashed for fingerprinting. A (global) version bump will now cause target(s) to become stale. Fixes #16, #19
arrdem
added a commit
that referenced
this issue
Nov 5, 2018
This patch leverages the manifest prep time across all tools.deps (eg. JVM) backed targets to run some shared initializer code in the JVM extension that reads Katamari's current global default deps.edn data sources. After that step in manifest prep, at rule prep time all the JVM manifests use the version pinning information currently somewhat magically delivered by the deps config to rewrite! their dependencies. This fixes #19 properly, by making the pinned and versioned deps part of the rule as it is content hashed for fingerprinting. A (global) version bump will now cause target(s) to become stale. Fixes #16, #19
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
At present, Katamari is quite good at sorting out what Rollfile defined targets have and haven't changed. The problem is that some state - like the deps defaults - don't come from Rollfiles. They come from these sidecar data files. Which means that I don't get change detection on them "for free".
The easy fix here is probably to import all of a project's Maven dependencies into the Rollfile target graph when initializing any
depsbacked target type. This would at least expose at the buildgraph level any changes in say the coords of a depended library. It's not ideal and it will clutter the buildgraph as well as conflate building with dependency resolution even more, but it may be the best approach.The text was updated successfully, but these errors were encountered: