#general
- b
bored-art-40741
10/05/2015, 4:40 PMI'd also be very wary of doing it in the current engine - b
bored-art-40741
10/05/2015, 4:41 PMOur products aren't tight enough in general to risk silent fingerprint thrash - w
witty-crayon-22786
10/05/2015, 4:44 PM@bored-art-40741: the alternative is silent correctness thrash. - w
witty-crayon-22786
10/05/2015, 4:44 PMor some other solution - f
fancy-queen-20734
10/05/2015, 4:44 PM@witty-crayon-22786: when you said that my fix didn’t affect jar-create, bundle, do you mean that a bundle will end up with the wrong classes in it? My impression was that the classes that end up in the bundle was dependent on the classes generated by the compile task—which would use the fingerprint. - w
witty-crayon-22786
10/05/2015, 4:45 PM@fancy-queen-20734: yes, wrong classes.
hits the cache independently ofjar-createcompile.jvm - w
witty-crayon-22786
10/05/2015, 4:46 PM@bored-art-40741: we'd need to have task fingerprints strategies be transitive - w
witty-crayon-22786
10/05/2015, 4:46 PMvery messy. - w
witty-crayon-22786
10/05/2015, 4:46 PMand i think much, much easier to hash inputs. - f
fancy-queen-20734
10/05/2015, 4:47 PMis this before or after removing classes_by_target? Or both - w
witty-crayon-22786
10/05/2015, 4:47 PMi don't know what the deterministic fingerprinting before products actually buys us... because 9/10 we don't do it then. we do it lazily. - w
witty-crayon-22786
10/05/2015, 4:47 PMand in fact, in the jvm_compile case we are explicitly hashing products because we must - w
witty-crayon-22786
10/05/2015, 4:47 PMi don't think it's a thing, sorry. - w
witty-crayon-22786
10/05/2015, 4:48 PM@fancy-queen-20734: independent... was just thinking about it over the weekend - b
bored-art-40741
10/05/2015, 4:48 PMThe entire point of the refactor was to have a deterministic task/target/config graph that could be cache-checked and scheduled before we ever invoked a tool - f
fancy-queen-20734
10/05/2015, 4:48 PMI’m not sure how jar-create hits the compile.jvm cache independently. Could you lay out a scenario for me? - b
bored-art-40741
10/05/2015, 4:49 PMI think the alternative here is to fingerprint input products and optionally double check/invalidate/raise an error if they weren't deterministically produced - w
witty-crayon-22786
10/05/2015, 4:49 PM@fancy-queen-20734: jar-create has its own cache key that has nothing to do with compile.jvm - w
witty-crayon-22786
10/05/2015, 4:49 PMcompile.jvm hits the cache with one key - w
witty-crayon-22786
10/05/2015, 4:49 PMputs classes on disk - w
witty-crayon-22786
10/05/2015, 4:49 PMjar-create hits the cache with a different key - w
witty-crayon-22786
10/05/2015, 4:49 PMputs different jars on disk - b
bored-art-40741
10/05/2015, 4:50 PMI think this problem is fairly unique to ivy resolution being pseudo-global but not actually treated like it - b
bored-art-40741
10/05/2015, 4:50 PMIf the transitive closure of your jar libraries lead to a deterministic resolution of classpath jar products, then the fingerprint strategy would already invalidate correctly - w
witty-crayon-22786
10/05/2015, 4:52 PMand be incorrect - w
witty-crayon-22786
10/05/2015, 4:52 PM...unless you can choose a global unambiguous classpath - w
witty-crayon-22786
10/05/2015, 4:53 PMbut the current behaviour of ivy is actually a feature - w
witty-crayon-22786
10/05/2015, 4:53 PMand i'm very interested in keeping it. - w
witty-crayon-22786
10/05/2015, 4:54 PMbut i'd like to know what we're actually losing. - b
bored-art-40741
10/05/2015, 4:54 PMHere's the reason I don't think that the product inputs should in general be rolled into a task's fingerprints: Imagine you have tasks C -> B -> A (read C depends on B depends on A) through some product, the name of which is unimportant. Now imagine that C is already happily in your artifact cache, it doesn't need to be recomputed. But A and B are not cached are very expensive to recompute. Now you have to recompute A and B just to find that C was done all along.